diff options
| author | Mike Lewis <mlewis@gitlab.com> | 2019-01-30 20:47:54 +0300 |
|---|---|---|
| committer | Mike Lewis <mlewis@gitlab.com> | 2019-01-30 20:47:54 +0300 |
| commit | 55b8b3e2e4a013f4db904a6076015295700b0bd0 (patch) | |
| tree | 93d11128cef3fef5cf0cfddb9a80452c25bb2c0b /.gitlab | |
| parent | f8e6a3957e22f9b879919b41917e0269a8e9ee4e (diff) | |
Drop duplicate talk of PM schedule that already exists in docs
Diffstat (limited to '.gitlab')
| -rw-r--r-- | .gitlab/issue_templates/Feature proposal.md | 12 |
1 files changed, 4 insertions, 8 deletions
diff --git a/.gitlab/issue_templates/Feature proposal.md b/.gitlab/issue_templates/Feature proposal.md index 944c15dc339..b0e428ea580 100644 --- a/.gitlab/issue_templates/Feature proposal.md +++ b/.gitlab/issue_templates/Feature proposal.md @@ -17,15 +17,11 @@ Use the persona labels as well https://gitlab.com/groups/gitlab-org/-/labels?utf ### Documentation -<!-- What doc pages need to be created or updated across user, admin, and API docs? +<!-- See the Documentation Workflows https://docs.gitlab.com/ee/development/documentation/workflow.html and specify the following: +What doc pages need to be created or updated across user, admin, and API docs? What concepts, procedures, or information is needed in each area? Is there an 'old way' that should be deprecated in the docs? - -Product managers: -* By the kickoff, finalize the answers to the bullets above, and also: - * When applicable, specify a new or updated feature name, description, benefits, - and use cases, which may all be used in the documentation or features.yml. - * Specify which use cases or scenarios would benefit from a set of instructions or a guide, - whether unique to a single use case or flexible enough to cover multiple use cases. --> +If applicable, specify a new or updated feature name, description, benefits, and use cases, which may all be used in the documentation or features.yml. +Which use cases or scenarios would benefit from a set of instructions or a guide, whether unique to each use case or flexible enough to cover multiple use cases. --> ### What does success look like, and how can we measure that? |