Many changes, including bug fixes and documentation improvements can beimplemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through abit of a design process and produce a consensus among the Kadalu community andthe [sub-team]s.

The "RFC" (request for comments) process is intended to provide a consistentand controlled path for new features to enter the Kadalu echosystem,so that all stakeholders can be confident about the direction thecommunity.

Active RFCs

You need to follow this process if you intend to make "substantial"changes to repos in github/kadalu organization, or the RFC processitself. What constitutes a "substantial" change is evolving based oncommunity norms and varies depending on what part of the ecosystem youare proposing to change, but may include the following.

• Any semantic or syntactic change that is not a bugfix.

• Removing features, including those that are feature-gated.

• API changes

• CLI changes

Some changes do not require an RFC:

• Rephrasing, reorganizing, refactoring, or otherwise "changing shape doesnot change meaning".

• Additions that strictly improve objective, numerical quality criteria(warning removal, speedup, better platform coverage, more parallelism, trapmore errors, etc.)

• Additions only likely to benoticed by other developers,invisible to users.

If you submit a pull request to implement a new feature without going throughthe RFC process, it may be closed with a polite request to submit an RFC first.

It’s often helpful to get feedback on your concept before diving intothe level of API design detail required for an RFC. You may open anissue on this repo to start a high-level discussion, with the goal ofeventually formulating an RFC pull request with the specificimplementation design. We also highly recommend sharing drafts of RFCsin#dev-rfc on theKadalu Slack channelfor early feedback.

In short, to get a major feature added to Kadalu, one must first get theRFC merged into the RFC repo as a markdown file. At that point the RFCis 'active' and may be implemented with the goal of eventual inclusioninto Kadalu.

• Fork the RFC repohttp://github.com/kadalu/rfcs

• Copy the appropriate template. For most RFCs, this is0000-template.adoc,for deprecation RFCs it isdeprecation-template.adoc.Copy the template file totext/0000-my-feature.adoc, where'my-feature' is descriptive. Don’t assign an RFC number yet.

• Fill in the RFC. Put care into the details:RFCs that do notpresent convincing motivation, demonstrate understanding of theimpact of the design, or are disingenuous about the drawbacks oralternatives tend to be poorly-received.

• Fill in the relevant core teams. Use the table below to map from projects toteams.

• Submit a pull request. As a pull request the RFC will receive designfeedback from the larger community, and the author should be preparedto revise it in response.

• Find a champion on the relevant core team. The champion is responsible forshepherding the RFC through the RFC process and representing it in core teammeetings.

• Update the pull request to add the number of the PR to the filename andadd a link to the PR in the header of the RFC.

• Build consensus and integrate feedback. RFCs that have broad supportare much more likely to make progress than those that don’t receive anycomments.

• Eventually, the [core teams] will decide whether the RFC is a candidatefor inclusion in Kadalu.

• RFCs that are candidates for inclusion in Kadalu will enter a "final commentperiod" lasting 7 days. The beginning of this period will be signaled with acomment and tag on the RFC’s pull request. Furthermore,Kadalu’s official Twitter account will post atweet about the RFC to attract the community’s attention.

• An RFC can be modified based upon feedback from the [core teams] and community.Significant modifications may trigger a new final comment period.

• An RFC may be rejected by the [core teams] after public discussion has settledand comments have been made summarizing the rationale for rejection. The RFCwill enter a "final comment period to close" lasting 7 days. At the end of the"FCP to close" period, the PR will be closed.

• An RFC may also be closed by the core teams if it is superseded by a mergedRFC. In this case, a link to the new RFC should be added in a comment.

• An RFC author may withdraw their own RFC by closing it themselves.

• An RFC may be accepted at the close of its final comment period. A [core team]member will merge the RFC’s associated pull request, at which point the RFC willbecome 'active'.

Once an RFC becomes active the relevant teams will plan the featureand create issues in the relevant repositories. Becoming 'active' isnot a rubber stamp, and in particular still does not mean the featurewill ultimately be merged; it does mean that the core team has agreedto it in principle and are amenable to merging it.

Furthermore, the fact that a given RFC has been accepted and is'active' implies nothing about what priority is assigned to itsimplementation, nor whether anybody is currently working on it.

Modifications to active RFC’s can be done in followup PR’s. We striveto write each RFC in a manner that it will reflect the final design ofthe feature; but the nature of the process means that we cannot expectevery merged RFC to actually reflect what the end result will be atthe time of the next major release; therefore we try to keep each RFCdocument somewhat in sync with the feature as planned, tracking suchchanges via followup pull requests to the document.

The author of an RFC is not obligated to implement it. Of course, theRFC author (like any other developer) is welcome to post animplementation 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).