_A new issue to not remove the content of the original issue, which is found here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20975_ ## Proposal Cycle analytics tracks the _median_ time between idea => production steps. This iteration does not ship a Chat ops integration, so we leave that out for now. Idea to production consists of several events, which we've labeled with a name and the time that is represented in that thing. E.g. _Plan_ represents the time spend in the planning phase, so the time that the idea exists and is planned, but no one has started implementing it yet. * Issue (Tracker) * from issue creation until given a milestone or list label (first assignment, any milestone, milestone date or assignee is not required) * Plan (Board) * from given a milestone or list label until the first commit * Code (IDE) * from first commit until the merge request is created (this might exclude coding time if you use WIP, so be it) * Test (CI) * total test time for all commits/merges * Review (MR) * from merge request creation until MR merged (closed MR's won't be deployed) * Staging (CD) * from MR merge until deploy to production (production is last stage/environment) * Production (Total) * sum of the above excluding Test (CI) time The dropdown at the top allows users to have the summary for the: * Last 30 days (*the things that went to production the last 30 days.*) * Last 90 days We will add more items in this dropdown in the future - probably things like `Current year` and `All time`.  ## Differences with original design - no chat part => not possible without integration of Chatops, needs another release at least - no feed of events => to reduce scope of iteration - reduced information on top => ditto, but if code coverage is easy to add, we should. Collaborator info seems useless - no delta's => to reduce scope - less statistics => to reduce scope and reserve for EE enhancements ## Questions > How do we track whether a branch corresponds to an issue? Not sure. I'm thinking the best strategy is to use either the suggested branch name (when you create a new one in an issue) or by using that in a regex, for instance `*5-branch-permissions*`, so you can still do things like `jobv/5-branch-permissions`. @sytses also suggested to check whether an issue is closed by a branch https://gitlab.com/gitlab-org/gitlab-ce/issues/21170#note_14155739 ## Original design This is the original design, I've simplified it above to reduce the iteration size.  ## New design elements we need - [ ] A design for this page - [ ] Blank state for the feature - [ ] In some cases, we will have stages (like Review step for instance) which will be blanked. We need a design for empty rows. ## References - #21375 Cycle Analytics: v1 Rollout