Issue Discovery Improvement Plan

Summary

This issue plans out the steps for improving issue discovery for contributors to GitLab. This covers directing both first-time contributors and return contributors to appropriate issues that have been validated and meet certain criteria set by the Contributor Success team.

Related sub-issues

• Explore how to measure how many "good" issues w... (#508)
• Establish what constitutes as a "good" issue (#509)
• Document Community Epic creation process (#507)

Where we are today

• Contributing documentation instructs contributors to view all issues on GitLab.com with quick win and Seeking community contributions labels
  • This hasn't been effective to date
  • Many Seeking community contributions are in fact not seeking community contributions or are no longer valid issues
  • Many quick win issues are not quick or are not for first time contributors
• Tutorial: Make a GitLab contribution offers no guidance towards finding real issues after the tutorial
• Several issues currently use the 1st contribution label without having been validated and are multiple years old
• We have no tracking in place for what new contributors are finding any of these issues or if they are going from the Tutorial to finding an issue to work on
• The handful of repeatable issues (Like Rubocop violation fixes) that would be good for first time contributors are difficult to find
  • Issues like these can also be repeated by the same contributor rather than saving these for first time contributors
• Planning out contributing events requires research into available issues that would be good for first-time contributors rather than having a SSOT for finding them

Where we want to be

• Create a SSOT for curated issues that are available and can be completed by first-time contributors with little knowledge of GitLab or software development
• Have documented criteria on what makes a good first issue
• Have documented workflow process for GitLab groups to create these issues that meet Contributor Success criteria
• Use automation like @gitlab-bot to detect these issues and verify they meet certain criteria like including an implementation plan
• Guide contributors getting started with onboarding steps and the Tutorial directly to these curated issues
• Utilize our MR coaches to offer support to first-time contributors for these specific issues
• Implement diminishing returns for contribution points/hackathon points when return contributors attempt to repeat the first-time contributor issues
• Establish a KPI on how many issues or what categories of issues we need engineering and UX groups to maintain
• Add a graduation step where contributors who have completed first issues can be guided into a next level of issues

Example of Ideal Contributor Journey

1. Contributor arrives at Contribute to GitLab page
2. They click a call to action to start onboarding as a GitLab contributor
3. The onboarding steps guide them towards completing the Tutorial
4. The next steps guide them to make a real GitLab contribution with one of the available first-contributor issues
5. They follow the issue's implementation plan and submit a merge request
6. Our MR coaches help guide the merge request through until merged
7. The contributor can continue with another first-contributor issue or be offered the next level up of issues too