[RFC] How to accellerate the patch flow (or should we?)

A typical lifecycle of a patch series sent to the list ought to be as follows:

 1. You write a solution, describe the problem and solution in a
    patch series, send it to the list.

 2. People notice, take interest in, and comment on these patches.

 3. After #2 above, you may find it necessary to produce an updated
    version.  Go back to #1.

 4. While the above cycle is running, the maintainer may queue it in
    'seen', for two purposes.  (1) not to lose sight and forget
    about the change.  (2) to catch potential conflicts and overlaps
    with other in-flight topics to keep their interaction manageable.

 5. The maintainer notices that the discussion has reached a
    conclusion that the patch series is in a good shape, and merges
    it to 'next'.

 6. If a problem is found while the topic is in 'next', the topic
    may be marked as 'on hold' until an incremental solution to the
    problem is created.  This step may repeat while the topic is in
    'next'.  If the problem, which hasn't been noticed before #5
    happend, turns out to be so severe, the topic may have to be
    ejected out of 'next' for fresh restart.

 7. If 7 calendar days passes since the topic was merged to 'next'
    (or any incremental fixes are also added and merged to 'next')
    without any further finding of more problems, the topic gets
    merged to 'master'.  We often call this 'graduating'.

 8. Any further updates (enhancements and bugfixes) to the already
    graduated topic goes through the same cycle as a new and
    independent topic, starting from #1.

The time taken during the 1..3 cycle and number of iterations to get right cannot be really shrunk without making our developers work harder and there are only 24 hours in a day. And I do not think we can realistically "make our developers work hader", as everybody's priority is different.

The time taken during 7. is pretty much fixed and unless we are willing to sacrifice the quality of the end result, cannot reasonably be shortened (note that this is based on the assumption that "find any remaining bugs while it is in 'next' before it hits 'master'" philosophy is working, but we have never run experiments to shorten this to say 3 days to see if we see more bugs on 'master' yet).

But I wonder if 5. can be accellerated without sacrificing the quality of the end result, every time I send out a "ping" e-mail to old discussion thread, with "The discussion seems to have petered out at this point. Is everybody happy?" Either I could have sent such "ping"s earlier, or reviewers who were involved in the review could have given a positive "oh, this looks good. let's declare a victory" sooner. Of course, from the point of view of distributing the load and making the process as parallelized as possible, the latter is more preferrable.

Let's take a handful of topics that graduated to 'master' on 2025-09-23 and examine how much they spent in each phase.

  * cs/subtree-squash-split-fix: The topic took 3 iterations (v1:
    2025-08-24, v2: 2025-09-05, v3: 2025-09-10).

  After <dd71ebee-8629-43c3-aa2a-40124400f262@gmail.com> gave an Ack,
  the topic was picked up to 'seen' on 2025-09-11, and then 42063163
  (Merge branch 'cs/subtree-squash-split-fix' into next, 2025-09-15)
  merged it to 'next'.  We probably could have merged it to 'next' a
  few days earlier.

  * rs/get-oid-with-flags-cleanup: a single iteration (2025-09-10)

  The topic was picked up to 'seen' on the same day,
  <aMevTM6YESMDdWPh@pks.im> gave an ack on 2025-09-15, triggering
  its merge to 'next' on the same day at ff8d1faa (Merge branch
  'rs/get-oid-with-flags-cleanup' into next, 2025-09-15).  I think
  this is an example of the process working perfectly for an
  uncontroversially good small change.

  * jk/add-i-color: 2 iterations (v1: 2025-08-21, v2: 2025-09-08).

  The first iteration was sent on 2025-08-21 after a bug report filed
  on the previous day.  After a few review exchanges starting
  2025-09-03, the second iteration sent on 2025-09-08 was acked on the
  next day.  The topic was merged on 2025-09-15, after spending a week
  in 'seen' outside 'next'.  I do not recall the details, but perhaps
  it was during relatively busy period, or there were topics that
  touched overlapping areas, or something?  Or perhaps maintainer
  fatigue?

  * cc/promisor-remote-capability: 8 iterations (v1: 2025-04-14,
    v2: 2025-04-29, v3: 2025-05-19, v4: 2025-06-11, v5: 2025-06-25,
    v6: 2025-07-21, v7: 2025-07-31, v8: 2025-09-08).

  Past round 4 or so we started seeing fewer reviews if any.  The
  topic has lived almost since its inception in 'seen' until the last
  round was merged to 'next' at 367d83c0 (Merge branch
  'cc/promisor-remote-capability' into next, 2025-09-15).  Again, this
  last round wasted 7 days in 'seen' without any activity, which I
  wonder if we could have somehow avoided?

Opinions and ideas to help topics not to waste too much time waiting for step 5. is very much appreciated. The most radical idea I can think if is to introduce two more "maintainers" and any two of them can vote to merge a topic in 'seen' to 'next' without waiting for the other maintainer, but there may be simpler approaches that do not require huge workflow changes.

Thanks.