maybe I should drop just these requirements, and instead make sure they're in the list of maintenance responsibilities that OEP-0055 lays out.

Agree. I would say in the top-level bulled

it has assigned `maintainers`_ who continually meet the responsibilities defined in OEP-55

I realize that these criteria leave a gray area between repositories that must be in the core, but don't follow the standards for repositories that may be in the core.

I have some thoughts on how to reconcile this but am curious what others think.

I think I see what you're saying, but, if something is already a dependency of an Open edX release, it can't just be removed, so this feels to me like a grandfathered-in situation. I could see at line 91 adding something like:

We recognize that, at the time of writing, there exist repositories that must be in the core, but don't follow the standards for repositories that may be in the core. These repositories will be identified by the Core Contributor team, and go through a similar review process as defined above - with the express goal of finding active maintainers for each repo.

Nit: According to the OEP spec, you should be putting proc in the document name (oep-0057-proc-core-repositories, see https://github.com/openedx/open-edx-proposals/tree/master/oeps/processes - all (except oep-1 lolol, and oep-54 where I also missed the notice) and https://open-edx-proposals.readthedocs.io/en/latest/processes/oep-0001.html#oep-header-preamble)

Agree. I would say in the top-level bulled

it has assigned `maintainers`_ who continually meet the responsibilities defined in OEP-55

I think I see what you're saying, but, if something is already a dependency of an Open edX release, it can't just be removed, so this feels to me like a grandfathered-in situation. I could see at line 91 adding something like:

We recognize that, at the time of writing, there exist repositories that must be in the core, but don't follow the standards for repositories that may be in the core. These repositories will be identified by the Core Contributor team, and go through a similar review process as defined above - with the express goal of finding active maintainers for each repo.

As far as the process goes - we've been having trouble getting more than 30-40% of any given core contributors to participate in any CC program survey or standup we arrange. I think it would be good to, like the CC nomination process, define a minimum number of votes. The process should be public, where anyone can weigh in but only CCs get votes. Time-bounded is good. Would we specifically want maintainers to weigh in (who are already CCs)? Defining a rough template of how a repo "applies" for admission may be nice: repo name, purpose, core development team, who in the community is using it, plans for future development, and plan for maintainership all come to mind.

I wonder if we need to just define a couple of general mechanisims for community voting and then we can refer to them in all the OEPs where we need that kind of input.

So far, we've got:

• Minimum X +1s where a single -1 can shutdown the proposal.
• Lazy Assent: Proposal is accepted by time X given no -1s by time X
• It feels like there are more, but maybe just variants on these two?

I think having two voting mechanisms, "affirmative consent +N" defined as requiring N positive votes and no negatives, & "lazy assent: X days" as a time-bounded default acceptance of X days given no negatives, makes sense to me! What do you think would be the best way to define these? The absolute shortest OEP ever? 😁

nit: before the bullets you use repositories... which, so your verbs at the beginning of bullets should be plural. eg, s/is a good target/are good targets/

I used singular verbs because a smaller set is the subject and a set is a single item. But if this still reads awkwardly then I can reword it.

Ah, got it. Yeah for some reason it does read awkwardly (to me); I actually think then the problem is the which. "we wish to enumerate a smaller set which is a good target" vs "we wish to enumerate a smaller set that is a good target"

You can also ignore me if you disagree.

I agree but also agree it's not a blocker. Offered a suggestion if you want to fold it in, @kdmccormick

🤔 migrating hundreds of GH issues will be a ton of fun!

Q: does this relative linking work in the RTD site? I've only seen explicit links in other OEPs.

But won't this document define that process?

Yeah. I should have included the whole Considerations section in the PR description, not the OEP. It's meant to be a conversation with the folks previewing this OEP, not contents of the final OEP itself.

I'm hopeful all of tCRIL will have gone through the CC nomination process before this lands (so tCRIL folx - get that nomination thread going!)

I wonder if we need to just define a couple of general mechanisims for community voting and then we can refer to them in all the OEPs where we need that kind of input.

So far, we've got:

• Minimum X +1s where a single -1 can shutdown the proposal.
• Lazy Assent: Proposal is accepted by time X given no -1s by time X
• It feels like there are more, but maybe just variants on these two?

I wonder if it will be valuable to have a second org for the looser but still close to core repos. For example repos tha aren't required but that are defacto the way you do X if you don't have other opinions? Even if X plugs into an interface.

The idea of openedx-contrib as an org popped into my head as I was reading this so just mentioning it.

I think it might be easier to use topics to tier the repos into different categories.

I just feel like it would be painful to maintain sync with users, groups, settings and such across a second org. Or dealing with moving repos around between those orgs.

We only use topics on a few repos now, and we use them in an inconsistent manner. But we could be more disciplined about it and make it something that folks could reasonably filter on, e.g. https://github.com/orgs/openedx/repositories?q=topic%3Afrontend&type=all&language=&sort=

I think it's worth holding off on a specific solution for this to see how things shake out with the maintainers and core changes. It might be that each contributing org maintains its own separate collection, or that the peripheral libraries fall clearly into guilds by topic. I'm just spitballing here but basically I think we should shift these core things and then see what the new emergent patterns are.

One small update on this idea--as 2U starts thinking about pilots for OEP-55 I'm realizing that one of our pain points is the way that our internal "ownership" spreadsheet scope is defined, which is basically "anything on the openedx or edx orgs". Arguably that definition will not scale, but I also can't think of a good alternative. Maybe org-based maintainership gets encoded as a tag? e.g. I can filter for all the repos currently maintained by 2U. That would allow us to continue to automate some of our ownership stuff without having to do weird things like duplicate the entire maintainer roster in our spreadsheet (which currently only lists teams internal to 2U).

Nit: I think "unspecific" means vague/not well defined, and that what we'd want here is "not specific to Open edX". (Or maybe "nonspecific"? I never use that one.)

Instead of saying that there is a Core with some repos that must be in Core and some that may be in Core, with (Core == openedx GitHub org), would it be useful to define tiers of repos that will end up in the openedx GitHub org? Something like:

• Core
• Supporting
• ...?

I realize that's somewhat at odds with the notion of aligning this language to "Core Contributors". I'm wondering if we have other kinds of information we want to convey in how we group these repositories–how actively they're developed, for instance. We've also maintained a number of forks of external open source projects over the years for upgrade or compatibility reasons, and I think it's confusing to lump that in as "Core".

I am not sure if directly aligning this with the "core contributors" language is a good idea if there isn't a 1:1 mapping. I like Dave's tiers idea, or even some qualitative schema like github topics. I think we would need to clean up and track our topic schema for sure, but it could provide a nice way to, say, group together a set of MFEs that are part of a consolidated effort to deprecate something (and are thus optional but collectively required if you remove the deprecated app). I'm thinking specifically of the instructor dash MFE project that 2U and OpenCraft will be collaborating on.

per Sarina's comment

Where are we at on this for Nutmeg?

Nutmeg master branches were created on Monday. There are four MFEs in the edx org included in Nutmeg, and two other repos that should probably be removed from the tagging process.

This only applies to code repos. We also have project repos (working group backlogs, etc).

The big picture of this OEP as I understand it is:

• Define criteria for a set of repos to be called Core, and
• Make that set be the same as the openedx GitHub set.

I'm wondering if it's a good idea to join those two ideas together. As Dave commented, orgs imply access administrations, and as Sarina pointed out, there will be data to migrate if some repos have to be moved.

Couldn't we find other ways of clearly indicating what is Core? As written, this OEP will require making yet another organization (or maybe more than one?) The phrase "open edx" refers to a software platform, but also a project. Why shouldn't the openedx organization include repos that are in the project but not the platform?

It might make the proposal more concrete if we could see a dry-run of what would have to move. What repos need to move into the openedx org, what repos would need to move out, and where they would go.