In the future, please always follow https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes when requesting such site configuration changes. Thanks.

This is not a well-maintained extension. See T226433#5282576

The eventual source of that comment, after resolving several chains of references:

In T177151#3649449, @QuimGil wrote:

Hi, sorry, the Newsletter extension cannot be deployed to other Wikimedia wikis until we have figured out how to solve T110645: Interwiki support for Newsletter extension. A key value envisioned for this extension is to have a single catalog with all the newsletters, so users can check the one and only list and find everything there. If we start enabling this extension before the interwiki question is solved, we will have dozens of catalogs of newsletters spread all over.

I think it's clear that this is wishful thinking. The Newsletter extension has not been actively maintained for years (I've occasionally poked at it in my free time when I didn't have anything better to do), so my guess is nobody ever will do that substantial rearchitecturing, 8-year-old promises notwithstanding. We should stop waiting for Godot and let the communities make use of the tools we have currently built rather than stifling them.

Hi @Pppery

To see all newsletters available from all wikis looks like a feature request. It is optional, just like I don't need to list all talk pages I can subscribe to. What is the rationale here?

As a comparison, watchlists are local, not global.

Don't ask me. I agree with you. I'm just trying to be helpful by digging down how the current state came to be,

Hi, long story short and if I recall correctly, in 2015 (when most of the development was done in the context of Google Summer of Code) the vision was to have just one list of newsletter Wikimedia-wide. In 2027 (when volunteer me write the paragraph quoted above) I was just repeating that assumption, which was a decision by whoever were approving new extensions installed in Wikimedia wikis back then. The agreement was that, ok, this extension right now (2015-2017) is still experimental and buggy, but we can install it on Meta so that we can get real use by newsletter editors and subscribers, and therefore real testing that would hopefully lead to the extension becoming stable. But this never happened in the end due to not enough interest from developers and editors.

In 2025 all that is almost past history, and any decisions about enabling this extension in other Wikimedia wikis can be made following the process that @Aklapper has linked to above. I haven't been involved in this project for a long time and I have no decision or say about enabling extensions in Wikimedia projects, but it seems clear that this extension is sadly unmaintained, and therefore not fit for further installations in Wikimedia wikis.

@QuimGil What is unmaintained in it? What needs to be fixed?

Note that I followed the process and linked to the on wiki consensus discussion.

@Gryllida I don't know, I haven't been involved in the Newsletter extension project in the past seven years or so. I just commented above because I was pinged and I thought I could give some historical context.

i checked linked patch. lt was rejected because @Qgil asked to add interwiki support. I disagree. Watchlists are local. There is no need in this feature. I would like a confirmation from you please.

If it is dreadfully needed then I will kindly suggest that for progress I might require a user who can advise me in the steps required to setup a tiny wiki farm of two wikis and coding the interwiki support. I would best enjoy this experience with someone who can commit to two 15-min meetings each week. I hope this is not too much to ask. This resource is scarce on smaller wikis.

Thank you for your time and consideration.

sorry, is @Qgil and @QuimGil the same person?

Yes, as explained in the respective profiles. :)

i checked linked patch. lt was rejected because @Qgil asked to add interwiki support.

This was a comment @Qgil (my alter ego) made in 2017. I have explained above why I personally don't think that the 2015-2017 assumptions are valid nowadays.

I have explained above why I personally don't think that the 2015-2017 assumptions are not valid nowadays.

Are you sure you have the right number of "not"s in that sentence?

@Pppery Good catch. Fixed. :)

Hi @Aklapper @QuimGil @Pppery @Bugreporter @Base could we please reach consensus hereabout

1. previous patch decline reason not valid today as "list all available newsletters at this wiki farm" is optional now

2. extension is stable and safe to install

3. he.wiki or whoever wanted it a few years ago, can have it now if they still have consensus

Hopefully, it is a Yay on all three counts. If a Nay for any of the above, could you please provide assistance in addressing that point.

Thank you very much.

Speaking only for myself, Yes, Yes, Yes. The repository has a few known bugs, but I sorted out most of the odd kinks a few years ago and am still watching the MediaWiki-extensions-Newsletter project so if some new bug report gets filed I will look into it if I have time.

The ultimate decision-making authority rests not with any of the people you pinged but instead with the deployers in a backport window, though.

What taavi wrote. Speaking for myself only, I'd prefer not to deploy more technical debt.

Thanks taavi, I will now search for a steward. I will keep you updated.

In T394022#10826315, @Gryllida wrote:

3. he.wiki or whoever wanted it a few years ago, can have it now if they still have consensus

Yes, we did. But for now we can't use even the Meta version, because the Flow is down, and there is no other proper way to send new issues until the problem of "one can sand only new page, it can't be section on some page" will be solved.

Yes, we did. But for now we can't use even the Meta version, because the Flow is down, and there is no other proper way to send new issues until the problem of "one can sand only new page, it can't be section on some page" will be solved.

We solved it last week btw. It should be out on the May 20th release: https://phabricator.wikimedia.org/T393844

I mean, if lacking a steward is the thing blocking the deployment of the extension to Prod, I would love to volunteer to that spot. I do get that I spend some time creating the interwiki support, and our aim was Meta back in the days - but almost 7 years later, we are not on the production cluster yet. Maybe individual wikis is the way to go then?

In T394022#10839239, @01tonythomas wrote:

Yes, we did. But for now we can't use even the Meta version, because the Flow is down, and there is no other proper way to send new issues until the problem of "one can sand only new page, it can't be section on some page" will be solved.

We solved it last week btw. It should be out on the May 20th release: https://phabricator.wikimedia.org/T393844

Incredible, thanks a lot!

Thank you! And, I went ahead and added myself as a steward for the extension in Developers/Mainteners. Now the extension has been running bug-free (mostly) in Mediawiki for a couple of years now, so we can trust that and give it a try in En-Wikinews?

So, what is the next step in these kind of cases? Do we simply add a configuration change to Mediawiki-config like https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/379316 or wait again to get the interwiki problem resolved and install to meta? From an architectural point of view, I see that - we should be able to still support a meta installation (assuming the interwiki is resolved in the future), even if we allow individual wikis to install and use the extension today.

If we follow the current plan (in my changeset in T110645), we should be able to simply db migrate all local newsletters to just "local" newsletters when we have global support for Newsletters.

Change #1152264 had a related patch set uploaded (by 01tonythomas; author: 01tonythomas):

[operations/mediawiki-config@master] Install newsletter extension on enwikinews

https://gerrit.wikimedia.org/r/1152264

Just went ahead and created a patch anyway ;) Will wait for a go-ahead from @Gryllida!

The code steward problem is still unsolved. As this edit notes the "steward" term in this context generally refers to a professional development team taking responsibility of basic maintenance of the code base. The primary reason for this requirement is to ensure we don't end up in a situation where the volunteers taking care of the code base all have disappeared for one reason or the other and there's nobody to fix some critical issue. (This is not to say that we don't appreciate the efforts of @01tonythomas or any other individual - it's just that experience has shown that relying on specific individual volunteers to stay around indefinitely is not a good strategy for long-term sustainability.) There's also the practical requirement to have at least two people working on it, since a single developer can't review and merge their own patches.

hi @01tonythomas , who would you suggest as second maintainer, please? Id be happy to volunteer if initial training is provided. I can commit to two hours weekly. (I ran moodle, mediawiki on vps before, and edited php for gnu savannah package. This was over 5 years ago so workflows may have changed)

This is great @Gryllida. I do not know what exactly would be the process here, but then, in this case, we agree to take care of the extension together, and you can add your name into the Individual contributors list, I would guess? If you want to simply play around the extension, we might have something in the backlog of MediaWiki-extensions-Newsletter (to setup Git/Gerrit and the feel of getting a patch out). Or, can someone else tell us what would be the expectation/steps here?