2020-11-26 10:00:03 +00:00
|
|
|
#+TITLE: [Meta RFC] RFC template
|
2020-11-26 09:12:29 +00:00
|
|
|
#+Author: Yann Esposito
|
|
|
|
#+Date: [2020-11-26]
|
|
|
|
|
2020-11-26 09:15:10 +00:00
|
|
|
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]]
|
2020-11-26 09:12:29 +00:00
|
|
|
source ::
|
2020-11-26 09:15:10 +00:00
|
|
|
|
2020-11-26 10:00:03 +00:00
|
|
|
/Abstract/: Yesterday in our weekly meeting I discussed about how I would
|
|
|
|
like us to work with RFCs.
|
2020-11-26 09:58:23 +00:00
|
|
|
I would like to add this document to talk about RFCs.
|
2020-11-26 09:15:10 +00:00
|
|
|
So this is a meta document.
|
|
|
|
I hope not to trigger the need for a meta-meta-document ;).
|
2020-11-26 10:00:03 +00:00
|
|
|
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
|
|
|
|
|
2020-11-26 10:02:37 +00:00
|
|
|
*Improvement*: Write a proper RFC template.
|
2020-11-26 10:00:03 +00:00
|
|
|
|
2020-11-26 09:29:43 +00:00
|
|
|
* Proposed Solutions
|
2020-11-26 09:27:49 +00:00
|
|
|
|
2020-11-26 10:04:36 +00:00
|
|
|
** Template
|
2020-11-26 09:32:47 +00:00
|
|
|
|
2020-11-26 10:05:53 +00:00
|
|
|
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.
|
|
|
|
|
2020-11-26 09:56:18 +00:00
|
|
|
*** [Title] <- name of the issue in github
|
2020-11-26 09:33:55 +00:00
|
|
|
|
2020-11-26 09:56:18 +00:00
|
|
|
/Abstract/: A little bit more than in the title
|
2020-11-26 09:36:24 +00:00
|
|
|
|
2020-11-26 09:56:18 +00:00
|
|
|
*Audience*: (Who's impacted?)
|
2020-11-26 09:51:51 +00:00
|
|
|
+ iroh team
|
|
|
|
+ ops
|
|
|
|
+ ui team
|
|
|
|
+ managers
|
|
|
|
+ customers
|
|
|
|
|
2020-11-26 10:05:53 +00:00
|
|
|
*RFC kind*: (remove non relevant part)
|
2020-11-26 10:01:23 +00:00
|
|
|
+ code convention (=> Audience; iroh-team only)
|
2020-11-26 09:42:56 +00:00
|
|
|
- ns naming convention
|
|
|
|
- position of args
|
|
|
|
- naming of args
|
|
|
|
- etc..
|
2020-11-26 10:01:23 +00:00
|
|
|
+ dev tooling (=> Audience; iroh-team, maybe ops)
|
2020-11-26 09:42:56 +00:00
|
|
|
- emacs mode
|
|
|
|
- cider
|
|
|
|
- clj-refactor
|
|
|
|
- CI
|
|
|
|
- scripts
|
|
|
|
- git commit message
|
|
|
|
- docker
|
|
|
|
- etc...
|
2020-11-26 10:01:23 +00:00
|
|
|
+ team organisation (=> Audience; iroh-team, managers)
|
2020-11-26 10:19:15 +00:00
|
|
|
- github dashboard, issue templates, github labels, etc...
|
2020-11-26 10:14:40 +00:00
|
|
|
+ technical specification (Audience not constrained);
|
|
|
|
The goal of a technical specification RFC is is to produce a
|
|
|
|
document containing:
|
|
|
|
- a functional specification
|
|
|
|
- a technical specification for our team
|
|
|
|
- technical specification(s) for other team if necessary (ops, UI, etc...)
|
|
|
|
- an execution plan
|
2020-11-26 09:33:55 +00:00
|
|
|
|
2020-11-26 15:42:57 +00:00
|
|
|
**** Objectives
|
2020-11-26 09:36:24 +00:00
|
|
|
|
2020-11-26 15:42:57 +00:00
|
|
|
- *Problems*:
|
|
|
|
- *New Features*:
|
|
|
|
- *Improve the current situation*:
|
2020-11-26 10:07:06 +00:00
|
|
|
|
2020-11-26 09:58:23 +00:00
|
|
|
**** Proposed Solutions
|
2020-11-26 09:49:40 +00:00
|
|
|
|
2020-11-26 10:08:38 +00:00
|
|
|
***** [Solution 1]
|
2020-11-26 09:50:47 +00:00
|
|
|
|
|
|
|
+ describe one possible solution
|
|
|
|
+ pros
|
|
|
|
+ cons
|
|
|
|
|
2020-11-26 10:08:38 +00:00
|
|
|
***** [Solution 2]
|
2020-11-26 09:50:47 +00:00
|
|
|
|
|
|
|
+ describe another possible solution
|
|
|
|
+ pros
|
|
|
|
+ cons
|
2020-11-26 09:33:55 +00:00
|
|
|
|
2020-11-26 10:10:16 +00:00
|
|
|
**** Furter Considerations and Remarks
|
2020-11-26 10:04:36 +00:00
|
|
|
|
|
|
|
Generic place to put comment not suitable in any other subsection.
|
|
|
|
Typically, we could add
|
|
|
|
|
|
|
|
+ Security
|
|
|
|
+ Communication
|
2020-11-26 09:51:51 +00:00
|
|
|
|
2020-11-26 10:10:16 +00:00
|
|
|
** Further Considerations and Remarks
|
2020-11-26 10:04:36 +00:00
|
|
|
|
2020-11-26 10:10:16 +00:00
|
|
|
*** =dev= label
|
2020-11-26 10:04:36 +00:00
|
|
|
|
2020-11-26 10:10:16 +00:00
|
|
|
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.
|