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.