# What is the Rust Project? This document outlines the initiative to determine the "shape" of the Rust Project. There are a variety of reasons for trying to clarify what the Rust Project is, and involves a number of entangled questions: - Review the structure of the Project. https://github.com/rust-lang/leadership-council/issues/33 - Determine who or which teams are actually part of the project. - Some people and teams have been formally or informally attached around the edges of the Project structure. Some of these are ambiguous. We may not have a clear picture of who those people are, and if those connections make sense in the context of the rest of this initiative. - Gamedev wg (https://gamedev.rs/) - Community team, which could be half-half (like local/national events could be separate entities) - Random things like I think some people with control of the Youtube account aren't in the team database. - Some of these are in Launching Pad. - Establish guidelines for determining whether or not to accept a new team in the project. - There are different levels, such as new top-level teams, new sub-teams. - Who decides if the subteam is appropriately in the purview of the parent team? - When is an RFC required to form a team? - What is the process for forming a team charter? - What level of contributions and activity on Rust Project-related things makes someone part of the Project, for example are there are working groups that can join without any or much prior work? - What to do with inactive teams/groups? - Organizational cleanup. - Ensure all teams and other governance structures are "attached" to appropriate places in the structure. This includes working with teams to find appropriate homes, and ensuring such changes are ultimately reflected in the team metadata repository. - Re-organize the top-level teams. https://github.com/rust-lang/leadership-council/issues/32 - And the Launching-pad. - Triage-wg (release), prioritization-wg (compiler) -- those could be more inter-mingled? - Collect and organize team charters. https://github.com/rust-lang/leadership-council/issues/44 - Every team or group should have a charter that defines certain properties about them (their purview, mission, membership, etc.). - Better define "team", "sub-team", "working-group", and "project group". - https://rust-lang.github.io/rfcs/2856-project-groups.html - https://github.com/rust-lang/wg-governance/blob/master/draft-rfcs/taxonomy.md - Confusion about a "member" being a direct member of a team, or one of its subteams. ## Ideas for making progress Some rough ideas for how to break this initiative into smaller pieces that we can achieve, and how to tackle it in general: - Survey current Project members to collect some information: - Any thoughts on different structures? What do you think the Project should look like? - Do you feel your team should be recategorized, or is in the wrong place? - Do you feel properly represented? - This might be a loaded question. You have to know your representative. Have to feel like they are not so far removed that you have a say. - Public survey: - Are there groups that should be included, but currently aren't? - Example: Education-based groups, area-specific working groups, etc. - What is your perceived structure of the Project? - TODO: Lots to fill out here... ## Launching-pad notes - wg-rust-by-example - Mário Idival -- still maintains. - community team - Jan-Erik (badboy), technetos, manish -- various comments, some things still going on, but not organized - wg-secure-code - Ton Arcieri: Mostly just maintaining the advisory db. Had aspirations for more, but hasn't happened. - Pietro: Said they would share a proposal, but don't see it. - Shnatsel: Bunch of ongoing projects (cargo-audit, etc.) - twir - nell: Running well, but doesn't know exactly where it should go (suggests maybe devtools?). - wg-gamedev - Forest Anderson - Seems to be actually pretty active. - People getting more busy, not really able to maintain. - Very little in terms of what it is, or how it runs. - wg-cli - epage: Has some activity, but mostly maintenance mode, trying to bring it back. - wg-wasm - nick fitzgerald: no response - wg-security-response - pietro/manish/cuviper: no response - wg-async - eholk: 4 active members - Yushua Wuyts - Does not live under a single team. Operates horizontally. No direct authority to make changes to Rust. - Interest in multiple parent teams like t-types. - wg-embedded - 23 members, 12 sub-groups. ## Meeting notes ### 2023-11-09 - Are these the right things to be looking at for this initiative? - Are the team charters the right thing to be looking at now? - ehuss: Intent was to ensure we know what the teams are actually do? - jp: Who is in the project is important to know, but when thinking about the shape of the project, it gets big quite quickly. - Blog post about horizontal vs vertical teams was interesting. - Where do we want to end up, and how to plot manageable steps to get there? - jack: Figuring out the structure now isn't too hard, since it is all in the team repo. For teams without a parent team, as you go you'll find them. - jp: Working groups act like teams. - We'll need to do the work of figuring out where working groups should be placed, since they typically don't define parents. - We'll find various unknowns, like what is wg-embedded-core vs wg-embedded. - The embedded group has a bunch of sub-teams doing individual things, and they have authority over their individual repo, and the work that they do. - `-core` is maybe legacy? - They like being part of Rust Project because they get access to all of our infrastructure. It also give them kudos, and makes them official. - jack: Start building up a map of all the teams, how they connect, and what they do. - eholk: Understanding what we're working with is a good start. - Interested in the organizational cleanup. Figure out the areas that teams are working on, and do a big refactor to figure out how things should fit. - Design versus implementation teams (teams that do design would be under "design", etc.). - Could very quickly be a massive project. Want buy-in from the teams. - Shrinking the size of the council to 7-5 could make it more efficient. - jp: Have broad latitude. The intent of launching pad is to do this reorganization. - jp: Someone needs to make a call: Is the Rust Project about making a toolchain, or is it about promoting Rust in a more general sense? - jack: For resources, could the Foundation provide those resources to the groups? Not just money. Computational resources, infrastructure like triagebot, bors, etc. - eholk: Lots of foundations work like an umbrella. Embedded could be under the Foundation, independent of the Rust Project. Doesn't seem ideal, but is an option. - jp: Floated the idea to embedded to being part of the Foundation, and it was unpalatable. - jack: Some transition could help ease the process. Start with asking the Foundation to help with certain things. Unfortunately some of the benefits like infra is provided by the Rust Project infra team. - eholk: Embedded seems to be a particularly tricky thing to figure out where it fits, since it seems quite large and running independently. But it does seem useful to be part of the Project. - jack: Top-level community team could be useful for a lot of things. - Jack: Would like to solicit input from the Rust Project to figure out what the Project should look like. - eholk: Call for blog posts, like Yosh's blog post. Long form input would be interesting. - JP: A survey would be useful for people who don't have blogs. People can provide feedback on specific organizational units. - Jack: Also wants a survey, was what they were originally thinking to start with? - Eholk: Likes mission statements to help guide, "does this belong?". - Jack: Each team? - eholk: The first entry of the team's charter should say what their mission is? - Also need a Project-wide mission statement. Then each team could justify how it fits in the overall mission statement. - Currently: "A language empowering everyone to build reliable and efficient software." - ehuss: I think it can be very difficult to define a mission statement that is not so vague that it covers all Rust things. - Thinks back to Niko's statements about having project goals, and some of the past work around roadmaps - jp: May need to narrow the scope to something more focused on the toolchain? - jack: Niko's project goals isn't quite a roadmap. So those aren't quite the same. - jp: People want organization support, insider-access, communication, visibility, etc. Orbits, a multi-level thing with different levels, but not all orbits are represented by the Council. - jack: Could have different sub-projects (toolchain, embedded, etc.). - Inactive team/subgroups: - jack: What does it mean to be inactive? - jp: What is the cost of keeping it. There is cognitive overhead when thinking about team structures, but otherwise might not have much cost. - Shouldn't be an ad-hoc process. Make it a well-defined process, as it appears the team is moving through their lifecycle, can help them move between those steps. - ehuss: This point wasn't particularly high on my priority list, just a point to include. - jack: Archive if it isn't fulfilling its charter/mission statement. - wasm example: If nobody is contributing to the compiler for web assembly support, then it might be ready for archival. But for llvm, they are active by contributing, even if they don't have meetings. - eholk: Have an annual review, just to check in. At a bare minimum, they respond to that. That could be an opportunity to update their charter. That also gives the team an opportunity to say it is time to spin it down. - jack: Charter could include how long it is expected for the team to last. Not just a time, could be some accomplishment is reached, or it could be indefinite. - jp: Likes OU organization unit to refer to team/group/etc. - Could potentially bundle the lifecycle: their mission, the duration, and how they are retired. - What are the next steps? - Is a survey a good idea? - jp: Fan of Google forms, doesn't require much work for people. - Which of these organization units do you want to talk about, what is your relationship to it, what do you want to say about it? - Bring up in the council meeting tomorrow. - Who is going to write it up? - ehuss: Curious if anyone has insights about other open source project structures? - Florian has insight about Ruby. - How to send it out? - ehuss: Suggest an inside-rust blog post, asking people to write their own long-form blog posts, or filling out a survey. - jack: Concern about broadly posting a survey on the blog (as opposed to all@). Might get too much vague feedback. - jp: Can ask council to set up survey committee to work on it. - jack: What is the timeline for moving this forward? - When will want to put out a survey? How long it would be up? - eholk: Would like to see less than a month. - Tricky around the holidays. - Three months may not be that weird of a timeline. :D - ehuss: Doesn't feel we necessarily need to wait until Jan to start collecting feedback. - Next steps: - Talk to council tomorrow about doing a survey and collecting feedback. - Ehuss can help to firm up our understanding of what the Project is today. - May also be peeking at other orgs to understand how they work.