Proposal to introduce implementation plans to the issue description

Problem to solve

For middle-sized and large features, the development cannot be "just started". There are backend and frontend parts, even different pieces of backend work (Rails application, Dockerfiles, security products etc.) The process of collecting the information from all of the stakeholders, identifying blockers and dependencies between pieces of work can quickly become chaotic and uncontrolled if it's not organized deliberately.

Target audience

The ~Secure team (as a minimum viable change).

Further details

  • The ~Secure team will collect some feedback on this practice and will improve it (e.g. during 1-2 release cycles).
  • The ~Secure team may present improved practice before the rest of the Engineering department.
  • The ~Secure team is going to update the issue templates in the https://gitlab.com/gitlab-org/security-products repos before the approach to the default MRs is standardized over GitLab

Proposal

I propose adopting the so-called implementation plans (aka implementation checklists, "Execution" section). See https://gitlab.com/gitlab-org/gitlab-ee/issues/5656#execution as an example.

Such checklists will represent the sequence of actions required to implement any changes, both technical and not (collecting info etc.). Also, they will in-place information for the EM/reviewer on the current progress.

What does success look like, and how can we measure that?

The ~Secure team is using the implementation plans for all mid-size and large features. An assignee a of particular issue produces such a plan between the Evaluation and Kick-off.

Links / references

Execution

Edited by Victor Zagorodny