mirror of
https://github.com/AleoHQ/leo.git
synced 2024-12-24 18:12:28 +03:00
45 lines
1.3 KiB
Markdown
45 lines
1.3 KiB
Markdown
|
# Summary
|
||
|
|
|
||
|
|
This is an RFC to propose RFC format for Leo language.
|
||
|
|
|
||
|
|
# Motivation
|
||
|
|
|
||
|
|
Leo develops rapidly and changes to the language need to be stated clearly and presented to everyone. RFC is the perfect tool for turning chaos into order.
|
||
|
|
|
||
|
|
# Design
|
||
|
|
|
||
|
|
This section describes proposed solution.
|
||
|
|
|
||
|
|
## Store RFCs inside Leo repository.
|
||
|
|
|
||
|
|
At early stages it is for better to see changes with the code eliminating the need to keep track of a different repository.
|
||
|
|
|
||
|
|
## Use standard PR mechanics for submitting new RFCs
|
||
|
|
|
||
|
|
New RFCs should be submitted as a PRs into Leo repository. PRs should be correctly labeled for easier search. Yet they should not have number unless PR is accepted by leo maintainers.
|
||
|
|
|
||
|
|
## Increase approvals count for RFCs
|
||
|
|
|
||
|
|
RFCs may propose changes affecting multiple systems or projects. They also introduce new changes to the language design or structure. Because of that they should be watched more carefully by as many involved team members as possible. Increasing number of required approvals should help achieve this goal.
|
||
|
|
|
||
|
|
## Format
|
||
|
|
|
||
|
|
For bootstrapping new requests template is made and placed into RFC folder.
|
||
|
|
|
||
|
|
## Number
|
||
|
|
|
||
|
|
RFCs should receive number once they are accepted.
|
||
|
|
|
||
|
|
# Drawbacks
|
||
|
|
|
||
|
|
None.
|
||
|
|
|
||
|
|
# Effect on Ecosystem
|
||
|
|
|
||
|
|
None.
|
||
|
|
|
||
|
|
# Alternatives
|
||
|
|
|
||
|
|
Propose language changes in team channels or as GitHub issues.
|
||
|
|
|