@Vikipolimer - Can we get a better idea of when this might be deployed to Wikimedia production? And is there a sponsoring team at the WMF to assist in the management of maintenance, security, etc. issues?

@sbassett - We aim to deploy this extension to Wikimedia production as soon as it is ready. I commit to assume maintenance responsibilities once deployment is complete. I will co-operate with the relevant teams at the Wikimedia Foundation to provide oversight to make sure that maintenance, security, and other issues related to sponsorship and support are managed properly. The Turkish Wikipedia community has requested this deployment, so it will be initiated as soon as the necessary permissions are obtained. It is considered a productivity improvement, and there is no strict deadline for deployment. Its non-deployment does not obstruct anyone from performing their tasks. There is currently no sponsoring team, unless Moderator Tools has the capacity to support it. Gergő Tisza is currently reviewing the code, and I am awaiting the VUE code review.

Hello @sbassett , Gergő Tisza has completed the php code review, would you mind starting the security review?

In T355150#9464152, @Dogu wrote:

There is currently no sponsoring team, unless Moderator Tools has the capacity to support it. Gergő Tisza is currently reviewing the code, and I am awaiting the VUE code review.

We'll need at least one WMF employee or team to offer basic support for the extension for when it's deployed to Wikimedia Production. They can comment on this task as an official acceptance of that responsibility.

In T355150#9762726, @Dogu wrote:

Hello @sbassett , Gergő Tisza has completed the php code review, would you mind starting the security review?

Per our Application Security Review SOP, we schedule application security reviews at the beginning of each quarter, once all prerequisites have been satisfied. So this review will likely go into next quarter's planning queue. There is a very small chance I could get to it towards the end of this quarter, but I cannot promise that.

@sbassett we (Moderator Tools) have been talking about this internally and want to see this extension get into production. We are certainly willing to help, but we don't want to overpromise for our capacity. What does it mean to sponsor/offer basic support?

In T355150#9804134, @jsn.sherman wrote:

@sbassett we (Moderator Tools) have been talking about this internally and want to see this extension get into production. We are certainly willing to help, but we don't want to overpromise for our capacity. What does it mean to sponsor/offer basic support?

Sadly, I don't think we have a formal definition at this time, but as a co-owner/supporter, you would likely be expected to address bugs (especially security bugs) within a timely fashion. And otherwise guide and assist with the future development and maintenance of the extension.

In T355150#9812817, @sbassett wrote:

In T355150#9804134, @jsn.sherman wrote:

@sbassett we (Moderator Tools) have been talking about this internally and want to see this extension get into production. We are certainly willing to help, but we don't want to overpromise for our capacity. What does it mean to sponsor/offer basic support?

Sadly, I don't think we have a formal definition at this time, but as a co-owner/supporter, you would likely be expected to address bugs (especially security bugs) within a timely fashion. And otherwise guide and assist with the future development and maintenance of the extension.

@sbassett, @Dogu I don't think we currently have the capacity to support this. Our team composition has recently changed and we have also picked up stewardship of several projects, so we are concerned about overextending ourselves. This is something I'd be happy to revisit in the future after the dust has settled and we understand what our velocity and capacity is looking like with our current projects.

In T355150#9843260, @jsn.sherman wrote:

@sbassett, @Dogu I don't think we currently have the capacity to support this. Our team composition has recently changed and we have also picked up stewardship of several projects, so we are concerned about overextending ourselves. This is something I'd be happy to revisit in the future after the dust has settled and we understand what our velocity and capacity is looking like with our current projects.

Ok, thanks for the update.

@sbassett, as mentioned in T355150#9843260, it seems the Moderator Tools team lacks the capacity to support the Adiutor due to recent team changes and new projects. However, I believe it is essential for the security review to be conducted. The security review can be completed without a dedicated team overseeing it. We can explore other methods to ensure this process is completed. I am ready to collaborate and provide the necessary support.

On an aside, can this requirement be documented at Writing an extension for deployment, preferably with an explanation of what "basic support" means? It's disrespective of volunteer contributors' time, to put it mildly, if they only find out at the end of a long development and review process that their extension cannot be deployed for reasons they have no control over.

I would like to add them in case the Community Tech team is interested.

We're of course interested! But I'm afraid we simply don't have the bandwidth right now. For our team, this would need to go through the wishlist and get prioritized through our normal processes. More info at https://meta.wikimedia.org/wiki/Community_Tech/Phabricator_criteria

<threadjack>

In T355150#9907769, @Tgr wrote:

On an aside, can this requirement be documented at Writing an extension for deployment, preferably with an explanation of what "basic support" means? It's disrespective of volunteer contributors' time, to put it mildly, if they only find out at the end of a long development and review process that their extension cannot be deployed for reasons they have no control over.

Maybe the collective "we" should put some effort into making that page a bit more clear to folks that the lead sentence does not promise that the page documents all requirements for deployment of a skin or extension to the Wikimedia production cluster. The lead is currently (emphasis included) "This page documents the steps needed for a maintainer or code steward of a MediaWiki extension to get that extension through the review process before the extension is possibly being deployed to Wikimedia wikis." The key phrase there for expectation setting is "possibly being deployed". I believe this means that the documented steps are necessary, but not guaranteed to be sufficient.

There are some additional elements documented there that hint at, but do not explicitly state, current expectations:

• Stewardship - Add the project to the Developers/Maintainers page indicating who will be responsible for it's long term stewardship and maintenance.

• A review from the product owner for the affected area, if applicable. If you are unsure who that might be, it is likely a good idea to reach out to various engineering teams within the Product or Technology verticals for more information and guidance.

It is a bit hidden, but https://www.mediawiki.org/wiki/Security/SOP/Application_Security_Reviews also includes:

Code which has not gone through appropriate processes (Technical decision making process, the creation of a product roadmap or support plan, sponsorship by a Wikimedia Foundation team, etc.) so as to be a strong candidate for deployment upon Wikimedia production infrastructure.

This seems to be the most direct mention of a benefit of sponsorship by a Wikimedia Foundation team in either document. We can probably do a better job of surfacing this earlier.

In an ideal world we would have a clearly documented process that is actively used by all projects headed for a Wikimedia production deployment. In practice we have difficulty documenting such a process because we also have no governance system to vet and approve a checklist if one were drafted or to review and adjust the living document as practical application demands. This is at least tangentially related to MediaWiki Product, but likely also subject to consensus of a number of other teams and roles within the Foundation and larger technical community.
</threadjack>

The requirement for some WMF team to support new extensions itself seems unnecessary and hypocritical. There are currently 61 extensions at https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation with no documented steward, and probably another dozen that are in some limbo state where a team has nominal responsibility but then declares it as unsupported (like Babel for example). Audiutor (or ChessBrowser, or any of the other volunteer-written extensions that the WMF has refused to install) would be in a situation significantly better, maintenance-wise, than most WMF-run code, in having at least one person who cares.

(I know this comment won't actually change anything, but just wanted to get it out there)

<threadjack>

In T355150#10001057, @Pppery wrote:

There are currently 61 extensions at https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation with no documented steward, and probably another dozen that are in some limbo state where a team has nominal responsibility but then declares it as unsupported (like Babel for example).

The uncertainty about maintenance and critical bug fix support for 60+ areas in the present is the driver for seemingly arbitrary and capricious rules about adding new components without known contractual obligations to the production wikis. These components also at some point in the past had at least one person who cared. The general problem is that the care of a volunteer is at the whim of that volunteer. When their feelings or life circumstances change in the future, they will stop caring. This isn't an attempt to pick on any individual; it is just a basic fact in all volunteer movements. Unfortunately the formerly caring volunteer will not be under any contract to the community to find a new person to care or to sunset the service before they walk away. They might!, it does happen occasionally, but we can't know that a priori. We actually have a pretty long history at this point that indicates that they very likely will not. Again this does not happen because they chose to cause harm or sow descent. It just happens because their life became less compatible with donating their limited time and effort to a particular project.

The parts of the on-wiki communities that have come to depend on feature X or feature Y will not as a collective be understanding when the things that they use are suddenly disabled because of a critical security or performance issue. They will write angry letters to wikimedia-l and start RFCs on their home wikis demanding the Wikimedia Foundation step up and fix the problem. Sometimes they will go further than this in attempting to drive home the point that they are mad that the world changed without asking them first. This all leads to sad managers, grumpy engineers, and overworked communications specialists. It leads to emergency teams being formed to try and patch things up with as few people and as little time as possible. It leads to volunteer and staff burnout, and a loss of trust in the community for the Wikimedia movement software and teams.

We talk about this problem of volunteer attention churn quite a bit in the tools ecosystem. See my essay/presentation at https://wikitech.wikimedia.org/wiki/User:BryanDavis/Developing_community_norms_for_critical_bots_and_tools for some attempts at telling stories about how this has happened in the past. We should talk about it more in the context of "production" software too. The same problems exist up and down our technical stack. It is fun to build new things. It is broadly not so fun to take care of old things. It is seldom seen as fun to figure out how to remove a thing with minimal community disruption.

Nobody really wants to be a jerky gatekeeper, but we also do not have any good ideas about how to keep a known problem from getting worse without some gatekeeping. Even "sponsorship" from a current Wikimedia Foundation or affiliate team does not guarantee future support. It does however make managers a bit more comfortable to assume there will be internal push back against wholesale abandonment by a team without a sun setting plan.
</threadjack>

@sbassett is this scheduled for security review this quarter?

In T355150#10304340, @Cparle wrote:

@sbassett is this scheduled for security review this quarter?

Not currently, no. I believe @acooper had a couple more decisions to make on this prior to review acceptance.

What a shame.

Volunteer developer hat on:

1. It does not appear entirely clear why Auditor needs to be its own extension to work cross-wiki. Other projects depending on a single developer, like Convenient-Discussions, function fine as user scripts/gadgets.
2. The policy of not approving new extensions if they cannot be backed by a WMF team is sound. It is much better than relying on a single developer to always exist, be present and to reply to all feedback. Even the WMF extensions that have teams behind them do not get the attention to the issues they deserve, which will be worse if you only have a single responsible person. As you show in your open letter itself, you can always leave and single-handedly kill the project.
3. Neglected extensions get neglected care. @Dogu’s own changes in FlaggedRevs extension caused a massive accessibility issue, T373769: Rework "Page version status" in FlaggedRevs to be unambiguous about its nature, that no one is interested in fixing now after you moved on. I’ve managed to fix this for my own wiki in T372694, but there are multiple others. The extension is used in many wikis, including English Wikipedia, but no one cares now.

In T355150#9907769, @Tgr wrote:

On an aside, can this requirement be documented at Writing an extension for deployment, preferably with an explanation of what "basic support" means? It's disrespective of volunteer contributors' time, to put it mildly, if they only find out at the end of a long development and review process that their extension cannot be deployed for reasons they have no control over.

I partially did this just now in https://www.mediawiki.org/w/index.php?title=Writing_an_extension_for_deployment&diff=prev&oldid=6846281. Anyone should feel free to improve it.

In T355150#10306005, @Novem_Linguae wrote:

In T355150#9907769, @Tgr wrote:

On an aside, can this requirement be documented at Writing an extension for deployment, preferably with an explanation of what "basic support" means? It's disrespective of volunteer contributors' time, to put it mildly, if they only find out at the end of a long development and review process that their extension cannot be deployed for reasons they have no control over.

I partially did this just now in https://www.mediawiki.org/w/index.php?title=Writing_an_extension_for_deployment&diff=prev&oldid=6846281. Anyone should feel free to improve it.

Thank you for this @Novem_Linguae

@Dogu, your frustration and dismay with this is understandable. The fact that you developed the extension and discovered that there was no clear path to deployment after the fact shows that we have work to do. FWIW, many people (including me) value your contributions.

I echo how much we value this work.

In T355150#10305971, @stjn wrote:

It does not appear entirely clear why Auditor needs to be its own extension to work cross-wiki. Other projects depending on a single developer, like Convenient-Discussions, function fine as user scripts/gadgets.

I don't think it needs it per se, but I can think of a few reasons:

1. Allow non-JS people can use non-JS tools. I don't recall any countervandalism tool existing for such users except rollback. (I personally do not identify with them, but I anecdotally remember there being a non-trivial amount of such users on the English Wikipedia.)
2. Browsers don't need to repeatedly load a large amount of minified JS code every time they visit a page. (Even with cache, it's uncertain when updates are going to happen.)
3. Settings can be in the unified Special:Preferences page.
4. It feels like it should be more stable.

You do bring up a good point in #3 though.

Personally I do not support deploying Adiutor to Wikimedia. Wikimedia has multiple series of community moderation tools in parallel (extensions: Adiutor, PageTriage; Gadgets: Twinkle, etc.) and many of them are community specific and hard to customize. What I want is let all of these to be gone, and replaced with a new extension with high level abstraction - see the last section of https://meta.wikimedia.org/wiki/User:Okeyes_%28WMF%29/Localising_page_curation (yes, this will replace at least all page and user related functionalities of Twinkle).

The current code of Adiutor supposes wiki to have a AFD/CSD/PROD process. Though they can be disabled, they are bad by design (and it is why PageTriage fail to be useful outside enwiki) - In an extension we should not preassume such process will exist. These should be always configured in client side (with a template for common tasks cross-wiki like speedy deletion).

In T355150#10308304, @Bugreporter wrote:

Personally I do not support deploying Adiutor to Wikimedia. Wikimedia has multiple series of community moderation tools in parallel (extensions: Adiutor, PageTriage; Gadgets: Twinkle, etc.) and many of them are community specific and hard to customize. What I want is let all of these to be gone, and replaced with a new extension with high level abstraction - see the last section of https://meta.wikimedia.org/wiki/User:Okeyes_%28WMF%29/Localising_page_curation (yes, this will replace at least all page and user related functionalities of Twinkle).

The current code of Adiutor supposes wiki to have a AFD/CSD/PROD process. Though they can be disabled, they are bad by design (and it is why PageTriage fail to be useful outside enwiki) - In an extension we should not preassume such process will exist. These should be always configured in client side (with a template for common tasks cross-wiki like speedy deletion).

Apparently, you have no idea about Adiutor. It can be localized and customized for any wiki through its settings page.

In T355150#10310884, @Dogu wrote:

In T355150#10308304, @Bugreporter wrote:

Personally I do not support deploying Adiutor to Wikimedia. Wikimedia has multiple series of community moderation tools in parallel (extensions: Adiutor, PageTriage; Gadgets: Twinkle, etc.) and many of them are community specific and hard to customize. What I want is let all of these to be gone, and replaced with a new extension with high level abstraction - see the last section of https://meta.wikimedia.org/wiki/User:Okeyes_%28WMF%29/Localising_page_curation (yes, this will replace at least all page and user related functionalities of Twinkle).

The current code of Adiutor supposes wiki to have a AFD/CSD/PROD process. Though they can be disabled, they are bad by design (and it is why PageTriage fail to be useful outside enwiki) - In an extension we should not preassume such process will exist. These should be always configured in client side (with a template for common tasks cross-wiki like speedy deletion).

Apparently, you have no idea about Adiutor. It can be localized and customized for any wiki through its settings page.

But it still has functionality specific to a particular process (https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Adiutor/+/refs/heads/master/i18n/en.json#36 has some messages for CSD/PROD, etc.) Ideally we should not built in any specific workflow in extension. We can have a visual (scratch-like) way to let community to define their community processes.

For example, if English Wikipedia added a new type of PROD for unsourced articles in the future, we only need to modify the community configuration page, without changingthe software. Also, English Wikipedia has multiple kinds of deletion processes - they should be configured client side; the software should not be specifically customized for any of them.

I think it is fine and useful to create a tool that would work for shared workflows among the wikis. No tool should assume, though, that every workflow exists in every wiki, and this is partly what makes the current makeup of that en.json page a bit problematic. PROD is not a concept in Russian Wikipedia, but Russian translators would translate messages for it for no reason. Once again, I have to point to Convenient-Discussions as a more positive example of a tool that tries to unite shared workflows but also allows for customisation that is useful for a specific wiki: https://github.com/jwbth/convenient-discussions/blob/main/config/w-ru.js#L-99

Another example is several wikis have AFD in subpage of the talk page of the page concerned (i.e. Talk:PAGENAME/AFD instead of Wikipedia:AFD/PAGENAME or Wikipedia:AFD/date). So we should allow local wikis to configure AFD workflow like this without having a specific workflow built in software or specifically adapting software for such kinds of workflow.

So file a Phabricator task for that ("Audiutor should support more local-wiki customization of deletion workflows") specifically? This arguing is entirely futile and not going to convince anyone in authority of anything. None of the participants here (including myself) should have any authority over what extensions are deployed to wikis they do not actively edit.

In T355150#10310943, @Pppery wrote:

So file a Phabricator task for that ("Audiutor should support more local-wiki customization of deletion workflows") specifically? This arguing is entirely futile and not going to convince anyone in authority of anything. None of the participants here (including myself) should have any authority over what extensions are deployed to wikis they do not actively edit.

In my opinion we should build a new extension (and also decline T50552: Make PageTriage wiki agnostic).

Tearing things down and rewriting from scratch is almost never the answer: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

I'm done engaging in this argument.

@Bugreporter: That’s even more out of scope here, tbf. Anyway, I think on the whole Auditor is a good idea, but implementing it as an extension without a proven track record of its use in many wikis and with a single volunteer developer behind it was a bad idea.

Yes it is at least better than PageTriage, so if it should be maintained and widely deployed I will at least want all Triage-related functionality (i.e. "page curation") in PageTriage removed. But It is not the case now.