You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Open edX project is comprised of nearly two hundred repositories that, together, contain millions of lines of code.
57
41
Each repository increases the effort required to maintain the project and the cognitive load required to understand the project.
58
42
43
+
.. to do
44
+
59
45
60
46
Specification
61
47
*************
62
48
63
-
.. The specification describes the technical details of the Architecture, Best
64
-
.. Practice or Process proposed by the OEP. If the proposal includes a new API,
65
-
.. specify its syntax and semantics.
49
+
50
+
Product Offerings
51
+
=================
52
+
53
+
The Open edX Product Working Group (PWG) shall create and maintain two product specifications:
54
+
the **Core Product Offering** and the **Extended Product Offering**.
55
+
The PWG may document these specifications in any format, provided that:
56
+
57
+
* they are always easy-to-find and publicly visible,
58
+
* they are reviewed and updated at least every six months, and
59
+
* a public revision history is maintained.
60
+
61
+
Core Product Offering
62
+
---------------------
63
+
64
+
This is an articulation of which features should come fully supported by the community Open edX installation *without any additional configuration steps*. In other words, it is the desired "out-of-the-box" Open edX experience. Ensuring the support, maintenance, security, and quality of these features is of highest priority to the Open edX community.
65
+
66
+
Extended Product Offering
67
+
-------------------------
68
+
69
+
This is an articulation of which features should come supported by the community Open edX installation *without installing any additional software*, although configuration (overriding settings, toggling Waffle flags, etc.) may be necessary. By definition, this is a superset of the Core Product Offering. Ensuring the support, maintenance, security, and quality of these features is important, although secondary to ensuring so for the features in the Core Product Offering.
70
+
71
+
72
+
Repository Tiers
73
+
================
74
+
75
+
Based on the Product Offering specifications,
76
+
we designate four tiers of Open edX repositories:
77
+
78
+
1. **Clerical** repositories exist solely to help manage the Open edX project itself.
79
+
For example, they may contain process documentation,
80
+
hold code for project administration tools,
81
+
or serve as a task-tracking repository.
82
+
However, they may *not* contain code or documentation intended for *users* of
83
+
Open edX, whether that be operators, educators, or otherwise.
84
+
85
+
2. **Kernel** repositories are necessary and sufficient to run a functioning
86
+
instance of the Open edX LMS. In other words, the Kernel is the minimal set of
87
+
repositories upon which Open edX depends. We recognize that it is ideal
88
+
to minimize the size of this tier over time.
89
+
(At the time of writing, this includes edx-platform
90
+
and every Open edX repository upon which edx-platform has a hard dependency,
91
+
of which they are currently very many.)
92
+
93
+
3. **Bundled** repositories, together with the kernel repositories,
94
+
are necessary and sufficient to support the Core Product Offering.
95
+
In other words, bundled repositories are part of the core product, but are
96
+
not strictly necessary in order to run the LMS. For example, several
97
+
XBlocks may be core to the Open edX product but may not be requirements of the LMS;
98
+
they would be considered bundled repositories.
99
+
100
+
4. **Supplemental** repositories, together with the kernel and bundled repositories,
101
+
are necessary and sufficient to support the Extended Product Offering.
102
+
In other words, supplemental repositories are part of the extended product
103
+
but no the core product. For example, a micro-service that operators could optionally
104
+
enable in the Open edX community release would be considered a supplemental repository.
105
+
106
+
5. **External** repositories describe all remaining repositories related to Open edX.
107
+
They are neither used in the Extended Product Offering nor for clerical purposes.
108
+
There are an unbounded number of repositories in this tier.
109
+
110
+
111
+
Repository Kinds
112
+
================
113
+
114
+
Depending on how a repository is used, we release it to the community in
115
+
one of two different ways:
116
+
117
+
* **Primary** repositories are the entry points for software that deploys and runs Open edX. These include:
118
+
119
+
* backend services,
120
+
* frontend applications,
121
+
* optional plugins that are *not* listed as explicit requirements by other repositories,
122
+
* tools that are *not* invoked by other repositories, and
123
+
* top-level documentation projects.
124
+
125
+
* **Secondary** repositories are referenced and used by primary repositories,
126
+
either by numerical version or by git hash. These include:
127
+
128
+
* libraries that are listed as explicit requirements by other repositories,
129
+
* tools that are loaded and used by other repositories, and
130
+
* documentation that is included into another documentation project.
131
+
132
+
Note that a reposity's "kind" is just a tactical technical distinction;
133
+
it does not indicate the repository's importance, support level, or anything else qualitative.
134
+
135
+
136
+
137
+
Repository Support Levels
138
+
=========================
139
+
140
+
.. todo table
141
+
142
+
We designate seven support levels for repositories powering the Extended Product Offering
143
+
(that is: kernel, bundled and supplemental repositories):
144
+
145
+
.. list-table::
146
+
:header-rows: 1
147
+
148
+
* - Support Level
149
+
- Open edX Release
150
+
- Production Readiness
151
+
- Forwards Compatibility
152
+
- Documention Level
153
+
- Continuing Development
154
+
- Community Support
155
+
* - **Pre-Alpha**
156
+
- ❌ Not in release
157
+
- ❌ Not production ready
158
+
- ❌ Frequent breaking changes
159
+
- ❌ Sparsely documented
160
+
- ✔️ Yes
161
+
- ❌ No support
162
+
* - **Alpha**
163
+
- ✔️ In release
164
+
- ⚠️ Production-ready for early adoptors (issues expected)
165
+
- ❌ Frequent breaking changes
166
+
- ⚠️ Partially documented
167
+
- ✔️ Yes
168
+
- ⚠️ Low-priority support
169
+
* - **Beta**
170
+
- ✔️ In release
171
+
- ✔️ Production-ready (issues anticipated)
172
+
- ⚠️ Breaking changes expected, but communciated
173
+
- ⚠️ Mostly documented
174
+
- ⚠️ Some
175
+
- ✔️ Supported
176
+
* - **Stable**
177
+
- ✔️ In release
178
+
- ✔️ Production0ready
179
+
- ✔️ Breaking changes minimized & communicated
180
+
- ✔️ Documented
181
+
- ⚠️ Some
182
+
- ✔️ Supported
183
+
* - **Sustained**
184
+
- ✔️ In release
185
+
- ✔️ Production-ready
186
+
- ✔️ Breaking changes minimized & communicated
187
+
- ✔️ Documented
188
+
- ❌ Little or none. May be candidate for future deprecation.
189
+
- ✔️ Supported
190
+
* - **Deprecated**
191
+
- ✔️ In release
192
+
- ⚠️ Production-ready, but migration encouraged
193
+
- ❌ Expect upcoming removal
194
+
- ⚠️ Possibly documented
195
+
- ❌ Little or none
196
+
- ❌ No support guarantee
197
+
198
+
.. 1. **Alpha** repositories are available for production trial by early adopters,
199
+
.. but instability should be anticipated and significant breaking changes should
200
+
.. be expected between releases. Documentation will provided when possible, but
201
+
.. due to the repository's frequent change rate, may not be comprehensive.
202
+
.. Support may be provided by maintainers but is not guaranteed.
203
+
.. 2. **Beta** repositories are ready for production use,
204
+
.. Documentation should be mostly complete.
205
+
.. Maintainers should provide support.
206
+
.. 3. **Stable** repositories are ideal for production use.
207
+
.. Complete documentation should be available and maintainers should provide support.
208
+
.. Breaking changes should be be minimized and notified with
0 commit comments