Two questions for better understanding:

They review patches like @Mainframe98 [1], @MGChecker, @D3r1ck01 , @SamanthaNguyen, and others.

Have these folks explicitly agreed on basically becoming a "fallback" for random ancient codebases?

Why is this approach wanted, instead of the current approach of archiving such repositories and also abandoning any proposed patches?

In T200322#4450174, @Aklapper wrote:

Have these folks explicitly agreed on basically becoming a "fallback" for random ancient codebases?

No, But these users are doing the review. Taking an example of @Mainframe98, He is the person who reviewed many many extensions registration patches (See Link Above). But can't merge any of those patches due to be not having +2 rights. He is a good review contributor of ext-reg if you can see his reviews.

Why is this approach wanted, instead of the current approach of archiving such repositories and also abandoning any proposed patches?

Quick answer: Here the main intention is not to stop extensions being the archive. It will focus on the archive's root problems. means Why are extensions becoming unmaintained? (Will give briefly with cases)

I am both a person with +2 on mediawiki/* and do a lot of Projects-Cleanup job in archiving extensions and stuff that is unmaintained, tasks that are mentioned in this ticket and I think I can humbly add my considerations.

I'd prefer not to break the mediawiki group, and would advice instead that more people apply or be nominated to Repository-Ownership-Requests for mediawiki/* +2 rights or the relevant extension-$extension_name if they want to focus just in an extension or some of them.

To enact this proposal this'd require amending several project configurations and manually adding the group to a lot of extensions as 'owner'; and that is a lot of work. Also, if this proposed new group is going to be only for a subset of extensions as proposed, having to keep an eye on which ones do qualify regularly will require more work too; for a little gain. According to the mediawiki/extensions .gitmodules file there are currently 787 extensions. I am sure a bunch of them does not receive a code commit other than translatewiki.net/build updates/general housekeeping in that timespan.

I do not see why the current mediawiki group cannot take care of the situation as described.

Also, I do not see archiving as a bad idea when the extension is unmaintained, specially if the extension does require a lot of work to get it back to work or has security issues and there's no developer that knows how to fix the extension or has the time and/or knowledge to do so. While we provide a software in a AS-IS basis, we also somewhat commit ourselves not to continue to offer bad, nonfunctional or dangerous software.

As such I do not support this proposal and suggest instead that people that are insterested in maintainin an extension or a set of extensions apply for the relevant existing groups.

In T200322#4450395, @MarcoAurelio wrote:

I am both a person with +2 on mediawiki/* and do a lot of Projects-Cleanup job in archiving extensions and stuff that is unmaintained, tasks that are mentioned in this ticket and I think I can humbly add my considerations.

I'd prefer not to break the mediawiki group, and would advice instead that more people apply or be nominated to Repository-Ownership-Requests for mediawiki/* +2 rights or the relevant extension-$extension_name if they want to focus just in an extension or some of them.

I agree 100% with MarcoAurelio. If people are trusted enough to have +2 across a ton of abandoned extensions (which likely includes some Wikimedia deployed ones), then I think they're trusted enough to have it across all of mediawiki/*.

If any of the people mentioned above are interested in +2 access, I'm happy to review their reviews, work with them and nominate them for it.

I welcome the idea of more actively requiring active maintenance for extensions, such that they are consistently archived after a set period of inactivity (the current span of 5 years was imho never formally adopted, if we do, I'd propose something closer to 3 years).

At the same time, I also welcome the opportunity for extension maintenance to be transferred. However, similar to @MarcoAurelio's, I have two concerns:

• If we create this group, I would hope this is a group for actual maintenance that involves improving the extension and address bug reports. Not just keep-alive against ecosystem-wide deprecation and migration. I do not think that cleanup-only is a worthy use of volunteer time given the state of those extensions. Such energy would be better to spend elsewhere. Cleanup-only would also mask deeper problems of bit-rot given we would likely not thoroughly test and understand each extension. Meanwhile, it would become harder to see which extensions are truly unmaintained. Also note that this will not work without continuous involvement from Gerrit admins and other people, who's time and energy should also be considered.
• If we move or extend ownership over an extension's repository beyond mediawiki/ for non-WMF maintained extensions, we may want to start thinking about how to formalise this process in a way that also involves the original maintainers. There is a lot more to software development than just the quality of individual code contributions. E.g. consider API design, UX, and product roadmaps. I do not think we should add maintainers (making non-trivial changes) to someone's project without their involvement. Perhaps after 5 years of inactivity the name can be transferred/released for re-use, but before that we should (in my opinion) attempt to contact the original author(s) and/or encourage forking under a different name.

To draw an analogy, if I publish a plugin to wordpress.org, I'd be surprised and shocked if after a year, someone could (without my involvement) take over the package and affect the package's users when they upgrade.

In T200322#4450395, @MarcoAurelio wrote:

I'd prefer not to break the mediawiki group, and would advice instead that more people apply or be nominated to Repository-Ownership-Requests for mediawiki/* +2 rights or the relevant extension-$extension_name if they want to focus just in an extension or some of them.

Then sir, You should need to see T193049. This was my first approach. I filled this task for MGChecker 3 months ago. What should I need to do next? Please suggest me.

I do not see why the current mediawiki group cannot take care of the situation as described.

• https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PhpHighlight/+/409569/ (10. Feb 2018)
• https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AllTimeZones/+/409624/ (11. Feb 2018)
• https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MassEditRegex/+/409733/ (12. Feb 2018)

Current MediaWiki group have most of MediaWiki engineer. And They don't have enough time to review patches of Non-WMF deployed extensions.

In T200322#4450779, @Legoktm wrote:

If any of the people mentioned above are interested in +2 access, I'm happy to review their reviews, work with them and nominate them for it.

Sounds good, I sent the email some users. and waiting for their answer.

I am apologizing for my bad English.

@Jayprakash12345 With regards to T193049 you know that I am not a Gerrit Administrator so I don't think I should be adding other people as 'owners' of extensions even if in some cases I am technically able to do so (the few cases I do are when I am creating new gerrit repositories as part of my Gerrit Manager role) [if that approach is incorrect and I am allowed to add people as long as they successfully pass an application then I am more than happy to help there too].

As for the patches you mention, the core rule of +2 is to only merge stuff one is qualified to review. I am not qualified to review any Extension Registration patch for many things, the main is that I don't have a way to test those (ie: MediaWiki-Vagrant or a wiki); although I appreciate that you added me to those so I can keep learning.

Thanks.

While I'm unsure if this proposal is the way to go, I think it has a point.

There are many extensions that are what I call semi-maintained, meaning that their owner (with +2 permissions) doesn't actively improve the extension anymore and gets only active if it stops working entirely or once a year or so. There are two types of these extensions:

1. Extensions that are widely used in non-WMF wikis. It's a huge problem if there is no work at all to keep them working in a way that is up to date, because many wikis depend on them working as specified. If they break and the owner is completely unreachable, some guy with global +2 permission puts out the fire (or if someone is poking them really much)
2. Extensions that are kind of nieche. It isn't that important that they don't stop working, if someone cares they're probably fixed after a few months.

To get an idea which extensions is of which type, WikiApiaray can help.

In both cases there are cleanup tasks concerning problems similar to extension registration, replacement of obsolete functions, and removal of obsolete backwards compability code, that need to be done to keep them working, but noone is there to merge the corresponding patches. This is really frustrating for the contributors, as they sit months on done patches with noone merging them. They try to poke other users with +2 permission, but this isn't always successful as well. This is particularly annoying for cleanup patches like noticed above, and I don't think it should be like this, as it keeps neither developers nor users of the extensions happy.

I have got two patches that are 3 months old and didn't get any attention myself in some extensions to do migrations like @Jayprakash12345 does and can understand his frustration really well. On the other hand, I understand the issues @Krinkle mentioned. I don't think it's actually possible for most people (me included) to spend the time required to actually spend the time required to really improve a larger count of extensions. While it's quite possible to work on a few extensions and get a good idea how they work (I chose to do so for Variables, one of the 10 most used non-WMF wikis), this just isn't doable.

Nevertheless, I think it isn't a bad idea to have people to have people who specialize in merging cleanup patches like mentioned earlier. For instance, a complete migration to extension registration is wanted (as suggested by the wall of superpowers), but you can notice a lag of reviews slowing this down. In situations like that, people with permissions like this can help. Please note that we're talking about bugfixes and cleanup here, not about imporant design changes.

However, personally I think it shouldn't be that difficult to become co-owner in a widely deployed extension if the original owner is inactive. They can quite often use further development. Moreover, I don't think you are entitled to an extensions just because you created it long ago.

In T200322#4451586, @MarcoAurelio wrote:

@Jayprakash12345 With regards to T193049 you ....... learning.

Sir, I am not blaming you or someone. I know wmf engineer have the busy schedule. Therefore I want to make this group.

• Person who has 10-25% amount of trust can get +2 on extension-{par}.
• Person who has 75% amount of trust can get +2 on mediawiki/*.

Now, what about the person who falls between 25-74% amount of trust? and are reviewing patches by CR+1. How will you tackle those extensions problems which are widely deployed but not have the active maintainer?

I am a person who enjoys uploading patches, not only here But also places as well. I catalyzing the other to review my patches. I wanted to upload thousands of patched for ext-reg. But I hanged my work because no one cared to review this type of patches.

I can also understand the frustration, but I don't think creating a new group is going to solve the issues if we need to have someone (a Gerrit administrator in most cases, a scarce specimen :-) ) to add it to hundreds of extensions, then get to maintain it from time to time. Let's just stick to the current groups.

I also note that there's E926: Code Review Office Hours that have sometimes helped me in getting those kind of cleanup patches reviewed and merged. The weekly WMDE's technical advice meetings have helped me too. With regards to the Office Hours, sometimes someone pays attention to them, sometimes not though. Maybe we can have more people involved there?

If there's shortage of manpower and there are people qualified to do the job, I'd be more than happy to support them for mediawiki/* access or for any extension-$extension_name accesses they need.

In T200322#4450238, @Jayprakash12345 wrote:

In T200322#4450174, @Aklapper wrote:

Have these folks explicitly agreed on basically becoming a "fallback" for random ancient codebases?

No, But these users are doing the review. Taking an example of @Mainframe98, He is the person who reviewed many many extensions registration patches (See Link Above). But can't merge any of those patches due to be not having +2 rights. He is a good review contributor of ext-reg if you can see his reviews.

I'd prefer to propose Mainframe98 for +2 rights in the mediawiki group in that case. :) It is a problem though that we lack a good workflow to systematically realize very active and skilled developers, see T199385: Develop a workflow to recommend / propose developers who should have +2 rights in Gerrit

Why is this approach wanted, instead of the current approach of archiving such repositories and also abandoning any proposed patches?

Quick answer: Here the main intention is not to stop extensions being the archive. It will focus on the archive's root problems. means Why are extensions becoming unmaintained? (Will give briefly with cases)

Code review is a problem but I am not convinced that the proposals in this task is a good solution (see T200322#4450395 for some technical aspects, and T200322#4450791 for some social aspects).
We have Repository-Ownership-Requests for people interested in taking over maintainership (though I am not sure if there is a functioning workflow to handle tasks in that project, which might be another problem to solve).

@Jayprakash12345: Don't get me wrong - I very much appreciate your work to fix and update code across many repositories, and trying to find solutions, and I'm glad you started this discussion.

In T200322#4450791, @Krinkle wrote:

I welcome the idea of more actively requiring active maintenance for extensions, such that they are consistently archived after a set period of inactivity (the current span of 5 years was imho never formally adopted, if we do, I'd propose something closer to 3 years).

+1. That sounds like T200324: Create list of extensions whose Gerrit patches have not received reviews by the corresponding +2 Gerrit group (=maintainers) in a certain timeframe.

I read a little about proposals for a better code review culture and want to support appointing a MediaWiki Code review wrangler, who could add appropiate reviewers and help to prevent frustrating experience in less maintained projects. (I think about timespans of more than 6 months here specifically)