2.9 KiB
[Meta RFC] RFC template
tags :: work 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)
- github dashboard, issue templates, github labels, etc…
-
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
Objectives
- Problems:
- New Features:
- Improve the current situation:
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
Plan
Optional, complete once a consensus has been reached. Should contain a plan to achieve the solution.
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.