Populating the graph from the bottom up

From my perspective how the graph gets populated is rather important. At the moment I believe inputs are prescriptive: i.e. a plugin that recognises a schema of contribution types such as “comments” or “pull requests”.

Letting anyone add anything however would pollute the graph and screw with the established value weightings… So how do we onboard a contribution if theres no pre-built measurement tool?

Having a bit of a ponder I realised that whats needed is a subjective evaluation mechanism thats community curated… which feels kinda like a TCR design pattern to me. Users could propose a piece of work for evaluation (free), but would perhaps stake on the value of the work (to incentivise a fair evaluation). Community members would then perhaps be able to accept reject or adjust the valuation.

If accepted we would then have a contribution thats valued and thus able to be added to the graph.

Not a perfect solution but perhaps a useful way to operate in the absence of pre-developed tooling?

Food for thought, I’d like to hear opinions around such :slight_smile:

1 Like

I agree that making an “bottoms up” or “contributor centric” way to get information into the cred graph is really important. My 2c, at this stage we can avoid worrying about getting the system to be incentive compatible (i.e. we don’t need a staking mechanic). Since SourceCred is a small enough community that by having every proposed change go through a community review process, people will orient on the “social incentives” rather than needing explicit “system incentives”. So the key for now is to get a good UI/UX so it’s easy and intuitive to use.

Once we’ve been using it together for a few months, we’ll have a better sense of what the “dark patterns” are, and how we can make the system more scalable by making it incentive compatible.


Agree with @decentralion that this is a bit tangential to SC at the moment. However, I think this idea is solid and exciting in regards to the OSS funding problem in general. This is how Maker operated informally in its early days, to great success (TW: it gets dark when they try to scale this with VC money pressure). It’s how my project pays contractors essentially (though it’s not formalized and there’s no staking or other game theory). There are several other crypto projects also experimenting with similar ideas, because it potentially solves the problem of how to price smaller contributions. Current governance systems are only able to (successfully) make larger funding decisions (e.g. fund the yearly dev budget).

The staking idea is interesting. It’s making me think of Numeri’s “griefing” system. Applied to SC, griefing could work something like this. To submit a contribution (however large or small), you must stake some coin. Perhaps a minimum amount is set to introduce skin-in-the-game and reduce spam. If the contribution (and/or price tag) is rejected, the contributor’s stake is burned, incentivizing them to not game the system. However, when a repo maintainer (or the community at large) rejects a submission, they must also burn an certain amount they have staked. How much they have to burn is determined by a “griefing factor”. If the griefing factor is 10/1, for example, when a maintainer burns a contributor stake by rejecting a contribution, they have to burn 1/10’th that amount of their own grain. This griefing factor could be a function of how much cred each party has in the system.

1 Like

Yeah I’m with you, its best we start with minimal constraints and see what tensions/dark patterns arise and fix them as decisions need to be made rather than proactively incentivising stuff. I appreciate your approach. You really should reach out to Bryan (Poochy) in the Telegram group surrounding such as we pretty much want to do exactly this but on a boat (#CabinFever) for a continuous “hack-along” with sprints timed to the moon… The intent being to catalyse mobile cities.

Anyway good thoughts, seems like something I’d be happy to Guinea pig - lets get a lab/boat built and measure things!

Thanks for sharing, I’ll take a look at these resources and get back to you. Agree that it was perhaps tangental right now, see my response Lions post above which puts my concern to rest (for now!)

I do think this is one of the more exciting ideas in OSS funding generally. Have ideas of my own around this and think it will resurface.