search

openedx / open-edx-proposals

Proposals for Open edX architecture, best practices and processes
http://open-edx-proposals.readthedocs.io/
Other
43 stars 32 forks source link

Write OEP answering "What code is part of the Open edX project?" #295

Open sarina opened 2 years ago

sarina commented 2 years ago
kdmccormick commented 2 years ago

Thanks for capturing this 🔥

robrap commented 2 years ago

I've been working in eduNEXT/openedx-events, and it serves as a good example.

I believe eduNEXT/openedx-events is meant to be a core part of the Open edX platform, but it isn't yet in the openedx repo.

  1. Does that mean it isn't officially core to the platform until it moves orgs?
  2. Does it mean that OEPs don't need to be enforced until it moves?
  3. How would I request that it be moved?
  4. What would happen if eduNEXT didn't want it to move?

I imagine this will be a recurring issue, as it will be quicker for any company to start a repo under its own org, even though it may be better for it to live in the openedx org. This is especially true for edX, who has created the most repos to date.

kdmccormick commented 2 years ago

One indicator for openedx org inclusion that I think @ormsbee had floated was "If the default Open edX installation cannot run without it, it needs to be in the openedx org." I think this is a good idea. Notes:

Does that mean it isn't officially core to the platform until it moves orgs?

To me, yes. "Core" code should exist in one place.

Does it mean that OEPs don't need to be enforced until it moves?

Again, yes. But it shouldn't be moved (and, therefore, shouldn't be required by the default installation) until follows OEPs, at least to a degree deemed reasonable. Therefore, folks aiming for their repo to move to openedx would best follow OEPs from the get-go.

How would I request that it be moved?

Not sure. I'd say "make a request to tCRIL", but I'm not sure whether or not tCRIL should be the sole deciders of what goes in the org. Interested to hear this discussion on the OEP.

What would happen if $FIRM didn't want it to move?

Well, the code should be under a free license, so we can fork any code into organization if we really must.

That being said, when working with the community, we should make this OEP's policies clear early on and make sure we're on the same page about the end state of the repo. Ideally, we should avoid anyone on either side of this process being surprised.

Also, I forget if we codified this somewhere or not, but bringing a repo into the openedx org will almost always result in the principal developer(s) of that code becoming core contributors with maintainer access to the moved repo. Following that guideline should reduce reluctance about the openedx org taking in new code.

I imagine this will be a recurring issue, as it will be quicker for any company to start a repo under its own org, even though it may be better for it to live in the openedx org. This is especially true for edX, who has created the most repos to date.

That is OK with me. I think it is natural for Open edX components to start their lifecycle within a firm's organization, only being installed into the platform as optional dependencies, until we deem the code "ready" to move into the core openedx org.

sarina commented 2 years ago

Also, I forget if we codified this somewhere or not, but bringing a repo into the openedx org will almost always result in the principal developer(s) of that code becoming core contributors with maintainer access to the moved repo. Following that guideline should reduce reluctance about the openedx org taking in new code.

I don't think it belongs in the CC OEP-54, because I think of that as almost a "how to be a CC" manual; the route of "making a bunch of code and having it moved to the org" falls under this OEP with a mention worthy in the maintainers OEP-55.

robrap commented 2 years ago

"If the default Open edX installation cannot run without it, it needs to be in the openedx org."

@kdmccormick: I think this comment and your notes are a great start. You'll still need to consider exceptions like any repos that have not been moved to openedx, but should have been based on your notes. Or, any new dependencies that slip through the cracks and are not optional. Also, you'll need to cover how to deal with MFEs, or new top-level services. Would it simply cover anything tagged to be included in the named release? Other?

Also:

  1. I think Django Plugins in edx-django-utils is close, but doesn't yet support IDAs outside of edx-platform. Do all IDAs allow for adding additional dependencies? We may want to document necessary work required to allow for such a plan.
  2. Does that mean that no one can merge requirements from any orgs within the community? Would you lint for that? (There could be exceptions of course.)
kdmccormick commented 2 years ago

Started on a very early draft: https://github.com/openedx/open-edx-proposals/pull/312

kdmccormick commented 2 years ago

Putting the draft down for now to focus on the Tutor work.

jmakowski1123 commented 2 years ago

Notes from Planning 3/7 - Partially blocked on OEP55 and waiting for feedback. Revisit at beginning of April.

kdmccormick commented 1 year ago

Overdue update: This will involve two OEPs (57 and 61), as well as several edits to existing OEPs. I wrote up an overview of the plan here: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3511091214/OEP-57+OEP-61+Update+Game+Plan

OEP-57 has entered review already: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3540713547/Open+edX+Proposal+57+Product+Offering

Once OEP-57 is merged, I/we can start on OEP-61 and the other OEP updates.

sarina commented 2 months ago

Update: OEP-57 is merged, but as discussed in https://github.com/openedx/open-edx-proposals/pull/393, we're in a holding pattern until we have firmer definition of Core Product. @kdmccormick What would you think if I revived a bit of what was done in #312 as like, the first part of OEP-61 that covers some of this stuff that Axim has basically already codified (core repos (for now by the definition provided above:

"If the default Open edX installation cannot run without it, it needs to be in the openedx org."

) as well as the mechanism of transfer action (including perhaps an addition of a forums notification and/or RFC as well as IP process stuff the authors will need to follow and addition of core contributor status).

I think that would be a good, scoped start to cover concerns of this issue, while leaving space to fill in more as Core Product is defined.

kdmccormick commented 11 hours ago

@sarina That sounds really reasonable to me!