RFC: Project Groups

[XAMPPRocky]

Rendered

Formalises the different groups in the rust lang organisation (specifically working groups and project groups).

Thank you to @nikomatsakis, @valgrimm, and everyone on @rust-lang/wg-governance who helped review this RFC.

[spacekookie]

I left some comments in the RFC, might finish the review later.

I'm quite excited about the idea of having a more official way to create groups and teams, although I think the distinction between a team (like lang or lib) and a working group (like embedded, or CLI) seems a bit arbitrary, i.e. would we want to create new teams or just working groups?

[Manishearth]

I've already read through this in the past and followed discussions (though I didn't have time to participate, sorry), but I'm +1 on this.

At some point it would be interesting if we could have something similar to the W3C where community groups are semi-formalized and provided support but still mostly unofficial.

[XAMPPRocky]

@Manishearth W3C was one of the organisations I looked at when writing this.

One thing I want to address in this RFC, that it doesn't currently. Is that it is a common pain point that our membership is often fickle, and it can be unclear who is in a group, and who isn't. People often leave members in teams even when they don't participate as they don't want to create friction with the person who is inactive. I think it would beneficial to have some kind of light policy to allow removal of inactive members.

If we look at the Python Software Foundation, they have a requirement for someone to be considered a contributor they dedicate five hours towards projects that advance their mission, and for someone to be considered a Shepherd (Managing Member), they dedicate 5 hours a month towards managing their working group.

If we had this I don't think we would need to rigorously enforce such a time requirement. More that it should be a guideline for people to ask themselves when evaluating whether they are able to commit to being member or shepherd, and whether a member or shepherd is still active and can be safely removed. Of course a team member being removed for inactivity doesn't mean that the person can't later rejoin once they are more active again.

[Manishearth]

It's tricky: In a volunteer organization, sometimes people just need to disappear for a while (I had to temporarily cut down a lot of my involvement in the rust project near the end of last year due to travel and work, I've had team members in similar situations, etc), and even if the idea is for the process to be low-friction and reversible, the end result is often that members feel obliged to do some halfhearted participation. Sure, that's not the intent for such a process, but it can end up being the effect.

This is not to say that we shouldn't do such a thing: I like the idea of having a rough guideline time period, and allow teams to have a process to deal with this if they so choose. This won't be a problem in the case of teams who are aware a member is busy, or teams which are really small (and often low-volume), where it is not desirable to ask people to leave just because they aren't constantly contributing. This seems to be roughly what is proposed; to be clear I'm not disagreeing, I just want to draw a good boundary.

[XAMPPRocky]

@Manishearth Yeah I agree with everything you just said. I don't think the issue we run into is participants disappearing. I think the problem we more often run into, is when the people who disappear are leads or shepherds. When they disappear, people are often being blocked on that person re-appearing because the task/project is meant to be their responsibility, and they have no process for continuing the work.

even if the idea is for the process to be low-friction and reversible, the end result is often that members feel obliged to do some halfhearted participation. Sure, that's not the intent for such a process, but it can end up being the effect.

Yes, that would be probably the worst outcome of setting this process. The process shouldn't be aimed at having only people that are constantly contributing, rather it should be built around the fact that people will come and go, and how we handle when they are gone.

[valgrimm]

Do the comments I made with suggestions help with this?

[XAMPPRocky]

@valgrimm What you wrote would work well, I'm just mainly not sure about the requirement itself, and need to think about it more.

[nrc]

I think this is a great RFC, thank you! I have a few comments inline, the most important I think is that this RFC should restrict itself to project groups only. I'm not sure of the status in the governance WG (which, to get meta, would the gov WG become a project group?), but I think we should explore some radical changes to domain WGs.

[Mark-Simulacrum]

I think this is great! I left a few comments. I would primarily like to see (as with Nick, I think) the working group and community group definitions split into a separate RFC - though that may just mean dropping them from this one for now.

Thank you (and the governance WG at large) for working on this.

[XAMPPRocky]

Okay I believe I have addressed most if not all of the feedback by @Mark-Simulacrum and @nrc (thanks!) so this should be ready for re-review/fcp.

[Mark-Simulacrum]

Thank you for the updates! I believe this is in a much better state, though I still have some concerns.

[Centril]

Something which I feel is unclear in this RFC is to what extent the structure proposed here is mandatory for each team and to what extent the teams may adjust (or entirely disregard) some part proposed here. It would be good if that aspect could be clarified.

[XAMPPRocky]

I think that's something for core to decide. What's I can say that I've always thought of this as a strong recommendation and a moratorium of calling new sub-teams "working groups", beyond that I think it's up to each team. I don't think mandatory would be productive or realistic. Mandatory would imply that there's going to be someone who enforcing this on teams, and I don't think that's a good use of time.

Adjustments are to be expected, we've only started with two project groups, neither of which have finished. Completely disregarding I'm not so sure about, I would hope that the leads of the teams voice their concerns before the merge rather than after.

[nrc]

Thanks for the changes. My outstanding questions are a subset of @Mark-Simulacrum 's, so I have nothing to add :-)

[XAMPPRocky]

@Mark-Simulacrum Okay, I believe I've addressed everything you've brought up.

[Mark-Simulacrum]

I personally feel happy with this RFC, modulo some of my comments above, but I don't feel that they change the spirit, just clarify the wording. With that in mind, and given @XAMPPRocky's prior comments, I am going to say that we can propose FCP here.

@rfcbot fcp merge

[rfcbot]

Team member @Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Manishearth
• @Mark-Simulacrum
• @aidanhs
• @ashleygwilliams
• @carols10cents
• @nikomatsakis
• @nrc
• @pietroalbini
• @steveklabnik

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[nikomatsakis]

Huzzah! The @rust-lang/core team has decided to accept this RFC and I (ahem, finally) just merged it.