Maintainers

3 Maintainers should attend to a Contributions Daily Meeting where we sort and label new issues (is:issue label:status/0-needs-triage), and review every Pull Requests
Every pull request should be checked during the Contributions Daily Meeting
- Even if it’s already assigned
- Even PR labelled with or contributor/waiting-for-feedback
Issues labeled with priority/P0 and priority/P1 should be assigned.
Modifying an issue or a pull request (labels, assignees, milestone) is only possible:
- During the Contributions Daily Meeting
- In case of emergency, if a change proposal is approved by 2 other maintainers (on Slack, Discord, Discourse, etc)

The status needs-design-review is only used in complex/heavy/tricky PRs.
From 1 to 2: 1 comment that says “design LGTM” (by a senior maintainer).
From 2 to 3: 3 LGTM approvals by any maintainer.
If needed, a specific maintainer familiar with a particular domain can be requested for the review.
If a PR has been implemented in pair programming, one peer's LGTM goes into the review for free
Amending someone else's pull request is authorized only in emergency, if a rebase is needed, or if the initial contributor is silent

Update and Merge Pull Request.

The maintainer giving the final LGTM must add the status/3-needs-merge label to trigger the merge bot.

By default, a squash-rebase merge will be carried out. To preserve commits, add bot/merge-method-rebase before status/3-needs-merge.

The status status/4-merge-in-progress is only used by the bot.

In such a situation, solve the conflicts/CI/… and then remove the label bot/need-human-merge.

To prevent the bot from automatically merging a PR, add the label bot/no-merge.

The label bot/light-review decreases the number of required LGTM from 3 to 1.

This label is used when:

closes stale issues [cron]
- use some criterion as number of days between creation, last update, labels, …

Add labels on new PR [GitHub WebHook]
Add milestone to a new PR based on a branch version (1.4, 1.3, …) [GitHub WebHook]
Add and remove contributor/waiting-for-corrections label when a review request changes [GitHub WebHook]
Weekly report of PR status on Slack (CaptainPR) [cron]

A maintainer that looks at an issue/PR must define its kind/*, area/*, and status/*.

The status/* labels represent the desired state in the workflow.

status/0-needs-triage: all the new issues and PRs have this status. [bot only]
status/1-needs-design-review: needs a design review. (only for PR)
status/2-needs-review: needs a code/documentation review. (only for PR)
status/3-needs-merge: ready to merge. (only for PR)
status/4-merge-in-progress: merge is in progress. [bot only]

: we need more information from the contributor in order to analyze a problem.
contributor/waiting-for-feedback: we need the contributor to give us feedback.
contributor/waiting-for-corrections: we need the contributor to take actions in order to move forward with a PR. (only for PR) [bot, humans]
contributor/needs-resolve-conflicts: use it only when there is some conflicts (and an automatic rebase is not possible). (only for PR) [bot, humans]

kind/enhancement: a new or improved feature.
kind/question: a question. (only for issue)
kind/proposal: a proposal that needs to be discussed.
- Proposal issues are design proposals
- Proposal PRs are technical prototypes that need to be refined with multiple contributors.
kind/bug/possible: a possible bug that needs analysis before it is confirmed or fixed. (only for issues)
kind/bug/fix: a bug fix. (only for PR)

resolution/duplicate: a duplicate issue/PR.
resolution/declined: declined (Rule #1 of open-source: no is temporary, yes is forever).
WIP: Work In Progress. (only for PR)

Automatically set by a bot.