Meta: methods of objection

[devsnek]

The collaborator guild mentions that collaborators may object, but does not define the method of the objection. I assume it is unspecified on purpose, but it may be helpful to codify it to avoid situations like #34562. For example, we might require objection to come with github's "request changes" feature.

[mmarchini]

I think we avoided the Request Changes feature because of the "aggressiveness" subtext that can be implied from it. If that's still a concern, maybe we could use a label (although if there are multiple objections this could still be an issue when only one objection is withdrawn). I think I saw more widespread use of the "Request Changes" feature lately in the repo, so it might be ok for us to recommend using it from now on.

[guybedford]

In the case in #34467 (comment) I took "I am not a fan of this" as an indication of preference and opinion and not as a formal objection. It seems that was the underlying misunderstanding in the choice of wording being misinterpreted but agreed it is better to give the benefit of the doubt in such cases.

Personally I would prefer that objections require some formality to them to avoid confusions like this in future.

[jasnell]

Fortunately, GitHub has made changes to the "Request Changes" flow that make it significantly less aggressive and less scary. I don't think use of a label is going to more any more effective than that workflow, and I'd prefer that we rely on it.

The larger issue with objections that I've seen are blocking objections from one or two individuals who do not follow up with any attempt at resolving the block. These generally fall into the category, "My opinion is.... therefor I'm blocking this" without any other rationale or effort. Fortunately, these are rare, but they can be extremely annoying when there is zero engagement or room for compromise on the part of the person blocking.

[mmarchini]

The larger issue with objections that I've seen are blocking objections from one or two individuals two do not follow up with any attempt at resolving the block. These generally fall into the category, "My opinion is.... therefor I'm blocking this" without any other rationale or effort.

No follow up is grounds to dismiss the objection per our current policy, although we don't stipulate how long until the objection can be dismissed (and we rarely dismiss objections anyway).

I'm happy adding "Request Changes" as a requirement (or strong recommendation) for collaborators to explicitly object to something. ncu even checks for objections that way, which is quite useful to avoid accidentally landing objected PRs.

"My opinion is.... therefor I'm blocking this" without any other rationale or effort. Fortunately, these are rare, but they can be extremely annoying when there is zero engagement or room for compromise on the part of the person blocking.

We might want to elaborate more how collaborators should object, making it clear that objections should not be based solely on personal preference and the objector must be willing to work collaboratively in a non-obstructive or combative manner to reach consensus or find a different solution.

[Trott]

I'm happy adding "Request Changes" as a requirement (or strong recommendation) for collaborators to explicitly object to something.

I think that's exactly the thing to do here.

[guybedford]

I would really value us making such a requirement. There shouldn't have to be any doubt as to the existence or nature of an objection, and ensuring things are always completely clear seems like it would aid collaboration.

[joyeecheung]

I usually only use "Request Changes" when I actually want to block it (just like some people also do, I believe), and I try to leave some comments about what I'd like to see before it can be dismissed (which is me trying to imply that "if for whatever reason I fail to come back when what I would like to see is done, please dismiss it for me"). If I don't use that button it means that my comments are non-blocking. I think it would be nice to make that formality a thing (so that node-core-utils can check it).

[mmarchini]

I think it would be nice to make that formality a thing (so that node-core-utils can check it).

I think node-core-utils already does that. If not, we can add a check for it.

[mmarchini]

Just confirmed, ncu detects requested changes and will add a ❌ in that case:

[mmarchini]

#34639