Skip to content
Snippets Groups Projects
Commit 95b57bcb authored by Crystal Poole's avatar Crystal Poole
Browse files

Merge branch 'crystalpoole-main-patch-b3ff' into 'main'

Cleanup Package handbook page

See merge request !6829
parents fa37c506 a72a3260
No related branches found
No related tags found
1 merge request!6829Cleanup Package handbook page
Pipeline #1353309691 canceled
...@@ -29,9 +29,9 @@ The Package stage is made up of two groups: ...@@ -29,9 +29,9 @@ The Package stage is made up of two groups:
## 📈 Measuring results ## 📈 Measuring results
In order to better align our effort with our customer's needs we will use the following methodology to measure our results. We believe that our best measure of success and progress is our [product category maturity plan](https://about.gitlab.com/direction/maturity/#package). Progress towards these goals will be measured as follows: In order to better align our effort with our customer's needs we will use the following methodology to measure our results. We believe that our best measure of success and progress is our [product category maturity plan](/handbook/product/categories/#package-stage). Progress towards these goals will be measured as follows:
1. The long term product category maturity goals will be split into each stage: [minimal, viable, complete and, loveable](https://about.gitlab.com/direction/maturity/) 1. The long term product category maturity goals will be split into each stage: [minimal, viable, complete and, loveable](https://about.gitlab.com/direction/#maturity)
1. For each category's next maturity stage, we'll break down each feature into small iterations and give them [issue weights](/handbook/engineering/development/ops/package/#issue-weighting) 1. For each category's next maturity stage, we'll break down each feature into small iterations and give them [issue weights](/handbook/engineering/development/ops/package/#issue-weighting)
1. These weighted issues will have the `Package:P1` label applied then be scheduled in upcoming milestones 1. These weighted issues will have the `Package:P1` label applied then be scheduled in upcoming milestones
1. We'll measure our delivery by the percentage of committed product issues that were completed within a given development phase. Our goal is 100% completion. We track this measurement with a [Say Do Ratio](/handbook/engineering/development/performance-indicators/#say-do-ratios). 1. We'll measure our delivery by the percentage of committed product issues that were completed within a given development phase. Our goal is 100% completion. We track this measurement with a [Say Do Ratio](/handbook/engineering/development/performance-indicators/#say-do-ratios).
...@@ -51,13 +51,7 @@ The below epics detail the work required to move each respective category to the ...@@ -51,13 +51,7 @@ The below epics detail the work required to move each respective category to the
We use quarterly Objectives and Key Results as a tool to help us plan and measure how to achieve Key Performance Indicators (KPIs). We use quarterly Objectives and Key Results as a tool to help us plan and measure how to achieve Key Performance Indicators (KPIs).
Here is the [standard, company-wide process for OKRs](/handbook/company/okrs/) Here is the [standard, company-wide process for OKRs](/handbook/company/okrs/). Our quarterly OKRs are available [here](https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/?state=opened&label_name%5B%5D=devops::package).
<iframe src="https://app.ally.io/public/e4b5sDXtc8Ru0zm" class="dashboard-embed" height="800" width="100%" style="border:none;"> </iframe>
### Performance indicators
We measure the value we contribute by using [performance indicator metrics](/handbook/product/performance-indicators/). The primary metric used for the Package group is the number of monthly active users or GMAU. For more details, please check out the [Ops section's performance indicators](/handbook/product/performance-indicators/).
### Dashboards ### Dashboards
...@@ -65,10 +59,6 @@ We monitor our features using different dashboards. It is recommended to check t ...@@ -65,10 +59,6 @@ We monitor our features using different dashboards. It is recommended to check t
These dashboards are all internal and can be only accessed by GitLab Team members. These dashboards are all internal and can be only accessed by GitLab Team members.
* [Package Registry Dashboard](https://dashboards.gitlab.net/d/stage-groups-package_registry/stage-groups-package-registry-group-dashboard) (Grafana)
* [Container Registry Dashboard](https://dashboards.gitlab.net/d/stage-groups-container_registry/stage-groups-container-registry-group-dashboard?orgId=1 (Grafana)
* [Package Registry Error Budgets (7 days)](https://dashboards.gitlab.net/d/stage-groups-detail-package_registry/stage-groups-package-registry-group-error-budget-detail?from=now-7d&to=now&orgId=1) (Grafana)
* [Container Registry Error Budgets (7 days)](https://dashboards.gitlab.net/d/stage-groups-detail-container_registry/stage-groups-container-registry-group-error-budget-detail?from=now-7d&to=now&orgId=1) (Grafana)
* [Container Registry](https://log.gprd.gitlab.net/goto/e7b62a23a5a9cdc88aa1de3cdb392758) (Kibana) * [Container Registry](https://log.gprd.gitlab.net/goto/e7b62a23a5a9cdc88aa1de3cdb392758) (Kibana)
* [Container Registry garbage collection details](https://dashboards.gitlab.net/d/registry-gc/registry-garbage-collection-detail?orgId=1&from=now-30d&to=now&var-PROMETHEUS_DS=Global&var-environment=pre&var-cluster=pre-gitlab-gke&var-stage=main&var-namespace=gitlab&var-Deployment=gitlab-registry) (Grafana) * [Container Registry garbage collection details](https://dashboards.gitlab.net/d/registry-gc/registry-garbage-collection-detail?orgId=1&from=now-30d&to=now&var-PROMETHEUS_DS=Global&var-environment=pre&var-cluster=pre-gitlab-gke&var-stage=main&var-namespace=gitlab&var-Deployment=gitlab-registry) (Grafana)
* [Cleanup policies for Container Images](https://log.gprd.gitlab.net/goto/b03da1dcaf2ac281994f72687347f40a) (Kibana) * [Cleanup policies for Container Images](https://log.gprd.gitlab.net/goto/b03da1dcaf2ac281994f72687347f40a) (Kibana)
...@@ -77,11 +67,12 @@ These dashboards are all internal and can be only accessed by GitLab Team member ...@@ -77,11 +67,12 @@ These dashboards are all internal and can be only accessed by GitLab Team member
### Error Budget ### Error Budget
[Error Budgets](/handbook/engineering/error-budgets/) for stage groups have been established in order to help groups identify and prioritize issues that are impacting customers and infrastructure performance. The [Error Budget dashboard](https://dashboards.gitlab.net/d/stage-groups-package/stage-groups-group-dashboard-package-package?orgId=1) is used to identify issues that are contributing to the Package group's error budget spend. [Error Budgets](/handbook/engineering/error-budgets/) for stage groups have been established to help groups identify and prioritize issues that are impacting customers and infrastructure performance. The Error Budget dashboards are used to identify issues that are contributing to the Package group's error budget spend.
The [Package::Package error budget peformance indicator](/handbook/product/performance-indicators/#packagepackage---error-budget-for-gitlabcom) is tracked and updated weekly. * [Package Registry Error Budgets (7 days)](https://dashboards.gitlab.net/d/stage-groups-detail-package_registry/stage-groups-package-registry-group-error-budget-detail?from=now-7d&to=now&orgId=1) (Grafana)
* [Container Registry Error Budgets (7 days)](https://dashboards.gitlab.net/d/stage-groups-detail-container_registry/stage-groups-container-registry-group-error-budget-detail?from=now-7d&to=now&orgId=1) (Grafana)
The engineering manager will review the error budget dashboard weekly to determine whether we're exceeding our budget, determine what (if anything) is contributing to our error budget spend, and create issues addressing root cause for product manager prioritization. Issues created to address error budget spend should be created using appropriate labels as well as the label `Error Budget Improvement` in order to facilitate tracking and measurement. At the start of each week the 7-day error budgets for CI groups are posted in the [#ci-section](https://gitlab.enterprise.slack.com/archives/C05B0MER7LM) Slack channel. If the budget is exceeded, the team will determine what is contributing to our error budget spend and create issues addressing the root cause. These issues will be prioritized in the milestone as part of the team's `~Engineering Time` budget. Issues created to address error budget spend should be created using appropriate labels as well as `~Error Budget Improvement` to facilitate tracking and measurement.
### Usage Funnels ### Usage Funnels
...@@ -110,7 +101,7 @@ Follow along our instrumentation and measurement of Package-related metrics in [ ...@@ -110,7 +101,7 @@ Follow along our instrumentation and measurement of Package-related metrics in [
## Understanding our users ## Understanding our users
As a team, we are committed to understanding our users needs. We believe the best way to do that is by understanding the reason they hired GitLab, and how those motivations translate into our area of the product. For that, we apply a research-driven approach to [Jobs to Be Done (JTBD)](/handbook/product/ux/jobs-to-be-done/) framework of innovation. This method aims to understand why a customer uses and buys a given solution. We apply the [job statement](/handbook/product/ux/jobs-to-be-done/#how-to-write-jtbd) to identify a list of specific, contextual user needs to fulfill their JTBD. In addition, we regularly evaluate the overall user experience of each JTBD, with [UX Scorecards](/handbook/product/ux/ux-scorecards/), to ensure that we are meeting the needs of our users. As a team, we are committed to understanding our users needs. We believe the best way to do that is by understanding the reason they hired GitLab, and how those motivations translate into our area of the product. For that, we apply a research-driven approach to [Jobs to Be Done (JTBD)](/handbook/product/ux/jobs-to-be-done/) framework of innovation. This method aims to understand why a customer uses and buys a given solution. We apply the [job statement](/handbook/product/ux/jobs-to-be-done/jtbd_topics__definitions/#job-statements) to identify a list of specific, contextual user needs to fulfill their JTBD. In addition, we regularly evaluate the overall user experience of each JTBD, with [UX Scorecards](/handbook/product/ux/ux-scorecards/), to ensure that we are meeting the needs of our users.
### JTBD ### JTBD
...@@ -129,28 +120,23 @@ The GitLab Container and Package Registry currently handle hundreds of millions ...@@ -129,28 +120,23 @@ The GitLab Container and Package Registry currently handle hundreds of millions
### Roles and responsibilities ### Roles and responsibilities
Our team emphasises ownership by people who have the information required. This means, for example, in the event of some discussion about UX considerations, our Product Designer will have ownership. When we're building features, the Product Manager owns the decision on whether this is a feature that meets our customer needs. Our Engineers own the technical solutions being implemented. Our team emphasises ownership by team members who have the information required. This means, for example, in the event of some discussion about UX considerations, our Product Designer will have ownership. When we're building features, the Product Manager owns the decision on whether this is a feature that meets our customer needs. Our Engineers own the technical solutions being implemented.
The process of making sure that there are issues to evaluate and break down is the responsibility of our Product Manager. It is the responsibility of the engineering team to evaluate each issue and make sure it's ready for development (using the `workflow::ready for development` label). It is the responsibility of our Product Designer to evaluate user experience and score our product maturity based on user research. This process will take some time to complete each time we achieve a new maturity stage. [MR Rate](/handbook/engineering/development/performance-indicators/#development-department-mr-rate) will be used as an objective measure of our efficiency, not of alignment with our customer's needs or our organizational goals. The process of making sure that there are issues to evaluate and break down is the responsibility of our Product Manager. It is the responsibility of the engineering team to evaluate each issue and make sure it's ready for development (using the `workflow::ready for development` label). It is the responsibility of our Product Designer to evaluate user experience and score our product maturity based on user research. This process will take some time to complete each time we achieve a new maturity stage.
### Issue boards and projects ### Issue boards and projects
Issues for Package group can be found in the following projects: Issues for Package group can be found in the following projects:
* [gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name[]=group%3A%3Apackage) - any issues for GitLab the product, this means all work and category issues. * [gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name[]=devops%3A%3Apackage) - any issues for GitLab the product, this means all work and category issues.
* [gitlab-com/www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues?scope=all&state=opened&label_name[]=group%3A%3Apackage) - issues for any changes in handbook or blog * [gitlab-com/www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues?scope=all&state=opened&label_name[]=devops%3A%3Apackagehttps://gitlab.com/groups/gitlab-com/-/issues/?sort=created_date&state=opened&label_name%5B%5D=devops::package) - issues for any changes in handbook or blog
* Inside gitlab-org [package-stage/package](https://gitlab.com/gitlab-org/ci-cd/package-stage/package/-/issues) - any issues related to team organization, team styles, how we work, etc. * Inside gitlab-org [package-stage/package](https://gitlab.com/gitlab-org/ci-cd/package-stage/package/-/issues/) - any issues related to team organization, team styles, how we work, etc.
* [package-combined-team/team](https://gitlab.com/package-combined-team/team/-/issues) (private) - any issues that don't fit in the previous ones, and for major reasons, example, psychologically safe environment, we want to keep private to just the Package team members. Examples could be issues similar to retrospectives
To plan, visualize and organize better our work, we use the following [issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards): To plan, visualize and organize better our work, we use the following [issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards):
* [Package:Milestones](https://gitlab.com/groups/gitlab-org/-/boards/1196366?&label_name[]=devops%3A%3Apackage&label_name[]=group%3A%3Apackage) - Issue board showing milestone planning for current and future milestones.
* [Package:Assignments](https://gitlab.com/groups/gitlab-org/-/boards/1200765?&label_name[]=group%3A%3Apackage) - Issue board organized by assignee to give a snapshot of who is working on what. * [Package:Assignments](https://gitlab.com/groups/gitlab-org/-/boards/1200765?&label_name[]=group%3A%3Apackage) - Issue board organized by assignee to give a snapshot of who is working on what.
* [Package:Cross-Group Assignments](https://gitlab.com/groups/gitlab-org/-/boards/2470946?label_name[]=package%3Across-group-dependency) - Similar to `Package:Assignments` but for [Cross-Group Dependencies](#cross-group-dependencies).
* [Package:Bugs](https://gitlab.com/groups/gitlab-org/-/boards/1200744?&label_name[]=type::bug&label_name[]=devops%3A%3Apackage) - Issue board displaying priority and severity of package related bugs.
* [Package: Validation Track](https://gitlab.com/groups/gitlab-org/-/boards/1397751?&label_name[]=group%3A%3Apackage)
* [Package:Scheduling](https://gitlab.com/groups/gitlab-org/-/boards/1382732?&label_name[]=devops%3A%3Apackage&label_name[]=group%3A%3Apackage)
* [Package:Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1284221?label_name[]=group%3A%3Apackage) - Issue board broken down by workflow label to give a snapshot of the status of in-progress issues. * [Package:Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1284221?label_name[]=group%3A%3Apackage) - Issue board broken down by workflow label to give a snapshot of the status of in-progress issues.
* [Package:Bugs](https://gitlab.com/groups/gitlab-org/-/boards/1200744?&label_name[]=type::bug&label_name[]=devops%3A%3Apackage) - Issue board displaying priority and severity of package related bugs.
### Tips and Tricks ### Tips and Tricks
...@@ -160,9 +146,8 @@ We have created a collection of Tips and Tricks for folks working with/around th ...@@ -160,9 +146,8 @@ We have created a collection of Tips and Tricks for folks working with/around th
| Meeting | Purpose | | Meeting | Purpose |
| :-------- | :---- | | :-------- | :---- |
| Biweekly sync (rotate EMEA/APAC) | Share news and information and provide an opportunity for people on the team to escalate concerns. | | Weekly sync (rotate EMEA/APAC) | Share news and information and provide an opportunity for people on the team to escalate concerns. |
| Retrospective (weekly) | Discuss not only what went well or not but also how we did things and what we can do to improve for next week. | | Weekly social (weekly) | No agenda. Talk about interests or play a virtual game. |
| Think BIG (monthly) | Discuss the vision, product roadmap, user research, design, and delivery around the Package solution. |
### Retrospectives ### Retrospectives
...@@ -176,13 +161,9 @@ where suggestions are lost and no action is taken. Consider the following possib ...@@ -176,13 +161,9 @@ where suggestions are lost and no action is taken. Consider the following possib
* [Everything starts with a Merge Request](/handbook/communication/#start-with-a-merge-request)! No matter if it is a small or big change, in the MR, you will have the opportunity to discuss the things you are suggesting with the rest of the team. Add the label `~Retrospective follow-up` and relate the MR to the retrospective issue. * [Everything starts with a Merge Request](/handbook/communication/#start-with-a-merge-request)! No matter if it is a small or big change, in the MR, you will have the opportunity to discuss the things you are suggesting with the rest of the team. Add the label `~Retrospective follow-up` and relate the MR to the retrospective issue.
* For any other follow-up that cannot be resolved through an MR, open an issue in the [Package retrospective issue tracker](https://gitlab.com/gl-retrospectives/package/-/issues) and apply the `~follow-up` label. Assign a due-date to the next month. Link the issue back to the retrospective that prompted the action. * For any other follow-up that cannot be resolved through an MR, open an issue in the [Package retrospective issue tracker](https://gitlab.com/gl-retrospectives/package/-/issues) and apply the `~follow-up` label. Assign a due-date to the next month. Link the issue back to the retrospective that prompted the action.
* Consider bringing some of the [follow-up issues](https://gitlab.com/gl-retrospectives/package/-/issues/?label_name%5B%5D=follow-up) into the weekly retrospective for discussion. * Consider bringing some of the [follow-up issues](https://gitlab.com/gl-retrospectives/package/-/issues/?label_name%5B%5D=follow-up) into the weekly sync meeting for discussion.
* Follow the same process for issues raised during the weekly retrospective. * Follow the same process for issues raised during the weekly retrospective.
#### Missed deliverables retrospectives
When issues that we commit to delivering (have the `Deliverable` label) are not delivered in the milestone we commit to, we will hold an asynchronous retrospective on the miss to determine the root cause following the [guidelines outlined in the handbook](/handbook/engineering/root-cause-analysis/). In instances of a single issue, these retrospectives may be quite brief, in scenarios where we miss a larger effort, the root cause analysis will be more detailed. These should be conducted within the first week following the determination that we'll miss the deliverable.
### Standups ### Standups
#### Async Daily Standups #### Async Daily Standups
...@@ -195,15 +176,9 @@ The Geekbot asynchronous standup will be reserved for blocking items and merge a ...@@ -195,15 +176,9 @@ The Geekbot asynchronous standup will be reserved for blocking items and merge a
#### Async Issue Updates #### Async Issue Updates
The purpose of daily updates is to inspect progress and adapt upcoming planned work as necessary. In an all-remote culture, we keep the updates asynchronous and put them directly in the issues. The purpose of async updates is to communicate progress and allow others to prepare for upcoming work as necessary. In an all-remote culture, we keep the updates asynchronous and put them directly in the issues.
The async daily update communicates the progress and confidence using an issue comment and the milestone health status using the Health Status field in the issue. A daily update may be skipped if there was no progress. It's preferable to update the issue rather than the related merge requests, as those do not provide a view of the overall progress.
When communicating the health status, the options are: The async update communicates the progress and confidence using an issue comment and the milestone health status. Add a comment in your issue with the title `Async Update` once per week, or when something notable happens with regard to the issue. It's preferable to update the issue rather than the related merge requests.
* `on track` - when the issue is progressing as planned
* `needs attention` - when the issue requires attention or intervention to keep it on schedule
* `at risk` - when there is a risk the issue will not be completed according to schedule
The async update comment should include: The async update comment should include:
...@@ -215,6 +190,8 @@ The async update comment should include: ...@@ -215,6 +190,8 @@ The async update comment should include:
Example: Example:
```text ```text
#### Async Update
Complete: 80% Complete: 80%
Confidence: 90% Confidence: 90%
Notes: expecting to go into review tomorrow Notes: expecting to go into review tomorrow
...@@ -226,6 +203,8 @@ Include one entry for each associated MR ...@@ -226,6 +203,8 @@ Include one entry for each associated MR
Example: Example:
```text ```text
#### Async Update
Issue status: 20% complete, 75% confident Issue status: 20% complete, 75% confident
MR statuses: MR statuses:
...@@ -288,7 +267,7 @@ Issues that we're expecting to work on in the milestone will have the `workflow: ...@@ -288,7 +267,7 @@ Issues that we're expecting to work on in the milestone will have the `workflow:
* Everyone can contribute and collaborate in the milestone issue to propose work, raise concerns and clarify topics. * Everyone can contribute and collaborate in the milestone issue to propose work, raise concerns and clarify topics.
* To identify work and their priority, issues are assigned to the milestone and labelled as `Package:P1` or `Package:P2` according to their priority. Our prioritization model can be found below in the section [Priorities](/handbook/engineering/development/ops/package/#milestone-priorities). * To identify work and their priority, issues are assigned to the milestone and labelled as `Package:P1` or `Package:P2` according to their priority. Our prioritization model can be found below in the section [Priorities](/handbook/engineering/development/ops/package/#milestone-priorities).
* Before commiting to the work for the milestone, engineers perform [refinement](/handbook/engineering/development/ops/package/#refinement) and confirm all issues are ready for development. * Before commiting to the work for the milestone, engineers perform [refinement](/handbook/engineering/development/ops/package/#refinement) and confirm all issues are ready for development.
* We commit to the `Package:P1` work in the milestone by having an engineer add the `workflow::ready for development` label and then having the engineering manager add the `Deliverable` label. We measure our predictability and commitments with Say/Do ratios. * We commit to the `Package:P1` work in the milestone by having an engineer add the `workflow::ready for development` label and then having the engineering manager add the `Deliverable` label.
#### Refinement #### Refinement
...@@ -302,18 +281,11 @@ The product manager will determine issues that need to be refined by the enginee ...@@ -302,18 +281,11 @@ The product manager will determine issues that need to be refined by the enginee
To drive refinement, we use a randomly assigned refinement [DRI](/handbook/people-group/directly-responsible-individuals/). The refinement DRI is not necessarily the person completing the refinement tasks, but is responsible for ensuring they are completed within the assigned milestone. To drive refinement, we use a randomly assigned refinement [DRI](/handbook/people-group/directly-responsible-individuals/). The refinement DRI is not necessarily the person completing the refinement tasks, but is responsible for ensuring they are completed within the assigned milestone.
Before the milestone starts: Before the milestone starts the engineering manager determines which issues need to be refined by engineers and applies the `workflow::refinement` label. When the milestone starts the product manager or engineering manager may randomly assigns refinement issues to DRIs.
* The product manager determines which issues need to be refined by engineers and applies the `workflow::refinement` label
* Issues needing to be refined are listed on the [milestone planning issue](https://gitlab.com/groups/gitlab-org/-/epics/3591)
When the milestone starts:
* The product manager, engineering manager, or product designer randomly assigns refinement issues to DRIs.
Before the milestone is finished: Before the milestone is finished:
* The engineers refine each issue with the label `workflow::refinement` from the milestone planning issue * The engineers refine each issue with the label `workflow::refinement` from the next milestone planning issue
* When refinement is complete, each issue is moved to `workflow::ready for development` * When refinement is complete, each issue is moved to `workflow::ready for development`
Refinement guidelines: Refinement guidelines:
...@@ -339,7 +311,7 @@ Refinement guidelines: ...@@ -339,7 +311,7 @@ Refinement guidelines:
* Assign a weight to the issue according to [weighting guidelines](/handbook/engineering/development/ops/package/#issue-weighting). * Assign a weight to the issue according to [weighting guidelines](/handbook/engineering/development/ops/package/#issue-weighting).
* Create any follow-up issues that come out of refinement * Create any follow-up issues that come out of refinement
#### Milestone Priorities <!-- #### Milestone Priorities
Throughout the [workflow](/handbook/engineering/development/ops/package/#workflow), issues should be addressed in the following priority order: Throughout the [workflow](/handbook/engineering/development/ops/package/#workflow), issues should be addressed in the following priority order:
...@@ -347,7 +319,7 @@ Throughout the [workflow](/handbook/engineering/development/ops/package/#workflo ...@@ -347,7 +319,7 @@ Throughout the [workflow](/handbook/engineering/development/ops/package/#workflo
1. `Package:P1` label: Used to identify high priority issues that should be committed to in a given milestone or scheduled in an upcoming milestone. 1. `Package:P1` label: Used to identify high priority issues that should be committed to in a given milestone or scheduled in an upcoming milestone.
1. `Community Contribution` label: When in the milestone planning, this identifies community contributions we committed to delivering in a given milestone. 1. `Community Contribution` label: When in the milestone planning, this identifies community contributions we committed to delivering in a given milestone.
1. `Package:P2` label: Used to stretch goals for a given milestone. 1. `Package:P2` label: Used to stretch goals for a given milestone.
1. `workflow::refinement` label: These are issues that require [weighting](#issue-weighting), feedback, and scheduling before being moved to `workflow::ready for development`. 1. `workflow::refinement` label: These are issues that require [weighting](#issue-weighting), feedback, and scheduling before being moved to `workflow::ready for development`. -->
##### Issue Weighting ##### Issue Weighting
...@@ -465,7 +437,7 @@ Additionally, the Package team can help set realistic review/merge times based o ...@@ -465,7 +437,7 @@ Additionally, the Package team can help set realistic review/merge times based o
Ultimately the aim is to enable community contributor to deliver meaningful work with the least amount of back and forth and minimising the risk of stumbling on a show stopper. Ultimately the aim is to enable community contributor to deliver meaningful work with the least amount of back and forth and minimising the risk of stumbling on a show stopper.
#### Definition #### Definition of community contributions
A merge request with the following properties: A merge request with the following properties:
...@@ -566,7 +538,7 @@ These sessions are applicable to all development specialties (backend, frontend, ...@@ -566,7 +538,7 @@ These sessions are applicable to all development specialties (backend, frontend,
#### Process #### Process
* While there is no strict frequency requirement, team members are encouraged to hold at least one session per month for the entire team. * While there is no strict frequency requirement, team members are encouraged to hold at least one session per quarter for the entire team.
* To ensure efficiency and engagement, each session should be timeboxed to 30 minutes. * To ensure efficiency and engagement, each session should be timeboxed to 30 minutes.
* Any team member can volunteer to present on a topic of their choice. * Any team member can volunteer to present on a topic of their choice.
...@@ -586,7 +558,7 @@ When hosting a session, the team member should: ...@@ -586,7 +558,7 @@ When hosting a session, the team member should:
Cross-group dependencies may exist as pre-requisites to deliver Package features or bug fixes. Issues to deliver such dependencies are owned by groups that Package depends on, such as [Delivery](/handbook/engineering/infrastructure/team/delivery/) or [Distribution](/handbook/engineering/infrastructure/core-platform/systems/distribution/). Cross-group dependencies may exist as pre-requisites to deliver Package features or bug fixes. Issues to deliver such dependencies are owned by groups that Package depends on, such as [Delivery](/handbook/engineering/infrastructure/team/delivery/) or [Distribution](/handbook/engineering/infrastructure/core-platform/systems/distribution/).
For discoverability, issues that represent cross-group dependencies should be labeled with `package:cross-group-dependency`. If working on one of these issues, Package engineers should ensure that they are labeled correctly. For visibility, these issues are shown in the [Package:Cross-Group Assignments](https://gitlab.com/groups/gitlab-org/-/boards/2470946?label_name[]=package%3Across-group-dependency) issue board. For discoverability, issues that represent cross-group dependencies should be labeled with `package:cross-group-dependency`. If working on one of these issues, Package engineers should ensure that they are labeled correctly.
The product manager should include cross-group dependencies in the milestone planning issue for review, discussion and prioritization. The product manager should include cross-group dependencies in the milestone planning issue for review, discussion and prioritization.
...@@ -616,12 +588,10 @@ There are times during the development lifecycle that changes need to be communi ...@@ -616,12 +588,10 @@ There are times during the development lifecycle that changes need to be communi
## 🔗 Other Useful Links ## 🔗 Other Useful Links
* [Package backend board](https://gitlab.com/groups/gitlab-org/-/boards/892745)
* [#s_package](https://gitlab.slack.com/archives/s_package) in Slack * [#s_package](https://gitlab.slack.com/archives/s_package) in Slack
* [Recorded meetings](https://www.youtube.com/playlist?list=PL05JrBw4t0KoPiSySNHTfvxC20i0LppMf) - This is where we post all of our team meetings and discussions. * [Recorded meetings](https://www.youtube.com/playlist?list=PL05JrBw4t0KoPiSySNHTfvxC20i0LppMf) - This is where we post all of our team meetings and discussions.
* [Recorded user research (internal only)](https://www.youtube.com/watch?v=2A-VGtP-RJg&list=PL05JrBw4t0KoPiSySNHTfvxC20i0LppMf&index=1) * [Recorded user research (internal only)](https://www.youtube.com/watch?v=2A-VGtP-RJg&list=PL05JrBw4t0KoPiSySNHTfvxC20i0LppMf&index=1)
* [Monthly Retrospectives](https://gitlab.com/gl-retrospectives/package/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=retrospective) * [Monthly Retrospectives](https://gitlab.com/gl-retrospectives/package-stage/package/-/issues/)
* [Timezones](https://timezone.io/team/gitlab-package-team)
* [Package Registry processes](/handbook/engineering/development/ops/package/product/package-registry/) * [Package Registry processes](/handbook/engineering/development/ops/package/product/package-registry/)
* [Package use case](/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/usecase-gtm/package/) * [Package use case](/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/usecase-gtm/package/)
* [Package risk map](/handbook/engineering/development/ops/package/risk-map/) * [Package risk map](/handbook/engineering/development/ops/package/risk-map/)
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment