Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Document reputation label #347

Merged
merged 5 commits into from
Jul 14, 2022
Merged

Document reputation label #347

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e3ed6ad
Update reputation document to use `x:rep` label
ErikSchierboom Apr 6, 2022
046842e
Document rep for opening issue
ErikSchierboom Apr 6, 2022
4cfd9e6
Add backwards compatibility note
ErikSchierboom Apr 22, 2022
e337ba0
Update rep doc
ErikSchierboom Apr 22, 2022
cfbacb1
Remove time estimates
ErikSchierboom Jul 14, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 39 additions & 15 deletions using/product/reputation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 | <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 | <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 | <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 | <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 | <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.
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have others ways of rewarding reputation for those cases.

Copy link
Member

Choose a reason for hiding this comment

The 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

Expand All @@ -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.
Expand All @@ -109,3 +115,21 @@ 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

Like pull requests, by default, **no reputation is awarded** when an issue is opened.
Unlike pull requests, reputation is only awarded for large or massive issues.

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/large` | 30 | <ul><li>Fully-fleshed out Concept Exercise</li></ul> |
| `x:rep/massive` | 100 | <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.