| sip | title | status | discussions-to (*optional) | author | created | updated (*optional) |
|---|---|---|---|---|---|---|
(To be assigned) |
(The tile of this SIP) |
Draft |
(Http/Https URL) |
(Comma-separated list of authors in following format `Name Surname <optional email> (Github username)`) |
(Date created on in ISO 8601 format. `yyyy-mm-dd`) |
(Date last updated on in https://en.wikipedia.org/wiki/ISO_8601 format. `yyyy-mm-dd`. This should be only used on SIPs with `Living` status) |
A few terse sentences that are a technical summary of the proposal. Someone should be able to read this paragraph and understand the gist of this SIP.
The "why"
Indented sections like this are considered non-normative.
Formal specification of the proposed changes in the SIP. The specification must be complete enough that an implementation can be created from it.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" written in uppercase in this document are to be interpreted as described in RFC 2119
Any SIPs that break backwards compatibility MUST include a section describing those incompatibilities and their severity. The SIP SHOULD describe how the author plans on proposes to deal with such these incompatibilities.
Copyright and related rights waived via CC0.