[rbdr/dotfiles] / atom / packages / vim-mode / MAINTAINERS.md

## Maintainers Guide

We'd like to foster an active community of mutual respect. With that as our
guiding principle, we strive to do the following:

* Respond to issues/pulls in a timely manner.
* Encourage new contributors when possible.
* Maintain high code quality by ensuring all pull requests:
  * Have clear concise code.
  * Have passing specs.
  * Have a proper note in the docs (if appropriate).
  * Be made mergable by its creator (good feedback is hard enough).
  * If a pull doesn't meet these standards, we should offer helpful actionable
    advice to get it there.
* Add `CHANGELOG.md` entries for every pull merged.
* Publish new releases in a timely manner.
* Responsibly upgrade along with Atom core
  * Tag the last compatible version with the correct Atom version before making a breaking change
  * Merge finished pull requests before merging breaking changes
* Label issues clearly
  * As either an `issue`, `enhancement` or `question`.
  * The `question` label indicates that there's a question about current
    functionality or future functionality.
* Label pull requests clearly
  * As either an `issue` or `enhancement`.
  * While being reviewed mark an additional `under-review` label if appropriate,
    so the community knows the status.
  * If a pull request requires changes by the creator an additional
    `requires-changes` label is appropriate.
  * Pulls that require core changes that aren't ready yet should be labeled
    with an additional `blocked` label.
Commit	Line	Data
24c7594d BB	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.