Proposal: New workflow for merge-process (Catalysts / Maintainers)

[p-i-]

Duplicates

• [X] I have searched the existing issues

Summary 💡

The PROBLEM

• We're undergoing a re-arch
  • Most maintainers are busy on this
  • We lack maintainer firepower to keep the Issue/PR revew-merge pipeline flowing
• We're getting a backlog, and this is stalling the project
• We now have HUGE Catalyst firepower, but only one or two maintainers available to execute merges

The CHALLENGE

• How to unblock our pipeline and effectively use the human resources available?

Proposed Solution

• We organize amongst Catalysts

  • 2 have volunteered to act as Lead Catalyst

    • Bernardus (EUR timezone) 🙏
    • Luke (USA timezone) 🙏

  • Lead Catalysts can organize Catalysts

• We evolve our WORKFLOW

  • Check the proposed kanban

    • A new issue/PR is auto-added to the New column (we encourage the creation of DRAFT-PRs with the idea in the description)

    • A Catalyst scans this column and moves potentially valuable cards into the Interesting+InProgress column

    • A maintainer/LeadCatalyst cherry-picks cards for the Milestoned/ScheduledForRelease column, assigning a milestone (e.g. next release, release after that, next major release -- I think we just have these 3 so far and that should do us well enough)

    • Now a Catalyst self-assigns to the card, and works with the dev (and maybe our dev-community, maybe our badged Testers on Discord) to get this PR working, tested, and ready for merge, at which point it is moved to the Tested/ReadyForMerge column

    • Now a Maintainer has an easy job merging cards in this column (moving them to the BeingMerged column), able to check in with the Catalyst that self-assigned to the card if need be

(NOTE: These names need some work; naming things is a HARD problem :-])

How does this look (user-stories)

• As a Developer who is adding to the codebase, I just want to know the state of my PR and whether or not I need to action something.
• As a Catalyst, I want to know which things need to be reviewed and prioritised.
• As a Tester, I want to know which things I need to test
• As a Maintainer i want to know what to merge.

How do we move on this?

• This proposal will be posted in the #dev-contributors-chat channel on the Discord, under a new thread.

  • Conversation is invited both here and on Discord

• Once everything's been evaluated, we move on this (~t+24h)

Other related moves/stuff

• If you're interested to operate as a Catalyst, please check the wiki page

  • If you're still interested, please DM pi#8377 on Discord to get a Catalyst badge

• If you're interested to operate as a Maintainer, the path is through working as a Catalyst. We're looking for engineers comfortable with the codebase at a granular level to operate as Maintainers.

Examples 🌈

...

Motivation 🔦

...

[p-i-]

Here's a suggestion (from the Catalysts' ConfRoom on Discord):

A catalyst with coding skills can fast-track a PR by fixing it.

• They create their own branch
• They merge in the PR
• They fix it up
• They TEST it :) (write tests if appropriate)
• They put the card in the Tested/ReadyForMerge column
• A maintainer merges it

This way the original author gets the kudos, and we don't need to wait on them for fixes.

ALSO this facilitates a move from Catalyst -> Maintainer

Currently maintainers are already doing this to speed up the merge process.

[p-i-]

Discord thread for the above: https://discord.com/channels/1092243196446249134/1097204317125091328/1108152352868925542

[Boostrix]

Honestly, it's a waste of manpower/resources to require a maintainer to review all PRs - there are some trivial ones like documentation updates, updated comments/doc strings or other non-code PRs that could probably be just as well reviewed by catalysts. Not sure if github can be taught to apply heuristics here, but absent that - let's just give lead-catalysts the power to review/merge, with the only requirement/convention being to always get 1-2 other catalysts involved to review the PR.

Given the agility of the project that may work well enough: give maintainer access to lead catalysts and those would by convention coordinate 1-2 other catalysts to clean up the PR accordingly.

I don't think we should bother maintainers for non-code stuff.

Alternatively, let's talk about introducing a dedicated "candidate-PRs" branch where catalysts can self-manage and merge stuff to prepare it for being reviewed/cherry-picked from by maintainers ?

Like you said, maintainers are the bottleneck - but we absolutely shouldn't be bothering them for non-code PRs

[github-actions[bot]]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[github-actions[bot]]

This issue was closed automatically because it has been stale for 10 days with no activity.