swalling wrote:

(In reply to comment #0)

There is not yet any community consensus for the deployment of this
extension,
but I thought I would get the ball rolling.

The [[mw:Extension:PageNotice]] extension allows the display of an arbitrary
notice, similar to SiteNotice, but at the top of a page's content area, below
the tagline. The notices can be set up on a per-namespace bases (or per-page
basis, if not disabled in LocalSettings).

There are currently three Gerrit changes awaiting review, that bring the code
up to the standards expected of a modern MediaWiki extension (Gerrit change
#105141), and add a couple of minor features (Gerrit change #105142, Gerrit
change #105143).

The motivation for this extension is to allow for a notice to be displayed at
the top of every page in the Draft namespace on enwiki. It could potentially
be
used by other wikis to display other namespace-specific notices (for
example, a
standard header on all article talk pages).

Here is "Greg's checklist" for this extension:

TODO/Check list

Extension page on mediawiki.org: YES
Bugzilla component: YES
Extension in Gerrit: YES
Design Review: NO, but since it is so simple, I doubt it really needs one
Architecture/Performance Review: NO
Security Review: NO
Screencast (if applicable): N/A
Community support: NOT YET

I do think design review is essential here.

Displaying a message in read mode is potentially a very annoying and ugly thing to do to readers and editors. To be honest I'm a little wary of allowing a general tool to add page notices in every namespace. I'd first prefer to meet the specific requirement of the draft namespace, as simply as we can.

We should definitely get a performance review as well, since performance concerns (maybe outdated?) were expressed at https://www.mediawiki.org/wiki/Extension_talk:PageNotice

Articles in draft namespace will look very different from "published" articles there will be no confusion by readers that they are reading a normal article while reading a draft. I would go so far as to say there may not even be a concept of "reading" a draft, e.g. Drafts are always in an editing mode (just a thought not a design decision)

Basically this bug proposes both a problem and a solution to an issue that doesn't exist yet. Let's not get ahead of ourselves.

Closing this. If once the new draft workflow exists this is an issues for readers then we can work on a solution together.

(In reply to comment #2)

Closing this. If once the new draft workflow exists this is an issues for
readers then we can work on a solution together.

Reopening, Community consenus hasn't happened either way yet. This isn't your place to close a bug.

Personally, I think this feature should go in core, as a compliment to the sitenotice feature.

Regardless,
(In reply to comment #2)

Articles in draft namespace will look very different from "published"
articles
there will be no confusion by readers that they are reading a normal article
while reading a draft. I would go so far as to say there may not even be a
concept of "reading" a draft, e.g. Drafts are always in an editing mode
(just a
thought not a design decision)

Has this been discussed onwiki anywhere? I had read https://blog.wikimedia.org/2013/12/20/new-draft-feature/ but what you're talking about wasn't even covered.

Basically this bug proposes both a problem and a solution to an issue that
doesn't exist yet. Let's not get ahead of ourselves.

Why do you think the problem doesn't exist now? The Draft namespace is already live on enwiki and being used.

Closing this. If once the new draft workflow exists this is an issues for
readers then we can work on a solution together.

This bug is not INVALID, please don't close it as such, I'm assuming you wanted WONTFIX. I recommend you review [[mw:Bug management/Bug report life cycle]], it's pretty helpful. :)

(In reply to comment #2)

Articles in draft namespace will look very different from "published"
articles

Jared: Have a look at [[Draft:Beth Sotelo]]. Does it look much different from a published article to you?

A small community discussion is occurring at [[Wikipedia talk:Drafts#.22This_is_a_draft.22_banners]], but I decided to jump the gun and start this process regardless of what happened there, since (a) extensions can take a very long time to get reviewed, and (b) I can see other potential uses for this feature besides Drafts on enwiki.

I'm also inclined to agree that this would work better in MediaWiki core. It should be fairly easy to merge PageNotice into core, and this can be done regardless of what ends up happening with enwiki's Draft namespace.

It seems more simple to continue the current behavior of using {{draft}} rather than codifying it into an automated process that could conflict with future uses of the draft namespace.

swalling wrote:

(In reply to comment #6)

It seems more simple to continue the current behavior of using {{draft}}
rather
than codifying it into an automated process that could conflict with future
uses of the draft namespace.

Jared,

There are significant disadvantages to using a template, in my estimation. These include:

• The template would need to either be preloaded using a form or added to new drafts by hand. This would indubitably require a bot or another tool which would require maintenance.
• Adding templates in to page content is part of what makes the "Articles for Creation" process confusing to new editors. Part of the source of an article is their draft, and part of it is metadata that they should not remove. This creates more of a burden on an already confused new person.

I am in favor of exploring an automated notice in read-mode that is sufficiently elegant but also noticeable. It seems that's what the community wants too, if you take a look at the discussion TTO linked to. All I objected to in my first comment was using the PageNotice extension to accomplish this design goal.

You may be interested in Gerrit change 105434, which implements a PageNotice-like feature in MediaWiki core.

Lowest priority. I'm no longer really interested in this.

May be a solution for T6469

Would be absolutely amazing for Draft space and others. Support.

To get this deployed, community consensus would be needed, then someone from WMF (probably Bawolff or Reedy) would review the code prior to deployment.

I tried to push for this extension to be deployed years ago when the Draft namespace on enwiki was about to be implemented, but certain people seemed resistant to the idea of placing a notice at the top of all draftspace pages in this way. (Edit: See above for some comments along these lines.) I'm not sure if the same resistance exists today. (I'm not referring to resistance to a particular notice, I mean resistance to the idea of a notice.)

https://www.mediawiki.org/wiki/Review_queue explains the required steps.

On English Wiktionary, this extension could be used to transclude a template at the top of pages in the Reconstruction namespace. At the moment, we have to manually add the template to every page. See for instance Reconstruction:Proto-Indo-European/dn̥ǵʰwéh₂s.

There have been discussions about this at Wiktionary:Grease pit/2018/September#{{reconstruction}}, Wiktionary:Beer parlour/2017/September#Proposal: install mw:Extension:PageNotice, and at Wiktionary:Grease pit/2017/June#Citations at citations where several people expressed support or interest in looking into it. There was talk of using the extension to transclude a template in the Citations namespace, but most likely the extension can't be used there because the template requires input.

If a clearer indication of support is needed, I can start another discussion.

In T61245#4857105, @Erutuon wrote:

If a clearer indication of support is needed, I can start another discussion.

@Erutuon: Please see T61245#4518756 what you need to do, if a community is interested in deploying this extension on Wikimedia servers.

In T61245#5364696, @Aklapper wrote:

In T61245#4857105, @Erutuon wrote:

If a clearer indication of support is needed, I can start another discussion.

@Erutuon: Please see T61245#4518756 what you need to do, if a community is interested in deploying this extension on Wikimedia servers.

https://www.mediawiki.org/wiki/Review_queue seems to relate to developing the extension. I am an editor at the English Wiktionary not involved in the MediaWiki or Wikimedia organizations, and am not sure how to get involved in the development process. I was expressing the interest of a particular wiki in the hopes that it would encourage someone to restart work on the extension.

@Erutuon: The initial part is for maintainers indeed; https://www.mediawiki.org/wiki/Review_queue#Preparing_for_deployment covers what any requester could perform. (Note however that a proposed extension shall have an active technical maintainer / steward; not sure if that is the case here.)

@Aklapper so what do you recommend as the next step for us to do to get this moving?

@Victar: See item 3 on https://www.mediawiki.org/wiki/Review_queue#Preparing_for_deployment , plus I think it will need someone to actively maintain/steward this code base in the future. If there is nobody, see https://www.mediawiki.org/wiki/Code_stewardship_reviews

@Aklapper what you're suggesting is beyond us. Again, we're just humble en.Wikt editors, unfamiliar with how to even properly fill out tickets here on Phabricator.

@Victar: Which specific issue creates a problem and why? Happy to help but that requires me to know which specific issues create which problems...

@Aklapper From your reply, "See item 3 on https://www.mediawiki.org/wiki/Review_queue#Preparing_for_deployment", you're saying we should apply for various reviews, but we are completely unfamiliar in how to do so. If you can't help us, can you ping someone that might be able to?

@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.