Request for Comments (RFCs)

This page gives an overview of the current RFCs for KSF Standards and Projects.

To create a new RFC, create a wiki article with the relevant details and link to it from this page. New RFCs should be announced on Mattermost.

Current RFCs

Voting

None at this time.

Under Discussion

RFC Title	RFC Owner	Project
(RFC) ZWI Metadata — Article Read Time or Word Count	Chris W	ZWI Format

RFC Process

Ownership and Editing

An RFC is effectively "owned" by the person that created it.

Anyone is welcome to add questions or comments.

If someone who isn't the RFC owner wants to make changes to the main content being discussed, they should get permission from the creator. If no agreement on changes can be reached, the best course of action is to create a competing RFC. In this case, an intermediate page should be created that points to all the competing RFCs, which should be named or renamed to have largely consistent titles.

Voting and Outcome

After a period of time in the "Questions and Comments" phase (at minimum 2 weeks, but up to an indefinite amount of time), the RFC owner or the KSF Board may call for a vote.

At this time, the various RFC pages should be updated to advertise that voting has opened, and an announcement should be made on Mattermost.

The voting period lasts until the RFC has been accepted or rejected according to the voting criteria, or through to a specified closing date (usually 4-8 weeks from when voting begins).

To be accepted, a quorum of members must have voted, a majority of voters must vote yes, and the project owner(s) must choose not to veto the proposal.

If an RFC doesn't meet the acceptance criteria through the voting process, it is rejected.

If the RFC owner is also the related project owner, they may choose to implement to discussed item regardless of the vote — in which case, the RFC acts more like an opportunity to seek community feedback and input. However, in cases where there is an overwhelming no vote, and the project owner still wants to implement the discussed item, it is recommended they try to accommodate or address the community input.

Quorum

A quorum is defined as ... (?) [Input is requested from KSF members on this point.]

Is an RFC Required?

The RFC process is not intended to slow development or adoption of any work.

It is not a required process for any stage of development within your own projects. Projects owners and developers should make and adopt changes as they best see fit.

The RFC process should generally be used as a means of proposing and discussing technical solutions, or changes to standards, that will impact a wider ecosystem of people. They also provide a mechanism for non-project owners to have input — although in this case, the RFC owner should generally discuss the idea with a relevant KSF member first.

Difference Between RFCs, Proposals, and Discussions

General questions, comments, ideas and suggestions are often best addressed through a discussion on Mattermost. Discussions are quick, often informal, and provide faster means of getting things done.

Proposals are for raising new ideas, projects, and open-ended or big picture proposals (although a proposal can contain anything, as long as it has some relevance to the KSF). These are more developed and concrete, and less ephemeral, than discussions. A solution may or may not be proposed.

RFCs should be specific, detailed, and contain an outcome or solution that is being voted on because the outcome impacts a wider group of people. Including supporting code is highly recommended, and there is an expectation the RFC owner will be an active participant in implementing the discussed content. (In general, RFCs should not be simple feature requests, which may be better raised in other forums, including the above options, or within the appropriate project development location.)