So far, SourceCred has tracked contributions at the level of raw activity. Here are some examples of activities we track:
- GitHub pull requests
- GitHub comments
- GitHub Reactions
- Discourse posts
- Discourse likes
The activity data has been a great starting point. Activity data is easy to collect automatically, so we can get a reasonable baseline for cred scores.
However, using activity data alone has serious issues. Valuing any individual piece of activity can be quite hard, and the activity data is so fine-grained that it’s often illegible. Also, valuing everything in terms of raw activity makes it hard for the community to decide to reward specific goals or values. For example, suppose the community wants to prioritize “usability” or “documentation”. It’s hard to express those goals by changing weights on pull requests or Discourse posts.
This post explores how we will use manually-curated “supernodes” to fix this, by creating a new, coarser-grained level of the Cred graph that’s amenable to explicit curation by the community. The first types of supernodes I have in mind are Initiatives and Artifacts.
An Initiative is a specific workstream that creates value for the project. You can think of an initiative as a flow of value.
Examples of initiatives include:
An Artifact is some durable or long-lived piece of a project. You can think of an initiative as a stock of value within the project.
Examples of artifacts include:
- SourceCred as a whole (the “meta” artifact)
- The SourceCred Discourse plugin
- The SourceCred podcast (the whole collection / long running program)
- The SourceCred whitepaper (if we ever write one)
I expect supernodes to flow cred to each other, and to individual pieces of activity. Here are some examples, focused on specific artifacts.
- Any particular podcast episode flows cred to the Podcasts artifact
- The podcasts artifact flows cred to specific contributions that helped set up the podcast
- For example, this Discourse post
- The podcasts artifact also flows cred to every individual podcast (cylical cred relationships are OK!)
- Any individual artifact flows some cred to the “Artifacts Artifact”
- The artifacts artifact flows cred to this post (for helping define it)
- This post flows cred to the Discourse artifact (because it is a Discourse post itself)
- The Discourse artifact flows cred to Discourse, the open-source project and company
- The Discourse artifact also flows cred to this initiative for adding an important feature to the Discourse plugin
Both of these examples focus on specific, concrete parts of the project. But we could also use artifacts to identify more abstract kinds of value in the project. Here are examples:
- Pull requests like #1431 which make the project more usable can be directly connected to the Usability Artifact.
- There will be a bit more judgement / subjectivity in deciding which contributions affect usability, and how strong the weights should be.
- For now, I’ll act as the arbiter if we have contentious disputes, but we’ll want to come up with a better governance mechanism before long.
- We could have a general artifact representing the SourceCred Community.
- It can be connected to other artifacts that are important to the community–e.g. the artifact representing our Discourse forum, the podcast, the website and documentation, etc.
- As with the Usability Artifact, deciding what connections should exist may be contentious.
Later on, we’ll likely build a dedicated UI for viewing and editing supernodes. However, bootstrapping on Discourse makes the initial prototyping a lot faster and easier.
Modifying Supernode Connections
For now, we’ll manually manage the supernodes’ connections by adding links to the post containing the M-node. For example, you can look at the Initiative template. It has dedicated sections for adding links to references, links to contributions, etc.
For now, anyone can edit the supernodes, adding new links, etc. As the community scales out of Trust Level 1, people may start to add spurious edges. This will be easy to detect and revert; once it’s a consistent issue, we’ll build a better permissioning model for editing those nodes.
Over time, we’ll need to develop clear policies and frameworks for assessing what contributions should be connected to supernodes, and what the strength of those connections should be. For example, both this PR adding Discourse references and this PR capitalizing the Discourse plugin name should both be connected to an artifact representing the Discourse plugin. However, they should have very different weights.
For now, I want to crowd-source the connections and weights, and in the event of controversy/disagreement I’ll step in to make a decision.
Because supernodes are much higher level, they are easier to explicitly value. For example, we could set an explicit and high Cred score that flows from a “Documentation Artifact”, so that everyone who writes documentation will earn a lot more cred.
Supernodes will also be great candidates for boosting, whereby someone can increase the (Cred) valuation of an supernode by burning some of their Grain.
Of course, like anything else in SourceCred, a lot of the value of supernodes will be derived from their connections. For example, if the “Founding SourceCred” initiative is connected strongly to the “SourceCred meta-Artifact”, then it will earn a lot of Cred, even if no one has explicitly boosted “Founding SourceCred”.
Since Cred is time-specific, there’s an open question of when supernodes should recieve cred. In the case of Initiatives, there may be a clear “completion” date, and we can have the Cred flow from the node as of that date. But for Artifacts, which may have very long lives, I’m not sure in what timestep the cred should emerge.
One of the best features Cred is that it updates retroactively. That means the community can always go back and do a better job of valuing past contributions.
In the case of SourceCred, as we build out the infrastructure for representing supernodes, I’d like us to go back through SourceCred’s history and create all of the missing initiatives and artifacts. It will be a lot of work, but it will leave us with a Cred instance that is more legible, more fair, and a much better foundation to build from as the community scales. In particular, people who have contributed via ideas, conversation, and advice are currently under-credited, because we don’t see their activity. Via supernodes, we can more directly connect people to the value they’ve contributed.
Creating all of those Initiatives and Artifacts will take some effort. Naturally, that work will itself be recognized and rewarded by SourceCred itself! Each supernode will flow some of its cred to the contributions that upkeep the supernode itself. (E.g. the work of adding new links to the supernode, refactoring supernodes, etc).
Making it Grain
Once we’ve achieved good retroactive coverage via updating past supernodes, we will have a cred distribution that is more robust and more accurate. That will be a good moment to celebrate. Once we achieve this milestone, I think we should “make it Grain” by paying out a very large amount of Grain to everyone based on their updated cred. See here for some related ideas.