Historically many major upgrades have been run by 2U and work for the upgrades has been done by the Arbi-BOM and FED-BOM teams. This made a lot of sense when all repositories were de-facto maintained by 2U. However, since OEP-55 was introduced, responsibilities for maintenance have been slowly shifting across multiple people and organizations throughout the Open edX community. To support this new situation, I think we need a new Maintenance working group that can help build out and coordinate a more distributed maintenance process. Here are my thoughts on the group so far but I’d love to hear from others.
Working Group Goals
Ensure the repositories that support the Open edX core product offering are well maintained.
Support maintainers of Open edX Repositories
Find/Replace maintainers as needed
Prioritize and coordinate major dependency upgrades
Discover and prioritize improvements to make the Open edX ecosystem more maintainable
Develop and document best practices for using maintenance tooling such as Dependabot and Renovate and serve as a center of expertise for such tools
Good question - is this a formalization of the maintainership pilot, graduating it from its pilot phase to a proper working group?
Would some of the rules change? And would the existing rules be applied to all members equally now - for example, in regards to the requirement for maintainers to be core contributors?
Another practice that could be improved would be to assign all commit rights through the core contributor nomination & review mechanism, vs being automatic when joining specific organizations - this way everyone would have the same incentives to become maintainers: to be able to decide on what gets into the official code base (by doing the work of maintaining it afterwards).
Maintenance here means the same thing as what we meant for the maintainership pilot for the most part. The part that I think is not surprising but is an expansion of meaning is that it should include any necessary upgrades as a part of the work the maintainer would be responsible for. Historically, this has been led by 2U but as more and more repos are not by default editable by 2U, this approach makes less sense.
I’m not sure about restricting access or rules conformity. My thought is that anyone willing to step up to maintain a project that needs maintenance is essentially asking for CC access along with taking on some accountability. My goal is to expand access to more people who can do the work of maintaining things. If we find that people are abusing their commit rights to work against building a long term maintainable project, we should handle those on a case by case basis but I think that is a related but separate problem from making sure we have a good public maintenance process.
To simplify the commitment, I liked the way @e0d suggested capturing a complexity factor for the repositories being maintained, to estimate the volume of recurrent work.
I don’t know of anyone abusing their power. When I suggest to apply existing rules to everyone for acquiring merge rights, I don’t mean removing anyone’s existing merge rights, it could make sense to grandfather in existing permissions. But for new people or new employees joining the project, getting everyone to acquire merge rights like everyone else in the community, by becoming a core contributor or a maintainer. Everyone could still get permissions like before, but would have to go through the community process/training. If we are going to ask the community as a whole to step up our contribution to the project maintenance, putting ourselves on equal footing proportional to our contribution level would be a good way to align incentives.
It sounds like there is no general opposition to starting up this new working group so I’m going to get the ball rolling on that.
I think this makes sense but I need to talk through it a bit more with legal and others and figure out what might make sense moving forward in terms of process.
