admin/brew
1
0
Fork 0
Code Issues Packages Projects Releases 6 Wiki Activity

docs/Maintainer-Guidelines: address maintainer feedback.

Browse Source
This commit is contained in:
Mike McQuaid 2018-09-07 08:56:01 +01:00
parent 9db1feb3da
commit 9d8b101ede
No known key found for this signature in database
GPG Key ID: 48A898132FD8EE70
1 changed files with 7 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/Maintainer-Guidelines.md
View File

@ -107,9 +107,8 @@ is a good opportunity to do it) provided the line itself has some kind
of modification that is not whitespace in it. But be careful about
making changes to inline patches—make sure they still apply.
### Adding formulae
Only one maintainer is necessary to approve and merge the addition of a new formula which passes CI. However, if the formula addition
is controversial the maintainer who adds it will be expected to fix issues that arise with it in future.
### Adding or update formulae
Only one maintainer is necessary to approve and merge the addition of a new or updated formula which passes CI. However, if the formula addition or update is controversial the maintainer who adds it will be expected to fix issues that arise with it in future.
### Removing formulae
Formulae that:
@ -123,12 +122,12 @@ Formulae that:
should not be removed from Homebrew. The exception to this rule are [versioned formulae](Versions.md) for which there are higher standards of usage and a maximum number of versions for a given formula.
### Closing issues/PRs
Maintainers (including the lead maintainer) should not close issues or pull requests opened by other maintainers unless they are stale (i.e. have seen no updates for 28 days) in which case they can be closed by any maintainer. If the close is undesirable: no big deal, they can be reopened when additional work will be done.
Maintainers (including the lead maintainer) should not close issues or pull requests opened by other maintainers unless they are stale (i.e. have seen no updates for 28 days) in which case they can be closed by any maintainer. Any maintainer is encouraged to reopen a closed issue when they wish to do additional work on the issue.
Any maintainer can merge any PR passing CI that has been opened by any other maintainer. If you do not wish to have other maintainers merge your PRs: please use the `do not merge` label to indicate that until you're ready to merge it yourself.
Any maintainer can merge any PR they have carefully reviewed and is passing CI that has been opened by any other maintainer. If you do not wish to have other maintainers merge your PRs: please use the `do not merge` label to indicate that until you're ready to merge it yourself.
## Reverting PRs
Any maintainer can revert a PR created by another maintainer after a user submitted issue or CI failure that results. The maintainer who created the original PR should be given an hour to fix the issue themselves or decide to revert the PR themselves if they would rather.
Any maintainer can revert a PR created by another maintainer after a user submitted issue or CI failure that results. The maintainer who created the original PR should be given no less than an hour to fix the issue themselves or decide to revert the PR themselves if they would rather.
## Communication
Maintainers have a variety of ways to communicate with each other:
@ -143,7 +142,7 @@ This makes it easier for other maintainers, contributors and users to follow alo
All maintainers (and lead maintainer) communication through any medium is bound by [Homebrew's Code of Conduct](CODE_OF_CONDUCT.md#code-of-conduct). Abusive behaviour towards other maintainers, contributors or users will not be tolerated; the maintainer will be given a warning and if their behaviour continues they will be removed as a maintainer.
Healthy, friendly, technical disagreement between maintainers is actively encouraged and should occur in public on the issue tracker. Off-topic discussions on the issue tracker, [bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality) and personal attacks are forbidden.
Maintainers should feel free to pleasantly disagree with the work and decisions of other maintainers. Healthy, friendly, technical disagreement between maintainers is actively encouraged and should occur in public on the issue tracker to make the project better. Interpersonal issues should be handled privately in Slack, ideally with moderation. If work or decisions are insufficiently documented or explained any maintainer or contributor should feel free to ask for clarification. No maintainer may ever justify a decision with e.g. "because I say so" or "it was I who did X" alone. Off-topic discussions on the issue tracker, [bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality) and personal attacks are forbidden.
## Lead maintainer guidelines
There should be one lead maintainer for Homebrew. Decisions are determined by a consensus of the maintainers. When a consensus is not reached, the lead maintainer has the final say in determining the outcome of any decision (though this power should be used sparingly). They should also be seen as the product manager for Homebrew itself and ensuring that changes made to the entire Homebrew ecosystem are consistent and providing an increasingly positive experience for Homebrew's users.
@ -152,4 +151,4 @@ In the same way that Homebrew maintainers are expected to be spending more of th
Individual Homebrew repositories should not have formal lead maintainers (although those who do the most work will have the loudest voices).
Maintainers should feel free to pleasantly disagree with the work and decisions of the lead maintainer. Constructive criticism is actively solicited and will be iterated upon to make the project better. Technical criticism should occur on the issue tracker and interpersonal criticism should be handled privately in Slack. If work or decisions are insufficiently documented or explained any maintainer or contributor should feel free to ask for clarification. The lead maintainer may never justify a decision with e.g. "because I say so" or "it was I who did X" alone.
Maintainers should feel even more free to pleasantly disagree with the work and decisions of the lead maintainer. With greater authority comes greater responsibility to handle and moderate technical disagreements.