Last modified: 2007-11-22 19:01:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1405 - Split patrolling into new page patrolling and recent changes patrolling
Split patrolling into new page patrolling and recent changes patrolling
Status: VERIFIED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.12.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
N/A
: patch, patch-need-review
Depends on:
Blocks: 3741
  Show dependency treegraph
 
Reported: 2005-01-25 15:42 UTC by Thue Janus Kristensen
Modified: 2007-11-22 19:01 UTC (History)
3 users (show)

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


Attachments
Split patrolling up into new page patrol and recent changes patrol (8.04 KB, patch)
2005-01-25 15:43 UTC, Thue Janus Kristensen
Details

Description Thue Janus Kristensen 2005-01-25 15:42:34 UTC
RC patrolling on en.wikipedia was shortly enabled, but was disabled again
because it wasn't suitable to the fast-moving RC-list in that project (and maybe
for other reasons).

But one part of that feature which I liked was patrolling on special:newpages.
That pages moves relatively slowly, and it is a great help to be able to mark
which articles are checked.

Therefore it would be nice to be able to enable patrolling on special:newpages only.

The following patch does:
*Split patrolling into RC-patrolling and NP-patrolling, with a new
$wgUseNPPatrol configuration variable
*add missing 'markedaspatrollederror' and 'markedaspatrollederrortext' texts
(they were also missing before this patch)
*Four combinations of RC and NP enabled are possible:
**RC=0, NP=0: As before this patch with patrolling disabled.
**RC=1, NP=0: Both edits and new pages can be patrolled, but there is no patrol
markup at special:newpages, and pages visited from special:newpages does not
have a patrol link.
**RC=0, NP=1: Only new pages can be patrolled, and the patrol link is only shown
when a page is visited from special:newpages.
**RC=1, NP=1: As before this patch with patrolling enabled.

It would also be nice to have the features implemented in Bug 1401 for new page
patrolling.
Comment 1 Thue Janus Kristensen 2005-01-25 15:43:27 UTC
Created attachment 227 [details]
Split patrolling up into new page patrol and recent changes patrol
Comment 2 Alex Z. 2007-10-29 17:49:40 UTC
With the plan to re-enable anon page creation (Nov. 9) on the English Wikipedia, this would be an extremely useful tool to have on Special:Newpages.
Comment 3 Gregory Maxwell 2007-10-29 20:44:09 UTC
I don't think that I am personally in favor of enabling this on English Wikipedia at the same time we allow anons to create pages again for the simple reason that it will disrupt our ability to measure the effect of allowing anons to create pages. 

However, this seems like an obvious and helpful change. As such, I've updated it against the current codebase and committed it: http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=27025
Comment 4 Ryan Kaldari 2007-10-31 21:08:36 UTC
I would oppose re-enabling anon page creation until a feature such as this is live. Whether or not this skews your data is less important than making sure that all new articles are reviewed in a timely and efficient manner. We cannot afford another Seigenthaler incident, after all.
Comment 5 Casey Brown 2007-10-31 21:57:34 UTC
(In reply to comment #4)
> I would oppose re-enabling anon page creation until a feature such as this is
> live. Whether or not this skews your data is less important than making sure
> that all new articles are reviewed in a timely and efficient manner. We cannot
> afford another Seigenthaler incident, after all.
> 

Please comment on the mailing list about that: <http://lists.wikimedia.org/mailman/listinfo/wikien-l>

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


Navigation
Links