The Odin project's development process is driven by design and pragmatism. Significant changes to the language, libraries, or tools must be first discussed, and maybe formally documented, before they can be implemented.
This document describes the process for proposing, documenting, and implementing changes to the Odin project.
The proposal process is the process for reviewing a proposal and reaching a decision about whether to accept or decline the proposal.
-
Ginger Bill is BDFL and significant changes must be passed by him.
-
The proposal author creates a brief issue describing the proposal.
Note: There is no need for a design document at this point.
Note: A non-proposal issue can be turned into a proposal by simply adding the proposal label. -
A discussion on the issue tracker will classify the proposal into one of three outcomes:
- Accept proposal
- Decline proposal
- Ask for a design document.
If the proposal is accepted or declined, the process is done. Otherwise the discussion around the process is expected to identify issues that ought to be addressed in a more detailed design.
-
The proposal author writes a design document to work out details of the proposed design and address the concerns raised in the initial discussion.
-
Once comments and revisions on the design document calm, there is a final discussion on the issue, to reach one of two outcomes:
- Accept proposal
- Decline proposal
After the proposal is accepted or declined, implementation of the proposal proceeds in the same way as any other contribution to the project.
The design document should follow this template:
# Proposal: [Title]
Author(s): [Author Name, Co-Author Name]
Last updated: [Date ISO-8601]
Discussion at https://github.com/odin-lang/Odin/issues/######
## Abstract
## Background
## Proposal
## Rationale
## Compatibility
## Implementation
If you need help with this process, please contact an Odin contributor by posting an issue to the issue tracker.