Follow-up from "Draft: Formalize the Security Division's dogfooding program"
Creating this issue to finalize the discussion around this when Andrew is back from PTO
The following discussion from !5876 (merged) should be addressed:
-
@ankelly started a discussion: (+4 comments) I touched on this idea here, but thought I'd extract it into a separate thread for discussion.
We could create a repository and issue template that Security Division team members are asked to use when requesting features/functionality. This would allow us to build a consistent process around handling product gaps that we can't dogfood.
A quick look at some of the contents of the MR indicates to me that its an idea worth exploring. The following things could be incorporated as a checklist/items to be filled out in the template:
- Capturing the specific feature request
- Why we can't dogfood it and what's missing
- Identifying the criticality and priority of need
- Linking it to external customer needs
- Explaining why current features/functionality don't meet the needs
- Identification of custom/self-managed tooling currently leveraged by the division
- Identification of critical security procedures reliant on the platform
It might be best for this template to live in a specific Security division repository, since certain parts of the discussion might not be appropriate for a
gitlab-org/gitlab
issue:- Build vs. Buy
- Wait for PM vs. Delegate vs. contractors
- Critical security procedures reliant on the platform (may be confidential or have confidential information?)
Having a centralized repository / set of issues for this would help with all of the
Communication Cycles
bits as well:- Dogfood status could be driven through labels and enable quarterly async updates
- Other metrics and reporting would be easy
- Getting a high level overview could be made easy via labels, issue boards, etc