Iterations In GitLab
Iterations In GitLab
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
gitlab#5135 (closed) and gitlab#35290 (closed) introduce the ability for issues and merge requests to be assignable to more than one timebox. The purpose of this epic is to break down implications across the rest of the product so implementation can be discrete and parallelized.
UX
Top of Iteration Report
Iteration Report Inheritance
Group By UX
General Availability Minimum
Iterations became Generally Available in %13.2. History:
- I can click into the iterations list from the sidebar - gitlab!31335 (merged)
- I can click a button to create an iteration - gitlab!31335 (merged)
- I can view a list of past iterations - gitlab!31335 (merged)
- I can click into a previous iteration to the iteration report - gitlab!31335 (merged)
- I can enter an title (required)
- I can enter description (optional)
- I can enter a start date (required)
- I can enter an end date (required)
- I can can click a button to create the iteration after the fields were filled out
- I can select the iteration an issue belongs to within the sidebar (gitlab!32361 (merged))
- I can remove an iteration from an issue via the sidebar (gitlab!32361 (merged))
- I can view an iteration report that contains a list of issues assigned to the given iteration (gitlab#218277 (closed)) (gitlab!34379 (merged))
- Iterations are auto-closed at 23:59:59 on the iteration's specified end date (part of gitlab#227272)
13.5 Goals - Provide better progress reporting
- Show iteration report via inheritance model (gitlab#222763 (closed))
- View burnup chart (gitlab#222750 (closed))
- View burndown chart (gitlab#222741 (closed))
- Toggle metrics / charts based on weight (gitlab#222753 (closed))
- Toggle metrics / charts based on time (gitlab#222754)
13.6/7 Goals - Integrate Iterations into other parts of GitLab
- Add "Group By" Project (when viewing the report from a group) (gitlab#225498)
- Add "Group By" assignee (gitlab#225499)
- Add "Group By" label (gitlab#225500 (closed))
- Show progress indicators for each grouping of issues (gitlab#225501)
- Improve the Iteration list view (gitlab#227272)
- Integrate Iterations into Boards (gitlab#196804 (closed))
- Filter by Iteration (gitlab#118742 (closed))
- Sort by Iteration (gitlab#196800)
- Bulk edit Iteration (gitlab#196806 (closed))
Misc
- I can view multiple pages of previous iterations
- Show more relevant Issue/MR card details based on what unit you are filtering your iteration report by. 1
- Improve ability to select set of labels to view "Group By" labels to reduce noise of all the labels you don't want to see. This should have a similar UX to that of selected labels that you want to have swimlanes for on Issue Boards.
- Add Velocity/volatility to the Iteration list View
- Better show scope change within an iteration report
- Backport report view to Milestones
After
- Shamelessly copy Pivotal Tracker's project settings for "Iterations and Velocity"
- Auto-move issues from one iteration to the next
- Incorporate iterations and analytics/reports into Boards...
Technical Considerations
- GraphQL First
- Pajamas First
- Iterations live at the group level
- There can only ever be one active iteration / in progress at a time
Iteration State
Ideally we would work towards this sort of state model:
- An iteration can be upcoming. The start date is in the future.
- An iteration can be in progress. That current date is on/between the start date and the end date.
- An iteration can be done. The current date is after the end date.
- An iteration can be archived but not deleted. This is less destructive than deletion and allows for traceability / audit trails.
As for validations:
- An issue can never belong to more than 1 in progress iteration.
- An iteration cannot be assigned a start and end date that overlaps with another iteration's timebox.
Original description:
To keep changes to a minimum, I think we can start by preparing our backend storage to support multiple milestones while keeping everything else working the same way.
The idea is to create separate tables issue_milestones
, merge_request_milestones
, and epic_milestones
and then reading / writing to that instead of milestone_id
. Old data would have to be migrated too.
We would still support just 1 milestone for now and then we would need something like:
def milestone
milestones.first
end
def milestone=(milestone)
self.milestones = [milestone]
end
Though in reality it's not that simple and a lot of things may break. Here are some things mentioned previously that need to be considered:
- API
- Webhooks
- Quick actions
- Filters
- Epic milestone date calculation
- Any code that has
where(milestone_id: ...)
would break and would need to aJOIN
now.
- Show closed items