Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce Sourcecred as a method for Funds Distribution #2257
As an a project administrator, I can automatically delegate regular or one-time funds to Contributors based on a https://sourcecred.io graph of one or more repositories.
Best solution for this problem
What does the ideal solution look like?
One or more projects that are currently aware of sourcecred and have funds to delegate could be invited to participate and contribute. Quasar Framework (where I am a member of the core team and co-administrator of the open collective) would agree to participating. Another potential group might be the SFOSC.
What metrics will be used to measure impact?
Sourcecred is not complicated, and can literally be explained in one sentences:
However, most people get it when they look at a graph:
@nothingismagick I didn't know about SourceCred, what a great project! I don't know if this issue is something we can prioritize for the short/mid term, but doing it manually at first seems feasible.
I could definitely see space to integrate and re-use data from SourceCred in the future
Most of the technical milestones we needed have been achieved. In particular, we can now generate cred scores via command-line API, rather than being restricted to an in-browser workflow. Also, we now have time-aware cred, so we can give scores for (say) just the last month or year, which would be well suited to sending out project updates, or for rewarding currently active contributors.
That said, we need to resolve some issues with downloading data from GitHub to get SourceCred robust on large repositories (sourcecred/sourcecred#1256). If we tried any large-scale integration before doing this, we would likely get bogged down tracing down the particular issues. Although if we wanted to test a small scale integration (on a few repos that opt-in) we could work around.
In addition to fixing the SourceCred robustness issues, my other top engineering priority is making SourceCred much easier to depend on and use (i.e. make it easy to install and run sourcecred via npm: sourcecred/sourcecred#1232). Getting both of these done will make all integrations a lot easier. :)
This is very interesting! From the perspective of the Open Source Collective, I'm very interested in partnerships and collaborations with aligned projects. If I'm understanding this correctly SourceCred could be used as a way to determine or justify distributions of Collective funds to contributors, right?
@decentralion - can you explain more about why an integration would be necessary? Can't current projects use SourceCred as is to analyse their contributions and distribute funds accordingly?
I'm wondering about a 'soft' integration first, where we, for example, mention SourceCred in our comms as a useful tool for Collectives looking for help deciding how to spend their funds, have a guest post by @decentralion or another SourceCred contributor on our blog, etc. Then we can see if Collectives are interested in it, and if so, if there are tech improvements on either side that would help make it a better experience for core contributors.
It looks like SourceCred itself doesn't have a Collective. Could that be a place to start? Using yourselves as a use case for distributing Collective funds would be a great case study.
I think both with and without a technical integration would be interesting to explore.
When you want to use SourceCred as input to inform the distribution, perhaps archiving a verifiable list of cred scores and referencing that would be the way to go.
However I think the automatic integration has some benefits, especially for the case where you want to pay contributors in a way that's directly proportional to their SourceCred score. Aside from being low-maintenance and less error prone when automated, you can provide additional guarantees of timely and unbiased distribution of funds.
The most extensive (but actually pretty exciting!) integration I could think of would be not to use a simple list of scores as your justification. But archiving the full dataset and being able to explore it with SourceCred's data exploration tool.
Instead of saying: Beanow scored 214 cred this month, you can explain down to the individual comment or
Very cool. OK, well let's start with the easiest first steps and go from there. I will include a mention of SourceCred in the next monthly newsletter, as a potentially helpful tool for Collectives.
I think the best next step would be to get an actual Collective to try out using it as a way to decide financial distributions from their Collective. Then we can write about that as a case study on the blog. That could either be SourceCred itself starting a Collective and dogfooding the tool, or you guys finding an existing Collective that wants to try it.
Keep me posted :)
@alanna -- I think dogfooding a SourceCred+OpenCollective on SourceCred itself makes loads of sense. Actually, one of my priorities this quarter is to start paying SC contributors based on their cred, so dogfooding on OpenCollective can align perfectly with that goal.
I've written a detailed proposal on how this could work over on the SourceCred discourse. Please take a look and share your thoughts, and whether it looks feasible from OpenCollective's perspective. I think the main thing I would need is an API for creating an invoice for every contributor who earned cred in a given month.
In the Discourse post, I suggested we frame this as a 3 month long experiment, and at the end we do a retro looking at how it affected the project, what did/didn't work, and whether we to continue funding SC this way. We could then do a shared blog post publicizing the experiment and inviting other collectives to try it too.
If OpenCollective finds this interesting, it would also be great if you'd be willing to contribute some funding to the experiment alongside Protocol Labs and others. :)