GitLab.org / GitLab Community Edition

@sytses Before I go too much further, is this the part of Hygieia you were thinking of? They also have a delivery pipeline and a product-level dashboard. I haven't quite figured out what the new product-level dashboard is showing, but it looks pretty cool. :)

Alternate idea inspired by this, but focused on merge requests for a given milestone: #18439 (comment 12513983)

Marked the task Deploys as completed

@markpundsack this is the right direction. But I want to see every step of the way, chat, issue, plan, version control, CI, review, staging, production. Including medium times and 95% times.

including stages trending up and down, including last 5, including 5 most stuck in any phase

Sounds like this is more about Hygieia's other pipeline views:

or possibly

Let's focus on the first one, but add idea creation (which occurred in chat) and issue so we can capture idea to production.

@markpundsack indeed let's focus on the first one, that is the one I meant. I want the right side to say to say 14 days from idea to production, 30 ideas produced in the last 90 days.

@sytses Horribly rough, but it's a start:

mentioned in issue gitlab-com/blog-posts#230

Just to add the perc 95:

Changed title: WIP: Project Dashboard → WIP: Idea to Production Dashboard

@markpundsack I love it! Can we also add a few stages and use the following naming?

1. Idea (Chat)
2. Issue (Tracker)
3. Plan (Board)
4. Code (IDE)
5. Commit (Repo)
6. Test (CI)
7. Review (MR)
8. Staging (CD)
9. Production (Chatops)

BTW I would make production the same column as the others and put '30 ideas shipped' in the pipeline health.

@sytses The way I've interpreted it is that the times included in each column are the times that features spent in each stage before moving to the next state. Since production is a terminal state, there's no next state to transition to, thus no duration for living in production. Thus production is used to provide a summary of the entire pipeline.

@hazelyang Might be a good time to get your help here both on making this pretty/complete, and thinking through the UX.

Added moonshots label

@markpundsack use the production column for the overall time in the same style as the others

Other than that we should only display:

Last 90 days:

1. 17 ideas shipped
2. 120 collaborators
3. 80% code coverage

@markpundsack will update the screenshot before handing it over to UX

@markpundsack I made a draft of out my proposal in https://docs.google.com/spreadsheets/d/1jKl5jDuOoBXIS-VLxC5IpN3hFFR5QmKKBdCkwipX72Q/edit#gid=0

Thinking about the spreedsheet:

I think having both average and median isn't valuable and can be distracting. Since we're including 95th percentile, a lot of people would say to then pair it with 50th percentile (median) and drop the mean.

I think the overall stats should be much more prominent than the recent issues. Otherwise it'll be a wall of numbers. The median should be most prominent of all.

I wonder if we'd want to see the stats for the last 5 issues that made it to production vs seeing the 5 most recent items currently in each stage, and the stats for that specific stage. In other words, in that chart , put different issues/MRs in each column, which would then give the viewer a sense of what is being worked on, what's being thought about, etc.

Something like this:

@sytses Not quite what you asked for, but it was easier to put together quickly. After creating it, I realize it might be cool to watch issues move around in real-time, moving from one column to another. That might be more interesting than squeezing time stats for each issue. The summary median and perc95 are more important numbers to watch.

mentioned in issue #19793 (closed)

Idea to production dashboard is too long of a name. Analytics sounds nicer than dashboard and we use that name for similar pages in GitLab (contributor analytics, etc.). Maybe call it 'velocity analytics'?

Changed title: WIP: Idea to Production Dashboard → Velocity Analytics

@sytses Updated title and description.

Milestone changed to 8.12

Added gitlab-org/gitlab-ce~19492 label

Added direction label

@tauriedavis Can you iterate on this?

Reassigned to @tauriedavis

I have a couple questions while I'm working on this.

1. What is the gear icon for?
2. Is the duplication of project name necessary?
3. The current wireframe is very wide and will cause the page to have a horizontal scroll even at max width. Is this intentional or should the UI be rearranged to stack (more like a vertical timeline rather than horizontal?) How important is it for management to view all sections at once?

cc @markpundsack

(1) To configure the dashboard. May be unnecessary. This originally sprung from a dashboard that contained multiple projects, but I kept it to a single project for simplicity. Not sure if the final version would have multiple projects on a single dashboard, but I would expect people to ask for that.

(2) No. :) If this dashboard has multiple projects, then the breadcrumb and menu shouldn't be for a single project. If it's for a single project, then there's no reason to include the project name in the lower part.

(3) I think we should expect this display to sit on a large monitor, so horizontal scrolling isn't reasonable, but wide screen real estate is. I'm not sure about vertical timeline, but willing to try anything.

This is a pretty different layout so let me know if you think this is way off the mark. It demonstrates a more vertical timeline. There is more space and I think it is easier to read. The idea is that you are able to view all the different stages at once and view the tracker for each stage individually. This allows there to be a better overview of the issues/MRs for each stage without feeling cramped.

Thoughts? @markpundsack @sytses @dzaporozhets @cperessini @jschatz1

Interesting take. I could see it being more useful when interacting at a desktop and wanting to drill into the areas. It wouldn’t work as well on a TV posted in a scrum pit because it requires clicking around on the stages to see the tracked items.

That is true, I wasn't thinking of this for a TV. But there could be a presentation mode that cycles through the different stages.

Thoughts?

@tauriedavis looks really nice

Interesting take. I could see it being more useful when interacting at a desktop and wanting to drill into the areas. It wouldn’t work as well on a TV posted in a scrum pit because it requires clicking around on the stages to see the tracked items.

@markpundsack we should design our UI for laptop/desktop first instead of TV. If there is a need for TV mod - it should be implemented separately as button to toggle it or something like that.

we should design our UI for laptop/desktop first instead of TV. If there is a need for TV mod - it should be implemented separately as button to toggle it or something like that.

I can get behind that. I was originally envisioning the primary interface for this dashboard to be a TV, but that's probably not actually true. And a simple TV mode could be to rotate through each of the stages every X seconds.

I definitely like having more real estate for the issues since they were so cramped in my mockup that they'd be useless.

The more I look at it, the more I think this is awesome.

@tauriedavis this is awesome! You did a really good job. Everything I asked for is in there. We can ship it like this.

Obviously this great mockup gives inspiration so I do want to share suggestions for additions:

1. This screen Velocity Analytics can come under the menu item Pipelines so the top menu doesn't need to expand.
2. Rename 'Tracker' to 'Latest production deploys'
3. For every production deploy show the total time as well.

Again, this is really well done.

Good point. @tauriedavis, my mockup showed 5 issues/MRs per stage, but Sid's original spreadsheet mockup showed the 5 most recent features (MRs) that have shipped to production, and included times for each of them. I couldn't make that work due to my limited mockup skills, but perhaps you could? :)

@sytses @ChadMalchow Do you have any large customers interested in this, so we could bounce off what they most want to see?

I was originally envisioning the primary interface for this dashboard to be a TV

@markpundsack think about GitLab - we don't have an office with TV :)

Added frontend and removed gitlab-org/gitlab-ce~19492 labels

Assignee removed

Thanks for the feedback everyone! I've updated the mockup to include Sids comments and added it to the issue description!

Thanks @tauriedavis!

Minor thing while I'm looking at it, as you click on the various stages, it would be great if the URL changed so people could bookmark and share individual stages. Probably true for timespan too.

@Haydn request from Mark above, #18687 (comment 13263267). Any clients you have that may be interested in seeing this and giving feedback?

I do have a contact from a new group at an existing customer who would be a good person to vet these metrics with. I'll make an intro via email @markpundsack cc/ @ChadMalchow

@markpundsack why not make this an EE feature?

Love what you guys are doing with this view. Posted yesterday by David Farley, a respected Continuous Delivery thought leader about this exact topic: http://techbeacon.com/doing-continuous-delivery-focus-first-reducing-release-cycle-times

"DevOps and continuous delivery is really about one thing: reducing release cycle time. By cycle time, I mean the time involved in having an idea, getting that idea into the hands of our users, and gathering feedback. We should optimize our software development processes for that. Whatever it takes."

@ChadMalchow yes, it should be!

Moved from #18687 (closed)

Thanks @dhekimian!

mentioned in issue gitlab-ee#110 (closed)

mentioned in issue #18687 (closed)

@markpundsack @JobV in agile development velocity means the number of points done per time period, I propose to rename this to "Cycle time analytics"

Good point. Cycle time could work. Would being more verbose with "release cycle time" be better?

@markpundsack that makes sense but I think 3 words are already a lot for a feature name, if we make it more people will start picking 3 out of 4 words at random I'm afraid

Changed title: Velocity Analytics → Cycle Time Analytics

@dzaporozhets recently added this rule to the UI guidelines:

When adding a new tab to the header don't use more than 2 words for text in the link. We want to keep links short and easy to remember and fit all of them in the small screen.

Do you think Cycle Analytics is enough?

@tauriedavis Cycle Analytics it is.

Changed title: Cycle Time Analytics → Cycle Analytics

mentioned in issue gitlab-ee#112

mentioned in issue #20800 (closed)

@ChadMalchow I'm sorry but @job reminded me that point 6 of https://about.gitlab.com/about/#stewardship states that we'll ship all of our scope in CE. Cycle analytics is part of our scope in https://about.gitlab.com/direction/#scope. A much smaller consideration is that it would be harder to demo idea to production if it was EE (we would have to add a license and there would be confusion of what was in CE and EE).

I think that over time we'll have cycle analytics features that will be EE exclusive. For example showing Cycle analytics on the group level and exporting reports with the data.

Having both the issue board and cycle analytics in CE means that we don't have major EE features except for branch permissions and HA Omnibus. We will spend some time identifying and prioritizing EE features for upcoming releases.

I think there is room in CI, by now CI is mature and is still 100% CE. It would be great to identify upcoming features that are more relevant to organizations with more than 100 users. Maybe for this we should talk to customers that use CI heavily. To help with this we should improve the usage ping in gitlab-ee#892 (closed)

/cc @markpundsack @JobV

Moved from gitlab-ee#847 (closed)

mentioned in issue #14605 (closed)

I had to design a very minimal version to be able to ship this with 8.12, as we're still lacking large parts (like Cog API and integration), which will be impossible to complete in the same cycle.

@regisF and I did wonder how many of the times came to be. We thought of a few ways to calculate them, but below some of our thoughts. I only listed the items I think we can ship with 8.12. It'd be great to get your feedback on them @markpundsack and @sytses

1. Plan
   1. Time from issue creation to existing on a board
   2. Time from issue creation to getting a milestone
   3. any of the above
2. Code:
   1. Mention an issue in your commit
   2. Have a MR reference the issue?
   3. The branch is pushed with the issue name
   4. any of the above
3. Test
   1. Time for the commit to be tested?
   2. Time for the commit to pass the test?
4. Review
   1. Time from MR creation to being merged
5. Staging 1.Time from merge to deploy on staging

mentioned in issue #20043 (closed)

@JobV I added the timings as I see them to the description.

Thanks @sytses. I'll rework it into a first iteration for 8.12

Added Product work label

mentioned in issue #21170 (closed)

created an issue for 8.12 specifically, as we have to reduce scope: #21170 (closed)

Milestone changed to Backlog

Added meta label

Changed title: Cycle Analytics → [Epic] Cycle Analytics

Why is there "code coverage" in metrics ? It does not make sense if you consider the goal of the page, isnt it ?

Mentioned in commit gitlab-com/www-gitlab-com@8303f99c

Am I missing something?
Why are there no information for each items in Cycle Analytics?

Another thought.
Shouldn't we add a new label for Cycle Analytics like issue boards for Issue Boards feature?

Am I missing something? Why are there no information for each items in Cycle Analytics?

@blackst0ne You need to have deployed to production to get analytics for "idea to production". Have you set up environments and deploys?

@markpundsack, that screenshot was made on GitLab.com.

https://gitlab.com/gitlab-org/gitlab-ce/cycle_analytics

I was wondering, why does Gitlab, introducing Cycle Analytics to people, not have it itself? =)

Mentioned in issue #22458 (closed)

@blackst0ne we don't deploy to GitLab.com yet with Gitlab Deploy.

Let's close this issue and improve Cycle analytics further in smaller issues.

Status changed to closed

mentioned in issue #30469 (closed)