This is WIP but it's something that's been cooking in my brain for the past month or so. We've been paying for PRs for around a year with varying levels of formality and success. In general, it's been awesome so I want to encourage more of it. I'm also hoping it creates a better than usual hiring pipeline. FOSS is how we got @ek after all.
I'd love to get feedback on the system design. This started out as me figuring out the structure of PR payments, but when I sat down to write it out yesterday, I began considering other types of non-code contributions because those are really important too.
contribution awards
We pay sats for
- pull requests closing existing issues
- code review
- issue specification whether for bugs, features, or enhancements
- discovery of security vulnerabilities
- discovery of privacy vulnerabilities
- improvements to development documentation
- helpfulness
Just in case: This document in no way legally entitles you to payments for contributions, entitles you to being a contributor, or entitles you to the attention of other contributors. This document lays out the system we can use to determine contribution awards which we generally intend to abide by but importantly we reserve the right to refuse payments or contributions, modify rules and award amounts, make exceptions to rules or reward amounts, and withhold awards for any reason at anytime, even just for the heck of it, at our sole discretion. If you need more certainty than what I've just described, don't participate. We provide awards as an experiment to make FOSS less sucky.
pull request awards
rules
- PRs closing an issue will be awarded according to the
difficultytag on an issue, e.g.difficulty:easypays 100k sats. - Issues are occasionally marked with a
prioritytag which multiplies the award of a PR closing an issue, e.g. an issue marked withpriority:highanddifficulty:hardawards 2m sats. - An award is reduced by 10% of the award amount for each substantial change requested to the PR on code review, e.g. if two changes are requested on a PR closing an issue tagged with
difficulty:hard, 800k sats will be awarded.- Reductions are applied before
prioritymultipliers, e.g. a PR closing apriority:highanddifficulty:hardissue that's approved after two changes are requested awards 1.6m sats. - You are responsible for understanding the issue and requirements before requesting review on a PR.
- There is no award reduction for asking specific questions on the issue itself or on the PR before requesting review
- There is no award reduction for asking more general questions in a discussion
- Reductions are applied before
- A PR must be merged by an SN engineer before a PR receives an award
difficulty award amounts
| tag | description | award |
|---|---|---|
difficulty:good-first-issue | at most a couple lines of code in a couple files and does not require much familiarity with the codebase | 20k sats |
difficulty:easy | at most a couple lines of code in a couple files but does require familiarity with the code base | 100k sats |
difficulty:medium | more code, more places and could require adding columns in the db and some modification chunky db queries | 250k sats |
difficulty:medium-hard | even more code, even more places and requires either more sophisticated logic, more significant db modeling eg adding a table, and/or a deeper study of a something | 500k sats |
difficulty:hard | either a bigger lift than the what's required of medium-hard or very tricky in a particular way that might not require a lot of code but does require a lot of context/troubleshooting/expertise | 1m sats |
priority multipliers
| tag | multiplier |
|---|---|
priority:medium | 1.5 |
priority:high | 2 |
priority:urgent | 3 |
code review awards
Code reviewers will be awarded the amount their code review reduced from the PR author's reward, e.g. two substantial problems/areas of improvement identified in a PR closing a
priority:high and difficulty:hard issue awards 400k sats.rules
- The problem or improvement must be acknowledged as such by SN engineers explicitly
- A PR must be merged by an SN engineer before a PR's code reviewers receive an award
Code review approvals are more than welcome, but we can't guarantee awards for them because the work performed to approve a PR is unverifiable.
issue specification awards
Issue specifiers will be awarded up to 10% of a PR award for issues resulting in a PR being merged by an SN engineer that closes the issue. In addition to being subject to PR award amounts and reductions, specification amounts are awarded on the basis of how much additional help and specification is required by other contributors.
rules
- The issue must directly result in PR being merged by an SN engineer that closes the issue
- Issue specification award amounts are based on the final PR award amounts
- that is, they are subject to PR award code review reductions and priority multipliers
- Award amounts will be reduced on the basis of how much additional help and specification is required by other contributors
- Issue specifiers who can close their own issues with their own PRs are also eligible for this 10%
- e.g an issue tagged as
difficulty:hardthat is both specified and closed by a PR from the same contributor without changes requested awards 1.1m sats
- e.g an issue tagged as
relative awards
| circumstances | award |
|---|---|
| issue doesn't require further help and/or specification from other contributors | 10% |
| issue requires little help and/or specification from other contributors | 5% |
| issue requires more help and/or specification from other contributors than the issue specifier contributed | 1% |
| issue is vague and/or incomplete and must mostly be entirely specified by someone else | 0% |
For example: a specified issue that's tagged as
difficulty:hard, doesn't require additional specification and disambiguation by other contributors, and results in PR being merged without changes requested awards the issue specifier 100k sats.responsible disclosure of security or privacy vulnerability awards
Awards for responsible disclosures are assessed on the basis of:
- the potential loss resulting from an exploit of the vulnerability
- the trivialness of exploiting the vulnerability
- the disclosure's detail
Award amounts will be easiest to assess on a case by case basis. Upon confirmation of a vulnerability, we agree to award responsible disclosures at minimum 100k sats and as high as the total potential loss that would result from exploiting the vulnerability.
rules
- Disclosure is responsible and does not increase the likelihood of an exploit
- Disclosure details how to exploit the vulnerability with certainty
development documentation awards
For significant changes to documentation, create an issue before making said changes. In such cases we will award documentation improvements in accordance with issue specification and PR awards.
For changes on the order of something like a typo, we'll award a nominal amount at our discretion.
helpfulness awards
Like issue specification awards, helping fellow contributors substantially in a well documented manner such that future contributors may also benefit and leads the helped fellow to contributing a PR that gets merged is eligible for a one-time relative reward.
| circumstances | award |
|---|---|
| substantial and singular source of help | 10% |
| substantial but nonsingular source of help | 1-5% |
| source of relatively trivial help | 1% |