status-im
/
sourcecred
mirror of https://github.com/status-im/sourcecred.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Remove outdated design documents (#45) 

design.md and overview.md both describe a vision of sourcecred
in which it is a measure of credit, and an explicit cryptographic
token. right now, SourceCred is more focused on just measuring credit,
with the expectation that cryptoincentives can be added on later.

Removing these outdated documents will reduce confusion; they may
be re-written and re-added later.
This commit is contained in:
Dandelion Mané 2018-02-28 20:41:04 -08:00 committed by GitHub
parent 01df727c39
commit cde98cd67b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 0 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
design.md
View File

@ -1,31 +0,0 @@
# SourceCred Design
## Design Goals
0. **Useful**
SourceCred is not a pie-in-the-sky project to design a theoretically ideal system. It is useful software that will solve a pressing need: to provide a funding and incentive model for developing open-source software. As such, given the choice between the ideal and the attainable, we will choose the attainable.
1. **Ethical**
We also recognize that by attempting to allocate credit and value, SourceCred is creating an economic system. Designing economic systems is a weighty responsibility in which small decisions may have large ethical consequences. By default, systems serve the powerful and connected. We will design SourceCred so that it also recognizes the least powerful and least connected contributors.
2. **Economically Valuable**
SourceCred will provide a viable funding model for open projects. That means that the tokens it generates need to have some real economic value that is derived from the value of the project. Just allocating credit to contributors is not enough - there needs to be an reason for other agents in the ecosystem to pay contributors for their work.
3. **Incentive-compatible**
SourceCred will generate robust incentives, so that rational actors trying to earn cred in a project will do so by making material contributions to the project's success and usefulness. The incentive system should be adaptable, so that as participants find ways to game them, communities can modify them to avoid incentive traps.
4. **Easy to Adopt**
SourceCred needs to be able to meet the open-source community where it is today, and to be easy to adopt and use. Basic usage of SourceCred should feel intuitive and low friction, e.g. by using GitHub reactions and messages from GitHub bots as a low-resolution way of engaging with the system. We should ask users to learn new behaviors, like setting up an Ethereum address, only when we're already delivering lots of value - not as a prerequisite.
5. **Fork-friendly and Upgradable**
Forking is an essential part of software development. SourceCred should enable forks with relatively low friction; users should not be locked into a single branch due to the difficulty of forking the cred allocation. Similarly, it should be easy for projects to upgrade to a newer version of SourceCred, or switch to a fork of SourceCred.
6. **A Protocol**
SourceCred is focused on an application: funding and incentives for open-source. However, at its core, it is also a protocol: a general purpose way to allocate credit, and flow tokens and rewards to contributors. As we build the application, we will also create clean interfaces so that the underlying protocol can be flexibly re-used in other domains.

9
overview.md
View File

@ -1,9 +0,0 @@
# Overview
SourceCred is a cryptoeconomic mechanism for funding and incentivizing open-source development. The goal of SourceCred is to create a funding model for open-source projects that rewards contributors, and an incentive system that welcome more people to work on the project.
SourceCred allows any project to create *cred* (Ͼ), which is a cryptographic token representing work done in that project. Every project has its own, particular cred - for example, PythonϾ and EthereumϾ would be two totally separate creds. Each project creates cred via Cred Allocations, which are periodic events when cred is given to people that contributed to the project. That cred is allocated based on community feedback, where users with more cred have more weight, a la [PageRank](https://en.wikipedia.org/wiki/PageRank). The exact mechanics are up to each project, although SourceCred will suggest good norms and useful tools. One such norm is that every project should give 20% of its cred to the other projects that it depends on, so as to support and reward shared infrastructure.
When an existing project starts using SourceCred, they will have an Initial Cred Allocation (ICA), which determines how to retroactively give cred to the people that developed that project. This is just a special case of the standard cred allocation process. SourceCred will provide tools that scan the history of the project, and suggest a starting point for the allocation, but ultimately the allocation is decided by the community.
Each project's cred will be a implemented as an [ERC20 token](https://theethereum.wiki/w/index.php/ERC20_Token_Standard) on Ethereum. That means that contributors can use the Ethereum infrastructure to buy and sell cred. One reason that others would want to buy cred is to have influence over the project. For example, consider a business that depends on an open-source project, and needs it to add some new features and fix bugs. If that business buys cred in the project, they can influence the Cred Allocations - e.g. to ensure that people that work on their priorities get a lot of cred. That would be more efficient than having their engineers try to fix the project directly.