Update 0000-project-groups.md

Author: XAMPPRocky

text/0000-project-groups.md

@@ -1,9 +1,9 @@
 # Summary
 
-- Formalize project groups as groups dedicated to specific projects
-  within the context of a Rust team
-- Project groups are created via an RFC and have a "parent team" (or
-  multiple teams)
+- Formalize project groups as groups dedicated to specific projects within the
+  context of a Rust team.
+- Project groups are created via team consensus (such as an RFC) and have a
+  "parent team(s)"
 - The groups then drive the project to completion, e.g. by authoring follow-up
   RFCs and doing design work.
 - Once the work has been concluded, the group is archived.
@@ -15,10 +15,10 @@
 
 # Motivation
 
-Working groups were not created through the RFC process, as such there's not
-much documentation on exactly what a working group does, what are its
-responsibilities, and also importantly setting expectations or goals. There is
-one definition of "Working Group" available in [rust-lang#54445]; quoted below.
+Working groups in Rust were not created through the RFC process, as such
+there's not much documentation on exactly what a working group does, what are
+its responsibilities, and also importantly setting expectations or goals. There
+is one definition of "Working Group" available in [rust-lang#54445]; quoted below.
 
 > A Rust Working Group is a set of people working at common purpose. Working
 > Groups are associated with a Rust team. Unlike a Rust Team, Working Groups
@@ -28,16 +28,9 @@ one definition of "Working Group" available in [rust-lang#54445]; quoted below.
 
 While this definition is true in the broad sense, it does not define the
 difference between what has come to be called "Domain Working Groups" and
-"Team Working Groups". Additionally the community has also adopted the Working
-Group terminology for organising and working on areas they are interested in,
-independent of The Rust Programming Language's Working Groups. It's great that
-we have a community able to self organise in this way, however it has led to
-some confusion over who is supporting these efforts, and whether they're
-considered _"official"_ Working Groups.
-
-This RFC aims to provide clarity by providing new distinct terminology that
-matches the intent behind "Team Working Groups", as well as codify some of the
-processes that these groups have been using to help facilitate creating
+"Team Working Groups". This RFC aims to provide clarity by providing new distinct
+terminology that matches the intent behind "Team Working Groups", as well as codify
+some of the processes that these groups have been using to help facilitate creating
 new groups.
 
 [rust-lang#54445]: https://github.com/rust-lang/rust/issues/54445
@@ -47,8 +40,7 @@ new groups.
 To address this confusion this RFC proposes switching from using "Team Working
 Group" in favour of "Project Group". This would serve as a catch all term for
 the sub teams of the existing teams to organise around specific efforts, such
-as certain project or effort in the Rust team. Project Groups are led
-by "Shepherds".
+as certain project or effort in the Rust team.
 
 ## Life-cycle of a Project Group
 This is a high level overview of the complete process of a project group.
@@ -75,7 +67,7 @@ This is a high level overview of the complete process of a project group.
 
 2. Obtain the consensus of the team to create group.
 
-- Specify the liaison, and shepherd(s).
+- Specify the liaison, and shepherd(s). (See [Project Group Creation](#project-group-creation))
 - Write a short motivation, and some notes on possible solutions.
 - How consensus is reached would vary from team to team, some would require an
   RFC while others could decide in a meeting. (See [Future Work](#future-work))
@@ -91,7 +83,7 @@ This is a high level overview of the complete process of a project group.
 4. Create a post on the Inside Rust blog announcing creation of the group. Be
    sure to include the following information.
   - An introduction
-  - The charter (either linked or inlined) \[See [Project Group Creation](#project-group-creation)\]
+  - The charter (either linked or inlined) \[See [Creating The Charter](#creating-the-charter)\]
   - A link to your group's GitHub repository
   - If your group is open for participants, provide information on how they
     can contribute.
@@ -175,7 +167,44 @@ can be hard to know their current status.
 [rustup]: https://github.com/rust-lang/team/blob/master/teams/wg-rustup.toml
 
 ## Project Group Creation
+A project group should have the following;
+
+- **Leads** — At least one person who acts as the leader of the group and is
+  typically responsible for writing the initial charter, handling
+  administrative and communication tasks, as well as delegating those
+  responsibilities to other members in the group.
+- **Liaisons** — A member from a official Rust team that is sponsoring the
+  work, and acts as a point of contact between the team and the group. They
+  may or may be that directly involved, but they should check-in
+  periodically and be able to represent the work in meetings with the team.
+  They should also look out for when this might intersect with other work
+  happening in the team that is beyond the working group itself.
+  - Liaisons may also be but are not required to be one of the leads.
+- **Members** — Individuals who regularly participate and/or
+  contribute to the project group.
+  - Membership requirements for groups are decided by the shepherd and should
+    be stated in the charter.
+  - Initial membership should try to represent people who have already been
+    participating regularly and productively in the respective area.
+  - It is not required for a project group to have a lot of members though,
+    some project groups may only have one or two members including leads and
+    liasions.
+- A charter that defines the scope and intent of the group.
+- A GitHub repository hosted under the `rust-lang` organization containing
+  the charter and instructions for how community members can monitor or
+  participate in the group.
+- Representation on the official [rust-lang.org] website.
+- No _"formal decision making power"_: meaning that they are not able to
+  accept RFCs on `rust-lang/rfcs`.
+  - Groups are of course encouraged to create RFCs as well as advocate their
+    concerns and desired changes to the Rust teams and community.
+- Dedicated space(s) in of Rust's officially managed discussion platforms.
+  - As of the time of this writing this includes [Zulip] and [Discord].
+  - Ideally the group should use the same platform as their parent team to
+    ease communication, though there may be cases where the team agrees to
+    a group trying out a different platform.
 
+### Creating The Charter
 Since project groups are approved by their relevant parent team over the core
 team, it's up to each team decide their specific requirements. However the
 author recommends that a group should try to make a charter that addresses 
@@ -197,38 +226,6 @@ the following questions.
   contact with?
 - Where do you see your group needing help?
 
-Process around project group membership is up to the shepherd's discretion.
-Typically, people who are productively contributing to the project group for
-some time will be added as members. It is not required for a project group to
-have a lot of members though, some project groups may only have one or
-two members.
-
-**A project group should have the following;**
-
-- A charter that defines the scope and intent of the group.
-- A GitHub repository hosted under the `rust-lang` organization containing
-  the charter and instructions for how community members can monitor or
-  participate in the group.
-- At least one person who acts as the leader of the group and is typically
-  responsible for writing the initial charter, handling administrative
-  and communication tasks, as well as delegating those responsibilities to
-  other members in the group.
-- A liaison member associated with an official Rust team.
-  - This liaison may also be but is not required to be one of the leaders.
-- Representation on the official [rust-lang.org] website.
-- Membership requirements for groups decided by the shepherd and stated in
-  the charter.
-  - Initial membership should try to represent people who have already been
-    participating regularly and productively in the respective area.
-- No _"formal decision making power"_: meaning that they are not able to
-  accept RFCs on `rust-lang/rfcs`.
-  - Groups are of course encouraged to create RFCs as well as advocate their
-    concerns and desired changes to the Rust teams and community.
-- Dedicated space(s) in of Rust's officially managed discussion platforms.
-  - As of the time of this writing this includes [Zulip] and [Discord].
-  - Ideally the group should use the same platform as their parent team to
-    ease communication, though there may be cases where the team agrees to
-    a group trying out a different platform.
 
 [rust-lang.org]: https://rust-lang.org
 [zulip]: https://rust-lang.zulipchat.com