What is the Creditor for?
SourceCred, at its technological core, is a system for assigning scores to contributions. For SourceCred to be able to do that, it needs data on contributions: what they were, how they relate to each other, and which ones were important.
So far, our approach has been to discover contributions by automatically importing data from platforms like GitHub, Discourse, and Discord. This has some major advantages for SourceCred. This has some big advantages, most notably that it’s easy to turn on for existing communities. However, it has some big flaws, too:
- It misses all the contributions that don’t occur on platforms
- It “becomes hard to see the forest for the trees”; interesting projects or achievements usually correspond to dozens or hundreds of individual contributions
- Because the data is overwhelming, it’s hard for humans to meaningfully review or provide feedback on what was really important
The Creditor is an attempt to fix these issues by building a flexible and powerful tool for humans to collectively improve the Cred graph. Basically, it will allow a community to review the contribution graph, add missing contributions, and organize contributions into higher-level meta-contributions that reflect what the community really cares about.
What capabilities will the Creditor have?
Some of the core functions of the Creditor include:
Adding new contributions that aren’t already recognized.
For example: suppose that someone did a great job presenting at a meetup. By default, this will go unrecognized, because we don’t have a “physical meetup” plugin.
The Creditor will solve this problem by allowing people in the community to add new contributions to the graph.
Specifying the relationships between contributions
Consider a partnership, like our partnership with MakerDAO. If the partnership goes well, we’d like to be able to flow more Cred to everyone who helped out with it. However, the partnership is successful thanks to hundreds or thousands of individual contributions: writing proposals, organizing meetings, adding requested features, et cetera. Right now, we don’t have any structure for keeping track of those relationships between contributions.
The Creditor will solve this by allowing people to specify the relationships between contributions. In general, this will mean adding new edges to the graph. As an example, we might make a “MakerDAO partnership initiative” as a new node in the graph, and then have it flow Cred to every individual contribution that helped the partnership.
Over time, that will become a bit overwhelming, so we can keep re-organizing it into smaller and smaller pieces. For example, we might have “MakerDAO: adding requested features” and “MakerDAO: trial administration” as seperate nodes, and flow Cred to both of those from the overall partnership nodes.
Determining what contributions the community finds valuable
One of the most important decisions in SourceCred is where to mint Cred. Whatever mints Cred is ultimately the “source” of positive rewards from SourceCred. Currently, plugins are responsible for these decisions, and because they only have raw data, we use heuristics to decide where Cred gets minted.
The Creditor can solve this by putting the community directly in control of some Cred minting. For example, imagine that every month, the Creditor is going to mint 500 extra Cred. People can vote throughout the month on what high-level contributions were valuable, and the Cred will get divided based on the voting.
(We will put a lot of thought into thinking about how this system could get gamed.)
Who will have control over the Creditor?
The Creditor will be a powerful and complex tool. It will need moderation: to keep it orderly, to remove spam contributions, etc. However, the people who are in charge of it will have a great deal of power. For example, if I am the moderator of our Creditor instance, I’d have the power to mint extra Cred for my friends, make more contributions flow Cred to my initiatives, etc.
I think we should focus on decentralization and transparency in how we operate the Creditor. Anyone should be allowed to propose changes, like adding a new contribution, re-organizing existing ones, etc.
We can use Cred scores as an input to decision-making throughout. For example, maybe rather than needing a moderator approval to make big changes, we would just require a the change be upvoted by people with a certain amount of total Cred.
If we have an issue with people spamming bad contributions or changes, we could require that participants spend a small amount of Grain to make changes with the Creditor. (But we should be sure to make it a small amount just to discourage spam, not something that gates access to the Creditor based on personal wealth.)
One thing I’d like to do is make governance power in the Creditor “local” to the part of the project being edited. If I’m voting on how Cred should flow within a design initiative, my voting power should be based on how much Cred I have in design, not based on my Cred in SC as a whole.
Some example usage of the Creditor
To make things more concrete, here are a few examples of how the Creditor could be used within SourceCred.
In Software Engineering
In the software engineering side: we make a Creditor node representing every feature that we’re thinking of developing, and a node for every bug that needs fixing. Then, people could vote on which features and bugs they want to flow Cred to. The team would focus on the highest-Cred features and bugs (which they would want to, if only for selfish reasons!). This would democratize and decentralize decision making about feature prioritization. Also, if someone really wants a particular thing to get worked on, they could Boost it.
Once someone works on a feature, we would use the Creditor to have the feature flow Cred to their contributions. This would include both “automatic contributions” like pull requests, but also “manual/Creditor contributions” like visual design work, usability audits, etc.
Also: suppose there’s a highly demanded feature, with a big Cred bounty, and someone “rushes” a half-baked solution. So it implements the feature, but it’s buggy and unreliable. Other people would need to do more work to fix it, and the Cred from the feature would get diluted between the initial work, and all of the future fixes. So there’d be an incentive to build it right the first time.
In Docs
In the docs branch, every individual document would be represented in the Creditor, with links to the contributions of writing and reviewing the document. As we re-organize docs, we could keep track of the relationships between them. For example, if one doc splits into three separate docs, each of those child-docs could flow some Cred back to the original.
Then, we could embed little <3 buttons onto the official SourceCred docs page. Each time the <3 button is pressed, it would direct a little bit more Cred towards that doc from the Creditor, meaning that the readers of the docs would be able to reward the best docs. (We’d need to think about how to ensure this wouldn’t get spammed or gamed, of course.)
In Ecosystem
We could create a node representing each co-community. Every week, when that community flows some of their Grain back to us, we could treat that as a boost of their node, increasing the amount of Cred that they get to flow within SourceCred. The co-community would have a lot of say in how that Cred flowed, giving them the ability to advocate for the features and improvements they need.
Next Steps
The Creditor is an ambitious undertaking. From a design standpoint, we need to build a novel and powerful UI and make it accessible to everyone in the community. From the software engineering perspective, we need to build a lot of infrastructure around the backend, identity verification, etc.
To start, I think we should first come to alignment within the community on the overall vision for the Creditor. This post is a step towards that, I’d love to hear others’ thoughts on how this could be used or how it should function. (In particular, I haven’t thought a lot yet about how the Creditor could improve Cred flows within the cultivation branch, and would love to learn how it ca help!)
Once we are aligned on overall vision, I think we should try to scope out a “minimum viable Creditor”. One that may not have every feature we’ve envisioned here, but would be a step in the right direction. Maybe to start, we would just allow tracking new contributions, and voting on which ones are important, without having support for re-organizing the edges in the graph. In that case, it’d be like a formalization of the #props channel on Discord.
Given the complexity of the overall tool, we’ll be well served by starting very simple and then growing from there.
PS: I want to work to make my writing more engaging and accessible, and welcome feedback on this post. Did you find it easy to read and understand?
this feels like a major pivot though right? From “automated comp” to “community comp” (via governance). I checked the honey thread you linked but am still fuzzy on how the voting would work.
