Any significant feature goes through three phases in development. Minor features may bypass one or both of the first two steps at the Maintainer’s discretion.
The following diagram illustrates the feature development process.
This process encourages the development of features from scratch within the community. It intentionally places a heavy burden on closed development, since even finished implementations must go through the three steps, which may result in changes to the design that invalidate the implementation.
One phase may begin before the previous phase ends, if it’s clear that the gating approvals and consensus will be given and that any remaining modifications will not significantly impact the next step. In particular, it is recommended that proof of concept code implementations be submitted for review when the discussion phase is winding down.
The first phase in the development of a new feature includes concept creation and Maintainer approval. This is usually accomplished by creating a new entry in the Project’s task tracker, indicating the objectives of the feature, what it does, who it is for, documenting known risks, etc.
In particular, feature development may happen at the same time as, or as the result of a new specification being developed in the OIC standards process. In that case, the scope of the feature is usually already understood and documented.
Concepts need to be approved by the Maintainer to become design documents.
In this phase, the community of Contributors discuss the feature details and provide feedback.
The lead developer of the new feature starts this process by sending an email to the Project’s mailing list with the tag “[RFC]” in the subject, describes the concept and the relevant details of how the feature will be implemented. The community provides feedback on this proposal, discussing potential pitfalls not yet understood and proposing improvements.
At this point, proof-of-concept code may or may not exist. If it exists, the developer should provide a link to it.
This phase ends when the community achieves a consensus on the feature and the technical solution.
In this phase, the Contributor writes the code necessary to implement the feature and submits it for peer reviewing. This phase is technically the same as the regular process of developing the source code, such as fixing bugs, writing documentation or adding tests. Reviewers of the change ensure that the code actually implements the feature as agreed in the previous two phases, in addition to verifying that it adheres to the contribution guidelines and minimal requirements of the Project.
Development of competing features or designs
For a variety of reasons, different teams may begin developing similar features that are mutually exclusive in their initial form. If that happens, the features must be harmonized in one way or the other.
The most favorable outcome is one in which the different teams resolve their differences during the concept or discussion phase and proceed to implementing a single, unified feature that includes the majority of benefits from the different implementations. The Maintainer plays a significant role as moderator of the discussion and may be expected to make decisions on the technical solutions being presented.
If unification of the features is not possible, the Maintainer has the authority to make a decision on how to solve the conflict and will weigh the technical benefits, the risks, the quality of the implementation (if available) of the different designs, among other criteria. The Maintainer’s decision in the selection must be substantiated by objective technical arguments, but he or she may use subjective or non-technical arguments as tie-breaking factors. Such arguments include business imperatives and friendliness to open source principles and behavior.