GitLab GitLab Group Kickoffs - Plan:Project Management, 13 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.4 Kickoff - Plan:Project Management

Description

Plan 13.4 Release Planning Issue - https://gitlab.com/gitlab-org/plan/-/issues/147

A

Hey y'all gabe, weaver senior product manager of the project management group in the plain stage of get lab, bringing you the 13.4 release, planning issue for the project management group. uh It's gonna be a fun release. um We're gonna highlight a couple of them: real, quick, high level, uh we're gonna complete the iteration chart for iterations we're also gonna, deliver the burn down trap for iterations, so real, quick, the uh burn down chart is showing you your actual progress against your estimator.

A

What should be your burn down for how many issues and the pace over a given um iteration that you should be bringing your issues down, and this is going to be selectable by weight or by um issue count, and so this is going to be, I think, largely driven by the new event system. We've been working on um and similar to that, but slightly different is the burn up chart and this is different and that helps you track and understand how your scope changes throughout a given iteration. So you can see if scope creeps.

A

This red line right here would be a scope added during the course of a iteration where your blue line is your scope, completed ideally in the iteration um they'll meet at the end.

A

But if you don't get everything done completed, that was added you'll kind of have this drift between the two and be able to see that maybe you added too much scope or over committed, and it will also be historically accurate and that if you move issues out of a given iteration efforts over, none of these charts will change, which has been a big pain point for our customers. So I'm excited to see these two things come to the iteration report.

A

Once we get the iteration report a little bit further on we're going to be back, pointing it to the milestone report view as well, uh so we'll get a fresh view app based mouse and report view in the very near future on the performance side of things, we're going to fix an m plus one in the profiles. uh Notifications, controller- and this is in your notification settings.

A

If you go into your uh your settings here- and you want to see all the uh groups and projects that you can change your notification settings for um right now, if you have or the member of a lot of groups, it takes approximately one minute for that page to load. uh That's because of this n plus one plus. There is no pagination in that view, and so we're committing to getting this n plus one done in 13.4 and a stretch goal for the team.

A

uh If we can get to, it is adding pagination to the notification settings page, and this is under quality of life performance improvements uh goals within our group, that we have every milestone um and yeah. So the the working theory right here is that if we fix the m plus one we add pagination, uh it should take that minute down to uh under a couple seconds. For that view to load which would be great uh performance boost for the application.

A

And then the last thing that we're going to be focusing on knocking out of the park in 13.4 is a kind of business related event tracking. So we're going to be adding aggregate counts for issue related user driven events right now.

A

We have some of these for com, but in order to understand everyone who interacts with an issue all the different parts of it, whether it's editing description, creating it closing it adding a comment changing labels, there are lots of different actions you can take on it and to get a better perspective and understanding of the total unique users who are interacting with issues.

A

We need to track some of these um kind of lower level events and aggregate uh distinct counts of unique users across those events, and so right now uh the four uh tables that contain all the events we want to track or spread across these four different database tables and we're going to add the ability to union these within the usage things.

A

So we can get distinct counts of unique users over a given time period, and so we've kind of listed out all the different events we want to track and union up and the challenge here is: it will be a performance problem looking to union all of these different events across four different tables in a performant way, so we might have to start with just doing a couple of them at a time and we'll look at ones that have the highest count currently and then work our way down the list until we figure out how to solve the problem for all of them.

A

But this is the same problem that we're going to face whenever we want to look at eventually being able to collect total uh unique users are now across all stages and interactions. um You basically have to start with events like these. You need up another level, then you need up another level to get to the stage level. Events uh so uh it'll be a fun challenge to solve, um and I'm hoping we'll start to make some good progress on this in 13.4.

A

uh If you have any questions, uh you can go check out. Leave a comment on this uh release issue: it's in gitlab, org, slash plan, that's issue; 147. I'll leave a link to this in the youtube video as well. Thanks for watching bye.