| | 1 | ## Maintainers Guide |
| | 2 | |
| | 3 | We'd like to foster an active community of mutual respect. With that as our |
| | 4 | guiding principle, we strive to do the following: |
| | 5 | |
| | 6 | * Respond to issues/pulls in a timely manner. |
| | 7 | * Encourage new contributors when possible. |
| | 8 | * Maintain high code quality by ensuring all pull requests: |
| | 9 | * Have clear concise code. |
| | 10 | * Have passing specs. |
| | 11 | * Have a proper note in the docs (if appropriate). |
| | 12 | * Be made mergable by its creator (good feedback is hard enough). |
| | 13 | * If a pull doesn't meet these standards, we should offer helpful actionable |
| | 14 | advice to get it there. |
| | 15 | * Add `CHANGELOG.md` entries for every pull merged. |
| | 16 | * Publish new releases in a timely manner. |
| | 17 | * Responsibly upgrade along with Atom core |
| | 18 | * Tag the last compatible version with the correct Atom version before making a breaking change |
| | 19 | * Merge finished pull requests before merging breaking changes |
| | 20 | * Label issues clearly |
| | 21 | * As either an `issue`, `enhancement` or `question`. |
| | 22 | * The `question` label indicates that there's a question about current |
| | 23 | functionality or future functionality. |
| | 24 | * Label pull requests clearly |
| | 25 | * As either an `issue` or `enhancement`. |
| | 26 | * While being reviewed mark an additional `under-review` label if appropriate, |
| | 27 | so the community knows the status. |
| | 28 | * If a pull request requires changes by the creator an additional |
| | 29 | `requires-changes` label is appropriate. |
| | 30 | * Pulls that require core changes that aren't ready yet should be labeled |
| | 31 | with an additional `blocked` label. |
git.r.bdr.sh / rbdr / dotfiles / blame_incremental