21:05:22 <teor> #startmeeting Network Team: Ticket Triage and Proposed Tickets
21:05:22 <MeetBot> Meeting started Tue Mar  5 21:05:22 2019 UTC.  The chair is teor. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:05:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:05:51 * gaba is reading the changes to your proposal teor: https://pad.riseup.net/p/network-team-triage-2018
21:06:13 <teor> Some background: we put a lot of tickets in milestones, but we don't end up doing them by the time the milestone is over
21:06:47 <teor> I suggested a new proposed tickets process in December 2018, where we tagged tickets and talked about them at the meeting.
21:06:55 <teor> It didn't work: meeting time is precious!
21:07:21 <teor> So we scheduled this meeting to talk about better ways to manage tickets.
21:07:47 <teor> I tried to come up with a better proposal (the "February 2019 Version" on the pad)
21:07:53 <teor> (done)
21:08:08 <nickm> So my perspective, such as it is: I like the thing where we don't put thing right into 0.x.y-final, but rather add an 0xyz-proposed tag to them...
21:08:28 <gaba> If this is related to releases can we just have as many tickets as we want for that release and only include the ones that were completed (leaving the non-completed tickets for the next release).
21:08:38 <nickm> but I think we need a clear set of criteria for what can go straight into 0.x.y-final...
21:09:04 <nickm> ...and I hope that we come up with a better procedure for approving 0xy-proposed tickets
21:09:04 <gaba> ok, nickm: you are saying that we need to define  what we mean by 'done' for a ticket to go into a release
21:09:36 <nickm> gaba: I don't understand?
21:10:15 <teor> gaba is suggesting that we don't put tickets in a release until they are done. nickm is suggesting that we put essential tickets in a release, even if they are not done yet.
21:10:21 <gaba> by 'better procedure' you mean we need a way to know when a ticket can go into 0xy release?
21:10:32 <gaba> ahh, ok
21:10:40 <gaba> thanks teor
21:12:13 <nickm> what should we try to figure out today?
21:12:34 <gaba> teor, catalyst: any thought on this?
21:13:12 * catalyst still reviewing the pad
21:13:18 <teor> I would like us to work out what we want to use release milestones for. And then bring that proposal back to the rest of the team.
21:13:45 <catalyst> teor: do you consider release milestones to be independent of release branches?
21:14:20 <teor> In general, the closed tickets in a release milestone on trac have been merged to that release branch (and all future branches)
21:14:29 <nickm> Personally, without thinking too deeply: I would like release milestones to be accurate predictions of what goes out in a given release series. I'd like the features in that branch to be done by the freeze date.
21:15:17 <teor> I would also like the bugfixes in that branch to be done about a week before the stable release date.
21:15:26 <catalyst> i think they're somewhat tightly coupled, because we generally want changes to go on the release branch for that milestone, so waiting until something's done to decide which release it goes in is difficult unless we change a lot of our process
21:15:56 <nickm> I think we need 2-3 weeks before the stable release date, given that we want to have the fixes in an rc before we declare stable
21:16:03 <teor> Fair enough.
21:16:10 <teor> nickm: ^
21:16:22 <nickm> We also have to think about the TB release schedule, which is itself a can of worms
21:16:32 <nickm> but basically yeah
21:17:03 <teor> nickm: I think we can adjust the exact timeframes as we go. I'd like to work out a broad process in this meeting.
21:17:33 <nickm> +1
21:17:45 <teor> catalyst, gaba: Here's an alternative suggestion: Our largest backlog is tickets that are in new, assigned, needs_information, ...
21:18:04 <teor> So let's add a ticket to a release when it is in needs_review.
21:18:21 <teor> * release milestone
21:18:33 <catalyst> teor: is this for features or bugfixes?
21:19:07 <nickm> on the theory that once a ticket has a patch from a reasonable person, it will probably make it into a release soon?
21:19:37 <gaba> that sounds good
21:19:45 <teor> nickm: Yes. And on the theory that the set of patches that don't make it in releases is much smaller than the set of proposed tickets that don't make it in releases.
21:20:28 <teor> catalyst: "Most tickets" = anything that has a flexible timeframe. Features, non-urgent bugfixes, etc.
21:20:29 <nickm> I agree with that. But one problem is that it doesn't mesh with our roadmapping and release planning so well.  I often want to find "what should I work on".  When I do that, I usually look at "what's in this release" and "what's assigned to me".
21:21:05 <nickm> I would be okay if there were another place I could look for "what should I work on" ... but 'tor: unspecified' is too big to be that place, of course
21:21:40 <nickm> I could look at the release milestone, plus whatever is in "this-release-proposed" ?
21:21:41 <teor> nickm: in my experience, releases can also be too big to be that place
21:21:50 <gaba> nickm: you mean things to work on that are not on the roadmap?
21:21:53 * catalyst wishes we had a proper backlog with fine-grained ordering of tickets
21:22:08 <nickm> gaba: I'm looking for things to work on, whether they are roadmapped or not
21:22:46 <nickm> things that are useful, important, etc. I find that often I do more productive work if I find the task that fits my frame of mind
21:22:52 <teor> Ok, so let's talk about the alternatives for a "what to work on next" queue:
21:22:56 <gaba> mm, I thought people were working on the roadmap, reviewing tickets or high-priority tickets.
21:23:08 <nickm> gaba: So I usually do the roadmap, sure...
21:23:12 <nickm> ... but it leads to trouble
21:23:23 <gaba> ?
21:23:31 <nickm> like right now, 040 needs to happen.  That isn't roadmapped, so it isn't happening.
21:23:59 <nickm> Also, often we have open-ended sponsors like S31.
21:23:59 <teor> gaba: I don't really have a process that helps me identify roadmap, reviews, or high-priority tickets. Let alone other essential things that we haven't roadmapped.
21:24:19 <nickm> We might have a ticket that says "modularize things!"
21:24:27 <gaba> by high-priority tickets i mean high-priority bugs... sorry
21:24:28 <nickm> and a hundred child tickets that we _could_ do
21:24:37 <nickm> but they might all be optional.
21:24:38 <gaba> oh, I see
21:24:54 <gaba> so you are saying that it should be more fine grained
21:25:12 <nickm> I don't know
21:25:22 <nickm> if it were fine grained that would solve some problems...
21:25:34 <nickm> but achieving that would be hard, and might create more problems...
21:25:42 <nickm> and might not be the best way to solve these problems
21:26:56 <nickm> If we can do this without periodic processes , though, that would rock
21:27:13 <gaba> yes, it may not be totally defined at the moment of drafting the roadmap and the definition of what needs to be done is part of the work
21:27:17 <nickm> maybe we should look at the current array of 040-proposed and 041-proposed tickets to see what kind of things wind up there?
21:27:25 <catalyst> i think periodic processes have important uses. i'd like them to be as unintrusive as possible
21:27:39 <nickm> I wish there were also a way to look at the tickets in the milestones that are not roadmapped
21:28:21 * catalyst thinks we're allowing the limitations of Trac to constrain our thinking
21:28:43 <teor> Every time we add a new system for tracking tickets that isn't on trac, we add a periodic data sync task
21:29:12 <gaba> Yes. It sucks that we can not integrate trac with other better tool to manage this.
21:29:17 <teor> Let's try to outline the high-level goals?
21:29:22 <gaba> ok
21:30:02 <teor> I want the tickets in our milestones/releases/roadmaps to be achievable by their due dates
21:30:26 <nickm> +1
21:30:39 <teor> catalyst and nickm and I have all talked about wanting a list of "what to work on next"
21:30:44 <nickm> I want a summary of what we ought to do for each release, and what we are suggesting that we ought to do
21:31:05 <teor> What do you mean by "ought"?
21:31:44 <teor> Do you mean "need"? Or "intend"?
21:31:46 <nickm> I'm not sure. It's kind of fuzzy
21:31:50 <gaba> In general the roadmap in a kanban board should be that, a place where we see what to work on next.
21:32:23 <teor> I don't want to talk about tools right now, because I want to focus on high-level goals.
21:32:36 <gaba> ok
21:32:46 <catalyst> i would like to ask what purposes we want the roadmap to serve?
21:33:14 <gaba> the roadmap is a place where we see what we need to work on next
21:33:38 <gaba> ideally we would have a roadmap per team and per project
21:33:58 <teor> The roadmap is not that place for me right now.
21:34:13 <catalyst> is it only that, or is it also a tool to communicate to people outside the team? because i think those have different constraints
21:34:27 <gaba> ok, tell me your process on how you look on what to work next
21:34:35 <nickm> My roadmap problem is that I don't know how to change it.
21:34:51 <gaba> catalyst: a tool for people outside? not the main goal of the roadmap
21:35:00 <teor> Ok, I'm going to mention one more goal, and then move on from goals:
21:35:03 <teor> I want a list of tickets that was merged into every release, and a list of tickets that will soon be merged into every release.
21:35:07 <nickm> I can change tickets, but I feel I shouldn't change them, since that would change the roadmap
21:35:25 <gaba> nickm: how do you change tickets?
21:35:33 <gaba> it would be good to have a living roadmap that we can change
21:36:00 <teor> (I think that's a high-level goal)
21:36:16 <nickm> gaba: I just change them on track. I adjust the fields on them or create them or whatever
21:36:32 <nickm> but I worry about putting new ticekts in
21:36:33 <gaba> you change what needs to be done in the ticket?
21:36:55 <teor> I don't want to spend a lot of time manually syncing data between different systems.
21:36:59 <nickm> I make new tickets, or put new tickets in a milestone, or change which milestone a ticket is in
21:37:24 <nickm> I try not to put new tickets in an existing milestone, though, because that conflicts with the roadmap as I understand it
21:37:25 <gaba> by milestone i guess you mean release number, right?
21:37:44 <nickm> yeah; those are the only milestones we have on trac right now
21:37:50 <gaba> ok, yes
21:38:15 <gaba> i think it would be good to add new tickets and if they need to be included in the roadmap then we need to review it and add them
21:38:45 <gaba> the roadmap will change once we start looking at each ticket we work on (sorry if I'm missing something)
21:39:17 <teor> Gaba: when you say "the roadmap", you're talking about the kanban?
21:39:37 <gaba> the roadmap is reflected in the kanban board (on my perspective) right now
21:40:13 <teor> OK. So the kanban only contains features for future releases. Which I have 3 days per week to work on.
21:40:26 <teor> But I also need to know what to work on next for the other 2 days a week.
21:40:26 <gaba> yes
21:41:17 <teor> Like nickm mentioned, there is no kanban for 0.4.0 bugfixes
21:41:28 <gaba> right
21:41:31 <teor> Nor is there a kanban for backports, for example
21:42:03 <gaba> right and you all are using trac queries for that
21:42:21 <gaba> with keywords and milestones
21:42:31 <teor> I am using trac queries for backports, because there are a limited number of backports.
21:43:05 <teor> I don't use trac queries for 0.4.0 bugfixes, because they are not on my list of tasks to do every week.
21:43:17 <teor> And sometimes the list of bugs takes a long time just to review.
21:43:30 <teor> * review = look at to work out which one to do
21:43:54 <nickm> I have a weekly item "look at 0.4.0" on my todo list. without it, I would do ~0 040 work
21:44:15 <nickm> as it is, I'm on track to do very little, and get the release out late again
21:44:24 <teor> Can we have a shared list of weekly items and suggested times?
21:44:32 <teor> For example:
21:44:39 <teor> 3 days roadmap coding
21:44:43 <teor> 0.5 days reviews
21:45:04 <teor> 0.5 days bugfixes
21:45:23 <teor> 0.5 days admin
21:45:57 <teor> 0.5 days rotations / roles?
21:46:38 <teor> Otherwise, only the people who notice do the things. And that feels terrible.
21:47:06 <nickm> I feel like I spend more time than that on all the things, and yeah.
21:47:27 <teor> Well, yes. I do think our 3 days of roadmap coding might need to be smaller.
21:47:37 <teor> But at least we can work from there and iterate.
21:47:43 <catalyst> it feels to me like we have far too much interrupt-driven stuff
21:48:01 <teor> Can you give an example?
21:49:25 * gaba wonder if this meeting would be clearer if we do voice instead of text
21:49:43 <teor> That's something to try for next time.
21:49:48 <teor> We have about 10 minutes left. What can we achieve in that time?
21:49:50 <catalyst> i'm not sure i can give a concrete example offhand
21:49:53 <teor> ok
21:50:27 <catalyst> between reviews and capturing stuff that happens in IRC to open tickets, that ends up being a lot of my time
21:50:43 <teor> Yes, I agree
21:50:53 <gaba> I need to think a little more about this. I still wonder what would be bad about changing the process and including only things that are done.
21:51:10 <catalyst> oh, and noticing when CI breaks and helping people troubleshoot that
21:51:30 <nickm> including only things that are done makes it hard to see what to do next
21:52:13 <gaba> ok, so the main issue may be on figuring out what to do next in general with tasks for releases
21:52:38 <teor> No, I'm sorry. We have a lot of issues. That is one of them.
21:54:56 * nickm has to go for dinner break. can we figure out some next steps?
21:55:21 <gaba> it may make sense to reserve the same time next week and talk via voice?
21:55:41 <nickm> okay w me
21:56:12 <teor> I feel like we raised a lot of important issues in this meeting.
21:56:21 <teor> But that makes it hard to focus on improving one thing.
21:56:34 <teor> So I don't want to have the same conversation by voice.
21:56:47 <teor> Instead, I want to have a conversation about improving one thing.
21:58:09 * nickm has to go now; but I'm +1 on whatever issue y'all want to talk about
21:58:22 <gaba> ok
21:58:23 <nickm> I'll be back in an hour for the team meeting
21:59:04 <teor> And I want us to come up with goals and actions, because voice meetings are hard to capture and review.
21:59:42 <gaba> I can commit on making a summary of this list. Teor: what is the one thing you want to focus on?
22:00:21 <gaba> Somebody needs to stop the meeting.
22:00:27 <teor> I want to read the goals from this meeting, and think about them, and then decide which one is most important.
22:00:27 * gaba does not remember who started it
22:00:33 <gaba> ok
22:00:47 <gaba> stop logging* the meeting
22:00:58 <catalyst> teor started it?
22:01:18 <teor> #stopmeeting
22:01:26 <teor> #endmeeting