Reducing Community Contribution Age

Challenge

How can Open Community Merge Request Age be reduced by identifying simple merge requests and accelerating them through the Community contribution process with tooling?

Questions

• Where are merge requests falling out of the funnel and need tooling or something to nudge?
  • Who would be the nudged DRI?
• How can simple merge requests be identified? Should these go through an accelerated process?
• What are the roles and responsibilities for Community Contribution, MR Coaches, Maintainers and Product teams for this process?
• How can we align on a SSOT for metrics (Bitergia vs Sisense)?

Relevant tooling

• Realtime welcome message which applies Community contribution label for www-gitlab-com and gitlab-org Example: https://gitlab.com/gitlab-org/quality/triage-serverless/-/blob/master/triage/processor/thank_community_contribution.rb
• Daily MR Coach triage report Example: https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/stages/report/untriaged-community-merge-requests.yml
• Twice a month team MR reports with Community Contributions Example: https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/template/merge-requests-needing-attention.yml.erb

Historical details

1. This process has historically used non-scaleable manual processes to achieve exceptional results for MRARR and Merged Community Contributions.
   • The previous Code Contributor Manager subscribed to the labels and nudged specific team members depending on the product area from email notifications.
   • For customer contributions, Quality team member DRIs identified and nudged them manually