Migrate `seeking community contribution` to `workflow::ready for development` and remove the use of `Accepting merge requests`
Problem to solve
The issue label ~"Accepting merge requests" is the primary way for community members to find issues to contribute toward. Unfortunately this label has unintended side effects:
- The label is being over-applied: at last check, 46% of all gitlab issues had this label, and GitLab frequently receives contributions for these issues that we reject because we are not actually accepting merge requests. Internally at GitLab, we agree that we want to be more targeted in the use of this label, but we have struggled to agree on how to do that.
- The label can be misleading for issues that do not have it. As expressed by @godfat-gitlab: "Maybe ~"Accepting merge requests" is not a good term to begin with. It seems to somehow imply that issues without this label means we don't accept merge requests, but that's really not the case at all."
- The label has no obvious logical connection to the
community contribution
label that is used on merge requests.
Proposal
-
Delete the accepting merge requests
label, remove from all issues and remove from the bot and get that in production -
Communicate to EM/PMs that we plan to replace seeking community contribution
with workflowready for development and that they have 4 weeks to verify the issues they are responsible for.- Explain that if the issue is not ready to be developed, an appropriate workflow label like workflowdesign or workflowproblem validation should be added.
- Explain that Issues with existing workflow labels will have the
seeking community contribution
label removed. -
create an issue & assign to the EM / PM of each group. It could be simple a description of the change and with checkboxes for each group, like Database Dictionary Audit for Create:Source Code (gitlab-org/gitlab#359333 - closed) , but be an optional action. Add a link with a query by the group, like this one -
communicate it to #whats-happening-at-gitlab
-
After the grace period, we should replace seeking community contribution
with workflowready for development and remove theseeking community contribution
label. Issues with existing workflow labels will only have theseeking community contribution
label removed. -
Change our documentation so that it is clear that community contributions are welcome for all issues, and tips & tricks for smooth sailing. Eg, issues with milestones are already planned by PM/EMs. Issues with the low hanging fruit
label are easier to execute on, etc..
Follow up issues to create
-
If the workflowready for development label is applied, a bot posts a helpful comment with links to "getting started" resources for community contributors, as everyone is able to contribute. -
https://gitlab-org/quality/contributor-success/team/-/issues/68 the label low hanging fruit
can be applied if the issue has a low entry barrier, explain this to the entire community through multi-modal-communication0 -
Open a discussion on adding targets around having enough ~issues with "workflow::ready for development" as EM /PM OKRs -
Open a discussion to create a new label not ready for community contribution
, and guidance on how & when to apply that label -
Open a discussion if we should add a danger/bot automation that if a milestone is added, a workflow state should also be present
Other proposals considered
- Re-name the existing label. Unfortunately there are differing perspectives on this label, so it is difficult to re-name this label in a way that does not cause unwanted disruption.
- Other names considered: The proposal ~"Ready for merge requests" was rejected because we don't want to discourage community members from taking on an issue just because GitLab has not prepared it for execution yet. The proposal ~"Seeking merge requests" did not answer "from whom".
- Start over: "Maybe we can start over with
~"Ready for merge requests"
, which won't really imply we don't accept merge requests for issues lacking it, and for sure we can just delete ~"Accepting merge requests" to signal that we no longer want to use that to indicate what's good for contributions." From @godfat-gitlab - Use
Seeking community contributions
label more for "uncontroversial issues with clear solutions that GitLab is not planning to execute soon." as proposed in #3202 (comment 803436497)
Edited by Nick Veenhof