Manishearth
commented
4 years ago Yeah the more i've been thinking about it the more it doesn't sit right with me to have official groups that are not a result of core priorities -- they're not going to have the level of involvement and cohesion from the rest of the organization for their inclusion in the governance to really mean anything. It also feels rare that groups which are a result of core priorities will exist.
To me it feels like Embedded might be something we should either spin off or make into a project group, because it actually had decent cohesion with the rest of the org and is doing great. The other DWGs did really well as well, but it's unclear to me if they still need team level involvement.
W3C-style community groups appeal to me. With a CWG we can list them separately somewhere on the site, mention that they're really their own thing and unofficial, and perhaps give them a venue on an existing chat platform. Low commitment from both sides.
The main reason I'm concerned about officialness is that if there's not a lot of buy in from the other teams/core, there's nothing stopping a WG from causing friction with the ecosystem via its official tag, and in general it can go off the rails. It feels easier to avoid this problem by making CWGs a matter of basic facilitation rather than blessing -- we give them a link on the website and a chat channel, but nothing else.
(Even then it feels to me that we might benefit more from letting them just organize completely out of our governance framework)
Current Status
Original Content
cc project groups RFC
Motivation
Domain WGs were a good way for the Rust org to focus the community on a few specific areas and provide some limited resources in the run-up to the 2018 edition. The existing domain WGs are in very different states, e.g., embedded is self-sustaining, active, and likely to be around (in some form) for the foreseeable future; it is operating mostly independently of the rest of the Rust org. The CLI WG is inactive, having run its natural course by improving the CLI landscape with better libraries, etc.
We are getting many requests for new domain WGs, but it is not clear to me why the Rust org needs to be involved with most of them, and it has been difficult to get movement on many of these requests because of limited core team bandwidth. I don't think that at this stage domain WGs get much benefit from the Rust org, beyond advertising on the website (and the legitimacy that brings) and a moderated chat channel. On the other hand, I think these WGs are valuable to the community as a way to encourage working together on key 'infrastructure' libraries and to keep people motivated.
Solutions
Any solution should maintain the benefits of organisation and motivation, and should reduce the bandwidth required from the rest of the Rust org.
Status quo
No procedural changes. We should officially close the WGs which are de facto inactive and make decisions about new WGs (probably we should define criteria for acceptance).
No domain WGs
We encourage new WGs to self-organize outside the Rust org. Existing WGs are either closed, made independent, or made into full teams.
Community WGs
Some kind of compromise between the above two proposals. Community WGs would be mostly independent of the Rust org. The Rust org does not play any part in creating new ones. We can provide some resources, e.g., links from the main website, a chat channel, perhaps x months of coaching from the community team (subject to very loose restrictions such as adherence to CoC). I think of this model as being similar to the Rust org's relationship with conference organisers. There are obviously plenty of details to figure out.
Something else?