Labels
Prioritized labels 50
Drag to reorder prioritized labels and change their relative priority.
-
groupauthorizationGitLab.orgIssues belonging to the Authorization group of the Govern stage of the DevOps lifecycle, https://about.gitlab.com/handbook/product/categories/#authorization-group
-
Architecture Evolution BlueprintGitLab.orgChanges to Architecture Evolution Blueprints described at https://about.gitlab.com/handbook/engineering/architecture/workflow/
-
groupcontainer registryGitLab.orgIssues belonging to the Container Registry group of the Package stage of the DevOps lifecycle. See https://about.gitlab.com/handbook/product/categories/#container-registry-group
-
quick winfirst-time contributorGitLab.orgQuick win issues that are ideal for first-time community contributors to work on
-
VerifyP1GitLab.orgIssues related to current milestone's top product priorities for the Pipeline Execution group in the Verify stage
-
complexitylowGitLab.orgIssue with low technical complexity. Complexity does not describe the time it will likely require to address the issue, but rather the familiarity required to address it. This label is only intended as a guideline to hint to individuals how involved the issue will likely be.
-
VerifyP2GitLab.orgIssues related to next milestone's top product priorities for the Pipeline Execution group in the Verify stage
-
complexitymediumGitLab.orgIssue with medium technical complexity. Complexity does not describe the time it will likely require to address the issue, but rather the familiarity required to address it. This label is only intended as a guideline to hint to individuals how involved the issue will likely be.
-
workflowin devGitLab.orgIssues that are actively being worked on by a developer https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/#build-phase-2-develop--test
-
VerifyP3GitLab.orgIssues related to future milestone's top product priorities for the Pipeline Execution group in the Verify stage
-
complexityhighGitLab.orgIssue with high technical complexity. Complexity does not describe the time it will likely require to address the issue, but rather the familiarity required to address it. This label is only intended as a guideline to hint to individuals how involved the issue will likely be.
-
workflowblockedGitLab.orgIssues that are blocked until another issue has been completed https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/#build-phase-2-develop--test
-
Category:Global SearchGitLab.orgIssues related to search using the search field in the top navigation bar
-
workflowcompleteGitLab.orgApplied after all MRs have merged and the issue has been verified if necessary https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/#build-phase-3-launch
-
workflowin reviewGitLab.orgIssues that are undergoing code review by the development team and/or undergoing design review by the UX team https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/#build-phase-2-develop--test
-
Model ExperimentsGitLab.orgModel Experiments allows Data Scientists to track candidates for their machine learning models
-
workflowrefinementGitLab.orgIssues that need further input from team members in order for it to be "workflow::ready for development" https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/#build-phase-1-plan
-
workflowready for reviewGitLab.orgMerge requests which are ready to be reviewed and can be reviewed by any team-member with sufficient knowledge in the given area. For reviewing the merge request just assign to yourself and remove this label.
-
workflowsolution validationGitLab.orgWorkflow label for validating that the proposed solution meets user needs https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/#validation-phase-4-solution-validation
-
modular_monolithGitLab.org / GitLabIssues related to the effort of having a Modular Monolith and #modular_monolith Slack channel discussions
-
workflowfeature-flaggedGitLab.orgEnabled through a separate feature flag rollout issue. https://handbook.gitlab.com/handbook/engineering/development/ops/verify/pipeline-execution/#workflow
-
Category:Code SearchGitLab.orgCode Search Category is part of Global Search that focuses on searching through Code Across Repositories
-
quad-planningcomplete-no-actionGitLab.orgIssue has gone through Quad Planning process (PM,Dev,UX,QE) and does not require any additional action
-
StORMIntakeGitLab.orgLabel to communicate potential security operational risks to the Security Risk Team
-
StORMNeeds Additional InformationGitLab.orgAdditional information is required to support the Security Risk Team's StORM Risk Assessment
-
CI persistenceGitLab.orgIssues related to Persistence (workspaces, caching). Does not include artifacts, which is its own label
-
StORMOut of ScopeGitLab.orgThe Security Risk Team performed a StORM Risk Assessment and determined that the potential risk identified is out of scope for the StORM program because it is not considered an operational security risk.
-
StORMUnder AssessmentGitLab.orgLabel used to note the Security Risk Team is currently assessing a potential risk
-
Risk and Field SecurityGitLab.orgThis label is for things related to the Risk and Field Security team
-
priority1GitLab.orgWe will address this as soon as possible regardless of limit on our team capacity. See https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#priority
-
priority2GitLab.orgWe will address this soon and will provide capacity from our team for it in the next few releases. See https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#priority
-
priority3GitLab.orgWe want to address this but may have other higher priority items. See https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#priority
-
priority4GitLab.orgWe don't have visibility when this will be addressed. See https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#priority
-
UXGitLab.orgIssues or MRs that introduce user-facing changes or impact the user experience. Applying this label to issues will signal a need for a designer.
Labels 4,743
-
design-weight1GitLab.org(Trivial) Mostly small UI changes leading to small incremental UX improvements. No users’ workflow involved in these changes. Requirements are clear and there are no unanswered questions.
-
design-weight13GitLab.orgHighly significant changes impacting multiple user flows, a large new feature, and/or a complete redesign. This issue could significantly impact product strategy and would require critical input from others (the wider GitLab community, e-group, customers), and there are many unknowns. This necessitates research where the designer could team up with a researcher and other designers to gather input data, plan and conduct exploratory interviews, lead user testing sessions… It's unlikely we would commit to complete this issue in a milestone, and the preference would be to further clarify requirements and/or break it into smaller issues planned in several milestones.
-
design-weight2GitLab.org(Small) Simple UI or UX change where we understand all of the requirements but may need to find solutions to known questions/problems. These changes should blend in with an actual user workflow.
-
design-weight3GitLab.org(Medium) A well-understood change but the scope of work is bigger. Several pages are involved and/or we're starting to design/redesign small flows or connect existing flows between each other. Designers may conduct extensive background research (previous issues, support tickets, review past user research, review analytics, etc). Some unknown questions may arise during the work.
-
design-weight5GitLab.org(Large) A complex change where input from group members is needed as early as possible. Spans across multiple pages, and we're working on medium-sized flows that potentially connect with another area of the product. There are significant open questions that need to be answered. The product designer may need to do some research on their own or in collaboration with a researcher, but this isn't always the case. Possible research activities might be to find and/or validate a Job To Be Done, conduct user testing or card-sorting, or do a survey.
-
design-weight8GitLab.org(Very large) Complicated changes introducing a new user flow that connects with other large flows and may require input from other designers, product managers, or engineers from the same or another stage group. This is the largest flow design/redesign that we would take on in a single milestone. This requires research where the designer may or may not be working with a researcher to plan and conduct exploratory interviews or user testing sessions
-
designdiscoveryGitLab.org[Monitor] Design Issues that are in the Discovery phase (Fact finding, research, user journeys, story maps)
-
designideationGitLab.org[Monitor] Design Issues that are in progress (wireframes, mockups, prototypes, etc...)
-
designreadyforengGitLab.org[Monitor] Design Issues that are ready for engineering (can be closed issues, linked to engineering issues)
-
designreviewGitLab.org[Monitor] Design Issues that are ready for review (Design review && Engineering review)
-
development guidelinesGitLab.orgChanges or updates to the development guidelines in the /development directory in the GitLab documentation. (Info: https://docs.gitlab.com/ee/development/)
-
development-analyticssupport-requestGitLab.orgSupport requests for the Development Analytics team, covering issues, enhancements, or questions related to tools, processes, and workflows within the Development Analytics scope.