@@ -13,7 +13,7 @@ An aspirational goal for the R&D organization is achieving an end state where ou
* 60%: focused on features and usability
* 40%: focused on optimization, general maintenance, security items, and bugs
We recognize that making progress towards our desired end state requires significant effort and cannot be achieved immediately. Success will require cross-functional discipline, diligence, and alignment in both planning and execution, with tangible progress towards our desired end state 60%/40% split being measurable release over release. We recognize that based upon the maturity of a given area, this ratio may need to be different per team. We see this represented in data today across the portfolio, where for example a team with relatively immature features may require more feature work allocated, while teams with more mature features carry a heavier maintenance burden. Each group has the ownership and accountability to define the correct ratio across all categories based on Category maturity as well as maintenance needed to continue meeting our security, scalability, reliability, availability, and quality requirements. Teams will align with R&D leadership across Product & Engineering to ensure R&D demonstrate continuous improvement towards our desired 60%/40% end state.
We recognize that making progress towards our desired end state requires significant effort and cannot be achieved immediately. Success will require cross-functional discipline, diligence, and alignment in both planning and execution, with tangible progress towards our desired end state 60%/40% split being measurable release over release. We recognize that based upon the maturity of a given area, this ratio may need to be different per team. We see this represented in data today across the portfolio, where for example a team with relatively immature features may require more feature work allocated, while teams with more mature features carry a heavier maintenance burden. Each group has the ownership and accountability to define the correct ratio across all categories based on maturity as well as maintenance needed to continue meeting our security, scalability, reliability, availability, and quality requirements. Teams will align with R&D leadership across Product & Engineering to ensure R&D demonstrate continuous improvement towards our desired 60%/40% end state.
The table below summarizes the 60%/40% split by component:
@@ -40,7 +40,7 @@ Note: These are the original labels from the working group. These were chosen so
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](/handbook/product/categories/), 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 maturity of what they are responsible for, 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](/handbook/product/groups/product-analysis/engineering/metrics/#work-type-classification). The development EM is the DRI to ensure that the merge requests are accurately labeled.
@@ -103,7 +103,7 @@ GitLab the product [plays well with others](/handbook/product/categories/gitlab-
**Community Is Devalued.**
Community is seen as a marketing tool instead of as participants working to make the product better together. -
We care deeply about our community and depend on all GitLabbers to help us improve our [category and stage maturity](https://about.gitlab.com/direction/#maturity).
We care deeply about our community and depend on all team members to help us improve our product.
We have [Merge Request Coaches](/job-families/expert/merge-request-coach/) who help contributors get their merge requests to meet the [contribution acceptance criteria](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#contribution-acceptance-criteria),
and [wider community contributions per release](/handbook/marketing/developer-relations/performance-indicators/#wider-community-merged-mrs-per-release) is [a GitLab KPI](/handbook/company/kpis/#gitlab-kpis).
@@ -445,7 +445,7 @@ Our belief is that we can guarantee a higher rate of success by incubating ideas
As a matter of process, we require that Single-engineer groups take part in our [Software Demo Process](/handbook/engineering/demos/#single-engineer-groups-demo) as a way to collaborate asynchronously with stakeholders, get iterative feedback, and maintain at least minimal alignment with the rest of GitLab while keeping their autonomy
If the group finds great success, as measured by adoption, and needs to drive deeper category maturity then the next step is to consider forming a multi-person group. Sometimes the category is complete and the group can successfully dissolve. There are other times when the category does not yield the adoption. We will gather the lessons learned and consider either dissolving the group or investing further based on the learnings.
If the group finds great success, as measured by adoption, and needs to further evolve that area of the product, then the next step is to consider forming a multi-person group. Sometimes the category is complete and the group can successfully dissolve. There are other times when the category does not yield the adoption. We will gather the lessons learned and consider either dissolving the group or investing further based on the learnings.
We have a huge opportunity in front of us and we want to be ambitious. Therefore over time we want to invest 10% of our R&D to continue to pursue these. However, in the spirit of iteration, we will start with only a handful of Single-engineer groups. As we learn more, and we get more dollars to invest, we will gradually add more SEGs.
@@ -15,8 +15,6 @@ The GitLab product is organized based on the DevOps stages.
If you're new to GitLab and the concept of "stages" are new to you, simply think of it as a category of related features that a customer finds value in with a **technical** narrative. The stages are organized in an infinite loop diagram to show the software development lifecycle from planning to development to release, with additional value for deployed applications with security and monitoring features. You can see a high-level overview of each stage on the [marketing page](https://about.gitlab.com/stages-devops-lifecycle/). Be sure to click the `Learn More` link for each stage to see more about the features of that stage.
One of the most helpful resources for understanding what GitLab does, the features in each stage, and how well the feature works is our [Category maturity](https://about.gitlab.com/direction/#maturity) chart. This may also be informally referred to as our "lovable feature chart".
If you understand what the stages are and want to dive deeper, you can look at the [product categories handbook page](/handbook/product/categories/) for a deep-dive on each of the stages, specifically the [hierarchy](/handbook/product/categories/#hierarchy) and the [DevOps Stages](/handbook/product/categories/#devops-stages).
For the purposes of education and enablement, we focus on the DevOps stages that the customer sees. There are additional stages that help GitLab as a business succeed, such as the [Growth stage](/handbook/product/categories/#growth-stage), [Fulfillment stage](/handbook/product/categories/#fulfillment-stage), [Enablement stage](/handbook/product/categories/#enablement-stage), and [Single Engineer Groups stage](/handbook/product/categories/#single-engineer-groups-section). Although these are not necessarily DevOps stages, the Engineering and Product departments use the stage terminology for consistency. **You do not need to spend time learning about these stages and can search for this information later if the need arises.**
@@ -208,7 +208,7 @@ We strive to provide excellent usability in all of our workflows, creating a bal
#### How we work
- We follow the [Product Designer workflows](/handbook/product/ux/product-designer/) and [UX Researcher workflows](/handbook/product/ux/ux-research/) described in the [Product Design section](/handbook/product/ux/) of the handbook.
- We measure our progress using [UX Scorecards](/handbook/product/ux/ux-scorecards/) and [Category Maturity Scorecards](/handbook/product/ux/category-maturity/category-maturity-scorecards/).
- We measure our progress using [UX Scorecards](/handbook/product/ux/ux-scorecards/).
- We prioritize the most important projects every quarter, and Fulfillment product designers [support projects instead of Groups](#product-designer-focus-areas).
- We use [[UX] issues](#ux-issue-management-and-weights) as the SSOT for designs. Implementation issues should link to the [UX] issue for the design details to maintain the SSOT.
