So far, SourceCred has depended on GitHub for its data—it considers every issue, pull request, and comment to be a contribution, and assigns scores to these based on how they interrelate. It’s a powerful approach, but it’s missing the human context.
What if we use this hackathon to explore a different approach: one which is focused, first and foremost, on user experience, and soliciting informtaion from contributors. I’m imagining a “SourceCred editor” which allows you to define the cred in a project in terms of “Components” (higher level pieces of the project, may be nested), “Contributions” (individual pieces of work for one or more components), and “Creators” (who create the contributions).
For example, let’s suppose we want to compute cred for a dance party that @LB threw at our house a few months ago. We could start with the Components:
- Preparing the house
- Design + theme
- Buying supplies
- Putitng up decorations
- Buying food supplies
- Cooking + Preparing
- Cleaning kitchen afterwards
- Sound system setup
- DJs / sets
- Make FB post
- Word of mouth invites
(Note: I’ve represented these like a tree, but it might be a general graph, e.g. “Sound system setup” might be connected to the Venue component as well as the Music component.)
Once components exist, it’s time to add “Contributions”. Contributions each have a description, and associated people. For example, I could add two contributions to the “Preparing the house” component:
- “Writing note to neighbors to let them know about the party” by @LB
- “Delivering notes to each neighbor” by @LB + @RyanLimbaugh
- “Re-arrange the living room to be a dance space” by @Dandelion + @Miguel
Components and contributions can also have dependencies on each other. For example, if someone posted an image of the decorations to the Facebook event, that could be included in the “outreach” component, but depend on the “decorations” component.
Since creating these contributions, writing good descriptions for them, etc, is a form of labor, we should also have a “cred-tracking” component that captures the meta-contribution of keeping the contribution graph up to date.
On top of this, we can add weights on the edges, so that you can say e.g.:
- Setting up the dance floor gets 2x the weight as delivering the notes
- The “Venue” component was more important than the “Food” component
We could also imagine the relative weight of each component just being derived from the number of contributions in scope. That might work, but would create perverse incentives to create as many tiny contributions as possible, e.g. “Cleaned the garage” becomes “cleaned the top shelf of the garage, cleaned the middle shelf of the garage, …”. Having some weight mechanism gives a good way to deal with that.
Then, we should be able to do cred analysis on a component-by-component basis.
- For any component: which people have cred in that component?
- For any user: what components do they have cred in?
If we can make some pretty charts for each component, that would be quite interesting!
Naturally, this system should work on software projects too, and interface through the plugin APIs with the rest of SourceCred. For example, the component tree for SourceCred might look like this:
implementation/ graph/ api/ implementation/ testing/ documentation/ plugins/ git/ git-loader/ graph-generator/ testing/ github/ data-loading/ mirror-module/ graph-generator/ reference-parser/ testing/ pagerank/ api/ performance/ testing/ documentation/ cred-explorer/ design/ score-normalization/ implementation/ features/ cred-aggregation/ node-descriptions/ weight-configuration/ testing/ research/ project-management/ ideation/ (coming up with SourceCred to begin with) goal-setting/ community-building/ discord/ discourse/ word-of-mouth-outreach/ blogging/ videos/ resourcing/
Then, besides manually adding contributions for the sections (as described above), we could also “link in” existing contributions. We could have a UI that displays every GitHub issue and PR that doesn’t correspond to any component, and then tag it with one (or more) components.
If this works, this would solve a lot of problems for SC:
- Makes it possible to recognize non-GitHub contributions
- Provides overall context so maintainers can signal how each contribution fits into the project
- Makes the system more spam resistant (the spam/trivial contributions won’t get connected to components)
- Makes cred scores a lot more interesting (“you have 30 cred in the API component and 90 in the research component; within the research component, 15 came from infrastructure and 65 came from algorithms” is far more interesting than “you have 120 cred”).
If we decide to go down this route, some interesting challenges are:
- How to make a UI that makes managing and updating this data structure intuitive?
- Do we use a graph visualization? A text based system? Some other GUI?
- How do users re-organize the graph, or split one component up, or group a set of related contributions into a new component?
- How do people collaborate on the UI?
There are also a lot of other neat things we could think about doing, like adding “types of labor” (implementation, communication, logistics, design, research, …) and then tagging each contribution with the applicable labor types. Then in addition to giving a component-wise view of peoples’ work, you can also see what kind of work they’ve been doing.