Signing off on own requested changes

[mscdex]

• Version: n/a
• Platform: n/a
• Subsystem: n/a

Currently pull requests submitted by non-collaborators only need a sign off by one collaborator in order to get merged. I think this rule should be tweaked to require at least two collaborators when the non-collaborator is making a change originally requested/suggested by an existing collaborator who signs off on the PR, to help remove any bias.

[Trott]

Given the large number of collaborators that we now have (116 and growing), it might be reasonable to simply increase the number of required approvals from one to two in all cases.

[targos]

+1. Always two is easier to verify / remember.

[mscdex]

That's fine by me too.

[jasnell]

-0 ... I'm fine with saying should be 2+, I'd be -1 on making it a must be 2+ in all cases.

[Trott]

Arguably, this is what the 48-hour waiting period is for. It gives others time to object. So another approach might be to require 2+ for only fast-track PRs. But I suspect that doesn't solve the problem @mscdex has apparently experienced.

[Trott]

I'd be -1 on making it a must be 2+ in all cases.

@jasnell Can you please explain why? (I'm not disagreeing with you, as I have yet to form my own opinion on this. Saying "I'm -1 on this" doesn't help the consensus-seeking conversation the way "I'm -1 on this because X, Y, and Z" would.)

[mscdex]

Sometimes PRs get "lost" amongst the other PRs, especially over 48/72-hour periods, so having a time window does not always work. It's especially a problem IMHO when there were objections in the original issue that led to the PR (and those who objected do not know the PR was made).

[vsemozhetbyt]

So another approach might be to require 2+ for only fast-track

This is already set.

[jasnell]

Because it's unnecessary and there are often times when the change is so obscure or limited in scope that very few have enough context to sign off on it. Making it a must can needlessly delay landing important fixes that should be landed.

I agree with @mscdex that no change should land if there are objections, and objections about whether the change should be made at all being discussed in the original issue and not the PR count towards that.

@vsemozhetbyt

This is already set.

Oh! nice, I'd forgotten about that. I even think I've inadvertently not followed that rule on a couple of simple obscure minor edits. Good to have the reminder.

[vsemozhetbyt]

Timely ref) https://blog.github.com/2018-03-23-require-multiple-reviewers/

[apapirovski]

I agree with @jasnell here. A great many http2, StreamBase, timers, etc. PRs have landed with a single approval because there aren't enough people available with the required expertise to review in a timely manner.

[devsnek]

that option only controls if you use the UI to merge a pr right? most PRs are landed by applying the diff and pushing from a collabs computer

[vsemozhetbyt]

To be honest, I found these big red spots with crosses a bit intimidating and discouraging for new contributors.

[vsemozhetbyt]

It seems this also means git pushing, if I get this right: https://help.github.com/articles/about-required-reviews-for-pull-requests/ (the example at the end).