# Last Steps

## Before Pushing RFC

### Dimensions

> This section is for questions that need to be answered or other attributes that need to be covered in the final plan for landing the rust-lang governance RFC

1. Will the summary include the git usernames who worked on this?
2. How will we handle sign-offs?
1. How will we track objections?
2. Do we want to do this entirely by hand?
3. Do we want to modify the teams repo to leverage RFCBot
3. Accessibility of feedback and discussion?
1. Not just from an abled/disabled perspective
2. Balance volume and productivity of conversation and the number of spaces available for the discussion
4. Provide an example of an answer for what a team lead should do to gather or not gather feedback from their team members and subteam members.
5. We should decide exactly what process we want to follow for incorporating feedback based on what people hand us publicly.
1. If someone sends us public feedback: do we respond directly or coordinate a response?
2. How do we coordinate pushing new changes?
1. Process for consent related to changes?
6. How are we going to communicate our plan clearly to leadership chat and the rest of the project?
7. From what repo fork do we do the pull request?
8. How are we going to handle moderation on that repo and RFC? Are we prepared?

### Plan Pieces

> These bullets serve as answers to the dimensions listed above, they can cover one or more dimension, they can answer them partially, they can contradict eachother, they can build on eachother, this is an idea gathering exercise used to inform the final plan to ease the process of consensus building.

* (1) summary should include list of the contributors to the RFC
* (2) JT: no idea how we'd handle this as a traditional RFC
* Create a separate repo for this RFC
* (7) The RFC should be pushed from a fork to the main repo
* (2) we should setup a leadership council team for the purposes of leveraging RFCBot, we should not do this process by hand
* (3) we should have a zulip stream and a github fork for discussions but otherwise minimize how fragmented the main conversation venues are
* (4) the team leads should email their team and subteams to indicate that they are reviewing the RFC on behalf of the team, that anyone else is welcome to participate and provide feedback, and that such feedback should default to being directed through the lead but that they can also reach out to anyone in leadership chat if they prefer.
* (5.1) we should coordinate our responses in a zulip channel using consent (reasonable time for review and no objections, then go for the response)
* (6) we should communicate our plan to the rest of the project with a inside rust blog post, an email to all@, and maybe more

## After Pushing RFC

### Dimensions

1. Specifics around merging the RFC, test that multi-file / multi-directory setup will actually work well, RFCbook
2. (Khio): this has been fixed and merged, should work?
3. Handoff process from leadership chat to the council
4. (Khio): From leadership chat? Or maybe from core? Both together or maybe separate handoffs?
5. Where are all the documents the governance-wg created going to be stored
1. how will they be handed off to the council?
2. which documents if any will be made public?

### Plan Pieces

* (1) handoff process should specify a council selection process
* (1) handoff process should specify an example council selection process