• Start Date: 2015-05-21
• RFC PR: rust-lang/rfcs#2856
• Rust Issue: N/A

Summary

• 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.
• Each project group typically
  一般的に、典型的に
  has:
  • A charter outlining the group's scope and goals.
  • Appointed shepherds and team liaisons.
  • An associated repository.
  • Dedicated streams on Discord/Zulip/etc.

Motivation

Working groups in Rust were not created through the RFC process, as such there's not much documentation

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 don't have "formal decision making power",

累乗

though often they are charged with drawing up recommendations, RFCs, or other documents

文書

for the teams (which is then intended to make the final decision).

While this definition

Guide-level explanation

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

Note: Currently existing working groups should remain working groups unless explicitly

Life-cycle of a Project Group

This is a high level overview of the complete

Figure 1. Project Group Lifecycle

Steps

1. Exploratory period.

• Initial
  初期
  discussions of the problem area.
  • Teams are not obligated to look at or respond to any of the initial
    初期
    discussions. Of course, interested members are free to participate.
• Write a short motivation for the project.
• Find a person from the relevant team who's willing to act
  振る舞う
  as a liaison.
  • Finding a liasion is specific
    特定の
    to each team, you should consult the team's documentation
    文書
    on how to propose project groups.
  • You may not always be able to find someone who is willing to act
    振る舞う
    as liasion. It's up to each team to decide how many new efforts they'll have the bandwidth for, which may at times be none.

2. Obtain
   得る
   the consensus of the team to create group.

• Specify
  特定する、指定する、規定する
  the liaison, and shepherd(s). (See 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)

3. Create infrastructure for group.

• GitHub repository under rust-lang for hosting work and discussions, such as for draft RFCs.
• A Discord channel or a Zulip stream for communication.
  通信
• Project group in rust-lang/team, as well as a team on GitHub, for handling permissions.

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 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.
  • If you're also planning on running regular
    普通の、正規の
    meetings, include when your group plans to meet along with a link to calendar event for the meeting.

5. The group works towards the goals laid out in their charter.

6. When active work has stopped a group is "archived".

• Archival can be started by the project group shepherds, the liasion, or the lead(s) of the parent team if needed.
• Archival is not necessarily a permanent state, it is only a reflection
  リフレクション、反映
  on the current status of the group.
  • Similarly
    同様に
    a groups archival doesn't imply that work in that area has been exhausted
• Reasons to archive (non-exhaustive):
  • Nobody in the group has time anymore or higher priority things arose.
  • There's a blocking issue that can't be resolved.
  • Don't see any additional
    追加の
    work to do in this area in the near future.
  • The work was done to a satisfactory state.
  • The group decided the idea wasn't so good after all.

7. Create a blog post announcing the archival of the group.

• The scope of this post will vary based
  基となる、基底(の)
  on the scope of the group, but ideally it would include some of the following.
  • Overview of decisions, RFCs, and other output the group produced.
    産出、産出する
  • Thoughts on the process, how it worked (or didn't as case may be), any difficulties encountered,
    出会う
    and what they would want to be improved.

8. Archive infrastructure.

• Archive GitHub repository to be read-only.
• Archive chat channel(s) on any platforms.

Reference-level explanation

A Project Group is a group of people working on a particular project or responsibilities at the behest of an official Rust team. Some project groups are are ephemeral, meaning that they are archived once the project is complete.

Examples of project groups around specific

The goal of a project is build a community or formalise an existing community around a particular feature or project in the organisation, and use this space to discuss and iterate on that feature.

Part of building a community is removing some of the institutional memory that develops in the design

Previously a lot of the discussion and iteration

This process has also been unsuitable to describe features that can take

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

• What value do you see your group bringing to the organisation?
• What support do you need, and separately want, from the Rust organization?
• Why should this be a project group over a community effort?
• What are the goals of your group?
  • Both in the short term,
    項、用語
    and if relevant over a longer period.
• What are explicitly
  明示的に
  non-goals of your group?
• What do you expect the relationship to the team be?
• How do you intend to make your work accessible to people outside your group?
• Who are the initial
  初期
  shepherds/leaders? (This is preferably 2–3 individuals,
  個々の、それぞれの
  but not required.)
• Is your group long-running or temporary?
• If it is temporary,
  一時的な
  how long do you see it running for?
  • What is the long-term vision of your group?
• If applicable, which other groups or teams do you expect to have close contact with?
• Where do you see your group needing help?

Initial

初期

Setup

Once a group has been approved, a pull request with the initial

It is then recommended for the project group to create a repository under the rust-lang organisation using the project group template, and making any relevant changes and personalisation.

Evaluation

評価

Parent teams should add checking in with their project groups as part of their regular

Archival

At some point, the group's work will conclude. Whether because the work is complete,

Announcement

A group that is considering

Once that has been resolved the group should write an announcement of their archival along with any relevant details about the migration and/or archival of projects.

Retrospective

While this RFC attempts to address some of the current organisational problems within the organisation, the author doesn't believe will be a panacea to those problems or that we won't encounter new problems in the future. As part of that, the RFC introduce

This would involve a discussion between the members of the group, and ideally their parent team and the Governance working group. The retrospective should produce

The blog post should try to cover the output of the group, such as RFCs or projects, as well what the group thought worked and importantly what didn't work. This should help us iterate on this initial

Both the retrospective and the archival announcement can and likely should be written as a single

Drawbacks

• There's a lot of inertia around the Working Group terminology, and switching to new terminology will likely cause
  起こす
  some confusion, though hopefully only in the short term.
  項、用語

Future Work

• An initial
  初期
  version of this RFC also specified
  特定する、指定する、規定する
  Working & Community Groups, however we found that we want to discuss that topic in more depth, and didn't want to block Project Groups, so it was removed. See wg-governance#46 for tracking future progress.
• Ideally the Governance WG would prefer if teams obtained
  得る
  consensus to form
  形式、形態、形作る
  groups through RFCs, as they an open process that allows
  許可する、可能にする
  us to easily keep track of decisions. However we recognise that the current RFC process is maybe too heavyweight for it work for some teams currently. We're currently looking how we can simplify some of this process, see wg-governance#38 for further
  さらなる、それ以上
  information.

Unresolved questions