Last modified: 2014-11-17 10:35:22 UTC
Currently to [Mark this page as patrolled] you need to follow the link to the page from [[Special:NewPages]]. It would be better if the [Mark this page as patrolled] button was always visible if a page has not yet been patrolled. For example this would allow you to patrol a page after you have added a deletion template without having to navigate back to [[Special:NewPages]].
Done in r45778
Backed this out in r46542 for now -- the extra checks have caused nasty performance regressions.
From what I can see in the commit and the revert-resion this made it check on every page view. Although that would be nice, the 'bug' is more specific. Bug/Logic: When in a Difference-view the rcid is automatically found and a [mark as patrolled] link is put in place when appripiate. When in an old-id (such as for the first revision) this check it not occuring causing the annoying to look up the page on [[Special:NewPages]] and patrol it from there. If this check would only be executed when in an oldid-view, would that be acceptable regarding performance ? Or is the performance problem not in the visiblity pages that the check was on but in the ineffeciency of the query itself ?
The thing that does it in the difference view was done in r24607 in DifferenceEngine.php[1] by the way. [1] r1=24606&r2=24607">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/DifferenceEngine.php?&pathrev=24607&r1=24606&r2=24607
This would be really useful as Special Newpages is frequently backlogged to 30 days. If this was enabled there are plenty of occasions where wikignomes would mark such new articles as patrolled when we found them whilst categorising and so forth. If there are still performance issues perhaps it could only be shown to auto confirmed editors or editors who have previously marked articles as patrolled.
Is there any way this could be an "opt-in" preference for those of us who are interested in patrolling, but discover new articles not via the Special:Newpages link. First stage: opt-in for all (ie default setting for all if off, announce it at some key talk pages for those interested to try it out) Second stage: (if performance not affected) opt-out for Admins third stage: opt-out for autopatrolled users 4th stage: opt-out for autoconfirmed users
(In reply to comment #6) > Is there any way this could be an "opt-in" preference for those of us who are > interested in patrolling, but discover new articles not via the > Special:Newpages link. > > First stage: opt-in for all (ie default setting for all if off, announce it at > some key talk pages for those interested to try it out) > Second stage: (if performance not affected) opt-out for Admins > third stage: opt-out for autopatrolled users > 4th stage: opt-out for autoconfirmed users If we're going to do this, I think we should find a way to do it for everyone. Having a feature that's semi-scary performance wise, and relying on not too many people opting in in order to be acceptable just seems like something that will go wrong.
One thing about performance issues is that Moore's law requires us to re-evaluate them periodically - what was a performance issue in 2009 may still be a performance issue today, but is no more likely to be a performance issue in 2019 than a 2001 performance issue is to be a problem today. Another is that they can often be overcome either by rewriting the code or adding more kit. This despite its low rating is actually quite an important project, and an uncontentious improvement to newpage patrol is a rare and precious opportunity. I'm not sure I could argue that it was worth putting a million dollars of hardware into, but if the performance issues could be resolved by buying another 100,000 worth of hardware then I think we'd have a good chance of selling this to the board. If the performance issues did need a couple of million dollars worth of today's kit to resolve then it would be fairy easy to decide to do this when hardware price performance has improved by a certain factor. Alternatively would it resolve the performance issues if we made this a button that appears for all logged in editors who have done more than 100 edits? We really want editors to get a bit of experience before they start patrolling, so having such a throttle should be uncontentious, especially if it was presented as needed for performance issues. You'd also want to exclude bot accounts, I suspect that would make a difference in performance terms and unless someone coded a bot patroller this shouldn't affect bots. Another option to resolve the performance issue. Only enable it at quiet times of the 24 hour cycle. We'd still get half the benefit of this change if this was running in the 16 hours of the day when half the editing takes place.
Bawolff, surely you have some data on other "gadgets" or options hidden in preferences and how quickly people "opt-in"? I can't see many people at all doing it - probably less than 100 in the first few weeks if it is only advertised at NPP related talk pages, maybe more if it's on the watchlist notice or signpost. And surely it can be marked as the first thing to be turned off if is too much of a performance drain. But can the performance issue be investigated and solved, rather than ignored?
I was hoping that this could be done as a standard feature - but I suppose it would do no harm to have an opt out for editors who positively don't want it. If you made it opt in we'd then have to market the idea to thousands of people, many of whom would scarcely ever use it. BTW would this be skin dependant? If so we might be able to resolve the performance concerns by only introducing it in Monobook
Opt in would be to test it... if it works, then switch to opt out.
In other circumstances that would be an interesting way to go. Though I'm not sure how you avoid the situation of people considering the option and deciding not to opt in and then finding themsevles opted in and having to opt out. But as I understand it we already have working code on an uncontentious enhancement and the only issue is performance. So testing it with a few users would not establish whether the performance has been resolved - better to test it for a short period of time or a given subset of users - all admins and reviewers for example.
I gave this another try (this is much more database friendly than the last one): https://gerrit.wikimedia.org/r/41196 Waiting for review
Thanks to Tim and the Amsterdam Hackathon we got this one merged :)
(In reply to comment #13) > I gave this another try (this is much more database friendly than the last > one): > https://gerrit.wikimedia.org/r/41196 Waiting for review Hoo pointed out, tallking about bug 48928 comment 5, that the commit message contains this passage I had not understood so far: > In case recentchanges patrolling is enabled this will try to > create a patrol link for the revision the user is currently > viewing. If only new page patrolling is enabled it tries to > create a patrol link for the first revision of the page. As we were speaking about page patrolling I never thought about RC patrolling, but the assumption was wrong. The second sentence, by "patrol link for the first revision", means page patrolling; and the first sentence, by negation, implies that the patrol link is *not* for the whole page but for a revision (the last one).
This bug should have been marked as invalid, not fixed. There's a reason the patrol link is only added for people coming from Special:NewPages, namely that it is confusing to users otherwise, especially in the case where they are using a different patrolling tool like PageTriage (Special:NewPagesFeed). If you want to be able to do edits and add tags without loosing your patrolling interface, you should try Special:NewPagesFeed. It retains the interface across edits. Having 2 competing interfaces on the same page is bad interface design.
(In reply to comment #16) > This bug should have been marked as invalid, not fixed. There's a reason the > patrol link is only added for people coming from Special:NewPages, namely > that > it is confusing to users otherwise, I don't see how it can be confusing. The patrol link for edit patrolling is shown on every diff. Nobody raised this concern in years and the original patch was reverted only for performance reasons; requiring rcid was *not* done for a reason, it was just a limitation. > especially in the case where they are > using > a different patrolling tool like PageTriage (Special:NewPagesFeed). If you > want > to be able to do edits and add tags without loosing your patrolling > interface, > you should try Special:NewPagesFeed. It retains the interface across edits. This is not a valid suggestion. New pages patrolling is in core, that's an extension. Moreover, the extension adds many other features. > Having 2 competing interfaces on the same page is bad interface design. Sure, it's annoying that this change was not coordinated with the extension. :[ PageTriage should hide the link if it has a competing interface, not too hard to do I hope. This will also fix the problem of competing interfaces for people adding the rcid manually or with scripts. However, note that this bug was not fixed completely, see bug 48928: currently, in some cases you actually need &patrolpage=1 to see the link. If the button being used also for edit patrolling causes confusion, the most obvious solution is amending the change to make the button about page patrolling only again, so that it disappears after the page ("first revision") is patrolled.
(In reply to comment #16) > This bug should have been marked as invalid, not fixed. There's a reason the > patrol link is only added for people coming from Special:NewPages, namely > that > it is confusing to users otherwise, especially in the case where they are > using > a different patrolling tool like PageTriage (Special:NewPagesFeed). If you > want > to be able to do edits and add tags without loosing your patrolling > interface, > you should try Special:NewPagesFeed. It retains the interface across edits. > Having 2 competing interfaces on the same page is bad interface design. Originally (and for some time, maybe not recently) the reasons were technical (though I think a mistaken due to getting blamed for the results of some orthogonal slow queries).
(In reply to comment #17) > However, note that this bug was not fixed completely, see bug 48928: > currently, > [...] you actually need &patrolpage=1 to see the link. Bug 48928 was fixed, I've split the complete fix of this bug to bug 49123 ("New page's patrol button should always be visible, even when not having special links"). For the new change patrolling button now always visible at bottom of the page, bug 49115 was filed to make the button itself clearer.
