I have spent some more days to realize how we could go forward, here are my ideas.
Any feedback is welcome. If you are in Berlin on 05-11.09.2018 let me know - it would be great to brainstorm in person.
I see two huge topics we can start with:
- Book of Ethereum Reference Architectures and Design Patterns
- Organize a EIPs in a meaningful way.
Both topics are much needed for community and for ethereum adoption. Although final goal is very unclear at the moment, I could imagine a way forward:
(1) Starting with List of Architecture:
I would propose to start first with simple list of links to possible architectures or reference solutions.
For somebody, who looks for suitable architecture it will be useful even in this simplest form. An author of the architecture description or an author of the reference implementation will have an incentive to include a reference to his work into the list. Looks like we have a good case for TCR (token curated registry) here.
Once we have collected dozen of entries in our list, we will see an internal structure of the list and organize it in better way, compare entries, introduce metrics and so on.
(2) Organizing EIPs:
Here I would start to create a labeling (tagging) structure for categorizing EIPs with. It should help to group and categorize them quickly. I have already few tags in mind (here is verbose naming):
[DESIGN_PATTERN vs. ETHEREUM_CHANGE]:
there are a lot of EIPs, that are not “Ethereum Improvement Proposals” (EIP) actually, but “Design Patterns” (DP).
DPs do not need a community consensus and do not change a protocol. DPs do not need much attention of entire community.
EIPs do require community consensus and need to be reviewed almost by anyone.
This label helps to filter out “must-read” proposals from “nice-to-have read”.
this label should mark a standard, which can be adopted without consensus, but once adopted, can’t be changed any more easily. Example: ERC20. It is an interoperability standard. Trying to change it will create a mess between old and new tokens on exchanges.
This label marks a proposal requiring broad and comprehensive discussion, but does not change protocol.
[HARD_FORK]: proposal can lead to hard fork.
marks dangerous EIPs that requiring community consensus.
Incentivization of the labeling work is not quite clear to me yet.
Any feedback is welcome. If you are in Berlin on 05-11.09.2018 please drop me a message.