# RFC: Request For Comment Meta | Field | Value | |-------|-------| | **Name** | RFC Process Meta Documentation | | **Summary** | This document is the meta document describing and initiating the RFC process. It is meant to give a general overview of the RFC process and how it will work. | | **Status** | ACCEPTED | | **Author(s)** | Eric Lubow | | **RFC Sponsor** | Eric Lubow | | **Proposed Date** | Jan 1, 2025 | | **Feedback Due By** | Jan 21, 2025 | | **Feedback Requested From** | Everyone | | **Final Status Date** | Jan 22, 2025 | --- ## Context Create a process by which those in Tech have the ability to read a document of a new process, system or service that might be rolled out. The people in Technology can comment on the document to ensure that we are implementing the correct solution in the correct way. ## Terminology - **RFC** — Request for Comment document ## Current System Use-Case We currently use the Global Architecture Meeting to share Technology ideas. I want to ensure that we are documenting things in addition to just recording and discussing them. ## Goals / Non-Goals **Goals:** - Document ideas and give Tech folks time to read, digest, comment, and discuss the pros/cons and how to move the idea forward. - Create a repository of standards for Tech ## Design Most of the information to execute this process is contained in the RFC template. It is not necessary (or even always appropriate) to fill out every section. Sometimes you may need to remove sections that don't make sense. Sometimes you may need to add sections that are missing from the template, but relevant for the idea(s) that you are trying to convey. The template is merely a suggested structure and an aid to ensure things have been thought through. For example, there are sections in the template that aren't present in this document. ### Statuses Every RFC that is written will have statuses in order to keep track of the documents: | Status | Meaning | |--------|---------| | **DRAFT** | The RFC is still being written and hasn't been presented to the larger group yet. | | **IN PROGRESS** | A general state for the document being worked on. It can be in this state after the feedback stage if there is a document re-work. | | **FEEDBACK REQUESTED** | The RFC is in the feedback stage. The author(s) are expecting feedback during this period. | | **ACCEPTED** | This RFC has been accepted and Tech has decided to move forward with the contents of this RFC in some form. | | **REJECTED** | The RFC hasn't been accepted as canon and the author or sponsor has decided not to pursue this. | ### Commenting There are multiple ways to give comments on an RFC when the timing is right. The suggested way is to use the inline comment feature of Confluence. This allows the discussion to take place at the right location and context in the document. Commenters can also add comments to the bottom of the document. The discussions in those threads work as well, just feel a little more disjointed. But they are good for more structural issues. Discussions can (and do) also happen outside of Confluence in the real world. It is often up to someone who took part in the conversation to briefly summarize the outcome and how it impacts the content of the document. When the discussion is completed and the document updated, the author can resolve the comment for tracking purposes. ### Versioning Every RFC will maintain a Version History at the bottom of the RFC document. The logic used for versioning can be left to the author. However, anything that constitutes a major change to the document should receive a new semantic version number. ## Assumptions Tech leaders will put in the prep time to ensure these documents are fleshed out and responded to in good faith. I want to stress the importance here of a good faith response. Always do your best to assume positive intent of the author and we should be working together towards the best outcome. ## Limitations This isn't a way to track every decision made in Tech. It's a way to socialize ideas and get buy in to execute on them. Additionally, RFCs may not reflect the current state of an implementation or contain all the necessary technical details (e.g. all API endpoints). RFCs are not a replacement for technical documentation or product specs. If there are potential security or compliance concerns with an implementation or a concept, there will still be the requirement to have a signoff on risk or risk mitigation from the security folks. ## System Diagram(s) The location of all RFCs will be stored in the same "folder". This is located under TECH → Technical Documentation → Architecture → RFCs: Requests For Comment → RFC Index. ## Technology We're taking advantage of the new wiki capabilities in order to deliver the right user experience for the RFC process. ## Monitoring If you create an RFC, you are expected to present it at the GAM to ensure that you get the correct feedback. ## Alternatives Considered While the GAM is an incredibly useful meeting, using RFCs to add structure where necessary will likely end up being more useful than simply having people present at the GAM without clear mechanisms for reference or follow-up. ## Development/Complexity Estimate The first 1-2 RFCs that someone writes is painful. After people start to get the hang of it, it ends up working quite well. ## Testing Strategy Testing in production. We'll announce the process and see how the first few RFCs end up going. --- ## Version History | Version | Date | Changes | |---------|------|---------| | 1.1 | Jan 4, 2025 | Comments section; page structure updates | | 1.0 | Jan 1, 2025 | Initial draft |