Release cycle triage proposal


Edit: This event happens every two weeks on #rust-triage. See here for the next scheduled in your time zone. Notes and minutes are kept at


I want to get the ball rolling on an idea that’s been batted around recently. You may be aware that some of us are constantly despairing of our inability to keep ourselves and the greater project abreast of our goals and efforts toward them. In particular, we could do much better at identifying the most critical work to be done and ensuring that somebody actually does it. Whether new features, bugs, or regressions, most people have some idea of what they think is important for each release cycle, but we rarely come to any project-wide understanding of the current work to be done.

We regularly come up with new schemes to tag and organize issues in the hopes that it will make the state of the project more clear. Inevitably these technical schemes fail to produce useful results, and my present belief is that this is because of human failures in our process - in other words, people don’t take advantage of the tools we already have available.

As just one step in yet another attempt to improve Rust’s project management I’d like to propose a new triage meeting, open to all, that takes place twice per release cycle. In the past we have had moco-internal triage meetings, and I felt pretty strongly that just putting the current set of issues in front of everybody’s eyeballs at once was effective at keeping key developers on the same page about the state of the project. I’d like to try doing such meetings again.

These meetings will differ from the team meetings in that they will be exclusively about triage, and will be taking a global view of the project. Most team meetings now are not focused on triage, which seems to be taking a backseat to more immediate matters like keeping the feature pipeline and RFC process moving.

The first of the two meetings will occur at the beginning of the release cycle, essentially setting goals for the release. The second would be half-way through the cycle, reviewing progress and adjusting priorities for the cycle.

Activities we will pursue:

  • Reviewing all P-high bugs, with an eye toward demoting them to P-medium.
  • Reviewing P-medium bugs with an eye toward promoting them to P-high or P-low.
  • Ensuring that all P-high bugs have somebody assigned to them and that they are actively working on them.
  • Reviewing regressions and assigning them priority.
  • Reviewing performance measurements for regressions.

Ideally, once we hit our stride the set of P-high bugs will present a reasonable view into the work going into the next release. Then we might evolve P-high into release milestones.

While this will be an open meeting, I’d suggest attendance is most appropriate for project and team leaders, developers closely involved in new feature development, and paid contributors.

So what do you think? Would this be effective? Are there other triage activities we might focus on? Would you attend?

What medium should we use? IRC? Hangouts? It’s so much easier to have productive meetings over video, but doing so with large open meetings is super difficult.

Rust 1.17 release status
New release milestones

I know some teams that have meetings over hangouts, that are open to the public. they found that when several people join (people who don’t want to actively participate, but want to watch/listen live), video quality suffered a lot. in response, I believe they still use hangouts, but also stream to youtube for any “read-only” participants.

For P-high bugs, does it make sense for the assigned fixer to check-in (via comment on github) every few weeks by providing a very brief status (“still working on this” or “blocked on #1234”). hopefully this would be a low-cost/high-value way to signal to the members of the community the latest status of the issue (think: people who are subscribed to the issue)


I would attend.


I would also love to see this happen. Live streaming with questions taken over IM/IRC, and ability to join the meeting if need be, would be a good start IMO.


Yes, I would expect them to demonstrate activity. At the triage meetiengs if it doesn’t look like anything’s happening we might ping them and expect a response at least by the subsequent triage.

Yeah that seems possible.


Could you good folks look at including “documenting the feature” to the list of things to triage as well (relevant RFC, of course, but it’d be nice to include in triage regardless).


As you know, I am a pretty big fan of this idea. However, I am concerned that two meetings per cycle is not enough. In particular, when high-priority issues arise, I’d like to become aware of them much faster than that. I had originally thought of the purpose of this meeting as circulating awareness of issues that have arisen (since not everyone can watch the issue tracker all the time). For that purpose, weekly would be better.

Still, we can start with 2 and consider upping to more once we’ve tried it out for a bit.


Yeah, this is a key question. I’d game to try IRC and see how it goes. It’s certainly the lowest common denominator. But I agree that voice can certainly be more efficient.


I’ve added a recurring event, every 3 weeks to the community calendar, starting on June 23. It’s set for 9 AM PST, which I think is 4 PM GMT. I sent invites to people I thought would be interested. If you need a reminder and want to be on the invite list just let me know and I’ll add you.

Right now it’s scheduled to take place solely on IRC, in #rust-triage. I’ll send out reminders before the first one.


Open meetings are a great idea, and I hope to see more progress like this going forward. I’m definitely going to attend.

Note to self: the meeting is at Noon Eastern Time. Must remember to be awake at noon.


This might be useful (since 9AM PST is not always 4 PM GMT):


Reminder that this is happening tomorrow at the time indicated in @djc’s link above. I’ve put together an etherpad with an agenda: Because the agenda is so massive we’re probably not going to get through the whole thing, and because the format is new, I expect surprises. But let’s try to rip through it quickly to see how it goes and not get too worried about the details for this first time.


Thanks for everybody who came and helped today. It went smoothly for a first try.

Here’s a summary of changes we made:


I wasn’t active in the discussion, but was watching from the sidelines. Awesome. So glad we’re doing this.


Reminder that this is happening again tomorrow. at 9 AM PST. See the calendar for the time in other timezones.


Thanks for coming today! It went really well. We’re down to only 7 P-high bugs and started plowing though P-medium. Uncovered lots of old issues to either close or nominate the teams to reconsider. A summary of actions taken follows.

Release triage minutes 2016-07-14




This is amazing. Nice work!


Reminder that this is happening again in 1 hour. Sorry for the late notice.


Here’s a summary of the actions taken in today’s meeting.




We’ve done this a few times now, so maybe a good time to review. I have thoughts on a few specific topics.

P-high - what’s it mean?

We are down to 3 P-high bugs!

This is awesome. We are ruthless at triage. It’s probably time to think again about what P-high means based on what we’ve learned, as well as how to make sure the right bugs are P-high.

My best guess is that P-high means ‘critical to fix right now’. As a corollary, that also means ‘somebody is assigned’. If we’re not willing to assign somebody thin it must not be critical.

P-high - how do we get more of them?

Is it really only 3 bugs that we think are important to fix right now? We’ve structured this to be great at demoting P-high bugs, but not uncovering new ones - most P-medium seem to stay P-medium. Should we incorporate triage of new bugs into this process? If so, it’s not clear when we’ll have the time, since there’s a steady stream of new bugs.


Similar to the last, we’re not doing anything in particular to uncover regressions and promote them to P-high. Just hoping that individuals are watching the incoming issues and tagging them right.


We still haven’t gotten through the backlog of P-medium bugs, and per the previous topics there’s still more useful triage we probably should be doing. Anybody interested in bumping the frequency from every 3 weeks to every 2 weeks?

cc @compiler_subteam, @lang_subteam, @sanxiyn @steveklabnik @alexcrichton @jntrnr reviewing the triage process

Release cycle milestones and P-high