@@ -21,9 +21,9 @@ To support GitLab's long-term product health and stability while keeping the pac
If one of these labels clearly doesn't apply for an issue, consider using the `type::ignore` label. This will exclude the issue from automation and dashboards used to do cross-functional prioritization and metrics tracking for the product. It is highly important we have accurate data, so please only use this label if the issue clearly does not pertain directly to Engineering changes to the product itself. This label will typically apply to issues used for planning or to track a process. For example, you could use the `type::ignore` label for a milestone planning issue where the issue's purpose is organization and will not have MRs directly associated with it.
A team's ratio might change over time and different teams may have different ratios. Factors that influence what ratio is appropriate for a given team include the [product category maturity](https://about.gitlab.com/direction/maturity/), the area of the product they are working in, and the evolving needs of GitLab the business. Teams should review labeling for accuracy and minimize the number of `type::undefined` items. This allows us to review the plans at the group, section, and company level with team members to ensure we appropriately prioritize based on cross-functional perspectives.
A team's ratio might change over time and different teams may have different ratios. Factors that influence what ratio is appropriate for a given team include the [product category maturity](https://about.gitlab.com/direction/#maturity), the area of the product they are working in, and the evolving needs of GitLab the business. Teams should review labeling for accuracy and minimize the number of `type::undefined` items. This allows us to review the plans at the group, section, and company level with team members to ensure we appropriately prioritize based on cross-functional perspectives.
For more details on these three work types, please see the section on [work type classification](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification). The development EM is the DRI to ensure that the merge requests are accurateliy labeled.
For more details on these three work types, please see the section on [work type classification](/handbook/engineering/metrics/#work-type-classification). The development EM is the DRI to ensure that the merge requests are accurately labeled.
#### Prioritization for feature, maintenance, and bugs
@@ -31,9 +31,9 @@ Our backlog should be prioritized on an ongoing basis. Prioritization will be do
1. Engineering Manager in development provides prioritized `type::maintenance` issues
1.[Test Platform Managers](https://about.gitlab.com/handbook/engineering/infrastructure/test-platform/#milestone-planning) provide prioritized `type::bug` issues using the [bug prioritization dashboard](https://10az.online.tableau.com/t/gitlab/views/OpenBugAgeOBA/BugPrioritizationDashboard)
1.[Test Platform Managers](/handbook/engineering/infrastructure/test-platform/#milestone-planning) provide prioritized `type::bug` issues using the [bug prioritization dashboard](https://10az.online.tableau.com/t/gitlab/views/OpenBugAgeOBA/BugPrioritizationDashboard)
*Note: UX-related work items would be prioritized in accordance with the appropriate sub-types. UX related bugs are included in the automated process (S1/2 and so on), UX-related maintenance items will be included in the EM's prioritized list, Product (feature) UX items will have been included as part of our normal [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/).*
*Note: UX-related work items would be prioritized in accordance with the appropriate sub-types. UX related bugs are included in the automated process (S1/2 and so on), UX-related maintenance items will be included in the EM's prioritized list, Product (feature) UX items will have been included as part of our normal [Product Development Flow](/handbook/product-development-flow/).*
The DRIs of these three core areas will work collaboratively to ensure the overall prioritization of the backlog is in alignment with [section direction](https://about.gitlab.com/direction/#devops-stages) or any other necessary product and business needs. If a team is not assigned a Product Designer then there is no UX counterpart needed for prioritization purposes. PMs will prioritize the final plan for a given milestone.
@@ -55,7 +55,7 @@ Cross-functional reviews will be done at the group, stage/section, and company l
##### When to review?
When the data is up-to-date and accurate. See the [timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline)
When the data is up-to-date and accurate. See the [timeline](/handbook/engineering/workflow/#product-development-timeline)
@@ -47,4 +47,4 @@ Once the item's success criteria are achieved, the Engineering Manager should co
When reseting a groups Engineering Allocation in the table above, the goal should be set as `floor %`, the goal should be `empower every SWEs from raising reliability and security issues`, percentage of headcount allocated should be `10%`, and `N/A` in place of a link to the Epic.
All engineering allocation closures should be reviewed and approved by the [VP of Development](https://about.gitlab.com/handbook/engineering/development/#team-members).
All engineering allocation closures should be reviewed and approved by the [VP of Development](/handbook/engineering/development/#team-members).
* Maximize your productivity through effective [time management](https://about.gitlab.com/handbook/engineering/development/dev/create/engineers/books/#time-management)
* Maximize your productivity through effective [time management](/handbook/engineering/development/dev/create/engineers/books/#time-management)
* Be proactive and take the initiative when the opportunity presents itself
* Demonstrate flexibility by being open and adaptable when assigned work tasks
