Skip to content
Snippets Groups Projects
Open Iterations In GitLab
  • Iterations In GitLab

  • Iterations In GitLab

    Open Epic created by Gabe Weaver

    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 A

    Iteration Report Inheritance

    Iteration Report Inheritance

    Group By UX

    Group By

    General Availability Minimum

    Iterations became Generally Available in %13.2. History:

    All checkboxed items will be shipped behind a feature flag in the release that they are completed. A secondary release post item will be created to align with the user journey of the feature. Once the GA milestone is reached, Iterations will be included as a primary item in the release post.
    • 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

    13.6/7 Goals - Integrate Iterations into other parts of GitLab

    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 :point_up:...

    • 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:

    This is the first step in implementing multiple milestones for Issues, Merge Requests and Epics (gitlab#5135 (closed))

    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:

    1. API
    2. Webhooks
    3. Quick actions
    4. Filters
    5. Epic milestone date calculation
    6. Any code that has where(milestone_id: ...) would break and would need to a JOIN now.
    20 of 36 checklist items completed · Edited by Gabe Weaver

    Linked items 0

  • Link items together to show that they're related or that one is blocking others.

    Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first