feat: Add an OEP defining the use of OpenFeature for feature toggles

oeps/best-practices/oep-0066-bp-openfeature-toggles.rst

@@ -0,0 +1,127 @@
+.. _pep_based_template:
+
+.. Below is the display in the left sidebar on RTD. Please omit leading 0's
+
+OEP-0066: OpenFeature Format For Feature Toggles
+######################
+
+.. This OEP template is based on Python's PEP standard.
+
+.. list-table::
+   :widths: 25 75
+
+   * - OEP
+     - Link to the doc in the following format::
+
+        :doc:`OEP-0066 <oep-0066-bp-openfeature-toggles>`
+
+        * <XXXX is the next available OEP number>
+        * <YYYY is the abbreviated Type: proc | bp | arch>
+        * <ZZZZ is a brief (< 5 words) version of the title>
+
+   * - Title
+     - Implement All Toggles Using OpenFeature Specification
+   * - Last Modified
+     - 2025-01-15
+   * - Authors
+     - Tobias Macey
+   * - Arbiter
+     - <Arbiter's real name and email address>
+   * - Status
+     - Draft
+   * - Type
+     - Best Practice
+   * - Created
+     - 2025-01-15
+   * - Review Period
+     - 2025-01-15 - 2025-02-28
+   * - Resolution
+     - <links to any discussions where the final status was decided>
+   * - References
+     - `OEP 0017 <https://open-edx-proposals.readthedocs.io/en/latest/best-practices/oep-0017-bp-feature-toggles.html>`_
+
+Abstract
+********
+
+OpenFeature is an open standard and ecosystem for managing feature toggles across
+various languages and frameworks. This offers a single, consistent format for managing
+the ubiquitous toggles in Open edX to improve their discoverability and maintenance.
+
+Motivation
+**********
+
+OEP 17 provided an excellent and valid argument in favor of the adoption of feature
+toggles as a core practice of the Open edX suite of software. Unfortunately, the
+implementation of that practice has led to a large variety in the methods used to manage
+those toggles, and dramatically different naming across repository boundaries. The
+adoption of the `OpenFeature
+<https://github.mit.edu/ol-platform-eng/concourse-workflow/issues/12253>`_ specification
+and associated SDKs allows us to be more consistent in the naming and management of
+those toggles.
+
+The adoption of OpenFeature as the implementation target for Open edX software also
+provides flexibility to operators of the software to use the toggle management service
+that they prefer. This improves the ability of Open edX to fit into an existing
+operations environment without forcing the site operators to conform to the use of
+operations technologies that they are not familiar with.
+
+Specification
+*************
+
+There are numerous pre-existing toggles across the Open edX ecosystem of projects. Many
+of them are implemented as Waffle flags, but there has also been widespread use of
+environment variables or directly setting application values via the various settings
+interfaces. All of those existing mechanisms can co-exist with the OpenFeature
+implementation, with OpenFeature becoming the entry-point and controller of the final
+returned values. This provides a method of backward compatibility, while also offering
+the ability to choose an alternative provider to manage the values of those toggles in a
+running system.
+
+Another challenge in the current state of feature toggles across Open edX projects is a
+lack of naming consistency in the name of the actual toggle, along with a high degree of
+variance with whether the toggle name has any relation to the feature being managed. In
+the adoption of OpenFeature, the differently named toggles that share purpose across
+repositories will be aligned. This will enable operators to manage a single toggle
+setting to enable the functionality across the full Open edX stack.
+
+Rationale
+*********
+
+The rationale adds to the specification by describing the events or
+requirements that led to the proposal, what influenced the design, and why
+particular design decisions were made. The rationale could provide evidence
+of consensus within the community and discuss important objections or
+concerns raised during discussion. It could identify any related work,
+for example, how the feature is supported in other systems.
+
+Backward Compatibility
+**********************
+
+This statement identifies whether the proposed change is backward compatible.
+An OEP that introduces backward incompatibilities must describe the
+incompatibilities, with their severity and an explanation of how you propose to
+address these incompatibilities.
+
+Reference Implementation
+************************
+
+The reference implementation must be completed before any OEP is given "Final"
+status, but it need not be completed before the OEP is "Accepted". While there is
+merit to the approach of reaching consensus on the specification and rationale
+before writing code, the principle of "rough consensus and running code" is
+still useful when it comes to resolving many discussions.
+
+Rejected Alternatives
+*********************
+
+This statement describes any alternative designs or implementations that were
+considered and rejected, and why they were not chosen.
+
+Change History
+**************
+
+YYYY-MM-DD
+==========
+
+* Document created
+* `Pull request #XXX <https://github.com/openedx/open-edx-proposals/pull/XXX>`_