diff options
Diffstat (limited to '.gitlab/issue_templates')
| -rw-r--r-- | .gitlab/issue_templates/Actionable Insight.md | 28 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Adoption Engineering.md | 14 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Basic Proposal.md | 2 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Dogfooding.md | 17 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Feature Flag Roll Out.md | 3 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Feature proposal.md | 6 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Lean Feature Proposal.md | 6 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Query Performance Investigation.md | 39 | ||||
| -rw-r--r-- | .gitlab/issue_templates/Security developer workflow.md | 2 | ||||
| -rw-r--r-- | .gitlab/issue_templates/actionable_insight.md | 34 |
10 files changed, 107 insertions, 44 deletions
diff --git a/.gitlab/issue_templates/Actionable Insight.md b/.gitlab/issue_templates/Actionable Insight.md new file mode 100644 index 00000000000..df519f81799 --- /dev/null +++ b/.gitlab/issue_templates/Actionable Insight.md @@ -0,0 +1,28 @@ +<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Learn more in the handbook here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/research-insights/#actionable-insights --> + +### Insight +<!-- Describe the insight itself: often the problem, finding, or observation. --> + +### Supporting evidence +<!-- Describe why the problem is happening, or more details behind the finding or observation. Try to include quotes or specific data collected. Feel free to link the Actionable insight from Dovetail here if applicable instead of retyping details. --> + +### Action +<!--Describe the next step or action that needs to take place as a result of the research. The action should be clearly defined, achievable, and directly tied back to the insight. Make sure to use directive terminology, such as: conduct, explore, redesign, etc. --> + +### Resources + <!--Add resources as links below or as related issues. --> + +- :dove: [Dovetail project](Paste URL for Dovetail project here) +- :mag: [Research issue](Paste URL for research issue here) +- :footprints: [Follow-up issue or epic](Paste URL for follow-up issue or epic here) + +### Tasks +- [ ] Assign this issue to the appropriate Product Manager, Product Designer, or UX Researcher. +- [ ] Add the appropriate `Group` (such as `~"group::source code"`) label to the issue. This helps identify and track actionable insights at the group level. +- [ ] Link this issue back to the original research issue in the GitLab UX Research project and the Dovetail project. + + + + +/label ~"Actionable Insight" + diff --git a/.gitlab/issue_templates/Adoption Engineering.md b/.gitlab/issue_templates/Adoption Engineering.md new file mode 100644 index 00000000000..01e9d0ea033 --- /dev/null +++ b/.gitlab/issue_templates/Adoption Engineering.md @@ -0,0 +1,14 @@ +#Design +<!-- This should include the contexts that determine the reproducibility (stickiness) of an experiment. This means that if you want the same behavior for a user, the context would be user, or if you want all users when viewing a specific project, the context would be the project being viewed, etc. --> + + +#Rollout strategy +<!-- This is currently called A/B test, which isn't accurate for multi-variants. Let's call this rollout strategy. It should outline the percentages for variants and if there's more than one step to this, each of those steps and the timing for those steps (e.g. 30 days after initial rollout). --> + +#Inclusions and exclusions +<!-- These would be the rules for which given context (and are limited to context or resolvable at experiment time details) is included or excluded from the test. An example of this would be to only run an experiment on groups less than N number of days old. --> + +#Segmentation +<!-- Rules for always saying context with these criteria always get this variant. For instance, if you want to always give groups less than N number of days old the experiment experience, they are specified here. This is different from the exclusion rules above. --> + +#Tracking diff --git a/.gitlab/issue_templates/Basic Proposal.md b/.gitlab/issue_templates/Basic Proposal.md index 4232561354c..8d47e87f8a3 100644 --- a/.gitlab/issue_templates/Basic Proposal.md +++ b/.gitlab/issue_templates/Basic Proposal.md @@ -6,6 +6,6 @@ <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. -/label ~"group::" ~"section::" ~"Category::" ~"GitLab Core"/~"GitLab Starter"/~"GitLab Premium"/~"GitLab Ultimate" +/label ~"group::" ~"section::" ~"Category::" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate" --> diff --git a/.gitlab/issue_templates/Dogfooding.md b/.gitlab/issue_templates/Dogfooding.md new file mode 100644 index 00000000000..d780fbd3f1f --- /dev/null +++ b/.gitlab/issue_templates/Dogfooding.md @@ -0,0 +1,17 @@ +<!--Lightweight issue template to encourage Dogfooding and educate team members about the importance of Dogfooding --> + +/label ~"dogfooding" ~"group::" ~"section::" ~"Category::" + +## Feature to Dogfood +<!--Link to Description of feature (Documentation, Epic, Opportunity Canvas, etc.) --> + +## Goals +<!--Level of Dogfooding you are looking for: problem validation, testing, production usage, etc --> + +## Progress Tracker +<!--List of tasks (e.g. a table with columns, project, status, issue links similar to what is [done here](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/8499))--> + +## Why Dogfooding is Important +- https://about.gitlab.com/handbook/values/#dogfooding +- https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything +- https://about.gitlab.com/handbook/engineering/#dogfooding diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md index 67686b654bd..615fb644967 100644 --- a/.gitlab/issue_templates/Feature Flag Roll Out.md +++ b/.gitlab/issue_templates/Feature Flag Roll Out.md @@ -31,7 +31,6 @@ If applicable, any groups/projects that are happy to have this feature turned on ## Roll Out Steps -- [ ] Confirm that QA tests pass with the feature flag enabled (if you're unsure how, contact the relevant [stable counterpart in the Quality department](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors)) - [ ] Enable on staging (`/chatops run feature set feature_name true --staging`) - [ ] Test on staging - [ ] Ensure that documentation has been updated @@ -42,7 +41,7 @@ If applicable, any groups/projects that are happy to have this feature turned on - [ ] Enable on GitLab.com by running chatops command in `#production` (`/chatops run feature set feature_name true`) - [ ] Cross post chatops Slack command to `#support_gitlab-com` ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#where-to-run-commands)) and in your team channel - [ ] Announce on the issue that the flag has been enabled -- [ ] Remove feature flag and add changelog entry +- [ ] Remove feature flag and add changelog entry. Ensure that the feature flag definition YAML file has been removed in the **same MR** that is removing the feature flag from the code - [ ] After the flag removal is deployed, [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel ## Rollback Steps diff --git a/.gitlab/issue_templates/Feature proposal.md b/.gitlab/issue_templates/Feature proposal.md index 66450c37a22..2cdf2341c88 100644 --- a/.gitlab/issue_templates/Feature proposal.md +++ b/.gitlab/issue_templates/Feature proposal.md @@ -61,7 +61,7 @@ Consider adding checkboxes and expectations of users with certain levels of memb <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change -* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements +* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing @@ -97,7 +97,7 @@ Create tracking issue using the the Snowplow event tracking template. See https: ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ -In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> +In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers --> ### Is this a cross-stage feature? @@ -111,5 +111,5 @@ Use the following resources to find the appropriate labels: - https://about.gitlab.com/handbook/product/categories/features/ --> /label ~devops:: ~group: ~Category: - +/label ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate" /label ~feature diff --git a/.gitlab/issue_templates/Lean Feature Proposal.md b/.gitlab/issue_templates/Lean Feature Proposal.md index 44210a89023..fb9ac306f31 100644 --- a/.gitlab/issue_templates/Lean Feature Proposal.md +++ b/.gitlab/issue_templates/Lean Feature Proposal.md @@ -14,7 +14,7 @@ -/label ~"feature" ~"group::" ~"section::" ~"Category::" ~"GitLab Core"/~"GitLab Starter"/~"GitLab Premium"/~"GitLab Ultimate" +/label ~"feature" ~"group::" ~"section::" ~"Category::" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate" <!--- Use the following resources to find the appropriate labels: @@ -73,7 +73,7 @@ Consider adding checkboxes and expectations of users with certain levels of memb See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change -* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements +* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html ### Availability & Testing @@ -96,7 +96,7 @@ Define both the success metrics and acceptance criteria. Note that success metri ### What is the type of buyer? What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ -In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers +In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers ### Is this a cross-stage feature? diff --git a/.gitlab/issue_templates/Query Performance Investigation.md b/.gitlab/issue_templates/Query Performance Investigation.md new file mode 100644 index 00000000000..3f2a6361d64 --- /dev/null +++ b/.gitlab/issue_templates/Query Performance Investigation.md @@ -0,0 +1,39 @@ +## Description + +As the name implies, the purpose of the template is to detail underperforming queries for futher investigation. + +### Steps + +- [ ] Rename the issue to - `Query Performance Investigation - [Query Snippet | Table info]` + - For example - `Query Performance Investigation - SELECT "namespaces".* FROM "namespaces" WHERE "namespaces"."id" = $1 LIMIT $2` +- [ ] Provide information in the Requested Data Points table +- [ ] Provide [priority and severity labels](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#availability) +- [ ] If this requires immediate attention cc `@gitlab-org/database-team` and reach out in the #g_database slack channel + +### Requested Data points + +Please provide as many of these fields as possible when submitting a query performance report. + +- TPS +- Duration +- Source of calls (Sidekiq, WebAPI, etc) +- Query ID +- SQL Statement +- Query Plan +- Query Example +- Total number of calls (relative) +- % of Total time + +<!-- + +- Example of a postgres checkup report - https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/snippets/2056787 +- Epic - Improving the Database resource usage (&365) - https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/365#short-term-query-improvements +- Past examples of query performance investigations that have led to this template creation. + - Possible Index suggestion or query rewriting (#292454) - https://gitlab.com/gitlab-org/gitlab/-/issues/292454) + - High number of Sessions to the database with the value SET parameter (#292022) - https://gitlab.com/gitlab-org/gitlab/-/issues/292022) + - Query performance "Select 1" (#220055) - https://gitlab.com/gitlab-org/gitlab/-/issues/220055 + - Select statements that are in execution during database CPU utilization peak times - licenses table (#292900) - https://gitlab.com/gitlab-org/gitlab/-/issues/292900 + +--> + +/label ~"group::database" ~"database::triage" diff --git a/.gitlab/issue_templates/Security developer workflow.md b/.gitlab/issue_templates/Security developer workflow.md index 3de004b0319..beb066cdfc4 100644 --- a/.gitlab/issue_templates/Security developer workflow.md +++ b/.gitlab/issue_templates/Security developer workflow.md @@ -1,7 +1,7 @@ <!-- # Read me first! -Create this issue under https://gitlab.com/gitlab-org/security +Create this issue under https://gitlab.com/gitlab-org/security/gitlab Set the title to: `Description of the original issue` --> diff --git a/.gitlab/issue_templates/actionable_insight.md b/.gitlab/issue_templates/actionable_insight.md deleted file mode 100644 index ff6a4f12918..00000000000 --- a/.gitlab/issue_templates/actionable_insight.md +++ /dev/null @@ -1,34 +0,0 @@ -## Actionable Insights -Actionable insights always have a follow-up action that needs to take place as a result of the research observation or data, and a clear recommendation or action associated with it. An actionable insight both defines the insight and clearly calls out the next step. These insights are tracked over time and at the group level. - -#### Link - -- [ ] Provide the link to the Dovetail actionable insight you created earlier (this should contain all the essential details) -- [ ] If applicable, link this actionable insight issue back to the original Research Issue in the GitLab UX Research project - -#### Assign - -- [ ] Assign this issue to the appropriate Product Manager, Product Designer, or UX Researcher - -#### Group label - -- [ ] Add the appropriate `Group` (such as `~"group::source code"`) label to the issue. This is done to identify and track actionable insights at the group level. - -#### Description - -- [ ] Provide some brief details on the actionable insight and the action to take - -------------------------------------------------------------------------------- - -| | PLEASE COMPLETE THE BELOW | -| ------ | ------ | -| Dovetail link: | (URL goes here) | -| Details: | (details go here) | -| Action to take: | (action goes here) | - - - - - - -/label ~"Actionable Insight" |