How to specify components and aspects?

[kiview]

When writing and working on specifications in a distributed and asynchronous way, with the involvement of multiple parties, we can look at a range of communities that came up with processes and structures that seem to work reasonably well.

The following come to mind and we might be able to take some inspiration from this:

• The Python language is developed using Python Enhancement Proposals PEP. From a process standpoint, a PEP can have different statuses (open, accepted, etc.) and is categorized by its type (meta, informational, standards, process).
• Bitcoin adopted the idea of PEP and uses Bitcoin Improvement Proposals BIP.
• Ethereum adopted the idea of BIP and uses Ethereum Improvement Proposals EIP.
• Java has the JDK Enhancement Proposal JEP for language development and the Java Community Process JCP as the connected governance process for the JEP.
• Much of the Internet is developed and standardized according to the Request for Comments RFC.
• A very much related process are the Internet Drafts I-D by the Internet Engineering Task Force (IETF).
• Hyperledger Aries, which is very closely related to ToIP, is developed using RFCs on GitHub as well.

So there seem to be a lot of existing process and best practices we can use as a template. Initially, we should strive for a lightweight process and maybe looking at other blockchain communities for the inspiration is the most logical start?

[kiview]

After a first look into the different models, I think the Aries process would work reasonably well and also mirrors our domain to a certain degree.

We could even copy their PR process directly.

[fflush]

I also think it's best to start by adapting the Aries process. Especially because of the proximity to ToIP. We should keep our eyes open and of course continuously improve the process. Maybe we will find something in the other blockchain communities that will improve the process even more. But first we should start with this. While working we will probably notice some things that we can still improve.

[chinmay241]

RFC makes sense when there are more people. But these can be improved upon with process we go forward as mentioned by @fflush. But since if(is) is already part of several consortium we can probably RFC from other consortium members who might be happy to contribute.

I am in several Network groups such as RIPE and ARIN. There exist some participants disconnected from the modern collaborative tools such as Google Docs and Github. They follow a Mail Chain process where the idea initiator sends a mail to the mailing list where they receive feedback ^ Since mails are easily accessible to the others who probably are not on Github. We can start using Github for RFCs as it seems the most straightforward collaborative method over Google Docs for example. Maybe others opinion like whole matter in this context.

Every consortium is shaped in the way they want to manage their members and technical output/result to achieve. Of all those inspiration @kiview mentioned are USA based entities which might miss out on the European aspect but might cover the legal aspects such as GDPR. Especially Germany like I mentioned BSI is an Information security standard comparable to ISO27001. Shaping up of these groups would be inherently German aspects ^

[kiview]

The example of Python PEP is at least to a certain degree of European/Dutch origin. However, Python Foundation is US-based, but PEP is overseen nowadays by the steering council, which is not a legal entity in a certain country.

The EIP is overseen by the Ethereum Foundation, which is registered in Switzerland.

I don't understand the connection to BSI, since this is a government organization.

Also note that the list above mostly does not describe consortia, but processes.

[kiview]

The Aries RFC project contains some useful enforced structures, that makes consumption of the RFCs easier and therefore allows rendering of different presentations and semantics already, even without using a real database to model relations.

Relations are just modelled by links and tags having certain default semantics. The Markdown files are then processed by Python as part of the CI pipeline in order to generate HTML artifacts.

Also note, that if we start by incorporating the files by Aries, this means we are obliged to also license our files under Apache 2 license. As an alternative, we can use Rust RFC as a starting point, since this is dual-licensed under Apache 2 and MIT, with MIT giving us more freedom to proceed as we see fit.

[chinmay241]

I agree @kiview The Aries RFC life cycle is detailed and self-explanatory than the RUST RFC. This is my idea for the lifecycle Proposed -> Demonstrated (Technical Implementation or PoC) -> Accepted -> Adopted -> Revised (Minor Revisions should be possible) -> Retired

Edit: We would need to decide the process and lifecycle along with clear explanation of what would need a RFC and what would not need to be an RFC.

[kiview]

I don't think we need such a detailed lifecycle, especially considering, that we have basically no technical implementations (Aries has). Therefore I can't see anything besides proposed -> accepted -> retired. With proposed state just meaning implicitly an open submitted PR.

[kiview]

After further discussion, we decided to use the Aries RFC format as the starting point and to bootstrap our own process. We will, however, reduce its complexity so it's a better fit for our needs.