@@ -298,81 +299,33 @@ The team uses the [`#g_pipeline_execution_quad`](https://gitlab.slack.com/archiv
The [Pipeline Execution Workflow board](https://gitlab.com/groups/gitlab-org/-/boards/1372896) is the source of truth for current and upcoming work.
### Planning
Our planning timeline follows the [GitLab Product Development timeline](/handbook/engineering/workflow/#product-development-timeline).
For information about `Engineering Time` see [Engineering Initiatives](/handbook/engineering/#engineering-initiatives).
**PM** (with help from **EM** as needed) will curate the [list of `Candidate::x.x` + not `Engineering Time` list](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=candidate%3A%3A17.x&label_name%5B%5D=group%3A%3Apipeline%20execution¬%5Blabel_name%5D%5B%5D=Engineering%20Time&first_page_size=20) to ensure there is a reasonable number of high priority issues to select from at any point. If there are no issues for the milestone you are looking for you may select from a future milestone.
**EM** (with help from **PM** as needed) will maintain the [list of `Engineering Time` + `Candidate::x.x`](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=candidate%3A%3A17.x&label_name%5B%5D=group%3A%3Apipeline%20execution&label_name%5B%5D=Engineering%20Time&first_page_size=20) issues to ensure there is a reasonable number of high priority issues to select from at any point. If there are no issues for the milestone you are looking for you may select from a future milestone.
By the Friday 2 weeks before the end of the current milestone each **Engineer** will:
- Ensure the milestone on your current issue reflects the milestone you believe it will be completed based on the latest knowledge
-**Note:** Any issues you have in progress that will not be completed in the current milestone can be used in lieu of selecting a new issue as long as the criteria matches
- If you are unsure if the issues you have in progress are still a priority check with the EM and PM to verify.
- Update the ~Deliverable or ~Stretch label if there is one if necessary
- Select 1 [`Candidate::x.x` + not `Engineering Time` issue](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened¬%5Blabel_name%5D%5B%5D=Engineering%20Time&label_name%5B%5D=group%3A%3Apipeline%20execution&label_name%5B%5D=candidate%3A%3A17.x&first_page_size=20) that you will work on in the upcoming milestone. Start with ~priority::1 issues first followed by ~priority::2 and ~priority::3
- Assign yourself
- Assure there is a weight set
- Set the milestone according to the milestone when you expect the work to complete
- If it is not the upcoming milestone, break the issue into multiple issues, one of which can be completed in the upcoming milestone if at all possible.
- Let the EM/PM know you have done this in an issue comment on the original issue so they can ensure the rest of the issues are planned for appropriately.
- Add the `Deliverable` label.
- Select 1 [`flaky-test` issue](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=group%3A%3Apipeline%20execution&label_name%5B%5D=failure%3A%3Aflaky-test&first_page_size=20) to fix.
- Do a quick check to see if there are multiple issues that are clearly caused by the same issue, link these as related and/or assign to themselves.
- Set the milestone appropriately to indicate when the test will be fixed.
- If you are unsure of the timeline, you can delay setting the milestone until you are comfortable committing to a milestone.
- Select 1 item to weight and refine for [upcoming work](https://gitlab.com/groups/gitlab-org/-/boards/4178322)
- Assign this item to yourself. You can unassign it once you have completed the refinement process.
- You may want to add a comment indicating that you are assigning to yourself for refinement purposes only, so there is no confusion. This is entirely optional.
- Do not set a milestone on the issue.
- If refinement is going to take considerable effort, create a [refinement "~spike" issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Pipeline%20Execution%20Refinement%20Spike)(see also [Spikes](#spikes) and [Steps for Refining and Weighting Issues](#steps-for-refining-and-weighting-issues))
- Tag the **EM** in a comment on the spike to let them know you have created this spike.
- Use this as your `Engineering Time` item for the milestone.
- Select 1 item to weight and refine for [community contribution](https://gitlab.com/groups/gitlab-org/-/boards/4178322)
- Assign this item to yourself. You can unassign it once you have completed the refinement process.
- You may want to add a comment indicating that you are assigning to yourself for refinement purposes only, so there is no confusion. This is entirely optional.
- Do not set a milestone on the issue.
- If refinement is going to take considerable effort, create a [refinement "~spike" issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Pipeline%20Execution%20Refinement%20Spike)(see also [Spikes](#spikes) and [Steps for Refining and Weighting Issues](#steps-for-refining-and-weighting-issues))
- Tag the **EM** in a comment on the spike to let them know you have created this spike.
- Use this as your `Engineering Time` item for the milestone.
- Select 1 [`Engineering Time` + `Candidate::x.x` issue](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=candidate%3A%3A17.x&label_name%5B%5D=group%3A%3Apipeline%20execution&label_name%5B%5D=Engineering%20Time&first_page_size=20) to fix.
- Assign yourself
- Assure there is a weight set
- Set the milestone according to the milestone when you expect the work to complete
- If it is not the upcoming milestone, break the issue into multiple issues, one of which can be completed in the upcoming milestone if at all possible.
- Let the EM/PM know you have done this in an issue comment on the original issue so they can ensure the rest of the issues are planned for appropriately.
- add the `Deliverable` label or `Stretch` label.
- Add a comment to the milestone planning issue to indicate which issues that you have completed this planning work and the issues you have selected.
Throughout the milestone, if an **Engineer** completes their tasks and has extra capacity:
- checkout [What do I work on next](#what-do-i-work-on-next)
- By the Monday the week the milestone ends:
- Planning issue is finalized and **PM** will tag manager, Product Design, engineers, and EM for review and feedback.
- By the Friday the milestone ends:
-**Engineers** should comment on the planning issue with any changes to their planned work.
-**PM** completes monthly kick-off video featuring `~direction` and `Deliverable` issues
- By the Monday of release week:
- The **EM** will ensure that labels are set correctly for any milestone issues
**Note:** The **EM** and **PM** may need to modify the team commitments and schedule work for the upcoming milestone as we focus on [Customer Results](/handbook/values/#results) over what we plan.
### Unplanned Work
#### How Engineering Refines Issues
Pipeline Execution has a few special workstreams of unplanned, reactive work that requires fast triage and resolution tied to explicit SLOs:
-[Pipeline Execution Infradev Triage and Tracking](https://gitlab.com/gitlab-org/verify-stage/-/work_items/635)
-[Pipeline Execution S1 & S2 Bug Triage and Tracking](https://gitlab.com/gitlab-org/verify-stage/-/work_items/619)
-[Pipeline Execution RFH Triage and Tracking](https://gitlab.com/gitlab-org/verify-stage/-/work_items/614)
- Pipeline Execution Flaky Tests: We do not yet have articulated process for this, but it is an emerging high-priority work stream that we'll need to monitor carefully and actively manage going forward.
_side note: we prefer [using Refining over Grooming](/handbook/communication/top-misused-terms)_
These issues can be scheduled for work at any time, based on their triaged severity. S1 issues may be pulled directly into development, and some issues could be backlogged or closed outright if the issue requests changes that we're not going to make. Regardless of the triage outcomes, these issues need to be _addressed_ promptly, and not left in the backlog. If there is a developer directly assigned to an issue, they should be the first point of contact and authority on the resolution of that issue. In general, the EM and PM will be responsible for ensuring these get resolved within our target timeframes.
Engineers are expected to allocate approximately 6 hours each milestone to refine and weight issues on the [`~needs weight` board](https://gitlab.com/groups/gitlab-org/-/boards/4178322).
### Planned Work
The purpose of refining an issue is to ensure the problem statement is clear enough to provide a rough effort sizing estimate; the intention is not to provide **solution validation** during refinement. When refining issues, engineers should timebox the activity to no more than 2 hours per issue. If an issue is complex and will require more research, we should track that effort in a refinement "~spike" to ensure we account for it in milestone planning. The "~spike" should be linked as blocking the original issue and outline the outcomes expected and a timebox for the effort should be specified. The original issue should be labeled as "~workflow::blocked".
-[Pipeline Execution Current Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1372896?milestone_title=Started&label_name[]=group%3A%3Apipeline%20execution): All work, planned and unplanned, will be assigned to the milestone we plan on delivering the issue. This board lists issues currently in-flight. If there is no assignee, the issue should be marked as Ready For Development and can be picked up at any time. If the issue isn't Ready For Development, it should be reviewed to confirm that it is, or kicked out of the milestone.
-[Pipeline Execution Upcoming Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1372896?label_name[]=group%3A%3Apipeline%20execution&milestone_title=Upcoming): In general, during any given milestone the EM and PM will queue up work for the next milestone. Due to the typical length of projects we work on, this can and will often contain new issues created by developers as follow-ups to their current work.
-[Next 1-3 Releases](https://gitlab.com/groups/gitlab-org/-/boards/1372896?label_name[]=group%3A%3Apipeline%20execution&milestone_title=Next%201-3%20releases): This is a pool of issues with relatively high priority that should be the main source of planned work for upcoming milestones. Periodically, this list should be reviewed to ensure priorities are up to date and there is a healthy top-of-backlog to pull issues from for development.
-[Net 4-6 Releases](https://gitlab.com/groups/gitlab-org/-/boards/1372896?label_name[]=group%3A%3Apipeline%20execution&milestone_title=Next%204-6%20releases): Similar to the Next 1-3 Releases pool, but low urgency. They can be pulled into development if appropriate, or used to refill the 1-3 release pool as issues are scheduled from there.
Engineering uses the [following handbook guidance for determining weights](#weighting-issues). If any issue needs any additional `~frontend ~backend ~Quality ~UX ~documentation` reviews, they are assigned to the respective individual(s).
As of FY27Q2, issues from the Backlog milestone are not proactively reviewed on a regular basis. As we do longer term strategic planning, we may search the backlog for related issues and bring them into our 6-month planning view. If you believe an issue in the backlog requires attention or a higher priority, contact the PM or EM in that issue.
#### How Engineering Refines Issues
If an issue isn't yet marked as **Ready for Development**, the EM or PM will ask an engineer to review, validate, and refine the issue as it moves into the [Upcoming Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1372896?label_name[]=group%3A%3Apipeline%20execution&milestone_title=Upcoming)
- Planned work should not exist in the [Current Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1372896?milestone_title=Started&label_name[]=group%3A%3Apipeline%20execution) without a complete refinement and technical implementation proposal. It should be **Ready for Development**.
- Planned work can exist in the [Upcoming Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1372896?label_name[]=group%3A%3Apipeline%20execution&) while in **Refinement**. In this state, it should be assigned to an IC on the team that has been explicitly tasked with refinement.
- Unplanned work, by its unpredictable nature, may exist in the current and upcoming milestone in any state. We'll do our best to move quickly on them, but the formal processes may be lighter and less visible if the assigned engineer has to work quickly to mitigate or resolve an active major problem.
##### Checklist for Refining Issues
@@ -382,7 +335,10 @@ Engineering uses the [following handbook guidance for determining weights](#weig
1. Does the issue have a proposal in the description? _If so:_
1. Does the proposal address the problem statement?
1. Are there any unintended side effects of the implementation?
1. Does the issue have proper labeling matching the job to be done? (e.g. bug, feature, performance)
1. Does the issue have proper labeling matching the value being delivered?
- Issue type: bug, feature, maintenance. These labels are important for both internal visibility and corporate compliance functions.
- Severity labelling: All issues should have their severity critically evaluated for current accuracy. Some issues, especially follow-up issues, can carry an inflated priority and severity label after the original source issues has been resolved. During refinement, it's critical that we consider the value being delivered in scope during refinement.
Any one on the team can contribute to answering the questions in this checklist, but the final decisions are up to the PM and EMs.
@@ -478,9 +434,9 @@ More detail on the workflow is available on the [Product-Development Flow](/hand
### "What do I work on next?"
- check with your team members to see if they need help to complete their committed work. See [Working Right to Left to reduce WIP](#working-right-to-left-to-reduce-wip)
- check with the EM or PM to see if there are any customer support requests you can help with.
- consult the lists used in [planning](#planning) to find additional unclaimed items to work on.
1. Check with your team members to see if they need help to complete their committed work. See [Working Right to Left to reduce WIP](#working-right-to-left-to-reduce-wip)
2. Check the [Unplanned Work tracking issues](#unplanned-work) for anything that needs to be picked up. If you're not sure, check with the EM or PM to see if anything requires attention or confirm that it doesn't.
3. Pick up a new [planned work](#planned-work) item. Check the Current Milestone board first, and if there's nothing unassigned or that you can help with, move on to an item from the Upcoming Milestone board.
#### What are the priorities for this milestone?
@@ -490,7 +446,7 @@ We use a series of labels to indicate the highest priority issues in the milesto
1. Each milestone will start with 1 issue per engineer, which will be labeled as `Deliverable`, and `group::pipeline execution`. This should account for approximately 30% of the average total milestone weight.
1. Once all of the `Verify::P1` issues have been picked up and are in `workflow:in dev` or beyond, we have `Verify::P2` and `Verify::P3` to signal issues that are important and will likely become `Verify::P1` issues in later milestones.
Following the priorities, the lists used in [planning](#planning)will be curated, so that each team member can pull items from these lists as they choose according to capacity.
Following the priorities, the lists used in will be curated, so that each team member can pull items from these lists as they choose according to capacity.
##### Setting the Milestone
@@ -834,7 +790,7 @@ This board has 2 main sections:
- the area affected does not change frequently
- the problem is related to a number of reported `severity::4` bugs
1. Issue scheduling. The Engineering Manager(s) will review the [PE Technical Debt issue board](https://gitlab.com/groups/gitlab-org/-/boards/3567075?scope=all&label_name[]=group%3A%3Apipeline%20execution&label_name[]=technical%20debt&assignee_id=None) and recommend issues to schedule for upcoming milestones by adding them to the [planning issue](#planning) for a milestone or communicating with Product a need to schedule the issue in an upcoming milestone. The team strives to have 20% of a sprint's capacity filled with Tech Debt issues.
1. Issue scheduling. The Engineering Manager(s) will review the [PE Technical Debt issue board](https://gitlab.com/groups/gitlab-org/-/boards/3567075?scope=all&label_name[]=group%3A%3Apipeline%20execution&label_name[]=technical%20debt&assignee_id=None) and recommend issues to schedule for upcoming milestones by adding them to the planning issue for a milestone or communicating with Product a need to schedule the issue in an upcoming milestone. The team strives to have 20% of a sprint's capacity filled with Tech Debt issues.
Note that multiple factors can exist at once. In that case use your judgment to either bump the impact score or lower it. For example:
