63 lines
1.7 KiB
Markdown
63 lines
1.7 KiB
Markdown
<!--
|
|
Implementation issues are used break-up a large piece of work into small, discrete tasks that can
|
|
move independently through the build workflow steps. They're typically used to populate a Feature
|
|
Epic. Once created, an implementation issue is usually refined in order to populate and review the
|
|
implementation plan and weight.
|
|
Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan
|
|
-->
|
|
|
|
## Why are we doing this work
|
|
<!--
|
|
A brief explanation of the why, not the what or how. Assume the reader doesn't know the
|
|
background and won't have time to dig-up information from comment threads.
|
|
-->
|
|
|
|
|
|
## Relevant links
|
|
<!--
|
|
Information that the developer might need to refer to when implementing the issue.
|
|
|
|
- [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>)
|
|
- [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png)
|
|
- [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png)
|
|
- [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>)
|
|
-->
|
|
|
|
|
|
## Non-functional requirements
|
|
<!--
|
|
Add details for required items and delete others.
|
|
-->
|
|
|
|
- [ ] Documentation:
|
|
- [ ] Feature flag:
|
|
- [ ] Performance:
|
|
- [ ] Testing:
|
|
|
|
|
|
## Implementation plan
|
|
<!--
|
|
Steps and the parts of the code that will need to get updated. The plan can also
|
|
call-out responsibilities for other team members or teams.
|
|
-->
|
|
|
|
- [ ] ~frontend Step 1
|
|
- [ ] `@person` Step 1a
|
|
- [ ] ~frontend Step 2
|
|
|
|
|
|
<!--
|
|
Workflow and other relevant labels
|
|
|
|
~"group::" ~"Category:" ~"GitLab Ultimate"
|
|
-->
|
|
/label ~"workflow::refinement"
|
|
|
|
<!--
|
|
Other settings you might want to include when creating the issue.
|
|
|
|
/milestone %"Next 1-3 releases"
|
|
/assign @
|
|
/epic &
|
|
-->
|