meta: clarify pr objection process further

Based on some recent confusion around the objection
process for PRs, this commit adds some additional
clarification to the collaborator guide.

Specifically, it clarifies that:

* Objections must be made in the PR itself
* All objections are considered equal... no special
  additional weight is given to objections from TSC
  members.
* When mistakes happen and a PR lands despite having
  an unresolved objection, any revert or fixup PR
  is subject to the same regular objection process,
  albeit with a callout that fast-tracking is
  possible if uncontroversial.

PR-URL: https://github.com/nodejs/node/pull/59096
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Ruy Adorno <ruy@vlt.sh>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Stewart X Addison <sxa@redhat.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
This commit is contained in:
James M Snell 2025-08-06 07:30:52 -07:00 committed by GitHub
parent 134625d761
commit 31aacfa67c
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -154,10 +154,13 @@ requirements. If a pull request meets all requirements except the
Collaborators can object to a pull request by using the "Request
Changes" GitHub feature. Dissent comments alone don't constitute an
objection. Any pull request 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. Where possible,
provide a set of actionable steps alongside the objection.
objection, nor do dissenting comments made in any associated issue.
A blocking objection to a change must be made in the pull request that
specifically proposes that change. Any pull request 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. Where possible, provide a set of actionable steps alongside the
objection.
If the objection is not clear to others, another collaborator can ask an
objecting collaborator to explain their objection or to provide actionable
@ -168,7 +171,22 @@ dismiss the objection.
Pull requests with outstanding objections must remain open until all
objections are satisfied. If reaching consensus is not possible, a
collaborator can escalate the issue to the TSC by pinging `@nodejs/tsc` and
adding the `tsc-agenda` label to the issue.
adding the `tsc-agenda` label to the issue. The change cannot proceed without
either reaching consensus or a TSC decision to dismiss the objection(s). If the
TSC does choose to dismiss any objections, a clear explanation of the reasoning
or a link to the public vote must be given in the pull request before it lands.
All Collaborator objections are considered equal. There is no greater weight given to
objections from TSC members than from any other Collaborator.
Mistakes do happen. If a pull request is merged with an unresolved objection,
submit a fix. Simple issues may be fixed with a follow-up PR that addresses
the concern. More difficult issues may require a full revert. Most corrections
can be fast-tracked. If deemed necessary take a slower route to ensure stability
and consensus.
Collaborators objecting to a pull request can best ensure their objections
are addressed by remaining engaged and responsive in the discussion.
#### Helpful resources