Review the top-level teams and rearrange as appropriate

[ehuss]

There are some open questions about what the appropriate set of top-level teams should be for the project. Some things to consider:

• Find permanent homes for launching pad teams.
• Consider if there should be some balance between sizes of top-level teams.
• Try to manage the number of representatives on the council (preferred 5 to 8).
• Consider where new teams might get created that don't fit within the categories of the existing top-level teams. For example, let's say we have a "docs" team, where might that go?
• Ensure that top-level teams have well-documented purviews, starting to identify gaps between those purviews, and working with teams to determine when those gaps should fall to specific existing teams or become the purview of new teams.

I don't offhand know what other considerations there might be, but I assume there are several more.

[diversable]

There are some open questions about what the appropriate set of top-level teams should be for the project. Some things to consider:

• Consider where new teams might get created that don't fit within the categories of the existing top-level teams. For example, let's say we have a "docs" team, where might that go?
  ...
• Ensure that top-level teams have well-documented purviews, starting to identify gaps between those purviews, and working with teams to determine when those gaps should fall to specific existing teams or become the purview of new teams.

Hi - I'm not sure if this is the right issue to post this under, but..

During the Rust re-org, I think it would be a great idea to include a "Rust Education" team that is responsible for items such as: the Rust book; Rustlings; Rust by Example; and generally keeping other foundational texts (collectively, the "Rust project education docs") which are created to help newcomers learn Rust complete, accurate, and up-to-date. This team could also be responsible for maintaining documentation (eg. mdbook content) when other working groups disband, such as maintaining the books for the old Rust WG-WASM.

The purpose of this team would be to help new Rust users get over the notorious learning curve that Rust has and get on to enjoying the benefits of coding in Rust. To that end, it would be nice to also develop a few "educational pathways into Rust" - for example, in addition to a 'learning path for new programmers', the Education team could develop content for Javascript users (ie. create a 'JS-2-Rust pathway' which includes content on 'web-servers & async' & 'working with WASM') and resources for Python users as well (ie. create a 'Python-2-Rust Pathway' which includes content on 'making Rust libs for Python'), since one of those 2 languages are often a programmer's first intro to coding, and it's easier to teach when you have some conception of the background & goals of the learner beforehand.

The Embedded Rust group in particular has done a great job with their documentation so far - they might have some learnings to share which other areas could benefit from.

I originally stumbled in here after trying to update the now-outdated "rustwasm" WG's books, and not really getting anywhere - it's a shame to let such a prime opportunity to 'smooth out' the transition from JS to Rust just slip away from lack of maintenance of a Rust WG's books..

Lastly, if you are looking for volunteers to help staff up a "Rust Education Working Group", I wouldn't mind being included ;)

Thank you for considering this proposal, and for your efforts with Rust-lang - best of luck with the re-org!

Cheers,
Daniel

[traviscross]

As this is marked as active but has not seen an update here for some time, I nominate to review this and to consider whether we should leave an update here about the status.

This should take five minutes.

[ehuss]

I'm going to close this issue as I think we have finished some of these items, and are splitting others out into separate issues.

• Opened Find homes for launching pad teams #118 specifically for the launching pad.
• We have reorganized the top-level teams over the past year (crates.io to devtools, and release to infra). For the most part, I think we are generally happy with the size, but I think we'll expect the number and structure to change continually over time as the project evolves, and we don't need an issue to track that.
• We don't have specific guidelines on how to decide the formation of new top-level teams (particularly ones filling the gaps). I suspect we will learn this as we go along, and after going through the process we might formulate guidelines we'll want to write down.
• Establish team charters #44 will work on charters which should help clarify the top-level team purviews. Similar to the point above, I think we will continue to evolve around the gaps as we work on any restructuring or new team proposals.