Proposal: remove minimal time limit for semver-patch prs

[jasnell]

@nodejs/tsc ... As we all painfully are aware, we enforce a minimal time period of 7248 hours to land all prs unless those are fast tracked. This can be rather.... Irritating.... When dealing with small patch changes and most of the time just causes needless delay.

I would like to propose that we completely eliminate the minimum time requirement for all non-semver minor and major prs. Those would still require minimal sign off from at least two contributors and passing ci with no outstanding objections.

If a pr lands that retroactively is recognized as being minor or major, then we would just revert.

[BridgeAR]

The minimum time is actually 48 hours. I suggest to open a PR to change/remove the minimal waiting time?

[jasnell]

Yeah, I'll open a PR soon but I want to see if there were any immediate objections first

[codebytere]

@jasnell I definitely recognize that it can be a needless delay for a lot of folks depending on the substance of a given PR, but i do think there's value in some minimum at least for time zone purposes. I'd be concerned that a potential stakeholder to a PR would miss out on the opportunity to review with no minimum at all if we don't allow them at least some reasonable time to catch it. What would you think about dropping down to 24 hours? I think that, while short enough to cause minimal imposition, at least casts a net across timezones.

[mscdex]

I think it's better to keep it as it is because:

• semver-patch PRs do not necessarily have to be simple/small changes, so making this the default is not a good idea.
• Keeping the rules for PRs as consistent as possible (and not having exceptions like this) makes things easier.

I think the fast tracking mechanism is already good enough for cases where it's absolutely necessary.

Additionally, I think by allowing more time for review it might help prevent the need for "fast tracked" followup PRs to fix missed issues with recently pushed PRs for example.

[jasnell]

@codebytere ... The delay just seems... Pointless ... Most of the time. In practice, I'd argue that most trivial prs would stay open for at least 24 hours anyway while any potential issues are worked through, or we know they're trivial and receive a bunch of people signing off quickly without any fanfare. Requiring the additional process just ends up feeling like process for the sake of it. If changes end up landing that shouldn't have, quick reverts are easy.

[bnoordhuis]

I regularly catch bugs, sometimes pretty severe bugs, in 10 line PRs with several sign-offs so yeah, I think there's value in not rushing things through. I like my merging like I like my dancing: slow, as to avoid accidents. :-)

[tniessen]

Alternatively, the first author approving a "trivial" change can suggest fast-tracking, and as soon as another collaborator approves the PR + fast tracking (and CI is green etc.), it can land.

[richardlau]

Given we sent out a contributor survey recently (#33583) I'd be interested if the minimal wait time came up in the responses.

[jasnell]

@richardlau ... the short answer is yes... the longer answer, which I will explore in the survey report back to the TSC is that a good number of survey respondents indicate frustration with our current contribution process.

[addaleax]

The results of the contributor survey (in nodejs/TSC#882) make it sound like this is definitely a problem.

I would also prefer to merge PRs faster, but I also feel like that should come with a more relaxed reverting policy; e.g., merge PRs without waiting, but also revert them without waiting¹, and if a collaborator requests that a PR gets a 48-hour waiting period for any reason, we respect that.

I also think this would reduce the amount of nits and optimization requests on PRs – because, honestly, it’s usually easier to perform minor fixups by oneself instead of commenting nits on PRs. It’s just hard to do that in our current model.

¹ (and without a separate PR just revert directly on master more importantly, without waiting for approvals or CI on the new PR)

[addaleax]

Opened #33879 which would implement that suggestion – I’m not set on that particular solution, but I’d like to see something happen.