-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document reputation label #347
Changes from 4 commits
e3ed6ad
046842e
4cfd9e6
e337ba0
cfbacb1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -65,21 +65,22 @@ By default, `12` reputation is awarded when a pull request is merged that was op | |
|
||
Depending on the content of the pull request, a maintainer can award more (or less) reputation by adding one of the following labels to the pull request: | ||
|
||
| Label | Reputation | Examples | | ||
| ---------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| `x:size/tiny` | 3 | <ul><li>Fixing a single typo or link</li><li>Removing a blank line or adding a line break</li><li>Changing/adding a single code comment</li></ul> | | ||
| `x:size/small` | 5 | <ul><li>Fixing a single test case, task or example</li><li>Fixing multiple typos or links in a single file</li><li>Clarifying content by adding a few lines to a file</li></ul> | | ||
| `x:size/medium` | 12 | <ul><li>Syncing an exercise with problem-specifications (incl. edits)</li><li>Adding one or more test cases from scratch</li><li>Improving multiple files in an exercise</li><li>Adding mentor notes for an exercise from scratch</li><li>Fixing a small bug in a test runner/analyzer/representer</li><li>Adding analyzer comments for a single exericse</li></ul> | | ||
| `x:size/large` | 30 | <ul><li>Adding a new concept or practice exercise</li><li>Adding new concept documentation</li><li>Substantial re-writing of an existing concept or exercise</li><li>Adding new CI scripts or other automation</li></ul> | | ||
| `x:size/massive` | 100 | <ul><li>Creating a test-runner, analyzer, representer or generator from scratch</li><li>Major refactors to those tools</li><li>Creating major documentation from scratch (e.g. contribution or testing guides)</li></ul> | | ||
| Label | Reputation | Examples | | ||
| --------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| `x:rep/tiny` | 3 (~5 mins) | <ul><li>Fixing a single typo or link</li><li>Removing a blank line or adding a line break</li><li>Changing/adding a single code comment</li></ul> | | ||
| `x:rep/small` | 5 (~10 mins) | <ul><li>Fixing a single test case, task or example</li><li>Fixing multiple typos or links in a single file</li><li>Clarifying content by adding a few lines to a file</li></ul> | | ||
| `x:rep/medium` | 12 (~30 mins) | <ul><li>Syncing an exercise with problem-specifications (incl. edits)</li><li>Adding one or more test cases from scratch</li><li>Improving multiple files in an exercise</li><li>Adding mentor notes for an exercise from scratch</li><li>Fixing a small bug in a test runner/analyzer/representer</li><li>Adding analyzer comments for a single exericse</li></ul> | | ||
| `x:rep/large` | 30 (~2 hrs) | <ul><li>Adding a new concept or practice exercise</li><li>Adding new concept documentation</li><li>Substantial re-writing of an existing concept or exercise</li><li>Adding new CI scripts or other automation</li></ul> | | ||
| `x:rep/massive` | 100 (~5 hrs) | <ul><li>Creating a test-runner, analyzer, representer or generator from scratch</li><li>Major refactors to those tools</li><li>Creating major documentation from scratch (e.g. contribution or testing guides)</li></ul> | | ||
|
||
The examples above can serve as rough orientation when to apply which label but maintainers are free to use their own judgement. | ||
|
||
- The estimated number of time spent should be interpreted as the average time a _maintainer_ would spend on doing the PR. | ||
- If more than one label is specified, the label with the highest reputation value determines the awarded reputation. | ||
- If a pull request is still open, no reputation is awarded (yet). | ||
- If a pull request is closed _without_ merging, no reputation is awarded. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be "exceptionable". There can be value in the discussion of code that does not come in, and a historical record of why. So reputation should be able to be given even if a PR is not accepted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have others ways of rewarding reputation for those cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But we clarify with the "(yet)" when it makes little sense to aware while a PR is still open, which is probably something that would be expected, yet, do not clarify that the no reputation for closed pull requests is not absolutely no reputation when warranted? |
||
|
||
Note that an `x:size` label on an **issue** never affects the awarded reputation - even if a merged pull request lacks an `x:size` label, and closes an issue that has one. | ||
_For backwards compatibility purposes, we also support using the `x:size` labels to determine the awarded reputation._ | ||
|
||
### Reviewing a pull requests | ||
|
||
|
@@ -91,16 +92,21 @@ For each merged or closed pull request reviewed by the user, `5` reputation is a | |
|
||
- The reputation awarded for a pull request review changes if one of the following labels are added to the pull request: | ||
|
||
| Label | Reputation | | ||
| ---------------- | ---------- | | ||
| `x:size/tiny` | 1 | | ||
| `x:size/small` | 2 | | ||
| `x:size/medium` | 5 | | ||
| `x:size/large` | 10 | | ||
| `x:size/massive` | 20 | | ||
| Label | Reputation | | ||
| --------------- | ---------- | | ||
| `x:rep/tiny` | 1 | | ||
| `x:rep/small` | 2 | | ||
| `x:rep/medium` | 5 | | ||
| `x:rep/large` | 10 | | ||
| `x:rep/massive` | 20 | | ||
|
||
It is _not_ possible to use different reputation "sizes" for a pull request author and reviewer. | ||
Both are based on the same `x:rep` label. | ||
|
||
If more than one label is specified, the label with the highest reputation value determines the awarded reputation. | ||
|
||
_For backwards compatibility purposes, we also support using the `x:size` labels to determine the awarded reputation._ | ||
|
||
### Merging a pull request | ||
|
||
For each pull request that was merged by the user, `1` reputation is awarded. | ||
|
@@ -109,3 +115,23 @@ For each pull request that was merged by the user, `1` reputation is awarded. | |
- If a pull request is closed _without_ merging, no reputation is awarded. | ||
- The user that opened the pull request does _not_ get reputation for merging their own pull request. | ||
- If the pull request does not have any reviews, `5` reputation is awarded instead. | ||
|
||
### Opening an issue | ||
|
||
By default, **no reputation is awarded** when an issue is opened. | ||
|
||
Depending on the content of the issue, a maintainer can choose to award reputation by adding one of the following labels to the issue: | ||
|
||
| Label | Reputation | Examples | | ||
| --------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| `x:rep/tiny` | 3 (~5 mins) | <ul><li>Fixing a single typo or link</li><li>Removing a blank line or adding a line break</li><li>Changing/adding a single code comment</li></ul> | | ||
| `x:rep/small` | 5 (~10 mins) | <ul><li>Fixing a single test case, task or example</li><li>Fixing multiple typos or links in a single file</li><li>Clarifying content by adding a few lines to a file</li></ul> | | ||
| `x:rep/medium` | 12 (~30 mins) | <ul><li>Syncing an exercise with problem-specifications (incl. edits)</li><li>Adding one or more test cases from scratch</li><li>Improving multiple files in an exercise</li><li>Adding mentor notes for an exercise from scratch</li><li>Fixing a small bug in a test runner/analyzer/representer</li><li>Adding analyzer comments for a single exericse</li></ul> | | ||
| `x:rep/large` | 30 (~2 hrs) | <ul><li>Fully-fleshed out Concept Exercise</li></ul> | | ||
| `x:rep/massive` | 100 (~5 hrs) | <ul><li>Designing a track curriculum</li></ul> | | ||
|
||
The examples above can serve as rough orientation when to apply which label, but maintainers are free to use their own judgement. | ||
|
||
- The reputation should reflect the amount of effort that _maintainer_ would spend to create the issue. | ||
|
||
- If more than one label is specified, the label with the highest reputation value determines the awarded reputation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've slightly rounded the estimated time to make it easier to remember.