Changes to the Nerine landscape have to be made to adapt it as a database to many challenges to it's ecosystem, and this repository exists as a way to formally change it as a landscape and outline the design behind the design of it. Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.
The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the ecossytem and standard libraries.
RFCs are first drafted over an issue, then once they are formally established with a repository with proper examples of it's implemenetation of it's own created by someone who can formally champion the RFC.
All RFCs are dictated by the process of stages established.
Before creating an RFC, make sure it's thoroughly reviewed and proposed properly, otherwise its chances at acceptence become marginally low. Anything that looks low quality can easily be rejected quickly, unless proper change is made to it. Most of us don't want to be that one person who had a bright idea just for someone else to do it better than you.
Although there is no really singular proper way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project developers or users beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.
This RFCs repository was created with the intention of providing a simple way for the community and committee members of all kinds to request significant changes to the specifications of the Nerine database.
What count's as significant are:
While significant changes will always warrant requiring it to go through the RFC process, some changes do not require a RFC beforehand:
A RFC has a lifecycle of it's own to go through, as determined by the stage it's in. If a RFC is determined to be "inactive", or otherwise is generally unseen and forgotten over a long period of time, then it'll be closed for a new champion to pick it up again.
"Inactive" RFCs are ones that have been rejected, or have been untouched for enough time to render it such. No matter the cause of inactivity, a new RFC issue will need to be created entirely from the start of the process.
Aside from everything above, in short; in order to get something added to the Nerine specifications, one must first chair and champion a RFC by an issue. When that issue is created, a RFC is deemed "active".
Once a RFC has been passed and approved by the community and committee, the RFC template can be formally used to induce it in the repository.
The process is usually of the following:
Many approved RFCs represent important, necessary features that need to be implemented right away. A few other accepted RFCs can represent features that can wait until some arbitrary developer feels like doing the work, as anyone who makes a database implementation most likely has an actual life. Every accepted RFC most likely has an associated issue tracking its implementation in other associated projects.
The author of an RFC is not obligated to implement it. Of course, the RFC author (like any other developer) is welcome to post an implementation for review after the RFC has been accepted.
If you are interested in working on the implementation for an "active" RFC, but cannot determine if someone else is already working on it, feel free to ask (e.g. by leaving a comment on the associated issue).
This repository is currently licensed under: Apache License, Version 2.0, (LICENSE or https://www.apache.org/licenses/LICENSE-2.0)
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.