Add team policy document

charter.md

@@ -0,0 +1,29 @@
+# Style Team
+
+## Aims: Evolving the Rust Style over time
+
+1. Defining the style for new Rust constructs
+2. Evolving the existing style over the course of Rust editions (without breaking backwards compatibility)
+3. Defining mechanisms to evolve the Rust style while taking backwards compatibility into account, such as via Rust editions or similar mechanisms
+
+## Domains
+
+1. [Style Guide](https://github.com/rust-lang/fmt-rfcs/blob/master/guide/guide.md)
+2. [T-style team repo](https://github.com/rust-lang/fmt-rfcs/)
+3. [#T-style](https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style) Zulip stream
+4. [#T-style/private](https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate) Zulip stream
+5. `rust-lang` issues with the `T-style` or `I-style-nominated` labels
+
+## Membership
+
+The active membership of the style team can be found on [rust-lang.org/governance](https://github.com/rust-lang/team/blob/master/teams/style.toml).
+
+The Rust style team shall have at least 3 members and at most 8. If the team has fewer than 3 members it shall seek new members as its primary focus.
+
+Members of the style team are nominated by existing members. All existing members of the team must affirmatively agree to the addition of a member, with zero objections; if there is any objection to a nomination, the new member will not be added. In addition, the team lead or another team member will check with the moderation team regarding any person nominated for membership, to provide an avenue for awareness of concerns or red flags.
+
+### Becoming a member of T-Style
+
+Contributors who believe they'd be a good fit for the style team are encouraged to request an invite[^1] to the team, by reaching out via Zulip private message to one or more team members. The style team will consider all such requests as as a proposal to become a team member and provide clear feedback to the contributor if there are any objections so that any issues may be resolved and the contributor can apply again in the future. The style team will not consider having previously been rejected as a basis for future rejections.
+
+[^1]: We suggest reaching out via zulip DM to one of the current team members, and contacting the lead by default if you're unsure who to reach out to.

team-policy.md

@@ -0,0 +1,144 @@
+# Style Team Policy Document
+
+This is a living document tracking the active policies of the style team. It is intended to fill a similar role to the books that many[^1] teams[^2] maintain[^3] independently[^4]. If in the future Rust establishes central linking/indexing/aggregating of policies, these will need to appear there.
+
+* **Original RFC**: https://rust-lang.github.io/rfcs/3309-style-team.html
+* **Charter**: https://github.com/rust-lang/fmt-rfcs/blob/master/charter.md
+
+## Style Guide Evolution
+
+The Rust style guide will generally match the latest version of the Rust style; the style team does not plan to maintain multiple branches of the style guide for different editions, in part because formatting for new constructs will apply to any edition supporting those constructs.
+
+Whenever possible, style decisions should be made before a new construct is stabilized. However, style decisions shall not be considered a blocker for stabilization.
+
+## Operational Roles
+
+The style team has various operational roles to delegate related and ongoing work to specific individuals, to clarify on our operations, and to coordinate sharing feedback with the members in those roles to enable iterative self improvement.
+
+### Operational Lead
+
+* Current Holder: [@calebcartwright](https://github.com/calebcartwright)
+* Next Feedback Date: TODO
+
+In order to stay in touch with where we want to be heading in the future, we need leadership. A team leader is paying attention to the team’s operations in relation to the team’s aim. What needs to be done, who agreed to do it. What is in the future to decide?
+
+Responsibilities:
+
+* Pays attention to the operation of the team
+* Pays attention to the team members
+* Reports wider context to the team
+
+### Facilitator
+
+* Current Holder: [@yaahc](https://github.com/yaahc)
+* Next Feedback Date: Wednesday 2023-02-01
+
+In order to be present with each other, we need a good facilitator.  The facilitator runs meetings according to the format of meetings and decision making adopted by the group. Leader and facilitator are separate roles because facilitation and overseeing operations are different skill sets. They can be held by the same individual.
+
+Responsibilities:
+
+* Facilitates team meetings.
+* Pays attention to equivalence[^5] during meetings.
+* Supports planning of the agenda.
+* Distinguishes facilitator voice from team member voice.
+
+### Scribe
+
+* Current Holder: [@calebcartwright](https://github.com/calebcartwright)
+* Next Feedback Date: TODO
+
+In order to manage continuity with the team’s past, we need to have written records. The scribe manages the notes during the meeting, makes sure the minutes are distributed and accessible.
+
+Responsibilities:
+
+* Makes sure meeting minutes are taken, approved, and stored.
+* Keeps track of all documents of the team.
+* Default interpreter of meeting minutes in cases of disagreement.
+* Supports planning the agenda from the backlog.
+    * Tracking when policies and roles are due for review.
+
+## Meetings
+
+The style team meets weekly on Wednesdays at 12:30pm PST [(everytimezone link)](https://everytimezone.com/s/3f88a253) for a weekly video sync. Agendas are posted in the #T-style zulip stream. 
+
+Unless otherwise noted, all of our meetings are public and open for anyone to attend. You will find the timing and event details on our [style team calendar](https://calendar.google.com/calendar/embed?src=d0564ed914a41cf4915bd5ebe6e2e4ec0ee1293fdc1d09d6f5bdb27d4f91c083%40group.calendar.google.com&ctz=America%2FLos_Angeles). We publish notes and minutes in written form in this github repository.
+
+### Agenda, Backlog, and Minutes
+
+The style team stores its agendas, backlog, and meeting minutes in a single live hackmd document (rotating as necessary when the documents reach their length limit).
+
+The agenda should be prepared in advanced of each meeting by the facilitator with the assistance of the scribe and the lead. The lead is responsible for looking forward and adding agenda items such as new requests from other teams and users or new priorities and goals. The scribe is responsible for looking backwards and adding agenda items from existing work such as items from the backlog or policies that are due for review. The agenda proposal is then presented at the beginning of each meeting by the facilitator for the rest of the team to consent or object too.
+
+Consent not needed to add to items to the backlog, anybody is welcome to add items to the backlog, but consent needed to move from backlog to agenda (since agendas themselves require consent). An item being present on the backlog does not represent a commitment by the style team.
+
+#### Inform / Explore / Decide agenda item classification
+
+Agenda items are labeled according to their desired outcome. There are three possible outcomes for any given agenda item, inform, explore, or decide. Each of these outcomes builds upon the previous outcomes. In order to explore an item it must first be understood, and in order to make a decision one must both understand and explore the item first. Inform is used for things such as status updates, and usually involves first a report, followed by a round of clarifying questions. Explore is used for situations where one would like feedback on a potential issue or proposal, and usually involves reaction rounds. Decide is used when the team must reach a decision as a group, and it is usually achieved via a consensus round.
+
+We identify the desired outcome in advance to avoid aimless discussions with unclear goals. The desired outcome can change during discussion as new information becomes available. It is the facilitator's responsibility to notice when this happens and formally make the change in the desired outcome with consent from the rest of the team. Extra clarity can be gained if, for every agenda item, we end by measuring whether we have achieved the desired outcome. Facilitators can make it a habit to pause before moving to a new agenda item by assessing whether the desired outcome has been achieved and by asking the scribe to read out loud what has been written in the notes.
+
+The agenda backlog and minutes document is structured according to the following template:
+
+```md
+# T-style Minutes
+
+Meeting Link: 
+
+## Action Items
+
+### Pending
+
+* owner: bullet point list of items that are in progress and assigned to a specific person
+
+### Completed
+
+- [ ] owner: check list of items that are completed or assumed to be complete
+- [x] owner: items are checked off once they've been reviewed in a meeting, confirmed complete, and given any relevant final status updates.
+- [x] owner: after a meeting the items that were checked off are moved into the `#### Completed Action Items` section of the meeting they were reviewed in by the scribe
+
+## Backlog
+
+* Bullet point list of items that have not been started or assigned yet
+
+## Next Meeting Date
+
+### Attendance
+
+### Agenda
+
+* (inform) bullet point list of proposed agenda items (labeled either inform, explore, or decide)
+* Review Action Items
+* Meeting Check-out
+    * Do not record in minutes, exceptions can be made with consent of team
+
+### Minutes
+
+#### Individual Agenda Items
+
+Notes related to the given agenda item
+
+#### Completed Action Items
+
+## Previous Meeting Dates <repeats>
+
+```
+### Meeting Check-out
+
+The style team wraps up the content part of our meetings 5-10 minutes before team members have to leave to make room for regular meeting evaluations. Meeting evaluations are an integral part of every meeting. We end the meeting with one or two rounds on:
+
+* “What worked well in the meeting?”
+* “What could be improved in future meetings?”
+* “Is there anything you are carrying out of the meeting that you’d like to get off your chest now?”
+
+Meeting evaluations are an opportunity to learn from our meetings. We can either talk about content, process, or interpersonal dynamics. We utilize meeting evaluations to help ourselves inhabit a growth mindset. Our goal is to have meetings which are well-run, refreshing, connecting, and energizing. We achieve this goal by giving space for people to speak up about both the positive and negative aspects of how we're working together so that we can prioritize continuous improvement and positive connections.
+
+Meeting check-outs are considered private and internal to the style team and are not recorded as part of our minutes. Exceptions to this can be made via an operational consent decision by the team, and are often useful in cases such as when new backlog or action items come up during the check-out.
+
+[Style Guide]: https://github.com/rust-lang/fmt-rfcs/blob/master/guide/guide.md
+[#T-style]: https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style
+
+[^1]: https://rust-lang.github.io/compiler-team/
+[^2]: https://lang-team.rust-lang.org/
+[^3]: https://std-dev-guide.rust-lang.org/
+[^4]: https://rust-lang.github.io/types-team/
+[^5]: Equality, making sure everyone's voices and feedback are receiving equitable attention.