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

[sarina]

• What organizations do (and can and should) hold code that belongs to the project?
• How do we govern code moving in and out of the project? (note: OEP-14 Archiving Repos touches on the mechanics of repo transfer out of the openedx org).
  • Are community organization repos governed by OEPs?
  • How to handle repos moving into the Open edX project that have not followed OEP guidelines?

[kdmccormick]

Thanks for capturing this 🔥

[robrap]

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]

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:

• The converse doesn't necessarily apply: the openedx org will contain some non-essential components.
• Of course, this does not third-party libraries like Django.

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]

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]

"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]

Started on a very early draft: #312

[kdmccormick]

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

[jmakowski1123]

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