Page MenuHomePhabricator

Review the PageNotice extension for deployment
Open, LowestPublic

Description

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 initial 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.
Other use-cases include:

  • a standard header on all article talk pages,
  • a standard notice on Wiktionary Reconstruction: namespace pages (described in comments below, with community support),
  • a standard CC-O notice on Mediawiki-wiki Help: namespace 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


Version: unspecified
Severity: enhancement

Details

Reference
bz59245

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 2:18 AM
bzimport set Reference to bz59245.
bzimport added a subscriber: Unknown Object (MLST).
TTO created this task.Jan 3 2014, 11:43 AM

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. :)

TTO added a comment.Jan 4 2014, 6:43 AM

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

TTO added a comment.Jan 5 2014, 3:50 AM

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

TTO added a comment.May 3 2014, 7:39 AM

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2015, 9:31 AM
Luke081515 closed this task as Declined.Feb 2 2016, 12:23 AM
Luke081515 added a subscriber: Luke081515.

Declined per T124354. There is no consensus for this change yet. Please reopen the task if consensus reached.

Luke081515 reopened this task as Open.Feb 2 2016, 12:45 AM
Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 8:44 PM

May be a solution for T6469

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

TTO added a comment.EditedAug 21 2018, 12:32 PM

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

Victar added a subscriber: Victar.Sep 26 2018, 5:22 AM

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.

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.

Erutuon added a comment.EditedJul 25 2019, 6:51 PM

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?

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

Aklapper added a comment.EditedJul 31 2019, 11:20 PM

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

Victar added a comment.EditedJul 31 2019, 11:44 PM

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

Victar added a comment.Aug 1 2019, 7:11 PM

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

Aklapper added a comment.EditedAug 1 2019, 10:07 PM

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

This comment was removed by Victar.
Aklapper removed a subscriber: Aklapper.Aug 1 2019, 11:44 PM

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.

Reedy added a subscriber: Reedy.Aug 3 2019, 9:05 AM

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

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

Done in T174657: Convert PageNotice to use extension registration.