Hi @maintainers! I’d like to rethink the way the maintainers program is organized.
In its current state, the maintainers program is not working very well, in my opinion. There are several issues:
I’m still a bottleneck for every change made in every Tutor plugin, and this is limiting our ability to release more plugins.
The list of maintainers is very static, although some maintainers have not been active at all for several months.
The Tutor forum should eventually be merged in the Open edX, which means that the “experts” and “moderators” role will become obsolete.
The contributions of maintainers are not very well recognized, which means that contributors do not have a great incentive to do their job.
During the Open edX conference last week in Lisbon, I’ve talked with many different people. I’m thrilled and humbled by the amount of work and innovations that happen in the Tutor ecosystem. I want to foster these initiatives even more.
In the past I have very strongly opposed adding core committers to Tutor. I changed my mind on this matter and I think that the project is now in a place where we can add core committers outside of Overhang.IO to the Tutor auxiliary repositories. I am not ready yet to add core committers to the main tutor repository. This might be a disappointment to some, but there is one main reason for that: currently the programming logic behind Tutor that handles configuration, template and CLI is intertwined with the deployment of the Open edX LMS/CMS. In the future, this will change and LMS/CMS deployment will be separate from “tutorcore”, which will then become a general-purpose tool for application deployment. To learn more about this project, have a look at this GitHub issue. I am not ready to onboard new core committers until we have achieved this split, because I want to be sure that I am in control of the project, at least until then.
I have found OEP-55, which is currently under review, very inspiring, and I think that Tutor can try to aspire to a similar (albeit less formal) implementation.
So here’s what I’d like to recommend:
Deprecate this forum by instead linking to the Open edX forum in the Tutor documentation.
Get rid of the @experts and @moderators roles. Existing @developers will be given priority if they apply as Tutor project maintainers. (see below)
Assign a single maintainer to every Tutor auxiliary repository. Each repository maintainer is in charge of triaging issues, answering questions related to the project on the forum, making improvements to the codebase and upgrading from one major release to the next.
Publicly acknowledge the contributions of maintainers by prominently displaying their name (and optionally affiliation) on the project README and in the project changelog. Currently, Tutor subprojects do not include a changelog, but this will change – and maybe creating a changelog will actually be the first task of the new maintainers. See this pull request to understand what I mean.
Maintainers will have git merge access to the GitHub repositories. Every pull request must have a single approval from either a maintainer or myself to be merged. If either the maintainer or myself requests changes, then a PR cannot be merged.
Create a clear set of guidelines for maintainers in the Tutor documentation.
Maintainers can step down from their role at any time, and this does not prevent them from joining back at a later time – on the contrary. Experience is a plus
Maintainers are expected to take time off and warn the community about it. In case of longer holidays (4+ weeks) we might want to find a temporary maintainer or replace the current maintainer. Such situations should be handled on a case-by-case basis.
Communication between maintainers and myself will be handled in a dedicated subcategory of the Open edX forum. This includes applications to become a maintainer.
Here is the list of Tutor repositories that would need a maintainer:
Not a maintainer, but moving Tutor discussion over to the Open edX forums sounds very appealing. Really appreciate all the thought that is being put into this, as well as the plugin system and dev environment updates.
I’m all for this @regis - I really like the way you’ve laid this out. Well thought out and community inclusive.
I’d love to know how tCRIL can assist in folding Tutor into the Open edX ecosystem a bit more. For starters, I am available as an Open edX forums admin to help with migration as need be.
Curious how much of this is going to be private vs public. I lean towards all public if possible, so future maintainers get a sense of what being a maintainer is like.
Hi @regis , thanks for wrap this up. Seems that Tutor has changed a lot since last year, sometimes it is difficult to catch up all the ideas in the behind (you are a really fast ). I think this may be one of the reasons which block me to work as a maintainer. I think it’s a good idea to assign maintainers to Tutor auxiliary repository as maintainers can just focus on the owned repository if they have very limited time.
Yes, I think that we should default to public conversations. Private conversations would be held by PM or email, when the need arises, but most of the conversations would happen in public. Maybe that some subcategory will be read-only for non-maintainers – I haven’t quite figured this out yet.
Hi @regis , I have not been active in the past months but I would like to join me to this effort andt take a road to understand how can I help more actively.Thanks in advance!!
The relationship between the Tutor and Open edX projects has always been an interesting one to me. @regis, I think that your independent leadership of Tutor throughout these years has led to it being reliable, focused, and quick-moving. Your concrete demonstration of how things could be done differently has challenged Open edX to be better, both in terms of its technology and its accountability.
That being said, I like it when we work together Your expansion of merge rights and your plan to join the forums together sounds excellent! If there’s room for me, I would have interest in maintaining a repo, particularly the plugin cookiecutter.
A few small questions:
Will maintainers gain merge access to just the repository that they maintain, or to all the auxillary overhangio repositories?
Given the new merged rights, would you want any community-developed plugins (for example, my CourseGraph plugin) to move into the overhangio org?
This is really great to hear @regis ! It would get Tutor a bit better integrated with the rest of the Open edX project I think, so that’s a great step to have - hopefully one of many! Imho opening the Tutor project to more contributors doesn’t make you risk your leadership of the project – on the contrary.
Btw, will you apply OEP-55 to Tutor’s auxiliary repositories, or do you still see the Tutor maintainer program as separate from the Open edX maintainer program?
The former. I’d prefer if there were at most two people with commit rights for every repo (the maintainer and myself). If we have N plugins, then we’ll have N maintainers, and I don’t want to grant a large number of people access to every repo.
No, for at least two reasons:
I don’t feel up to it.
It would not bring any value to the plugin or to the community.
Ned asked the same question, and I also thought about it. I think it would be great, but the maintainers program as described in OEP-55 is really designed for repositories hosted in the “openedx” GitHub organization, both for legal and technical reasons. Now is not the right time to ask for a complete rewrite to encompass repositories outside of the openedx org.
Would there be a lot of changes to make? In any case since OEP-55 is now merged in the provisional status, if we want to explore this, it could be in a follow-up PR? It could also be worth posting about it on the official forum or comment on oep-pr#290, this way we could loop in Ed, @sarina and Jeremie?
I don’t think any OEP should presume that it governs associated Open edX projects. But if Tutor wants to adopt OEP-55 particularly, I think that’d be great.
). I think this may be one of the reasons which block me to work as a maintainer. I think it’s a good idea to assign maintainers to Tutor auxiliary repository as maintainers can just focus on the owned repository if they have very limited time.