How to share maintenance burden?

[nedbat]

It's a lot of work to keep dependencies up-to-date, upgrade Django, squash warnings, keep the tests running, and so on, in our repos, especially edx-platform. How can we equitably share the burden?

[hurtstotouchfire]

Is this just a question of how we time our contributions? Presumably we will continue fixing these things for our platform.

[nedbat]

In the past, edX has done almost all of the maintenance chores, because we had to for our own business. But the community benefits from that maintenance. Can we share that work with the community so that edX resources can spend more time on substantive changes?

[sarina]

There is some prior art, @nedbat , with INCR and the django upgrades project. It'd probably be useful to link any resources/planning/learnings from those projects.

[jmbowman]

I took a first stab at writing up some guidelines for this, including learnings from previous attempts: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3467640837/Code+Maintenance+Parallelization . Maybe get some feedback on what's here before doing further work on incentives and such?

[nedbat]

This issue is too vague to make progress on. Can we split/groom it into chunks that are more accomplishable?

[jmbowman]

Breaking it down a little:

• We created a bunch of issues in public-engineering labeled "help-wanted" and "maintenance". I just added a link to them in https://openedx.atlassian.net/wiki/spaces/COMM/pages/941457737/How+to+start+contributing+to+the+Open+edX+code+base , but what else can we do to raise awareness of such issues and create incentives to chip away at them?
• One idea was to create forum badges for type / count of maintenance contributions.
• The maintenance pilot is helping with this by enabling maintenance of more repos to move to organizations other than 2U.
• I'm working on better tracking of cross-repo and cross-team maintenance work in https://github.com/orgs/edx/projects/17/views/1 , with process automation ideas sketched out in https://docs.google.com/document/d/1bja3xvWZ3mrZ6AVDKPXlGTsq9EeWvcZIchEIXyMbz0w/edit# . The primary goal is to get things unstuck within 2U, but it could well help with cross-organization coordination also. This is part of the upgrade project template that I plan to complete in time for the Open edX conference.

[jmbowman]

I added some additional notes in https://openedx.atlassian.net/wiki/spaces/AC/pages/3467640837/Code+Maintenance+Parallelization#Recruiting-Help-with-Maintenance-Tasks . Asking Core Contributors for help is straightforward enough, but I suspect doing the other ideas decently would require a point person (or maybe working group) regularly dedicating a significant amount of time to identifying and coordinating opportunities for recruiting volunteer developers.

[jristau1984]

I also think that for repos that are not edx-platform the maintainership effort will help make this a lot more balanced. However, I think one item that effort could benefit from is 2U being explicit about what repos we expect to be maintained by 2U vs ones that are not, so maintainers can be identified as early as possible.

[jristau1984]

This problem has transferred to the new Maintenance Working Group, and 2U has relinquished maintainership of many non-edx-platform repos.