I would like to propose a policy for how and when our Core Contributors should be maintainers of a particular Open edX repo/component. (This is only for repos in the openedx GitHub org; for OpenCraft stuff, we are the maintainers already.)
“All non-deprecated components of the Open edX project must have one or more named maintainers.”
The maintainer(s) of a particular repo/component has an additional level of responsibility in addition to the usual coding CC responsibilities, including: communicate with the community, select and approve Core Contributors, ensure that maintenance work is done, ensure bug reports are read and quickly responded to, understand the architecture and future direction, keep docs up to date, and more.
e.g. any MFE theming/extension systems that may be developed
Non-Core components that our clients need, if they need a maintainer.
e.g. edx-enterprise? (if it needed a maintainer)
Anything else would be lower priority for us (I think - let me know if you have other thoughts). We could still offer to maintain it if a maintainer is needed and we have capacity, but it’s low priority.
Example: xblock-google-drive (not developed by us. Not sure if any client uses it?) (maintained by @Piotr)
Example: xblock-image-explorer (we developed it. Not sure if any client still uses it?) (maintained by @Piotr)
What’s the budget for these things? The time for these maintainership duties comes out of the regular budget/commitment of Core Contributor hours.
This is all just a draft for now. Please let me know things that I missed or got wrong, as well as your thoughts.
The prioritization that I did in that sheet is mostly from my perspective of where to focus Maintenance resources from a project perspective and not related to the prioritization that Braden suggested above which makes sense from your business perspective.
@braden This looks good to me overall, thank you for coming up with a proposal!
One exception though:
We don’t know yet exactly the breakdown of the repos that are coming up unmaintained out of the 2U changes, but I’m expecting that it will be a lot - if not immediately, over time, especially if they keep divesting. Right now we need to make sure that the core itself will be properly maintained. Also, we want to fix the elephant factor on the project as a whole, including the core, so we should pick up a good piece of it - that will help ensuring it is done at all, and might inspire others to do the same. Axim might pick up a lot of it, but it wouldn’t be good to have them just replace edX as the elephant there.
So I would remove the “Non-core” qualifier from your point 1) - to say simply “Components that need a maintainer and are important for our clients or our infra.” It could include core or non-core elements. I agree that it’s important to continue maintaining Aspects & Harmony - but we now need to pick up core elements. Later if we see that the core maintenance looks secure, we can start looking at non-core elements then?
Also, from this perspective, what do we need to get a first list of core repositories that we can offer to take the maintainership of?
@braden Btw when will we have a list of the repositories we are interested in maintaining? @feanil mentioned in the maintainers meeting today that he will be cross-referencing what the different providers are interested in, and check if there are overlaps or missing parts, so it could be good to give a list for OpenCraft too.
Actually, from working on the list I have a new proposal:
Components that need a maintainer and are directly important for: any our clients, our hosting/infra, or our development process.
e.g. Aspects (important for our clients, important for the community)
e.g. Harmony (important for our infra / our hosting, important for the community)
e.g. extendable interfaces like XBlock API, REST APIs, or theming
Components that we developed or majorly contributed to, but aren’t necessarily currently used by our clients. Also, dependencies of anything in Priority 1 (i.e. things we don’t really care about directly but they’re currently required for something we do need) (e.g. we don’t use proctoring but we consider edx-proctoring a priority 2 because it’s required for the “timed exams” feature, which we do need.)
Anything that we think our clients might use, or that is currently used but we don’t really want to support in the future would be the third priority for us. We could still offer to maintain it if a maintainer is needed and we have capacity, but it’s low priority.
Here is a draft list. @Agrendalath , @farhaan , @kshitij and anyone else - could you please help me my filling out column H about which clients use things, add notes in Column G, and add any comments you have in general?
Note that Column D is the Axim priority from @feanil and Column E is the proposed OpenCraft priority.
@braden Yup I’ve had a quick look, I was planning to check it more closely once you had the answers you needed. Is it ready? If not it’s worth chasing people for the answers, to keep this moving.
@antoviaque It will probably evolve a bit, but I think it’s ready for wider review. Also I’m not yet sure what our capacity is, so just because it lists our priorities doesn’t mean we can take everything on the list on.
@braden OK. I have done a pass, and made some comments inline, but aside from those it looked good overall! Thanks for the work.
And agreed for the capacity - it might be worth figuring out what we can fit in the core contributors’ budgets and availability. That’s actually worth starting to estimate - even if we don’t know yet which repos we’ll be maintaining exactly, know who has capacity and how much will later help driving decisions. If we have core contributors already well positioned to maintain some of the priority 1 repos, then we should probably highlight those.
Also, we might need some kind of point or t-shirt size estimates for the repos themselves - some are very small, others very large.
Could all the epic owners / client managers please review this list and let me know if your clients are using any of these things? You can tell me in a comment on MNG-4088 , or reply here, or update my spreadsheet directly. Even if your client(s) aren’t using any of them, please let me know so I know you reviewed it.
@braden FYI at the maintenance working group today, @feanil and Felipe started the process of taking maintainership of repositories, by starting to do nominations in the forum - can we do the same? To get started now, begin 2-3 of the ones we would be the most interested in, or sure to end up maintaining?
Feanil has added eduNext’s options to his spreadsheet. Seeing OpenCraft missing there, I have asked him to do the same for your spreadsheet, he said he wasn’t sure how to add our list, since we had a list of priorities. I told him to start by adding our priorities 1.
I think this is used indirectly by hooks and filters, and by Aspects (aka. OARS). IIRC, it’s installed in edx-platform.
Isn’t this used by edx-platform for wiki?
Not used by any clients directly, but by us for creating new XBlocks, plugins, etc.
Doesn’t work in learning MFE, because learning MFE let’s LMS render XBlocks and embeds it via an iframe, and this XBlock is not designed to be embedded through an iframe. If it was working, one of the clients would be using it.