Added OKR for status extension URI schema
Signed-off-by: Julien Eluard <julien.eluard@gmail.com>
This commit is contained in:
parent
5a96b329f3
commit
e1f6292833
|
@ -0,0 +1,40 @@
|
|||
# 1. Record Decisions
|
||||
|
||||
| Date | Tags |
|
||||
|------------|---------|
|
||||
| 2018-02-16 | process |
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
|
||||
## Context
|
||||
|
||||
We make a lot of decisions during the life of a project and
|
||||
documenting those decisions would help new team members and outside
|
||||
contributors follow our thinking. It also opens up an opportunity for
|
||||
constructive criticism around those decisions which will result
|
||||
in better decision making.
|
||||
|
||||
We want to develop a product in the open. Opening up our decision making process for outside contributors is an important part in providing the opportunity to take ownership and impact the project in non-trivial ways.
|
||||
|
||||
Recording decisions will also be a useful form of documentation in general as it does not get out of date. All that's documented is that a decision has been made at a certain point in time.
|
||||
|
||||
## Decision
|
||||
|
||||
We will adopt a format similar to [Architecture Decision
|
||||
Records](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) (ADR)
|
||||
to propose and document notable decisions. In contrast to ADRs we will try to embrace this tool for more than just architectural concerns. Decisions regarding development practices and product direction are just as important.
|
||||
|
||||
What decisions are notable and which are not is left to common-sense and informal consensus among the team.
|
||||
|
||||
Decisions may be proposed and discussed informally, should however eventually end up — with all relevant discussion summarized — in the `doc/decisions/` directory of this repository.
|
||||
|
||||
Decisions are numbered to have a clear identifier.
|
||||
|
||||
## Consequences
|
||||
|
||||
- We need to document that we record decisions this way and where people can find those documents.
|
||||
- We should probably provide some pointers around tooling to better work with decision records. [`adr-tools`](https://github.com/npryce/adr-tools) comes to mind.
|
||||
- Since we deviate from ADRs a bit (we document more than architecture-related decisions) we might need to provide different templates than what comes with tools like `adr-tools` by default.
|
||||
A template like this may also be useful to guide decision authors to provide appropriate context.
|
|
@ -0,0 +1,28 @@
|
|||
# 0002. Extension URI
|
||||
|
||||
| Date | Tags |
|
||||
|---|---|
|
||||
| 2018-04-26 | extension, uri, ethereum |
|
||||
|
||||
|
||||
## Status
|
||||
|
||||
proposed
|
||||
|
||||
## Context
|
||||
|
||||
Extensions are defined by an EDN file accessed from decentralized storage. An URI schema allows to identify those files.
|
||||
|
||||
## Decision
|
||||
|
||||
URI follows ethereum URI schema as specified in [EIP 831](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-831.md)
|
||||
|
||||
|
||||
```
|
||||
uri = "ethereum:" path
|
||||
path = "status:extension" ":" storage "@" id
|
||||
storage = STRING (e.g. IPFS)
|
||||
id = STRING (e.g. IPFS hash)
|
||||
```
|
||||
|
||||
An example of an extension available on IPFS is: `ethereum:status:extension:ipfs@QmTeW79w7QQ6Npa3b1d5tANreCDxF2iDaAPsDvW6KtLmfB`
|
|
@ -0,0 +1,12 @@
|
|||
# Decisions
|
||||
|
||||
We record decisions. More context on why and how we do that can be found in [DR-0001](0001-record-decisions.md).
|
||||
|
||||
The remainder of this document is intended to document tooling around this process.
|
||||
|
||||
## Utilities to Write Decision Records
|
||||
|
||||
- `doc/decisions/templates/template.md` - contains a template for a decision record.
|
||||
- When recording a decision follow the established file name format
|
||||
`XXXX-some-title.md` where XXXX is the ever increasing count of decisions
|
||||
we've made.
|
|
@ -0,0 +1,31 @@
|
|||
# NUMBER. TITLE
|
||||
|
||||
| Date | Tags |
|
||||
|---|---|
|
||||
| DATE | e.g: architecture, database |
|
||||
|
||||
|
||||
## Status
|
||||
|
||||
STATUS
|
||||
|
||||
Common states: proposed, accepted, rejected, deprecated, superseded
|
||||
|
||||
## Context
|
||||
|
||||
Describe the context in which the decision has been made.
|
||||
Some questions that should give some ideas what to write here:
|
||||
|
||||
- What problems have you encountered that this decision impacts?
|
||||
- What is the current state of things that are related to this decision?
|
||||
|
||||
## Decision
|
||||
|
||||
Describe your decision.
|
||||
|
||||
- In what ways does it solve the aforementioned problems or improves something?
|
||||
- What tradeoffs does this decision make?
|
||||
|
||||
## Consequences
|
||||
|
||||
Expand on tradeoffs and other side-effects of this decision.
|
Loading…
Reference in New Issue