Dandelion Mané b2c13ac891
[refactor] Move node/edge types to addresses (#105)
This pull request adds a string type as a field of the address, thus canonicalizing that all Nodes and Edges have a Type. This allows for simpler PluginAdapters, and simpler implementation of the GitHub plugin (as it no longer needs to invent its own mechanism for storing types).

I explored making the Address interface generic, with a Type parameter that is a subtype of string. Unfortunately, Flow type resolution seems to have an exponential performance degradation with many subtyped parameters, and adding the extra type parameters to Graph.merge resulted in my flow instance locking. Maybe we can explore adding the subtypes later.

In the GitHub plugin, we entirely do away with the NodeIDs, but we still have EdgeIDs. I plan to remove the need for EdgeIDs in a separate PR which will enforce uniqueness of (srcAddress, dstAddress, pluginName, type) tuples, so that explicitly generating IDs for edges will be unnecessary. In the mean time, I bifurcated the makeAddress function in the GitHub plugin to makeEdgeAddress and makeNodeAddress.

Test plan:
Flow and unit tests all pass. Inspect snapshots, and verify that all the changes are reasonable. Note that since we order by serialized address, adding the type field to address has changed the snapshot order in a few cases.

Close #103
2018-03-26 10:36:49 -07:00
2018-02-26 22:32:23 -08:00
2018-03-02 14:39:54 -08:00
2018-02-03 17:58:49 -08:00
2018-03-06 19:09:46 -08:00

SourceCred

Build Status

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 follow along with our issues, as we are using issues to coordinate development and design decisions. We also have a slack.

Description
a reputation protocol for open collaboration
Readme
Languages
JavaScript 96.1%
Shell 3.7%
Python 0.1%