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

doc: rewrite consensus seeking in guide #23349

Closed
wants to merge 3 commits into from
Closed

doc: rewrite consensus seeking in guide #23349

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
664a248
doc: rewrite consensus seeking in guide
Trott Oct 9, 2018
cf16b2c
fixup! doc: rewrite consensus seeking in guide
Trott Oct 11, 2018
4f4aea3
fixup! doc: rewrite consensus seeking in guide
Trott Oct 11, 2018
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
43 changes: 20 additions & 23 deletions COLLABORATOR_GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,29 +139,26 @@ the CI outcome.

### Consensus Seeking

If there is no disagreement amongst Collaborators, a pull request should be
landed given appropriate review, a green CI, and the minimum
[waiting time](#waiting-for-approvals) for a PR. If it is still awaiting the
[minimum time to land](#waiting-for-approvals), please add the `author ready`
label to it so it is obvious that the PR can land as soon as the time ends.

Where there is discussion amongst Collaborators, consensus should be sought if
possible. The lack of consensus may indicate the need to elevate discussion to
the TSC for resolution.

If any Collaborator objects to a change *without giving any additional
explanation or context*, and the objecting Collaborator fails to respond to
explicit requests for explanation or context within a reasonable period of
time, the objection may be dismissed. Note that this does not apply to
objections that are explained.

Note that breaking changes (that is, pull requests that require an increase in
the major version number, known as `semver-major` changes) must be [elevated for
review by the TSC](#involving-the-tsc). This does not necessarily mean that the
PR must be put onto the TSC meeting agenda. If multiple TSC members approve
(`LGTM`) the PR and no Collaborators oppose the PR, it should be landed. Where
there is disagreement among TSC members or objections from one or more
Collaborators, `semver-major` pull requests may be put on the TSC meeting
If there are no objecting Collaborators, a pull request may land if it has the
needed [approvals](#code-reviews), [CI](#testing-and-ci), and
[wait time](#waiting-for-approvals). If a pull request meets all requirements
except the [wait time](#waiting-for-approvals), please add the
[`author ready`](#author-ready-pull-requests) label.

Where there is disagreement among Collaborators, consensus should be sought if
possible. If reaching consensus is not possible, a Collaborator may escalate the
issue to the TSC.

Collaborators should not block pull requests without providing a reason. Other
Collaborators may ask objecting Collaborators questions about their objections.
If an objecting Collaborator is unresponsive, another Collaborator may dismiss
their objection.
Copy link
Member

Choose a reason for hiding this comment

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

Collaborators should not block a pull request without providing a reason.
Questions may be asked about why a collaborator objects. If the objector
is unresponsive, the objection may be dismissed.

Copy link
Member

Choose a reason for hiding this comment

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

Not for this PR, but: timeslot?

Copy link
Member

@ChALkeR ChALkeR Oct 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Also, this new wording (in PR) could cause confusion.

Other Collaborators may ask objecting Collaborators questions about their objections.
If an objecting Collaborator is unresponsive, another Collaborator may dismiss their objection.

This could be read as if any objection could be dismissed after the objector becomes unresponsive, even if they feel that they answered all questions already.

The variant that @jasnell proposed is better, but I would prefer to keep the «Note that this does not apply to objections that are explained.» part.

Copy link
Member

Choose a reason for hiding this comment

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

The original text did have the loose within a reasonable period of time.


Note that [breaking changes](#breaking-changes) must receive
Copy link
Member

Choose a reason for hiding this comment

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

[Breaking](#breaking-changes) (`semver-major`) must receive
[TSC review](#involving-the-tsc). If two TSC members approve
the pull request and no Collaborators object, then it may land.
If there are objections, the TSC may be asked to give additional
consideration (by adding the `tsc-review` label), or the pull
request may be put on the TSC meeting agenda (by adding the
`tsc-agenda` label).

[TSC reviews](#involving-the-tsc). This does not mean that a Collaborator must
put the pull request on the TSC meeting agenda. If two TSC members approve the
pull request and no Collaborators object to the pull request, it may land. If
there are objections, a Collaborator may put the pull request on the TSC meeting
agenda.

#### Helpful resources
Expand Down