Better handle community contribution in Secure

Problem to solve

From the 12.7 retrospective:

We need to get better at triaging and helping with Community Contributions, some get stalled and we don't do a good job of assigning a DRI and carrying it over the finish line

During the retro, some suggestions were made:

  • look at what has been done for the gitlab project already.
  • setting up a workflow for our security-products projects.
  • consider setting up a reviewer list for contributors to assign MRs, or a process that allows for every engineer to look at a list of MRs to be reviewed on a regular basis.
  • make sure our contributing guidelines are accurate within our projects.
  • notify contributors about the expected SLO => a bot could post a comment with guidelines/process

Proposal

Short Term

  1. Update CONTRIBUTING.md in each security project with how-to information and that sets expectations on our SLO. WIP: gitlab-org/security-products/dast!178 (merged)
  2. Create a weekly report similar to Gitlab-CE's for community contributions WIP: gitlab-org/quality/triage-ops#477 (closed)
  3. Appoint owners of this report with specific DRI responsibilities.
  4. Create common response language for politely rejecting a contribution.

Longer Term

  1. Notify contributors about the expected SLO.

Example MRs

Edited by Neil McCorrison