Thanks Daan for raising this, just sharing my 2 cents: I don't think the 4-week inactivity period for merging PRs is a good idea. I agree with Slavka that this approach can be risky, also considering that we do have release managers actively triaging PRs and issues to be included in the release.
In these cases I would expect release managers to review the PRs and decide whether additional reviews are needed or whether a PR can be merged at a certain point, instead of leaving it to the PR author to perform a self-merge. Regards, Nicolas Vazquez El mar, 3 nov 2026 a las 8:42, Slavka Peleva (<[email protected]>) escribió: > Hi all, > > > First of all, I’d like to thank Daan for raising this important question. > Recently, we’ve seen instances where some maintainers take matters into > their own hands and self-merge their code. This can definitely discourage > committers and external contributors, creating a feeling of double > standards—where some feel 'left behind' or treated differently than others. > It is crucial that we establish strict, fair rules so that everyone, > regardless of their official status in the project, feels valued and plays > by the same rules. > > > Regarding the specific proposal for a 4-week self-merge option, while I > completely share the frustration about PRs stalling and want to find a way > to speed things up, I feel this approach is too risky for a few reasons: > > 1. *Blind spots in testing:* We all have blind spots regarding our own > code. We test based on the same assumptions we used to write it, making it > very easy to miss critical edge cases or integration issues that a fresh > pair of eyes would catch. > 2. *Risk of quality and security loopholes:* Allowing self-merges > after inactivity could unintentionally create a loophole. Low-quality or > problematic code could slip through simply because a PR managed to 'wait > out' the 4-week window during a quiet period in the community. > > Since we are a global, asynchronous community working across different > time zones, synchronous meetings are not realistic. Instead, we could look > at how other distributed open-source projects improve review velocity > fairly and transparently using asynchronous methods: > > - *Automated Reviewer Assignment (CODEOWNERS):* Automatically tagging > specific maintainers based on the changed files, so the responsibility for > the review is clearly assigned and doesn't fall into a void. > - *Stale Bots & Reminders:* Automated pings in GitHub/Mailing lists > when a PR has been inactive for more than two weeks, bringing the focus > back to forgotten PRs. > - *Asynchronous Triage Queue:* Using automated labels (like > needs-review or prioritizing by age) so maintainers can easily spot and > unblock the oldest pending PRs whenever they log in, regardless of their > time zone. > > This way, we can make the process faster, fair, and more transparent for > everyone, while still keeping our codebase secure and thoroughly reviewed. > > Best regards, > Slavka > > On Tue, 3 Nov 2026 at 10:46, Daan Hoogland via private < > [email protected]> wrote: > >> People, >> >> Since very early in the project we had maintained the standard that any >> PR will need >> - two reviews >> - at minimal one review containing a test report >> We also stated some exception; >> - text only changes >> - changes to test code >> - changes to ci code >> Lately, mostly with the involvement of storage vendors we had let that >> go. I remember that we would allow PRs that need specific hard- or >> software, if the vendor would add a test report to their own PR (citation >> needed!) >> >> Now there are two amendment that I want to make to that practice: >> - I want formulising it in some textual form in our git repo. >> - I want to add that users that tested their own code can merge it if >> after a period of four weeks nobody else tested it to prove some flaw and >> made an objection. >> >> Especially the last one is a significant change. The intention is for >> users to be able to get through the large backlog we have and have fixes >> and enhancements that are vital to them merged. >> >> thoughts? >> >> regards, >> >
