[Placeholder] OEP-61

[kdmccormick]

We will be writing this OEP according to https://openedx.atlassian.net/wiki/spaces/COMM/pages/3511091214/OEP-57+Update+Game+Plan (OEP-57 is already in review at #398).

I'm opening a placeholder PR for now just to reserve the OEP numbers.

[feanil]

@kdmccormick , Security WG already started writing an OEP-60, you mind taking OEP-61 instead?

PR coming shortly.

[kdmccormick]

Sure @feanil

[sarina]

I feel like this particular OEP may be stalled, in part, on the fact that we still don't have a clear definition of Core Product. It feels to me a bit challenging to "define the new repository classification system in detail based on the idea of Product Offerings" prior to really knowing what we're dealing with. I'm also a bit concerned that Core Product is a way bigger challenge than we initially thought and the Core Product WG has really spent its efforts defining (very needed!!!) product processes for the community and defining "core product" seems to always be just around the corner....

[kdmccormick]

@sarina It is definitely stalled. I'd like to see OEP-57's framework further implemented before inventing another framework on top of it. In particular, I wouldn't start writing this OEP until we have a Core Product definition.

That said, I think we still need this OEP or something like it. While having a strong Product WG and progress towards a Core Product is making the release process better, I find that we are still flying by the seat of our pants when it comes to deciding things like:

• which repos should have release tags?
• what's the difference between "experimental" and "supported"?
• which features belong on the community testing sandbox?
• which features belong on the core testing sheet?
• what is OK and isn't OK to have in core repos?
• what makes an extension "official" or "unofficial"?
• what's the boundary between Open edX and its "distributions" (Tutor)?

These decisions are just being made on-the-fly by community members who have experience and/or are stepping up. We're also deferring decision-making to the Tutor project in several ways: e.g., it's Tutor's leadership that has decided what plugins are "officially supported", not Open edX's leadership.

I think that's OK for Redwood, and maybe even Sumac and Teak, too. To a certain degree, it's good to leave space for just-in-time decision making by trusted community members. But, to say we have a mature release process, I do think we need formalized answers to many more of these questions than we have now.

[sarina]

@kdmccormick 100% agree, I think you laid that out well. To be clear, I wasn't proposing to close this draft, because it does represent a needed OEP, but wanted a little discussion on this PR to anyone who may be checking in on it. I'll follow up with Product leadership about core product definition and how to kick it forward in the coming 6-12 months.