-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review and organize overall project team structure #33
Comments
These docs are very outdated and contains some misleading information. There are important things to resurrect at some point, which is something the Council should take on: * Definition of teams, and the structure of the Project in general: rust-lang/leadership-council#33 * Team charters, defining what each team's mission and responsibilities are: rust-lang/leadership-council#44 * Suggestions on moderation team processes should follow up with either the Council or https://github.com/rust-lang/moderation-team * Suggested decision making processes for teams: rust-lang/leadership-council#45 (and rust-lang/leadership-council#23 to some degree).
These docs are very outdated and contains some misleading information. There are important things to resurrect at some point, which is something the Council should take on: * Definition of teams, and the structure of the Project in general: rust-lang/leadership-council#33 * Team charters, defining what each team's mission and responsibilities are: rust-lang/leadership-council#44 * Suggestions on moderation team processes should follow up with either the Council or https://github.com/rust-lang/moderation-team * Suggested decision making processes for teams: rust-lang/leadership-council#45 (and rust-lang/leadership-council#23 to some degree).
And are there people we would want to consider "part of the project" that aren't on a team? For the purposes of consulting people about a decision? |
I believe rfcs#3392 is somewhat explicit about ensuring that everyone is part of the project through a team because this makes answering a question of why they are part of the project much more straightforward. If we ever want a "group of people whose opinions we value" we should make that a team and have explicit criteria for inclusion. |
I guess that depends on whether we think a Working Group is a Team? The Rust Embedded Working Group is in the teams repo, but sits under the Launching Pad team. |
rust-lang/rfcs#3392 considers working groups teams in the wider sense of the word (i.e., a governance structure). Everyone considered a part of the Rust project is a member of a governance structure (i.e., a team, subteam, working group, project group) that ultimately "reports up" through a top-level team into the Council. The RFC was purposefully worded as such to avoid any "dangling" members - i.e., there should never be anyone in the Project who does not have Council representation and Council representation is determined by the Council rep for the top-level team the governance structure(s) the person is on reports up through. |
This is a bit nebulous, but the overall idea is to:
I seem to recall there are some ambiguities, but I don't remember what they were exactly.
See also #32 for specific considerations of the top-level team arrangement.
The text was updated successfully, but these errors were encountered: