Merge pull request #114 from nikomatsakis/2019.07.08

notes from 2019.07.08 meeting

Author: nikomatsakis

minutes/design-meeting/2019-07-08-triage-wg.md

@@ -0,0 +1,123 @@
+# Triage Working Group Discussion
+
+- [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05)
+
+# Summary
+
+- Discussed ideas of a triage working group and how that might interact
+- Discussed pnkfelix/nikomatsakis taking leave over next few weeks and what to do in the meantime
+- Discussed the problems around review queues
+
+# pnkfelix/nikomatsakis absence
+
+pnkfelix will be going on parental leave for 2 months starting
+July 15. nikomatsakis will be on PTO for a month or so, with limited
+availability. In the interim, nagisa has volunteered to run meetings.
+
+Another concern was the general review backlog. pnkfelix/nikomatsakis
+discussed spending a bit of time triaging things that need review and
+trying to develop a plan.
+
+In general, we noted that it would be useful to keep a calendar
+on [the compiler-team repository][ctr] to help track this sort of thing.
+
+[ctr]: https://github.com/rust-lang/compiler-team
+
+# Triage plan
+
+In general, the compiler triage effort is feeling pretty stretched.
+It also falls largely on a few people at this point in time. We
+discussed how we might broaden the effort.
+
+## The work of solving a regression 
+
+[Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169713350
+
+Most errors come in the form of regressions: something that used to
+compile or run, but no longer does. One observation is that the work
+of handling a regression is actually something you can break down into
+many steps:
+
+- Figuring out the impact of the bug and assigns priority
+- Coallescing duplicates
+- Determining the cause of the regression: we have a tool that bisects to a nightly
+  or even a specific PR, but somebody has to run it
+- Minimizing the error case into a standalone example that can be debugged
+- Identifying the *expected behavior* of the test case -- sometimes
+  the regression comes from a bug **fix**!
+- Actually fixing the bug
+
+The final two require some amount of expertise -- though the precise
+amount varies. Today, there are a lot of people who help and do the
+minimization and bisection work, but it would be great if we could
+help organize those efforts more.
+
+## The ICE-breakers
+
+[Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169713884
+
+The next thing is one we've kicked around for a while -- can we create
+some kind of "ICE-breaker" group that is dedicated to fixing
+regressions, ICEs, and other "small" bugs in the compiler? What
+overlap does that group have with the triaging efforts described
+above?
+
+We discussed this for some time and seemed to come roughly to the
+following conclusions:
+
+- The [#wg-triage effort in the release team][wg-triage] obviously overlaps a lot
+  with these efforts.
+- Perhaps we should divide responsibility as follows:
+    - wg-triage:
+        - decides what is important to fix or address based on the impact
+        - helps to bisect, minimize, and identify the source of problems 
+        - brings it to compiler team attention and checks on progress regularly
+        - tries to find assignees -- this will require compiler team participation! 
+    - compiler-team:
+        - does the actual fixing
+- Note that if wg-triage is going to find out who to assign to a bug,
+  that is going to require compiler team participation. We could in
+  tricky cases have a "liason" who can be assigned that has the job of
+  just reassigning to someone more appropriate.
+- On compiler side, the ICE-breakers group might still exist as well,
+  and many of its members would likely participate in the wg-triage
+  effort, but the focus of ICE-breakers would be mostly on the actual
+  fixing of the bug, and less on the bisection and so forth.
+
+[wg-triage]: https://www.rust-lang.org/governance/teams/operations
+
+We concluded ultimately that we should try to touch base with the
+wg-triage effort and discuss.
+
+## Expert map, reviewing load
+
+[Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169715908
+
+We have an [expert map] on the compiler-team repository, but it is
+sparsely populated and doesn't include the new compiler team
+contributors. That would be in principle be helpful in finding people
+to assign to fix regressions or to review PRs. We also discused how
+contributors, even if they don't know an area well, can still be
+assigned to do a preliminary review or fix. We need to improve the
+"expert map" to be more complex and also to include "levels of
+knowledge". Perhaps rename it to "knowledge map" or something like
+that. Also, this can be a great way to figure out things that need to
+be added to the rustc-guide.
+
+[expert map]: https://github.com/rust-lang/compiler-team/blob/master/experts/MAP.md
+
+## Nomination labels
+
+[Link to approximate start of conversation]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-07-05/near/169715099
+
+We spent a bit of time discussing how the `I-nominated` tags are not
+sufficiently precise -- at minimum, they should identify the team, but
+perhaps also have more information.
+
+## Action items
+
+Emerging from this meeting:
+
+- Extend expert map with member/contributor levels
+- Create a compiler-team PTO calendar where people can note their upcoming absences
+- Join discussion with #wg-triage