Who is SourceCred for?

1

Moving this out of email with @decentralion:

  1. Are you hoping to reach maintainers (“surface your hard work” / “discover who’s doing work that you might not have noticed”) or contributors (“if you pitch in, you’ll earn cred”) with your messaging? My guess is the former will resonate more early on, since cred doesn’t have real-world use yet, and also because maintainers are the one who will implement SourceCred :wink: Either way, I’d tailor the site copy more explicitly to one or both of these audiences.

  2. As a maintainer, my first q would be: what additional insight will this give me over the GitHub’s contributor graph? I think the strongest way to show this is with specific examples of interesting insights that can be generated.

Ex. “Most contributions on this community project come from Bloomberg employees” (or the reverse!), “X person doesn’t rank highly on GitHub’s contributor graph, but according to SourceCred they do substantial work”, “Y person isn’t well known, but makes a ton of respected contributions”

If you have thoughts on the types of insights you’d love to show off, happy to help brainstorm projects that might demonstrate them.

2 Likes
2

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.

  1. 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.

  2. 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.)

  3. 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?”.

  1. 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.

image
image1367×780 58.6 KB
image
image1364×636 95.3 KB

  1. SourceCred ingests social feedback, like GitHub reactions (not implemented yet)

  2. SourceCred can be used to create tailored incentives, and to gamify open-source contributions.

  3. 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:

  1. Users vote on which issues they think are important / urgent by reacting to them on GitHub (:heart: > :+1: and so forth)
  2. SourceCred aggregates over all the votes and produces a scoring of the open issues, which the maintainer makes prominently visible
  3. 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.

1 Like
3

because maintainers are the one who will implement SourceCred

I think what you need to figure out is if this initial release is a one-sided or two-sided market. In other words, do maintainers turn this on and use the information themselves, or do they turn this on and then use SourceCred as a way to collaborate and incentivize other people. I know what the long term vision is, but in the short term this needs to be worked out.

If this is just about maintainers the messaging is much easier. Even if maintainers are using the information from SoureCred in their project but aren’t actively having contributors interact with SourceCred directly you can have similarly simple messaging.

If this is two-sided, there is a bit more work to do in terms of understanding potential contributors and what they care about, not just from the perspective of maintainers but what might motivate them as individuals to contribute. That’s significantly harder to figure out than the maintainer perspective.

4

Here are a number of answers; some are already fleshed out, some need some more development work.

My intuition is that of the examples you list, #1 and #3…

  1. 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.
  1. 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?”.

…are probably most compelling to maintainers at this stage (ex. you mention #3 is important to Karthik).

#3 feels like an “easy win” (please take “easy” relative to the fact that I know I’m not the one implementing anything :smile:), because it’s something GitHub doesn’t do, and lots of maintainers want more functionality around. And it seems you can already offer low-hanging insight in this direction.

#1 is a high-impact win, but requires a lot of nuance to get right. Ex. being able to distinguish between “noisy” community members who comment a lot, vs. frequent commenters who add value (ex. perhaps someone who triages issues). If you do it well though, I think that’d be a big hook.

One way to think about SourceCred development might be writing down the top 1-3 selling points to maintainers, and prioritizing product development only on those things.

1 Like