112 lines
2.6 KiB
Org Mode
112 lines
2.6 KiB
Org Mode
|
# Created 2020-11-26 Thu 11:10
|
||
|
#+TITLE: [Meta RFC] RFC template
|
||
|
#+DATE: [2020-11-26 Thu]
|
||
|
#+AUTHOR: Yann Esposito
|
||
|
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
|
||
|
|
||
|
Probably it should be one of those:
|
||
|
|
||
|
- Solve a problem.
|
||
|
- Provide a new feature,
|
||
|
- Improve the current situation.
|
||
|
|
||
|
Describe the objective of this RFC.
|
||
|
|
||
|
**** Proposed Solutions
|
||
|
|
||
|
***** [Solution 1]
|
||
|
|
||
|
- describe one possible solution
|
||
|
- pros
|
||
|
- cons
|
||
|
|
||
|
***** [Solution 2]
|
||
|
|
||
|
- describe another possible solution
|
||
|
- pros
|
||
|
- cons
|
||
|
|
||
|
**** Furter Considerations and Remarks
|
||
|
|
||
|
Generic place to put comment not suitable in any other subsection.
|
||
|
Typically, we could add
|
||
|
|
||
|
- Security
|
||
|
- Communication
|
||
|
|
||
|
** Further Considerations and Remarks
|
||
|
|
||
|
*** =dev= label
|
||
|
|
||
|
We already have a =dev= label we should probably use for RFC whose audience
|
||
|
is just the iroh team.
|
||
|
|
||
|
*** =Epic= label
|
||
|
|
||
|
We should continu to use the =Epic= label for issues whose goal is to
|
||
|
produce a specification document along with an execution plan.
|