Last modified: 2014-05-17 17:12:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T61245, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 59245 - Review the PageNotice extension for deployment
Review the PageNotice extension for deployment
Status: REOPENED
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: community-consensus-needed
Depends on:
Blocks: 31235
  Show dependency treegraph
 
Reported: 2014-01-03 11:43 UTC by This, that and the other (TTO)
Modified: 2014-05-17 17:12 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description This, that and the other (TTO) 2014-01-03 11:43:48 UTC
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
Comment 1 Steven Walling 2014-01-04 01:06:42 UTC
(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
Comment 2 Jared Zimmerman (WMF) 2014-01-04 02:13:58 UTC
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.
Comment 3 p858snake 2014-01-04 02:22:13 UTC
(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.
Comment 4 Kunal Mehta (Legoktm) 2014-01-04 02:24:54 UTC
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. :)
Comment 5 This, that and the other (TTO) 2014-01-04 06:43:37 UTC
(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.
Comment 6 Jared Zimmerman (WMF) 2014-01-04 08:01:29 UTC
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.
Comment 7 Steven Walling 2014-01-04 08:11:28 UTC
(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.
Comment 8 This, that and the other (TTO) 2014-01-05 03:50:37 UTC
You may be interested in Gerrit change #105434, which implements a PageNotice-like feature in MediaWiki core.
Comment 9 This, that and the other (TTO) 2014-05-03 07:39:14 UTC
Lowest priority. I'm no longer really interested in this.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links