Are you hoping to reach maintainers or contributors?
Like you said, I think focusing on the maintainers makes the most sense;
both because they have the power to turn on SourceCred for their projects,
and because the status quo kind of sucks for them.
Either way, I’d tailor the site copy more explicitly
Makes sense; I think switching “here’s our mission” to
“here’s how we can help your project” would be much stronger/more actionable.
Once we answer the questions you bring up in this thread we
should be ready to write much stronger copy.
As a maintainer, my first q would be: what additional insight will this give me over the GitHub’s contributor graph
Here are a number of answers; some are already fleshed out, some need some more development work.
The GitHub contributor graph only detects code changes, while SourceCred detects all GitHub activity.
So if there’s a contributor who is active in commenting on issues, reviewing pulls, etc, but doesn’t code much, they will be much more visible to SourceCred.
SourceCred explicitly maps a number to each contributor, which makes it much more actionable (e.g. for distributing cryptos). (This can also be a bad thing, especially when the numbers are easy to game.)
The GitHub contributor graphs are per-repository only; SourceCred can integrate across every repository in a project (e.g. every libp2p repository).
We will make it possible to ask “for this subset of the project, who has cred?” and also “for this contributor, which repos do they get their cred from?”.
- In addition to scoring users, SourceCred also scores the commits, issues, repos, etc.
Looking at the distribution of repo scores in libp2p and in ipfs is already pretty interesting;
it reveals that IPFS is much more centralized around a single repository (go-ipfs) whereas libp2p development occurs across many smaller repos.
SourceCred ingests social feedback, like GitHub reactions (not implemented yet)
SourceCred can be used to create tailored incentives, and to gamify open-source contributions.
SourceCred admits moderation by a project’s maintainers. If someone starts overtly gaming
a project’s cred, the moderators can step in to remove their ill-gotten cred.
For the time being, I’m focused on making cross-repository support really solid.
Karthik from rOpenSci and wants to turn on cred for rOpenSci, and they have >300 repos so
the feature is a must-have. Generally speaking, the larger a project is
(in collaborators, repos, issues, code), the harder it is to get legibility, and so
the more useful SourceCred can be.
In the slightly longer term, putting together 4, 5, and 6,
I think we could make a compelling system around issue prioritization
and triage. Something like:
- Users vote on which issues they think are important / urgent by reacting to them on GitHub ( > and so forth)
- SourceCred aggregates over all the votes and produces a scoring of the open issues, which the
maintainer makes prominently visible
- Users can earn cred by closing/fixing those issues, and earn a lot of cred if they focus on the
ones with high scores
- …which then gives them more influence in step 1.
This targets a few problems for open-source projects
(drowning in issues, lack of clear prioritization,
insufficient incentive for non-maintainers to triage/fix bugs),
and makes having a lot of cred in a project useful (your fav bugs get fixed). What do you think?
Ex. “Most contributions on this community project come from Bloomberg employees”
This could be a cool feature to add too—we could display users’ public organizations with badges,
so it would be easy to see if all the top contributors came from one company. Or if you have an
org for the project, you could see if there are up-and-coming contributors who have made a lot
of contributions, and deserve an invite into the org.
Thanks for asking these questions, @nayafia! They are really helpful to think about.
Super curious for your feedback.