Skip to content
This repository has been archived by the owner on Jul 10, 2021. It is now read-only.

Commit

Permalink
Update working-group-terminology.md
Browse files Browse the repository at this point in the history
  • Loading branch information
XAMPPRocky authored Jan 13, 2020
1 parent 8f13812 commit 4c74bbf
Showing 1 changed file with 14 additions and 8 deletions.
22 changes: 14 additions & 8 deletions draft-rfcs/working-group-terminology.md
Original file line number Diff line number Diff line change
Expand Up @@ -164,7 +164,11 @@ working group.

- 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?
- What vision does your group want to realize?
- What are some of the core objectives that support that vision?
- What are the group's short-term goals?
- Think about what you can and want to achieve in the first month or first year,
depending on the group's scope.
- What do you expect the relationship to the organisation be?
- How do you want to establish accountability?
- If applicable, which other working groups or teams do you expect to have close
Expand Down Expand Up @@ -198,14 +202,16 @@ A Project Group is a group of people working on a particular project or
responsibilities at the behest of an official Rust team. Examples of this would
include [FFI Unwind], [Inline ASM], and [Safe Transmute].

The goal of a project is build a community or formalise and existing community
around a particular feature or project in the in the organisation, and use this
space to discuss and iterate on that feature.
The goal of a project is build a team or formalise and existing community
around a particular feature or project in the organisation, and ensuring that
a group is able to follow through on feature through to stabilisation.

Part of building a community is removing some of the institutional memory that
develops in the design process, and centralising the information and discussion
around the feature so that we can provide better visibility into why certain
decisions and trade offs were made over others.
Part of this process is having a more standard and open collboration and
iteration throughout the design process, rather than at the start and end that
usually happens today. Centralising the information and discussion in a way that
is more discoverable around the feature can provide better visibility into why
certain decisions and trade offs were made over others. And hopefully serve
to help SKSKSKSK.

Previously a lot of the discussion and iteration for large features would
happen in the initial RFC thread. This leads to a lot of discussion in the top
Expand Down

0 comments on commit 4c74bbf

Please sign in to comment.