Stop using the "accepting merge requests" label
Spun off from https://gitlab.com/gitlab-org/quality/contributor-success/team/-/issues/77
- 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. - The label introduces duplication (the logic used to apply the label could simply be used to search for the issues).
- We want to reconsider the criteria the wider community use when looking for issues to work on. Ideally, we should more closely align with team members (e.g. use workflow labels- and not exclude anything- although something may be workflowplanning breakdown, that shouldn't stop a wider community member being involved in the planning).
Proposal
-
Reach out to team members and the wider community to make sure we have considered all arguments for/against -
Remove from the handbook/docs: gitlab-com/www-gitlab-com!114435 (merged) -
Remove from the bot: gitlab-org/quality/triage-ops!1754 (merged) -
Mark the label as deprecated (with a link to this issue) -
Communicate internally and externally
Edited by Lee Tickett