perlindgren
commented
7 months ago What about a traditional RFC process, roughly:
- 1) problem to solve/motivation
- 2) use case(s)
- 3) design/implementation
- 4) evaluation, tests/regression tests, providing evidence to 1)
- 5) documentation
- 6) semantic versioning, backwards/forwards compatibility, (ensuring stability and avoiding dead-end design choices)
- 7) PR/Merge
After merge master is the the specification of RISC-V RT for given semantic version.
Changes with only non-normative impact can be done without the strict RFC process, only 4) is required to ensure stability.
Please suggest suitable contributions regulations.