|
| 1 | +--- |
| 2 | +title: Working Group Retrospective |
| 3 | +type: docs |
| 4 | +--- |
| 5 | + |
| 6 | +# Working Group Retrospective |
| 7 | + |
| 8 | +* [Zulip stream] or read on the [Zulip archive](https://zulip-archive.rust-lang.org/131828tcompiler/82575designmeeting20191112.html) |
| 9 | + |
| 10 | +[Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-12 |
| 11 | + |
| 12 | +## What you are looking at |
| 13 | + |
| 14 | +We did a [short survey](https://forms.gle/PmZVgsAWZckceT3Y6) before |
| 15 | +the meeting. The following notes were scraped from the 10 responses. I |
| 16 | +tried to de-duplicate common items. Towards the end, you will find |
| 17 | +some minutes that were taken during the meeting itself. --nikomatsakis |
| 18 | + |
| 19 | +## Things to KEEP doing |
| 20 | + |
| 21 | +* Working groups are useful |
| 22 | +* Nice to know who to talk to in order to get involved |
| 23 | + * this was more of a struggle before |
| 24 | +* Providing opportunities for mentorship is good |
| 25 | +* Scoping out small groups of decision makers for "in the weeds" decisions |
| 26 | +* Weekly updates |
| 27 | +* Dedicated Zulip streams: great to have ability to link/skim, even if most are muted |
| 28 | +* Regular meetings are a good way to keep working groups focused |
| 29 | + |
| 30 | +## Things to STOP doing |
| 31 | + |
| 32 | +* Maybe fewer working groups, with more time/energy invested in each? |
| 33 | + * Some of the smaller WGs don't see much activity, could discourage people |
| 34 | + |
| 35 | +## Things to START |
| 36 | + |
| 37 | +* Check in with WGs not just about achievements but process |
| 38 | + * e.g., diagnostics and mir-opt don't have any meetings |
| 39 | + * Question from editor: Not clear if the idea here is to try and have a more uniform process across teao use that as a signal that help may be needed |
| 40 | + * yes, that's what I meant |
| 41 | + * which is what you meant? :) |
| 42 | +* Improve our labeling system |
| 43 | + * Tag PRs with WG-XXX instead? |
| 44 | + > [name=Centril] Instead or both? We (T-release) can still use A-* labels. |
| 45 | + > [name=Felix S Klock II] I worry about *switching* to this (rather than the A-categories) because it can mean that multiple WG's get pings for incidental stuff...? I guess the labels don't actually cause pings so maybe that doesn't matter. Another potential issue (again that arises from multiple WG-labels on one issue) is that it can become ambiguous *which* WG should be taking lead on something. |
| 46 | +* Proactive recruitment for specific working groups? |
| 47 | +* Devise metrics to evaluate effectiveness? |
| 48 | + * [name=Centril] What would those metrics be (also... performance reviews? ^^ Rust is not a company; heh) |
| 49 | + * Should WGs create those? |
| 50 | +* Figure out the "wind down" process (e.g., for groups like NLL and pipelined compilation) |
| 51 | + * Do we need to document which members are responsible for long-term maintenance? |
| 52 | + * Consider e.g. NLL |
| 53 | + * How to ensure the remaining work gets done? A lot of it is falling to Matthew Jasper for NLL, is that ok? |
| 54 | +* Some better way to advertise what we are doing |
| 55 | + |
| 56 | +## Things to IMPROVE |
| 57 | + |
| 58 | +* Longer timeslot in compiler team triage meeting (maybe just a few minutes) |
| 59 | + * More time for discussion or Q&A related to plans, progress, etc |
| 60 | + > [name=Felix S Klock II] maybe if we just moved it to the begining but had a hard limit on time? |
| 61 | +* Onboarding could still be improved |
| 62 | +* Some better way to get a sense of status without participation in every compiler team meeting |
| 63 | + * Maybe use Inside Rust blog or other means to make more regular public announcements |
| 64 | + * Maybe a regular (but less frequent) time when *all* groups can check-in |
| 65 | +* Require explicitly documented leaders, some older WGs are missing them |
| 66 | +* Improve use of WG labels: |
| 67 | + * the set of github WG labels and actual WGs do not correspond in a meaningful fashion |
| 68 | + * Hard to know when to use the A label vs WG |
| 69 | + - [name=Centril] This is primarily a matter for T-release triage. When in doubt, use both labels. |
| 70 | +* Distinction between shorter and longer term groups |
| 71 | + * maybe use distinct terms |
| 72 | + * add metadata indicating this |
| 73 | +* Help ensure that each working group has active leadership, which makes a big difference |
| 74 | + * hard to find people with enough time |
| 75 | + * maybe we can help leaders? |
| 76 | + * multiple leads are good |
| 77 | + * [name=mw] +1! [name=Centril] +1 |
| 78 | +* More involvement from the lang team on Zulip is useful, developing a better working relationship between lang and compiler team would be good |
| 79 | + * [name=Centril] The lang team recently "moved" to Zulip |
| 80 | + * [name=Centril] Narrowing the funnel through which T-lang adds new work to T-compiler's queue would be good |
| 81 | +* Relationship between triaging wg (from release team) and compiler team |
| 82 | + * |
| 83 | +* More retrospectives to help us reflect on how things are going! |
| 84 | +* compiler-team web pages feel like they could be better |
| 85 | + * templates are not that useful |
| 86 | + * would be nice to have the updates there |
| 87 | +* overhead of maintaining all the web pages and other things feels too high |
| 88 | + * can we post updates in a more central fashion? |
| 89 | +* fold the activity of "regular contributors" into the working groups more |
| 90 | + |
| 91 | + |
| 92 | +## Other things |
| 93 | + |
| 94 | +* don't generalize too much from NLL, it was a big prominent lang feature with lots of interest |
| 95 | + |
| 96 | +## notes and ideas from meeting |
| 97 | + |
| 98 | +The following notes and conclusions were extracted during the meeting. For more details, |
| 99 | +please see the complete [Zulip stream]. |
| 100 | + |
| 101 | +### discussing check-in and how to keep the info up to date |
| 102 | + |
| 103 | +* maybe a zulip stream that people can post updates to |
| 104 | + * perhaps with bot support to scrape and collate |
| 105 | + * this would land in github in the form of meeting minutes |
| 106 | + * but it would also make it easy to catch up on the status |
| 107 | +* make a point to help WGs develop roadmaps |
| 108 | + * helps to frame check-ins |
| 109 | +* metrics? |
| 110 | + * but what? and let's not try to make this too much like a company |
| 111 | +* wind-down |
| 112 | + * things like NLL are winding down but it doesn't feel very organized |
| 113 | + * even the concept of wind-down requires more work on roadmaps, so this ties in with the point above |
| 114 | + * maybe the next step for winding down is to try and use that process, but aimed more at finding the work left to be done |
| 115 | + * goal: "what did we get done, what's left, and -- if it matters -- who will do it" |
| 116 | +* kinds of working groups |
| 117 | + * groups doing manual, recurring tasks and upkeep |
| 118 | + * groups around an area of the code ("WG-NLL", "WG-mir-opt") |
| 119 | + * project groups with a pretty clear goal ("WG-NLL") |
| 120 | + * maybe projects are things that "area-based groups" do? |
| 121 | + * groups to ping people ("ICE-breakers", "WG-rollups") |
| 122 | +* labels |
| 123 | + * some way to indicate that the issue has been triaged by a given wg (e.g., `AsyncAwait-Triaged`) |
| 124 | +* follow-up topics to drill into more |
| 125 | + * creation of wgs is undocumented |
| 126 | + * there are ongoing activities that it would be great to "capture" in a WG |
| 127 | + * designation of kinds of working groups didn't reach much of a conclusion |
0 commit comments