• Keep all RFCs under a single location
• Uniquely identify RFCs
• Use a shared template
  • Editor: Name <email>
  • Status: Draft/Review/Approved/Abandoned/Implemented
  • Required approvers: Name <email> (why), Name <email> (why), ...
  • Approvers: Name <email> (date), Name <email> (date), ...
  • Created on: <date>
  • Updated on: <date>
  • Overview: A high level description of what you're describing in the document
  • Background/Context: Context relevant to understanding the document
  • Problem description: Describe what you are currently cannot do and want to be able to do
  • Motivation/Why: Why is it relevant to solve this problem now?
  • Drawbacks/Why not: What are the downsides of solving this problem?
  • Proposed solution: What is the best solution proposed?
  • Alternative solutions: What are the alternative solutions considered and why aren't they the proposed solution?
  • Impact and risks: What will be the impact of this change on existing systems, processes, or stakeholders?
  • Unresolved questions: What are the questions that need to be answered but don't have an answer to yet?
  • References: Documents/URLs that can be useful to consult
• If a RFC is abandoned, the reasons why should be made explicit in the document

References

• https://en.wikipedia.org/wiki/Request_for_Comments
• https://github.com/rust-lang/rfcs/blob/master/0000-template.md
• https://wiki.en.it-processmaps.com/index.php/Checklist_Request_for_Change_RFC
• Sourcegraph RFC template: https://docs.google.com/document/d/1TRVmwpLzTgYWhBqPwkSWpzPYvXI3Z2miJSmBN2G7ygc/edit
• https://about.sourcegraph.com/handbook/engineering/rfcs
• https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/
• https://github.com/golang/proposal/blob/master/design/TEMPLATE.md

Repositories with RFCs

• https://github.com/rust-lang/rfcs
• https://github.com/reactjs/rfcs
• https://github.com/yarnpkg/rfcs

Before

• Write/prepare an agenda listing the items to be discussed
• Indicate the duration and responsible/lead of each
  • Aim for a meeting to last under an hour. If more time appears to be required, then prior work should be done in order to reduce the amount of time necessary for the meeting.
• Define the list of invitees, try to keep it short, possibly under 6 people
• Share the agenda with all the attendees
• Schedule the meeting around boundaries (beginning/end of day, before/after lunch)

During

• Present the agenda
• Designate a person that will make sure that the agenda is respected

At the end

• Determine next actions
• Define deadlines for each next action
• Assign a responsible for each next action

After the meeting

• Create tasks in a task tracking system for the next actions

Recurrent meetings

• In the case where a recurrent meeting needs to be scheduled at a different time than usual, specify in the body of the message the reason of the change.

References

• https://vadimkravcenko.com/en/how-to-run-efficient-meetings-with-engineers/