f5d486087d
Summary: The main problem with having these fields on the node is that this presents the illusion that the API surface area is larger than it actually is. Clients with reference to a node object could somewhat-reasonably expect that mutating these fields would be sufficient to update the structure of the graph, but this isn’t the case (as the edge objects would need to be updated, too). It’s a nice semantic bonus, too, as edges aren’t conceptually “part of” nodes. wchargin-branch: top-level-edges |
||
|---|---|---|
| config | ||
| experiments | ||
| flow-typed/npm | ||
| public | ||
| scripts | ||
| src | ||
| .flowconfig | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc.json | ||
| LICENSE | ||
| README.md | ||
| package.json | ||
| yarn.lock | ||
README.md
SourceCred
The open-source community provides an enormous amount of value to the world. However, open-source contributors go largely unrewarded and unrecognized. SourceCred aims to help that situation, by building tools that enable quantitatively measuring the value that open-source contributors provide to individual projects, and to the community as a whole.
SourceCred will create a "Cred Graph", which is a graph that shows how the contributions that compose open-source projects are related to and derive value from each other. From this, we'll be able to assign "cred" to users based on how valuable their contributions are. Cred will be assigned based on a mixture of objective data (e.g. references between GitHub pull requests) and subjective feedback (e.g. projects' own judgments on how important different contributions were).
If you'd like to contribute, please join our slack.