Super excited to have you championing this, @Beanow!
Here are some implementation thoughts:
-
We’ll want to add a new, lightweight plugin. I the Discourse plugin is a good reference case.
-
A plugin consists of a few vital pieces:
- A
declaration
(example) which provides new node and edge types. I think for now the only node type will be the Initiative node, and the edge types will includechampions
,references
,has contribution
,depends on
. - A
createGraph
method (example). This will be responsible for actually creating a new subgraph containing information from the plugin, which is then merged with other plugin graphs.
- A
-
Our existing plugins get data from an external source (e.g. Discourse, GitHub, etc). This plugin will get data from another plugin–from the Discourse plugin. We currently don’t have any mechanism for cross plugin data dependencies. Eventually we should build clean APIs to handle this, for now I’m fine with something relatively hacky that gets the job done.
-
Once we’ve figured out how to expose the Discourse mirror:
- We’ll need to update the Discourse plugin to store and provide category information. This will mean updating the fetching logic (e.g. adding category id here). Possibly we’ll want new APIs on the sqlite mirror.
- We should be able to re-use logic from Discourse Reference Detection to parse the actual links, although we’ll need to add GitHub detection as well. (Adding GitHub reference detection to Discourse will likely make sense as its own initiative; I’d be fine to see the initiatives plugin merge without GitHub support, we can add it as a followon).
- We can then have the Initiatives plugin parse all the topics within the Initiatives category, and generate an intermediate Initiatives data structure.
- We can then transform the initiatives data structure to generate the Initiatives subgraph. We should think a bit about error handling, and how to accommodate changes to the schema, or incomplete initiatives.
-
The steps above should leave us with a working initiatives plugin, so we’ll just need to configure it. We have a fair bit of technical debt in how we configure plugin information, which you can see in the fact that plugin configurations accumulate in a single hardcoded project config. Since we’re going Deep then Wide, I think it’s not yet time to pay off this debt. So we can just update the Project config to store information about whether initiatives are getting used, what their CategoryId is, etc.
-
Then we can update api/load to use the new plugin information.
-
Once we do this, we can start leveraging the initiatives system, by starting in on cred bounties. Until then, as a hack we can give initiatives a high node weight, although this won’t be quite right–we want to unlock the cred when the initiative is completed, not when it is proposed.
If you think this post is a valuable contribution towards achieving the initiative, I suggest explicitly linking to this post as “Contribution” in the overall initiative wiki. A good way to reward the work of clearly documenting the context around achieving our goals.