#+TITLE: [Meta RFC] RFC template #+Author: Yann Esposito #+Date: [2020-11-26] tags :: [[file:../../../../../../.org/journal/2020-11-26--10-12-21Z--work.org][work]] [[file:../../../../../../.org/journal/2020-11-26--10-12-42Z--organisation.org][organisation]] source :: /Abstract/: Yesterday in our weekly meeting I discussed about how I would like us to work with RFCs. I would like to add this document to talk about RFCs. So this is a meta document. I hope not to trigger the need for a meta-meta-document ;). I will try to keep it self-referencing by using its own description. Closer to the quine :). *Audience*: (Who's impacted?) + iroh team + managers *RFC kind*: + team organisation ** Objective *Improvement*: Write a proper RFC template. * Proposed Solutions ** Template This is the template I would like us to provide. We should probably add that as a github template for issue. So if you declare you want to create a new RFC issue you will be presented this template. The author will only need to fill the blanks and remove parts that are not relevant. *** [Title] <- name of the issue in github /Abstract/: A little bit more than in the title *Audience*: (Who's impacted?) + iroh team + ops + ui team + managers + customers *RFC kind*: (remove non relevant part) + code convention (=> Audience; iroh-team only) - ns naming convention - position of args - naming of args - etc.. + dev tooling (=> Audience; iroh-team, maybe ops) - emacs mode - cider - clj-refactor - CI - scripts - git commit message - docker - etc... + team organisation (=> Audience; iroh-team, managers) + technical specification ( not Audience constraint ) - goal write a document for other dev (potential other teams), managers, and provide an execution plan **** Objective Select one or many of those and for each item write a description. - Solve a problem. - Provide a new feature, - Improve the current situation. **** Proposed Solutions ***** Solution 1 + describe one possible solution + pros + cons ***** Solution 2 + describe another possible solution + pros + cons **** Considerations Generic place to put comment not suitable in any other subsection. Typically, we could add + Security + Communication ** Considerations Here are my proposed templates. We already have a =dev= label we should probably use for RFC meaningful only for developpers, and we should continu to use the =Epic= label for issues whose goal is the provide a spcecification document that we could give to Managers with an Execution Plan.