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 https://public.etherpad-mozilla.org/p/rust-release-triage.
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.