@Victar: Everyone is unfamiliar, as we all don't ask very often for deployment of an extension. :) That's why there is documentation.
Could you be more specific which specific items and sentences are unclear on https://www.mediawiki.org/wiki/Review_queue#Preparing_for_deployment and why/how so the documentation can be improved? Thanks!

So to make this clear and to not make you waste time on going through the list of items: This extension is not already deployed on Wikimedia sites. Someone or a team needs to be a steward for this code base. Do you know if the author still maintains that extension? Or do you know tech contributors (e.g. on your site) who plan to maintain this code?

@Aklapper The problem is not in the clarity of Review_queue#Preparing_for_deployment, it is technical infeasibility of layman to complete the tasks suggested.

I've attempted to reach out to @Zoranzoki21, but no reply as of yet.

I am not maintaner of this extension.

@Zoranzoki21, you are the owner of the build here: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageNotice/ /425034/ Could you tell of the status of this? Thanks.

That's a contributed proposed patch to update extension code. Zoranzoki21 was kind enough to write such patches for many extensions! It's not clear to me how that's related to this task? (It is not that the last person who touched a code base becomes the maintainer of the code base, if that is maybe the thought? :)
The status of that patch is that it "Needs Code-Review".

I am still happy to act as maintainer of this extension; I rewrote it a few years ago, and it is awfully simple (barely 100 lines of code). Plus I am irregularly active on English Wiktionary :)

Because this extension is so simple, only a security review should be required. I have opened a task for this: T229718: Security review for PageNotice extension.

Extension wants converting to extension registration before we'd deploy it (should be trivial)

In T61245#5389385, @Reedy wrote:

Extension wants converting to extension registration before we'd deploy it (should be trivial)

Done in T174657: Convert PageNotice to use extension registration.

I posted at https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2021/January#PageNotice_extension_again to start a discussion/vote.

I guess start branching it into wmf deployment branches, let it sit for a couple of weeks and then look at enabling it on beta and to request a perf review (they might not necessarily need/want to do much with the simplicity of the extension itself)

Change 661168 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/tools/release@master] Start branching PageNotice

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

Change 661168 merged by jenkins-bot:
[mediawiki/tools/release@master] Start branching PageNotice

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

Change 661177 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] Zuul: [mediawiki/extensions/PageNotice] Tag as in-wikimedia-production, move

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

Change 661177 merged by jenkins-bot:
[integration/config@master] Zuul: [mediawiki/extensions/PageNotice] Tag as in-wikimedia-production, move

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

Mentioned in SAL (#wikimedia-releng) [2021-02-02T19:28:58Z] <James_F> Zuul: [mediawiki/extensions/PageNotice] Tag as in-wikimedia-production, move T61245

Change 668156 had a related patch set uploaded (by TTO; owner: TTO):
[operations/mediawiki-config@master] Enable PageNotice on enwiktionary beta

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

@Reedy or anyone else - any chance of a look at that patch?

Hi all,

The checklist in the task description is incomplete. Please review https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment and add sub-tasks where appropriate.

Notably, identifying and documenting who will be the code steward is needed: https://www.mediawiki.org/wiki/Developers/Maintainers and https://www.mediawiki.org/wiki/Code_Stewardship

Thanks!

There's renewed interest in this extension for the enwiki draft header usecase (idea lab discussion). @TTO Would you still be interested in listing yourself as maintainer?

My time is limited, but this extension is simple and I would be happy to continue as maintainer. I added myself at Developers/Maintainers.

I'll revisit my patch at some stage and hopefully we can get the extension tested on beta.

Just noting here that the patch for beta is still awaiting a 1 so it can be deployed - the deployers are apparently insisting on a 1 prior to deployment now: https://gerrit.wikimedia.org/r/668156

Pinging a few people who have recently 1'd patches in operations/mediawiki-config: @kamila , @jhsoby - as well as @Reedy again.

It seems you really need to have a certain tenacity to do something like this...

In T61245#9141241, @TTO wrote:

Just noting here that the patch for beta is still awaiting a 1 so it can be deployed - the deployers are apparently insisting on a 1 prior to deployment now: https://gerrit.wikimedia.org/r/668156

Pinging a few people who have recently 1'd patches in operations/mediawiki-config: @kamila , @jhsoby - as well as @Reedy again.

It seems you really need to have a certain tenacity to do something like this...

There is no point in randomly pinging people that previously did a Code-Review: 1 on another change. Kamila did one for Gerrit 954593 - Add new OAuth Rate Limiter tier for Wiki Education which does not automatically make them suitable for vetting whether an extension should be added to the wiki. The Code-Review: 1 is a way to indicate the change is authorized, and for enabling an extension that needs someone making that decision. Until a decision is made, people are not going to randomly Code-Review: 1.

Hi @TTO,

Thanks for your message. I reviewed this task, and it seems all the necessary things for extension deployment are done here:

✅ Extension went through the security readiness review, with a risk score of Low. According to the Foundation's policies, a risk level of Low is automatically accepted. This means deployment is okay without any other steps from a security standpoint.
✅ Extension is branched and its code is deployed to Wikimedia servers for at least two trains (for two years, actually :))
✅ Given the extension's simplicity, there is no apparent need for any other reviews.

@TTO, congratulations on getting PageNotice here! With all of the other steps done, the last remaining step would be to review the config patch and deploy it. I went ahead and reviewed it; please see Gerrit for my comments.

Before I'd feel comfortable with giving a thumbs up on that patch, I'd like to clarify one other thing and make one thing explicit. What is the plan for the extension's maintenance in the long term? I know that @TTO listed themselves as a maintainer on the patch (thanks!), but considering self-merges are prohibited on Wikimedia-deployed extensions, any change needs at least two developers to get merged.

The thing that I want to make explicit: I hope this doesn't ever happen, but as with any other extension without official WMF support, if it ever starts to pose significant issues (performance, reliability, security or other), it might get undeployed. This can be prevented by actively maintaining the extension and responding to tasks that eventually get filled about it, but it has happened in near past with DynamicPageList, the experience was far from pleasant and it would be best for everyone to avoid similar situations in the future.

The Code-Review: 1 is a way to indicate the change is authorized, and for enabling an extension that needs someone making that decision. Until a decision is made, people are not going to randomly Code-Review: 1.

I believe that decision was already made: PageNotice is currently deployed to Wikimedia servers. It is not enabled, which is a different question (and fortunately, much easier to handle).

In T61245#9150803, @Urbanecm wrote:

I believe that decision was already made: PageNotice is currently deployed to Wikimedia servers. It is not enabled, which is a different question (and fortunately, much easier to handle).

In general, this is not correct - the branch-for-production step runs ahead of the security review - but in this case indeed I made the call two years ago as part of the branching.

In T61245#9150469, @hashar wrote:

There is no point in randomly pinging people that previously did a Code-Review: 1 on another change.

Do you see my frustration, though, @hashar? You've told me what I shouldn't do, but haven't offered an alternative course of action.

that needs someone making that decision.

This is exactly the source of my frustration: (a) who is the "someone" and, (b) how are people like me supposed to find out who the "someone" is? In this case I feel very lucky because @Urbanecm has appeared out of the blue and "saved the day", but if that didn't happen - serious question - what is someone in my position meant to do? For example, https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment#Deploy_to_Beta_Cluster exists, but omits the crucial detail of who should review the patch - in fact, it hardly mentions review of ops patches.

In any case, thank you very much for your input, @Urbanecm . I will make the necessary changes to the patch and re-upload for review.

As for ongoing review, the extension is very simple, so the need for review is likely to be limited (perhaps 1 patch a year at most). I would call upon members of the MediaWiki-Platform-Team to assist with review.

In T61245#9151521, @TTO wrote:

In T61245#9150469, @hashar wrote:

that needs someone making that decision.

This is exactly the source of my frustration: (a) who is the "someone" and, (b) how are people like me supposed to find out who the "someone" is? In this case I feel very lucky because @Urbanecm has appeared out of the blue and "saved the day", but if that didn't happen - serious question - what is someone in my position meant to do? For example, https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment#Deploy_to_Beta_Cluster exists, but omits the crucial detail of who should review the patch - in fact, it hardly mentions review of ops patches.

Thanks for asking those questions -- I understand how not knowing the answers can feel frustrating. Attempting to answer them here. Ad (a): Unfortunately, there is no _the_ someone. We currently do not have a process for deploying new extensions to Wikimedia wikis (we have a set of requirements that need to be met, such as the security readiness review; there is even a process to get said review, but there is no process for actually deploying the extension). Because of that, there is no one whose responsibility it would be to review "new extension" patches.

As a result, to get a patch like yours reviewed/deployed, it is necessary to find a volunteer [1] who would be willing to help. One way to find such people is looking for people who got involved with new extension installing reasonably recently [2]. This can be done by examining the repository's history, looking for extension-enabling commits (can be done by looking for changes of wmf-config/extension-list) and also checking the context in which that commit was made.

New extensions get enabled fairly infrequently, but when they do, they can be categorized into two different groups: (a) WMF-led extensions and (b) volunteer-led extensions. The big difference between those two is that extensions in the first group have a clear WMF owner (the team that created that extension), who is responsible for moving things forward (including enabling it), while moving extensions in the second group don't have such an owner/responsible individual/team.

This means that extensions in the first group are enabled by engineers of the team which invented that extension, and this is the context in which the commit was made/reviewed. While those engineers do know the technical procedure, they might not be sufficiently comfortable giving their thumbs up precisely because there is no clear owner. This is fine, as no one is required to volunteer [1] their time. For that reason, finding someone who recently helped enabling a volunteer-led extension would be best positioned to help reviewing the patch and advising for next steps.

Hope this comments helps to understand the situation around new extension and how to navigate similar issues.

[1] In this context, by "volunteer" I mean both people Wikimedia (WMF/WMDE/etc.) does not pay at all and people who are paid, but to do something else. Because installing extensions is in no one's area of responsibility, everyone is a volunteer in this case.
[2] This might be years ago, because of how infrequent successfully installing a new extension is. By "relatively recently", I mean the latest possible commits, to avoid running into people who are no longer active.

Thanks very much for that detailed explanation. It is most unfortunate that this gap exists, and speaks perhaps of a disconnect between WMF teams and volunteer developers, and a need for WMF staff members who specialise in liaising between the two groups.

I have added a note at https://www.mediawiki.org/w/index.php?title=Writing_an_extension_for_deployment&diff=6097533&oldid=6088386 - I tried to word it neutrally, but please edit it if you feel it can be improved.

In T61245#9153968, @TTO wrote:

Thanks very much for that detailed explanation. It is most unfortunate that this gap exists, and speaks perhaps of a disconnect between WMF teams and volunteer developers, and a need for WMF staff members who specialise in liaising between the two groups.

Agreed. For the records, similar issues are present in other unowned areas (getting reviews for individual patches, especially the more complex ones, can be tricky for pretty much the same reasons). It'd be great if everything we have deployed had an owner, but unfortunately that's not the case now (and discussions on resolving this issue'd be OoS here).

I have added a note at https://www.mediawiki.org/w/index.php?title=Writing_an_extension_for_deployment&diff=6097533&oldid=6088386 - I tried to word it neutrally, but please edit it if you feel it can be improved.

Thanks for doing that! I rephrased a part of the paragraph you added, see diff. I mainly linked the how to get reviews guide. While it is not directly applicable to this particular problem, I believe several pieces of advice from that document can be helpful. I also changed "Volunteer developers are advised" to "(All) developers are advised" (the difference between volunteer-led and WMF-led extensions is mostly in the amount of dedicated time available -- otherwise, both cases have similar complications).

In T61245#9151521, @TTO wrote:

As for ongoing review, […]. I would call upon members of the MediaWiki-Platform-Team to assist with review.

Why this team in particular? This team was created 30 days ago, and currently has as its scope: AuthManager, ResourceLoader, and BagOStuff. We can ask but I don't think we should presume that a team will become steward for a new extension in production.

You need to understand the extreme simplicity of the PageNotice extension; its single PHP file is only 100 lines long. The risk level associated to not having a WMF team assigned to this extension is negligible.

In any case, if you do insist on a WMF team being nominated as steward, the reason I thought MediaWiki-Platform-Team would be suitable is because this extension is so simple that anyone with a reasonably comprehensive understanding of MediaWiki internals would be able to review its changes. I recognise many of the names in that team - including your own, @Krinkle - and they are people who know what they are talking about when it comes to MediaWiki.

@Krinkle Is there another team you think would be more appropriate? Where actually can I find a complete list of WMF teams? Ideally I'd assign it to the team that looks after "basic MediaWiki stuff", but I struggled to identify such a team.

Change 668156 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable PageNotice on enwiktionary beta

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

Mentioned in SAL (#wikimedia-operations) [2023-09-12T07:28:00Z] <oblivian@deploy1002> Started scap: Backport for [[gerrit:951047|ClusterConfig: also allow to return hostname]], [[gerrit:668156|Enable PageNotice on enwiktionary beta (T61245)]]

Mentioned in SAL (#wikimedia-operations) [2023-09-12T07:56:10Z] <oblivian@deploy1002> tto and oblivian: Backport for [[gerrit:951047|ClusterConfig: also allow to return hostname]], [[gerrit:668156|Enable PageNotice on enwiktionary beta (T61245)]] synced to the testservers mwdebug2002.codfw.wmnet, mwdebug2001.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug1001.eqiad.wmnet, and mw-debug kubernetes deployment (accessible via k8s-experimental XWD option)

Mentioned in SAL (#wikimedia-operations) [2023-09-12T08:13:24Z] <oblivian@deploy1002> Finished scap: Backport for [[gerrit:951047|ClusterConfig: also allow to return hostname]], [[gerrit:668156|Enable PageNotice on enwiktionary beta (T61245)]] (duration: 45m 23s)

For completeness I will repeat the comment by @Urbanecm on the Gerrit patch:

I went ahead and updated the wiki page to list PageNotice as stewarded by active volunteer (this is the same what we did for recently(ish) deployed RealMe or GlobalWatchlist and what is done for several other components, like AbuseFilter or ProofreadPage. I believe "Active volunteer" matches the current reality, and mw:Developers/Maintainers should, first and foremost, respect and document the reality.

The testing on beta has proceeded without any issues. Now it's time to enable the extension on the production cluster.

I have a bold suggestion - and that is to enable PageNotice on all production WMF wikis (with $wgPageNoticeDisablePerPageNotices = true).

The extension has no effect unless the relevant MediaWiki: namespace pages are created. It simply adds an extra feature that communities can take advantage of, via their local admins, if they so desire - or if they are not interested in using it, simply leave the relevant pages uncreated.

@Jdforrester-WMF I'm keen to hear your thoughts on this proposal.

In T61245#9369815, @TTO wrote:

enable PageNotice on all production WMF wikis (with $wgPageNoticeDisablePerPageNotices = true).

There being no objections, I will proceed with this plan.

Change 993824 had a related patch set uploaded (by TTO; author: TTO):

[operations/mediawiki-config@master] Enable PageNotice extension in production

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

Change 993824 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable PageNotice extension on testwiki

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

Mentioned in SAL (#wikimedia-operations) [2024-01-30T08:18:15Z] <ladsgroup@deploy2002> Started scap: Backport for [[gerrit:993824|Enable PageNotice extension on testwiki (T61245)]]

Mentioned in SAL (#wikimedia-operations) [2024-01-30T08:19:42Z] <ladsgroup@deploy2002> ladsgroup and tto: Backport for [[gerrit:993824|Enable PageNotice extension on testwiki (T61245)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-01-30T08:28:40Z] <ladsgroup@deploy2002> Finished scap: Backport for [[gerrit:993824|Enable PageNotice extension on testwiki (T61245)]] (duration: 10m 24s)

The plan is to enable the extension first on testwiki (done), then on enwiktionary, then on all other wikis.

@Ladsgroup has expressed the intent to do a performance review before proceeding any further with this plan.

In T61245#9496945, @TTO wrote:

In T61245#9369815, @TTO wrote:

enable PageNotice on all production WMF wikis (with $wgPageNoticeDisablePerPageNotices = true).

There being no objections, I will proceed with this plan.

Hi! Sorry, I didn't see your query. Silence is never assent, and it was not appropriate for you to act in this case like it was.

I don't think it's appropriate to rush this into production for everyone without a quick discussion in an appropriate place e.g. on Meta, but it's not a huge issue if there's clear documentation on what it is and how it can be used. However, Extension:PageNotice is pretty light, and there's no Help:PageNotice page yet to which we could point communities. Can this please be done first?

In T61245#9498555, @Jdforrester-WMF wrote:

I don't think it's appropriate to rush this into production for everyone without a quick discussion in an appropriate place e.g. on Meta, but it's not a huge issue if there's clear documentation on what it is and how it can be used.

Indeed, as this is an extension that (a) does nothing by default, and (b) is only usable by admins and hence has no potential for abuse by vandals etc, I feel there is no need to discuss. I'm imagining a Tech News item.

However, Extension:PageNotice is pretty light, and there's no Help:PageNotice page yet to which we could point communities. Can this please be done first?

I expanded https://www.mediawiki.org/wiki/Extension:PageNotice slightly, but there really is not much more to say about this very simple extension. I redirected https://www.mediawiki.org/wiki/Help:PageNotice to Extension:PageNotice#Usage.

In T61245#9501228, @TTO wrote:

In T61245#9498555, @Jdforrester-WMF wrote:

I don't think it's appropriate to rush this into production for everyone without a quick discussion in an appropriate place e.g. on Meta, but it's not a huge issue if there's clear documentation on what it is and how it can be used.

Indeed, as this is an extension that (a) does nothing by default, and (b) is only usable by admins and hence has no potential for abuse by vandals etc, I feel there is no need to discuss. I'm imagining a Tech News item.

Definitely. :-)

However, Extension:PageNotice is pretty light, and there's no Help:PageNotice page yet to which we could point communities. Can this please be done first?

I expanded https://www.mediawiki.org/wiki/Extension:PageNotice slightly, but there really is not much more to say about this very simple extension. I redirected https://www.mediawiki.org/wiki/Help:PageNotice to Extension:PageNotice#Usage.

Thank you! Let's ship it.

Hello @Jdforrester-WMF,
For Tech News - What wording would you suggest as the content, and When should it be included? Thanks!

In T61245#9527661, @TTO wrote:

In T61245#9527504, @UOzurumba wrote:

When should it be included?

This is blocked on T356159, so there's nothing to announce until that task is resolved. I'll try to look at it soon, but as you can see, progress here has been very slow over the years, so I can't promise anything.

Thanks @TTO