Establish criteria for `quick win` and first-time contributor issues
See parent issue: Issue Discovery Improvement Plan (#512)
Summary
This issue discusses the criteria to use for quick win and first-time contributor issues. This issue is part of the Issue Discovery Improvement Plan (#512).
Contributors, especially first-time contributors, will be directly guided to find and work on issues with these labels through the upcoming community onboarding steps, the Tutorial, and the contribute to development documentation.
-
Document criteria in the handbook -
Documented for quick win (https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#criteria-for-quick-win-issues) -
Documented for first-time contributor issues (proposed scoped label added for quick win::first-time contributor
-
-
Set criteria for gitlab-bot
in triage-ops-
Set for quick win -
Set for quick win::first-time contributor
-
- Retroactively collect all issues previously labeled
-
Run for quick win -
Run for quick win::first-time contributor
-
Working draft of criteria
quick win
- Requires a completed "Implementation plan/guide / Instructions" that broadly outlines what a contributor needs to do in order to complete the issue
- Check for a non-empty
## Implementation plan
section. We could make sure that there is at least one non-empty line between that header and the next one (or the end of the description). - If this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria
- Check for a non-empty
- Requires an issue weight of 0 to 3
- If this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria
- While issue weight is quite subjective the point here would be to get the author/team member to consider how challenging the issue might actually be for a contributor when applying the quick win label
-
Requires aworkflowready for developmentlabelIf this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria-
This is tricky, while we want contributors to work on valid issues, it makes it difficult for someone to apply thequick winlabel to an issue that hasn't been validated yet or is in process of being validated. -
Could also allow any of the Product Development Flow labels e.g.workflowvalidation backlog workflowready for design workflowdesign workflowproblem validation workflowsolution validationetc. indicating validation steps are in place for the issue Contributors are always instructed to validate an issue in a new comment when they find something to work on so it's a question of who we put more responsibility on here
quick win::first-time contributor
- Requires quick win
- If this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria
- Requires issue weight of 0 to 1
- If this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria
- Requires workflowready for development (if this is not already included in quick win criteria)
- If this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria
- Requires a designated contact for support/questions (e.g. a GitLab team member's name/handle is listed)
- Have at least one row starting with
Support contact:
and have one or more usernames after inside of the## Implementation plan
section - If this criteria is not met, the label is removed and a note for the author is left with the instructions & handbook page link on meeting criteria
- Have at least one row starting with
Edited by Daniel Murphy