Proposed Maintenance/Maintainership Policy

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.)

For context, please be familiar with OEP-55: Project Maintainers and in particular “what maintainers do”. In short:

  • “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.

You can see who the maintainer of each component is on Backstage at https://backstage.openedx.org/

Draft Proposal:

As OpenCraft, we should try to take on the maintainership role for the following types of Open edX repos/components, in order of priority:

  1. Components that need a maintainer and are important for our clients or our infra.
    • e.g. Aspects (important for our clients, important for the community)
    • e.g. Harmony (important for our infra / our hosting, important for the community)
  2. Core components that we developed.
    • Specifically: blockstore, openedx-tagging, content libraries, Drag & Drop XBlock, Pluggable Discussions API
    • This can include things that we didn’t develop but which we majorly refactored, like the XBlock runtime [BD-13]
    • But, if at some point our clients stop using/developing this thing, we may need to hand over maintainership.
  3. Core extendable interfaces that we use to develop extensions for for our clients, if they need a maintainer.
    • e.g. XBlock
    • e.g. any MFE theming/extension systems that may be developed
  4. 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.

Relates to: Seeking Maintainers
Ticket: MNG-4088

5 Likes

These priorities make sense to me.

I can’t see any components here that don’t have an Owner… Are un-owned components omitted from backstage?

Yea, currently repos that don’t have an official maintainer are not listed. The full list I’m working from is here: Release repos and Maintenance Priorities - Google Spreadsheets

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.

1 Like

@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 Also FYI the notes, recording and transcript of the maintainers meeting from yesterday are available at https://openedx.atlassian.net/wiki/spaces/COMM/pages/4031578215/2024-02-01+Meeting+notes (though no Otter, while an issue with it was being investigated). It’s only the beginning of that conversation, but it was a productive meeting.

@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.

Also FYI: Maintainers Requirements Update - Maintainers - Open edX discussions

@antoviaque I’ll try to get that put together today or Monday.

1 Like

Actually, from working on the list I have a new proposal:

  1. 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
  2. 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.)
  3. 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.

2 Likes

I filled out some fields in Column H and left a few comments in Column G.

1 Like

Thanks @Agrendalath, that’s super helpful.

@antoviaque Ping that a draft list is available ^ in case you hasn’t seen it.

@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.

openedx/frontend-app-communications
openedx/frontend-app-discussions
openedx/frontend-app-learner-record
openedx/frontend-app-profile
openedx/frontend-template-application
openedx/edx-rest-api-client
openedx/edx-notes-api
openedx/openedx-atlas
openedx/openedx-translations
openedx/xblock-skill-tagging
openedx/frontend-app-ora-grading
mitodl/edx-sga
openedx/acid-block
openedx/frontend-component-cookie-policy-banner
openedx/frontend-lib-special-exams
openedx/help-tokens
openedx/openedx-calc
openedx/openedx-chem
openedx/tinymce-language-selector
openedx/frontend-app-ora
openedx/frontend-app-shell
openedx/frontend-components-tinymce-advanced-plugins
openedx/openedx-wordpress-ecommerce
openedx/frontend-app-support-tools
openedx/react-unit-test-utils
openedx/edx-bulk-grades
openedx/openedx-i18n
openedx/django-lang-pref-middleware
openedx/django-pyfs
openedx/django-user-tasks
openedx/i18n-tools
openedx/edx-django-sites-extensions
openedx/event-tracking
openedx/super-csv
openedx/typescript-config
openedx/olxcleaner
openedx/django-wiki
openedx/edx-celeryutils
openedx/edx-enterprise-data
openedx/edx-enterprise-subsidy-client
openedx/edx-rbac
openedx/frontend-enterprise
openedx/frontend-app-enterprise-public-catalog


Not as important but still interested to know about:

openedx/edx-tools
openedx/frontend-app-learner-portal-programs
openedx/xss-utils
openedx/edx-django-release-util
openedx/cc2olx
openedx/edx-cookiecutters
openedx/edx-repo-health
openedx/frontend-app-program-console
openedx/frontend-app-programs-dashboard
openedx/pytest-repo-health
openedx/pytest-warnings-report
openedx/schoolyourself-xblock
openedx/staff_graded-xblock
openedx/tutor-contrib-coursegraph
openedx/xblock-free-text-response
openedx/xblock-image-modal
openedx/xblock-in-video-quiz
openedx/xblock-qualtrics-survey
openedx/xblock-submit-and-compare
openedx/code-annotations
openedx/openedx-slack-invite
openedx/openedx-webhooks
openedx/platform-roadmap
openedx/enterprise-access
openedx/enterprise-catalog
openedx/frontend-app-ecommerce
openedx/frontend-app-payment
openedx/stylelint-config-edx
openedx/mdrst
openedx/onboarding-course-introduction
openedx/openedx-con-materials
openedx/openedx-conference-website
openedx/pr_watcher_configuration
openedx/pr_watcher_notifier
openedx/repo-tools-data-schema
openedx/training-courses
openedx/webhook-test-repo

Also wondering if we use any of these parts of edx-platform:

edx-platform/openedx/features/announcements
edx-platform/lms/djangoapps/bulk_email
edx-platform/openedx/core/djangoapps/learner_pathway
edx-platform/lms/djangoapps/mobile_api
edx-platform/openedx/core/djangoapps/catalog
edx-platform/openedx/core/djangoapps/dark_lang
edx-platform/openedx/core/djangoapps/lang_pref
edx-platform/common/djangoapps/course_modes
edx-platform/common/djangoapps/entitlements
edx-platform/lms/djangoapps/ccx
edx-platform/cms/djangoapps/xblock_config

@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.

Yes, but you have to actually turn on the wiki and use it in the course. I’m asking if any clients use it.

That sounds like something we can fix if they want us to!

That is right. It’s is not a priority for the client right now.