@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. :)
@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.
@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 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.
Mark PundsackAdded gitlab-org/gitlab-ce~394693 label
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.
@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.
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'?
Mark PundsackChanged title: WIP: Idea to Production Dashboard → Velocity Analytics
Changed title: WIP: Idea to Production Dashboard → Velocity Analytics
I have a couple questions while I'm working on this.
What is the gear icon for?
Is the duplication of project name necessary?
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?
(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.
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.
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.
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? :)
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.
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
"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."
@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
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.
@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 https://gitlab.com/gitlab-org/gitlab-ee/issues/892