OpenFeature Enhancement Proposals(OFEP)

This repository serves as a focal point for research and experimental work. It also enables the creation of discussions, proposals and ideation through issues.

We use OFEP: OpenFeature Enhancement proposals, which comes from the lineage of PEP much like the Kubernetes project uses KEP and Open-Telemetry project uses OTEP.

Should I create an OFEP?

You should create an OFEP for anything that:

• a blog post would be written about after its release (eg. Client-side Feature Flagging)
• requires multiple parties/owners participating to complete (eg. Client-side Feature Flagging [Specification & SDKs])
• requires significant effort or modifications to OpenFeature (eg. something that would take 10 person-weeks to implement, introduce or redesign a system component, or introduces Specification changes)
• impacts the UX or operation of OpenFeature substantially such that engineers using OpenFeature will need retraining
• users will notice and come to rely on
• impacts multiple implementations or languages

It is unlikely an enhancement if it is:

• rephrasing, grammatical fixes, typos, etc
• bug fixes
• refactoring code
• adding error messages or events
• a thing that affects only a single language or implementation

Note: The above lists are intended only as examples and are not meant to be exhaustive. If you don't know whether a change requires an OFEP, please feel free ping someone listed in sdk-maintainers and cloud-native maintainers (or) ask in the CNCF OpenFeature Slack channel. If you are new, you can create a CNCF Slack account here.

OFEP Scope

While OFEPs are intended for "significant" changes, we recommend trying to keep each OFEP's scope as small as makes sense (eg. on broader scale, mentioning the category of the proposal). A general rule of thumb is that if the core functionality proposed could still provide value without a particular piece, then that piece should be removed from the proposal and used instead as an example (and, ideally, given its own OFEP!).

How to start with writing an OFEP?

• First, create an issue using the Enhancement Proposal template.
• Fill in the template. Put care into the details: It is important to present convincing motivation, demonstrate an understanding of the design's impact, and honestly assess the drawbacks and potential alternatives.

Discussing the OFEP

• As soon as the above-mentioned issue is created, potential reviewers (based on the category of proposal specified in the issue) would be automatically asked for review. This is done as a preventive measure to avoid long-winded and open-ended discussions in the early design phase of the proposal but the OFEP author should use their discretion here.
• The OFEP author may choose any place for discussions but needs to be linked to the issue. The suggested ones include continuing in the same GitHub issue or creating a thread on Slack mentioning the issue.
• The OFEP authors are responsible for collecting community feedback on an OFEP before submitting it as a proposal for review.

Submitting the OFEP and life-cycle

• Once the idea of the proposal is reviewed by the assigned reviewers, the OFEP author can then reference a Pull Request to the issue containing the proposal.
• For adding the OFEP as a Pull Request, first, fork this repo.
• Copy OFEP-template.md to OFEP/my-title.md, where my-title is a title relevant to your proposal. If you want to attach any image to the OFEP, add that image to the OFEP/images folder and attach it to the OFEP in the format ![label](images/image-name.png "label").
• Fill in the template and please take care of the details as followed while creating the issue for Enhancement Proposal.
• The initial status of an OFEP should be in drafting or pending for review stage.
• An OFEP is approved when atleast two/three reviewers github-approve the PR but this surely depends on its nature. The OFEP is then merged.
• If an OFEP is rejected or withdrawn, the PR is closed. Note that these OFEPs submissions are still recorded, as GitHub retains both the discussion and the proposal, even if the branch is later deleted.
• If an OFEP discussion becomes long, or the OFEP then goes through a major revision, the next version of the OFEP can be posted as a new PR, which references the old PR. The old PR is then closed. This makes OFEP review easier to follow and participate in.

Automerging-flow of an OFEP Pull Request

• Approved OFEP Pull Requests receive the automerge label.
• A 3-day waiting period starts for objection raising.
• A comment is also posted on the Pull Request stating the same.
• Objections lead to the removal of the automerge label.
• No objections result in auto-merging by Mergify.

Implementing the OFEP

Some accepted OFEPs represent vital features that need to be implemented right away. Other accepted OFEPs can represent features that can wait until a community member decides to implement the functionality. Every accepted OFEP has an associated issue tracking its implementation in the specific repository.

The author of an OFEP is not obligated to implement it. Of course, the OFEP author (like any other developer) is welcome to post an implementation for review after the OFEP has been accepted.