Skip to content

Commit

Permalink
doc: reduce repetitiveness on Consensus Seeking
Browse files Browse the repository at this point in the history
Rearrange Consensus Seeking section to reduce repetitiveness.

Ref: #34639 (comment)
Ref: #34639 (comment)

PR-URL: #34702
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Guy Bedford <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
  • Loading branch information
mmarchini authored and addaleax committed Sep 22, 2020
1 parent 335b61a commit 653d88a
Showing 1 changed file with 18 additions and 19 deletions.
37 changes: 18 additions & 19 deletions doc/guides/collaborator-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,34 +114,33 @@ pull request creator pushed new code since the last CI run.

### Consensus Seeking

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
A pull request may land if it has the needed [approvals](#code-reviews),
[CI](#testing-and-ci), [wait time](#waiting-for-approvals) and no
[outstanding objections](#objections). [Breaking changes](#breaking-changes)
must receive [TSC review](#involving-the-tsc) in addition to other
requirements. If a pull request meets all requirements except the
[wait time](#waiting-for-approvals), please add the
[`author ready`](#author-ready-pull-requests) label.

If a collaborator believes a pull request should not land as is, **the "Request
Changes" GitHub feature must be used to make the objection explicit**. An
implicit objection not using the "Request Changes" feature is not a
blocker for a pull request. Pull requests with an explicit objection should
not land until all objections are satisfied. Collaborators should not block a
pull request without providing a reason. **Providing a set of actionable steps
alongside the objection is recommended, and the objector must be willing to
work with the pull request author to reach a consensus about the direction of
the pull request**. If reaching consensus is not possible, a Collaborator may
escalate the issue to the TSC.
#### Objections

**Collaborators may object to a pull request by using the "Request
Changes" GitHub feature**. Dissent comments alone don't constitute an
objection. **Any PR objection must include a clear reason for that objection,
and the objector must remain responsive for further discussion towards
consensus about the direction of the pull request**. Providing a set of
actionable steps alongside the objection is recommended.

If the objection is not clear to others, another Collaborator may ask an
objecting Collaborator to explain their objection or to provide actionable
steps to resolve the objection. **If the objector is unresponsive for seven
days after a collaborator asks for clarification, another Collaborator may
dismiss the objection**.

[Breaking changes](#breaking-changes) 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, a
Collaborator may apply the `tsc-agenda` label. That will put the pull request on
the TSC meeting agenda.
**Pull requests with outstanding objections must remain open until all
objections are satisfied**. If reaching consensus is not possible, a
Collaborator may escalate the issue to the TSC by pinging `@nodejs/tsc` and
adding the `tsc-agenda` label to the issue.

#### Helpful resources

Expand Down

0 comments on commit 653d88a

Please sign in to comment.