Last modified: 2014-06-05 10:34:57 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 T20790, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18790 - Unwatched recent changes page via rc_watched
Unwatched recent changes page via rc_watched
Status: NEW
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
unspecified
All All
: Low enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: schema-change
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-13 21:55 UTC by mk
Modified: 2014-06-05 10:34 UTC (History)
8 users (show)

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


Attachments

Description mk 2009-05-13 21:55:35 UTC
Background: Vandalism is a problem on all pages, but it is a much larger problem on pages that, on average, have fewer or zero people watching them. One solution to this problem is Special:UnwatchedPages, which was requested by Jimbo, is accessible only to admins, is updated infrequently, and is therefore very difficult (impossible) to clean out.

This problem could be handled by adding an rc_watched column to the recentchanges table to store a watcher-count, based on the watchlist table at the time of the revision, and counting only editors that have been active in the past N (7) days. An alternative to schema modification is to use rc_type to store this information.

This would allow a "recent changes in unwatched articles" page. This page would catch vandalism that would usually have gone unnoticed for long periods of time, and encourage editors to take these pages into their watch-lists. It would eliminate the need for Special:UnwatchedPages. Vandalism of pages on this list would not be a problem, as such edits would be bumped to the top of the list and be twice as likely to be caught, and substantially more likely than at recentchanges due to lower volume.
Comment 1 Happy-melon 2009-05-13 22:11:13 UTC
Per bug11181#c11, no booleans --> bitfields (I only recently found that comment from Brion, using rc_type was originally my idea at enwiki VPR).  The performance increase from having an rc_watched column is offset by having to *populate* an rc_watched column... which is harder on the servers, querying once for many pages for the Special:RecentChanges/unwatched, or querying many times for one page every time an edit is saved to the recentchanges table? 
Comment 2 Alex Z. 2009-05-14 02:26:46 UTC
Doing the query on page save would likely be less load and if a schema change was done, it would be the only way; populating it on-demand would just be kind of odd and hard to do. If only 1 in 5 edits is to an unwatched page, you'd have to load the data for at least 250 to be able to hopefully generate a list of 50.

Counting only active editors would be possible, but it might add too much to the query to be usable. 
Comment 3 mk 2009-05-14 04:15:12 UTC
Another option might be to add page_watchers to the page table itself, which would be changed whenever a user watches/unwatches. This might be much less useful, since it would miss articles that have been abandoned.

An optimization is to populate the field with active users only when the watchers count is under 20 or 100. If there are that many watchers we can assume that at least a few of them are active. This would cut down on the need to join to users, though it would be a strange or double query.
Comment 4 Roan Kattouw 2009-05-14 07:58:58 UTC
(In reply to comment #1)
> Per bug11181#c11, no booleans --> bitfields (I only recently found that comment
> from Brion, using rc_type was originally my idea at enwiki VPR).  The
> performance increase from having an rc_watched column is offset by having to
> *populate* an rc_watched column... which is harder on the servers, querying
> once for many pages for the Special:RecentChanges/unwatched, or querying many
> times for one page every time an edit is saved to the recentchanges table? 
> 

The load for populating rc_watched on edit time shouldn't be too bad: determining whether a single page is watched is a very simple and very fast query.
Comment 5 mk 2009-06-07 18:48:27 UTC
(In reply to comment #4)
> The load for populating rc_watched on edit time shouldn't be too bad:
> determining whether a single page is watched is a very simple and very 
> fast query.
> 

This would be more useful if we had more information than just a boolean 'has watchers'. Can it be made to count the number of watchers without much strain, and in particular, autoconfirmed watchers active in the past 7 (or 60) days?
Comment 6 Chad H. 2009-07-15 19:52:20 UTC
Keep in mind that an rc_watched column will only be a page's watch status _at_ the time the action occurred. We won't go back and change old entries when they no longer are watched (or become watched).

Just something to keep in mind.
Comment 7 Mark Hurd 2009-07-15 23:44:19 UTC
(In reply to comment #6)
> Keep in mind that an rc_watched column will only be a page's watch status _at_
> the time the action occurred. We won't go back and change old entries when they
> no longer are watched (or become watched).
> 
> Just something to keep in mind.

I believe that would be the preferred scenario anyway: we want to know about changes that weren't being watched when they were made, not before or after.
Comment 8 mk 2009-07-19 22:54:07 UTC
At the enwiki VPR discussion for this feature (which, it should be noted, currently has 22 unanimous supporters), a couple of editors were concerned that making this feature immediately public might expose unwatched articles to vandalism, were the list subsequently shut down due to bugs. I don't think this is a problem - if even 1000 unwatched articles were edited during this time, editors would have little trouble watching all of them. But the concern deserves mention here. The discussion and straw poll:

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Recent_unwatched_changes_straw_poll


(In reply to comment #7)
> I believe that would be the preferred scenario anyway: we want to know about
> changes that weren't being watched when they were made, not before or after.
> 
This is my view also.


What steps would need to be taken to have this feature implemented? If someone were to try to create a patch, what files should they look at, what should they be aware of, and where should they begin? (Though this seems to be something for those familiar with the code, perhaps a few steps can be taken care of by others.)

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


Navigation
Links