journal/2020-11-26--10-11-23Z--meta_rfc_for_dev_team.tmpo9WI1e.org
This commit is contained in:
parent
d88bfbf0c1
commit
0e8bb43247
1 changed files with 111 additions and 0 deletions
|
@ -0,0 +1,111 @@
|
|||
# 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.
|
Loading…
Reference in a new issue