with the priorities for the team. The team members are notified, and proceed to update the issue
with their commitments for the milestone.
### Issue Development Workflow
In general, we use the standard GitLab [engineering workflow](/handbook/engineering/workflow/).
The easiest way for Engineering Managers, Product Managers, and other stakeholders
to get a high-level overview of the status of all issues in the current milestone,
or all issues assigned to a specific person, is through the [Current milestone board](https://gitlab.com/groups/gitlab-org/-/boards/1459244?milestone_title=Upcoming&label_name%5B%5D=group%3A%3Aimport%20and%20integrate),
which has columns for each of the workflow labels.
As owners of the issues assigned to them, engineers are expected to keep the
workflow labels on their issues up to date, either by manually assigning the new
label, or by dragging the issue from one column on the board to the next.
Once an engineer starts working an issue, they mark it with the `workflow::in dev` label as the starting point and continue updating the issue throughout development.
The process primarily follows the guideline:
``` mermaid
graph LR
classDef workflowLabel fill:#428BCA,color:#fff;
A(workflow::in dev):::workflowLabel
B(workflow::in review):::workflowLabel
C(workflow::verification):::workflowLabel
F(workflow::complete):::workflowLabel
A -- Push an MR --> B
B -- Merged --> C
C --> D{Works on production?}
D -- YES --> F
F --> CLOSE
D -- NO --> E[New MR]
E --> A
```
If someone starts working on an issue but it has the same workflow label for a
week, the assignee has to leave a comment explaining the status of the issue.
We should write at least one comment every week that the issue is not moving.
We use the standard GitLab [engineering workflow](/handbook/engineering/workflow/).
### Issue Boards
The work for the Import group can be tracked on the following issue boards:
The work for the Import group can be tracked in the following locations:
-[Import Current Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1459244?milestone_title=Upcoming&milestone_title=Started&label_name%5B%5D=group%3A%3Aimport&group_by=epic)(manually adjust the milestone filter to the current milestone)
To maintain good label hygiene, please apply the correct labels when creating or triaging issues.
To increase discoverability, apply the correct labels to issues.
All issues should have:
@@ -100,45 +62,6 @@ All issues should have:
For issues related to importers, also apply an `Importer:` label. For example: `~"Importer:GitHub"` or `~"Importer:Direct Transfer"`.
### Capacity Planning
We use a lightweight system of issue weighting to help with capacity planning.
These weights help us ensure that the amount of scheduled work in a cycle is
reasonable, both for the team as a whole and for each individual. The "weight
budget" for a given cycle is determined based on the team's recent output, as
well as the upcoming availability of each engineer.
Since [things take longer than you think](https://erikbern.com/2019/04/15/why-software-projects-take-longer-than-you-think-a-statistical-model.html),
it's OK if an issue takes longer than the weight indicates. The weights are
intended to be used in aggregate, and what takes one person a day might take
another person a week, depending on their level of background knowledge about
the issue. **That's explicitly OK and expected.** We should strive to be
accurate, but understand that they are estimates! Change the weight if it is
not accurate or if the issue becomes harder than originally expected. Leave a
comment indicating why the weight was changed and tag your EM so that we can
better understand weighting and continue to improve.
#### Weights
The weights we use are:
| Weight | Description |
| --- | --- | --- |
| 1: Trivial | The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.<br><br>Examples are documentation updates, simple regressions, and other bugs that have already been investigated and discussed and can be fixed with a few lines of code, or technical debt that we know exactly how to address, but just haven't found time for yet. |
| 2: Small | The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. Few surprises are expected, if any, and no coordination with other teams or people is required.<br><br>Examples are simple features, like a new API endpoint to expose existing data or functionality, or regular bugs or performance issues where some investigation has already taken place. |
| 3: Medium | Features that are well understood and relatively straightforward. A solution will be outlined, and most edge cases will be considered, but some extra investigation will be required to realize the solution. Some surprises are expected, and coordination with other teams or people may be required.<br><br>Bugs that are relatively poorly understood and may not yet have a suggested solution. Significant investigation will definitely be required, but the expectation is that once the problem is found, a solution should be relatively straightforward.<br><br>Examples are regular features, potentially with a backend and frontend component, or most bugs or performance issues. |
| 5: Large | Features that are well understood, but known to be hard. A solution will be outlined, and major edge cases will be considered, but extra investigation will definitely be required to realize the solution. Many surprises are expected, and coordination with other teams or people is likely required.<br><br>Bugs that are very poorly understood, and will not have a suggested solution. Significant investigation will be required, and once the problem is found, a solution may not be straightforward.<br><br>Examples are large features with a backend and frontend component, or bugs or performance issues that have seen some initial investigation but have not yet been reproduced or otherwise "figured out". |
Anything larger than 5 should be broken down if possible.
Weights should account for both development and review time.
Security issues are typically weighted one level higher than they would normally
appear from the table above. This is to account for the extra rigor of the
