docs: add OEP-57: Cores and Extensions

oeps/architectural-decisions/oep-0057-cores-and-extensions.rst

@@ -0,0 +1,92 @@
+
+OEP-57: Cores and Extensions
+############################
+
+.. list-table::
+   :widths: 25 75
+
+   * - OEP
+     - :doc:`OEP-57 <oep-0057-cores-and-extensions.rst`_
+   * - Title
+     - Cores and Extensions
+   * - Last Modified
+     - 2022-08-??
+   * - Authors
+     - Kyle McCormick <[email protected]>
+   * - Arbiter
+     - TBD <[email protected]>
+   * - Status
+     - Draft
+   * - Type
+     - Architecture
+   * - Created
+     - 2022-08-??
+   * - Review Period
+     - 2022-??-?? - 2022-??-??
+   * - Resolution
+     - TBD
+   * - References
+     - TBD
+
+Abstract
+********
+
+The abstract is a short description of the technical issue that
+this Open edX proposal (OEP) addresses.
+
+Motivation
+**********
+
+The motivation is critical for OEPs that will change any part of the Open edX
+ecosystem. Explain why the existing architecture or process is inadequate to
+address the problem that the OEP solves, or why adopting the best practice
+would significantly improve the Open edX world.
+
+Specification
+*************
+
+The specification describes the technical details of the Architecture, Best
+Practice or Process proposed by the OEP. If the proposal includes a new API,
+specify its syntax and semantics.
+
+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
+**************
+
+2022-08-??
+==========
+
+* Document created
+* `Pull request #XXX <https://github.com/openedx/open-edx-proposals/pull/XXX>`_