Create structure around WG setup

[skade]

We need to derive some structure around who WGs can be proposed and ultimately be set up. This doesn't need to be an automatic process and ultimately, the decision to accept a WG remains in the project.

[skade]

Progress report:

Started by posting https://internals.rust-lang.org/t/enabling-the-formation-of-new-working-groups/10218 and trying to derive a process from the experiences.

[XAMPPRocky]

I've written down a list of questions related to this topic I that came to my mind. Some of which have fairly obvious answers, but I think we need to write down the common questions with obvious (to us) answers. Also of course these answers would be purely advisory and not an ironclad set of procedures.

• Where should the working group put their work?

  • In my experience there's two kinds of very distinct work that working group performs. Projects related to their field, and the meta work of organising the working group itself.
    • Some working groups have the latter kind hosted on rust-lang (e.g. allocators, grammar, governance).
    • Some working groups have entirely separate organisations for all of their work (e.g. cli, embedded, wasm).
  • In my view I think we should recommend for working groups to have the meta work on the rust-lang, and I think their are quite a few reasons to do so.
    • It removes some of the initial set up cost in terms of figuring the meta structure, as people are oft to make organisations before they need to, and now need to spend their time managing permissions on GitHub that should really be managed by rust-lang/team.
    • It provides "Official-ness" to the working group.
      • People come across a working group's work in all kinds of ways, and may not know it's relation to the rust-lang group.
      • It's also important not to forget on the working group participants side, the "bragging rights" (not a good term for this) that come with getting access to a rust-lang repo, and getting to have the official rust-lang organisation badge on your GitHub profile. I don't think people are joining soley for this, however in an age where your GitHub profile gets you jobs, having this thing that looks nice to an employer can be more motivating to put in the work for some people.
        • This also provides a more proper credit to their work.
    • For the

• How do you add a working group to rust-lang/team / the rust-lang website?

  • Currently there's no documentation on how to do this, at least none I could find on the team repo.

• When does a working group officially start?

  • The internals post mentioned above is a good resource for finding the Shepard of the working group. However there hasn't been much discussion for what to do once we've found a shepard.
  • While there's never been a discussion on a required member count for a working group, I think it's safe to say a working group can't comprise of only a single individual.
  • I think should be a very small required number of members (e.g. 2–3) that are not the Shepard.

• What are the actual responsibilities of a working group Shepherd to the rest of the rust-lang organisation?

• A working group should probably have some form of regular communication with a Rust team.

  • This is important at the start, especially if the Shepherd doesn't have previous experience leading working groups, as they can feedback on their progress.
  • This will also help catch when working groups begin to decay and need to be retooled or deprecated.
  • This communication doesn't have to be that regular. This could be like every six months or a year, though I would lean to six months more than a year.
  • The exact nature of this communication would probably be working group dependent, some will have a lot to say and would merit meetings, while some might only need "pulse checks".
  • I think this also something that might only be needed for the start of working groups, and as a working group becomes more stable the training wheels so to speak would

• Who would be this contact? Some working groups have obvious teams they could talk to, others e.g. Secure Code or Cryptography are more general and probably requires a volunteer.

• How do we get the volunteers for the working group? The current procedure has been "make a post on internals", but it would be nice if we could provide more detail and also how to promote it on other platforms (e.g. The rust-lang twitter, reddit, etc).

• Also related is suggesting what social platforms have been successful for other working groups. E.g. Embedded have a popular twitter account.

• The post on internals has the problem where a lot of people say "yes" but they never participate to the working group.

• What are responsibilities of working group volunteers? This is obviously highly dependent on the working group leadership, but at least we should put that you are in fact expected to come and participate such as attend the meetings.

  • We should advise Shepherds to have an initial meeting with volunteers interested where they lay out the working group's intentions (Essentially repeating the charter), and give people a chance to opt out at that point, and then gather a list of volunteers who are still interested after these and use this as the initial group.
    • Membership can change after this of course.
    • I think we should also encourage this initial meeting to try to be sync and over video/voice if possible.
      • While it makes harder for some people to initially help, when a working group is getting started it's important to have a core set of people who are willing to commit their time to this.
      • It also helps with future collaboration in the working group as it's helpful to get to know who you're working with build a working relationship with those people.

• When and how do we make a more public announcement of the new working group?

  • Probably a blog post on rust-lang
    • Who would write this blog post?

[XAMPPRocky]

closed as superceded by #46