User talk:Quiddity (WMF)

Jump to: navigation, search

About this board

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL (talkcontribs)

I was going to reply to your comment at the hovercard-talkpage, but the discussion is locked against anons.   ("Reason:  excessive everything")

Here is the talkage, section is "Similar browser extensions or add-ons to be inspired by"

First, a complaint slash anti-comment:  

  • "...To show how popular the idea was (proving we ought to implement something)..."

Please don't think like that.  en:WP:NOTFACEBOOK is important.  Just because something is popular on other websites built with other purposes and priorities in mind, does NOT prove that the wmf ought to waste time implementing 'it' (whatever feature 'it' happens to be) for use on wikipedia.  There is such a thing as a misfeature.  For instance, I'm sure you could do some research, and learn that most major websites have banner-adverts.  That is a very popular thing.  But just because it is popular, very much does not mean, that wikipedia also should be doing it.  See the parable of your friends, and jumping off the bridge.


Second, my question slash fear is, I notice that #1) the explanation of the hovercards feature is silent on whether it will popup a hovercard for enWiki links only, or whether it will also popup a hovercard for ELs.  I further notice that #2) there are plans to make hovercard 2.0 or whatever, eventually support interwiki-popups.  Are there plans to make hovercards for ELs?  Because with the exception of interwiki links (frWiki and wiktionary and such), that is probably a en:WP:BADIDEA thanks to unintended consequences.  The main reason that other websites implement hovercards, is related to banner-advert revenues.  Why wait for the reader to actively CLICK on linkspam, when you can forcibly shove the advertising into their faces merely when they move their mouse around?  In terms of enWiki and other wikipedia projects, implementing hovercards for footnotes is extremely useful, and implementing hovercards for wikilinks and interwikilinks will also be SOMEWHAT useful. 

But don't make the mistake of assuming that, hey we need hovercards for ELs just like we have them for interwiki-links.  That would incentivize increasing refspam, inline-EL-linkspam, and other kinds of undesired edits.  I understand that technologically implementing interwiki-hovercards is not much different than implementing EL-hovercards, but don't treat them as the same sociologically, they will have very different impacts.  And just because other websites do it, should not be treated as 'proof' wikipedia websites ought to follow along.  Best, ~~~~

Quiddity (WMF) (talkcontribs)

Hi. 1) Yup, I agree that common sense is required! (and also not always very common/widespread, despite the name! [the term always makes me think of Calvin...])

2) Yikes, no! I've never even seen that suggested before, and completely agree it would be a terrible idea. I would add detail to that, and explicitly say that it should not even consider interwiki links to non-Wikimedia-wikis (i.e. most of the items in the top-half of Special:Interwiki) but I'll emphasize nobody has ever suggested it should. Definitely 100% not.

Thanks for elaborating on your concerns though!

Reply to "future of hovercards"
MediaWiki message delivery (talkcontribs)

Hello! Thank you for leaving feedback on the Wikistats - Future per report page. We read it carefully and designed a set of wireframes that reflects your priorities. We're now looking for feedback on the design, and we'd love your input. We have key questions that touch on different sections, and links for feedback here: Request for feedback/Round 1 (if you prefer email, write to and please include "Wikistats Design" in the subject). Please comment by Monday, February 13th so we can include your thoughts and iterate. Thank you very much!

Your Wikistats 2.0 Team, 17:09, 3 February 2017 (UTC)

Reply to "Wikistats 2.0 Design Preview"
Sisi la famille (talkcontribs)

aime tu les chats

Sisi la famille (talk) 09:58, 21 January 2017 (UTC)

Reply to "Un p’tit minou pour vous !"
MediaWiki message delivery (talkcontribs)

James Forrester (Product Manager, Editing department, Wikimedia Foundation) 19:23, 14 December 2016 (UTC)

Summary by Quiddity (WMF)

Was testing Phab:T154156

Whatamidoing (WMF) (talkcontribs)
The Special Barnstar
This is a test.
Whatamidoing (WMF) (talkcontribs)

See phab:T154156.

Whatamidoing (WMF) (talkcontribs)
The Original Barnstar
Test 2
Whatamidoing (WMF) (talkcontribs)
The Special Barnstar
This is a test.
Whatamidoing (WMF) (talkcontribs)
The Special Barnstar
This is a test.
MediaWiki message delivery (talkcontribs)

20:22, 19 December 2016 (UTC)

Reply to "Tech News: 2016-51"
Kudpung (talkcontribs)

Hi Nick. I'ts a shame I wasn't able to assist at the Wikimania discussion I originally proposed and I hpe you didn't take my comments about it too personally. However, at en'Wiki we are far more advanced on the preparation for addressing these issues than the current make-up of the fOundation might realise. For one thing, Page Curationwas developed mainly at my lobbying and in direct collaboration with Erik and Brandon. Brandon had also begun work on precisely the same kind of landing page that your project at Edit Review Improvements appears to suggest, and I strongly reccommend you read his recent comment to me at because these are the local Wikipedia project discussions that the WMF is rarely aware of.

Hus a lot of thre groundwork has already been done and we will shortly be starting an RfC to introduce a very long overdue user-right for operating the suite of Page Curation tools. With this in mind, after now 4 years of its use, we realise that some essential elements were no included in the code, and which I would like the WMF devs to address. These issues do not require a community consensus as they are basically aimed at bringing the drop down options in the Curation control panel in line with the more comprehensive Twinke tool which theoretically should no longer be being used for New Page Patrol. The fundamental difference between Twinkle and Page Curation is that Twinkle is a community developed and maintained script which can be modified with very little fuss, while Page Curation being MediaWiki hard-coded requires long, and often bitter requests through Bugzilla or Phabricator and depends upon the Foundation's own perception of priorities.

I hop you will allow me to discuss these minor changes with you in detail. When you reply here, please ping me on my en'Wiki talk page. Refgards, Chris.

Quiddity (WMF) (talkcontribs)

Hi Kudpung, It was good to talk with you at Wikimania.

You requested a link to the notes from the session: I've copy&pasted them into the page at wm2016:Discussions/Quality_tools

I've re-read that /Archive_4 link, which I'd read before, but still found useful to see again. I've also looked through Article Creation Workflow/Design again, and I still agree that it contains many great ideas. I also agree with Noyster's comment that we need to improve the information that people get when they first register their account.

Generally: As we discussed earlier, it would probably be smoothest for everyone, if you and I could figure out the rough requirements, so that we can get a thumbs-up from the devs on various options, before broader discussion. That way you'll know, and be able to explain, any development complexity that might exist with the various options, before starting the wider RfC discussion.

Specifically: You mentioned at Wikimania and above, the idea of introducing a user-right for operating Page Curation. There is already a user-right required, the one named "patrol". However, that right is given to all autoconfirmed accounts (per w:en:Special:ListGroupRights - ctrl-F for "patrol"), so it does make sense to change the requirement for Page Curation wranglers, to something that is less easily & automatically obtained.

I believe it is easier for everyone concerned (from editors to admins to bcrats to devs) if we re-use an existing user-right, rather than creating a new user-right (and all the code and translations and policies and other documentation that tend to go along with a new user-right or user-group).

From a look at the existing user-rights, I'd tentatively suggest that re-using the "review" user-right, might work well. It is only currently given to the group "Reviewers" aka "Pending changes reviewers", of which there are currently 1,295 administrators and 6,629 pending changes reviewers on the English Wikipedia. Only admins can assign/remove editors from that user-group. I'll ask a dev to comment with some better ideas.

Let me know what you think of all this. (And hopefully I won't need to ping you manually, due to the magic of cross-wiki notifications and flow, doing so automatically!). Cheers.

Kudpung (talkcontribs)

Hi. Thanks for the ping (I don't know why the cross-Wiki notifications does not work for me - it seems to be frozen on 99 and I can't find a way to clear it). I'll be replying in more detail as soonas I've dug out some more background for you). Best, Chris.

Quiddity (WMF) (talkcontribs)

Update: I've struck out my suggestion, as it was flawed.

However, Matt points out that the "patrol" user-right is already given to the "Pending changes reviewers" user-group, so, if we just removed "patrol" from "auto-confirmed", that would potentially solve it in one.

Questions to answer:

  1. Are we sure about using one group for both (do we trust the same users to publish unpublished text (PendingChanges) and to just review already-published text (patrol)?
  2. Is "Pending changes reviewers" too narrow a group of people

Possible outcomes:

  1. Create a separate Patrollers group with only 'patrol'.
  2. Add more people to the Pending Changes Reviewers group (bearing in mind they can also publish unpublished pending changes).
  3. Other.
Kudpung (talkcontribs)


Stage 1  is to make some minor expansions to some of the features of the Page Curation fly-out (doesn’t require  a RfC, just the collaboration of a WMF engineer) to bring it in line with Twinkle. We do know that some users are still patrolling with Twinkle because its CSD criteria are more granular.

Stage 2 is to get a user right created for patrolling mew pages, i.e. access to the New Pages Feed and the Page Curation tool. This will also have the effect of providing feedback on who is actually patrolling pages and allow those who monitor the system to provide help to patrollers as requiredI’m suggesting 90/500 - it has to be higher than reviewer or rollback, or the 30/500 I got introduced for AfC. Grandfather only those who have patrolled at least 100 pages in the last 12 months. Deprecate the current New Page Patroller userbox. On successful adoption by the community of the user right, send a nesletter to all those who no longer automatically meet the new criteria, inviting them to reapply. User right to be requested at PERM.

Stage 3 is to  deprecate the old new page feed and stop people using Twinkle , Stiki, and Huggle tp patrol pages in an attempt to get all patrollers singing from the same page.

Stage 4 (ultimately) Merge AfC with NPP. We actually already have a community consensus for this but it was decided to wait until the requirements for NPP have been established and rolled out.


The reason why we  have the staggering number of 6,629 pending changes reviewers on the English Wikipedia is because when it was first created, the right was accorded in early 2010 by a bot based on a very low threshold of criteria - the lowest requirement of all the minor user rights on en.Wiki. In the 2009 pre-RfC poll for Pending Changes it clearly stated that there is no comparison with flagged revisions (Pending Changes) and the Patrolling of New Pages, and that in any case, NPP  does not lend itself well to being carried out by Huggle (or other mass-editing or speed-editing scripts as we now understand it).

The recommendation to admins is to grant the pending changes reviewer on a fairly liberal basis. Recent blocks or noticeboard threads should generally not be used as a reason to deny a user the right upon request. The reviewer right simply re-enables a tacit ability autoconfirmed editors possessed prior to the implementation of pending changes—the ability to approve anonymous edits. Essentially, Reviewers do not take responsibility for the correctness of edits they accept. A reviewer only ensures that the changes introduced to the article are broadly acceptable for viewing by a casual reader. the rights can only be removed by an administrator after a community discussion has taken place.

The next user-group minor right of the edit-quality-control kind  is Rollbacker which was unbundled from Admin some years ago. Accorded by admin discretion following a fairly thorough examination of the user's experience, it is never given for less than 200 mainspace edits and at such a low level of experience, graduation through the Counter Vandalism Academy is recommended.

Finally, but not a MediaWiki controlled access, is the use of the Articles for Creation helper script, a development by a volunteer. AfC is a process that permits articles to be submitted through the Article Wizard or the Draft:Namespace by users who are otherwise technically or through sanctions are not permitted to create articles immediately in mainspace. AfC reviewing is a fairly complex process and while it is theoretically still possible for anyone with a registered account to accept or decline AfC submissions, the helper script is practically essential and a sub-routine developed by a volunteer prevents the use of the script by any user not having at least 30 days tenure and 500 mainspace edits - a requirement I suggested and proposed and which was accepted by a solid consensus, and passed the scrutiny of the AfC project members.

Landing Page (Article Creation Workflow/Design):

Many years ago, not knowing that ACTRIAL was going to be ruled out by the Foundation, in anticipation of ACTRIAL I began to develop a reworked Article Wizard as part of the ACTRIAL package. The WMF had not taken into account (at that time) the full package of the trial we had  proposed and  ruled the trial out without understanding the full scope of what the  community had agreed to by an overwhelming majority on a very highly subscribed debate. As a result however, parallel to the development of Page Curation, and partly based on my ideas for an improved Article Wizard, Brandon began work on Article Creation Workflow/Design. Knowing what is required here, I would be happy to collaborate with the Foundation to get it, (or something like it) finalised; Brandon's ideas have enormous potential and could certainly be used as a starting point.

Quiddity (WMF) (talkcontribs)

Hi Kudpung, my apologies that it has taken me so long to get back to this, and thanks for your notes on some of the background context.

Replies in order:

Stage 1
If I understand correctly, you just want to add (or change) a few of the options in the "Add tags" and "Mark for deletion" sections of the Curation Toolbar.
  • Is that accurate?
  • Do you have a list already, of which options to remove, and which to add?
Stage 2
OK, from that description, and from looking at w:en:Special:ListGroupRights and m:User groups and trying to keep things tidy, it sounds like the proposal you are recommending is:
  1. Create a new user-group on Enwiki called "Patrollers" (or similar)
  2. Add the user-right "Patrol" to this new user-group
  3. Remove the user-right "Patrol" from these user-groups: "Autoconfirmed", "Confirmed", and "Pending changes reviewers". (Leaving it assigned to "Administrators" and the new "Patrollers")
  4. Create a documentation page for this new user-group. (To be summarize at, and linked from, w:en:Wikipedia:User access levels)
  5. Automatically assign all editors who have 90+ days and 500+ edits, to this new user-group.
  6. Verify that all editors, who have completed patrols of >100 pages in the last 12 months, have been assigned to this new user-group. (Grandfathered in).
  7. Send a newsletter to all those who no longer automatically meet the new criteria, inviting them to reapply at w:en:WP:PERM
  • Is that accurate?
Stage 3 & 4
Let's discuss these later.


Kudpung (talkcontribs)


Stage 1: Yes I do have a list of tweaks. I sent it to Jonathan after my Skpe discussion with him. I naturally assumed that his job would have been to pass that information on to you.

Stage 2: Almost right.

  1. Yes
  2. Not quite sure what you mean here. The user group "Patroller" (Ultimately I would like to see this called 'New Page Reviewer') accords access to the features of the New Pages Feed and the operations of the Page Curation Toolbar (which we sommetomes refr to as the 'fly-out'. It also restricts access to the tags in Twinkle that are specifically related to placing CSD, PROD, and AfD tags. Non NP Reviewers would still be able to see the list at New Pages Feed, but if they try to click on anything the would be met with: 'Sorry, you do not have access to this. Please see the requirements at ...'
  3. If 'Patrol' means New Pages Patrol, then it should be removed. But if I have understood correctly these 7 years, there is not, and never was any usuer group or permission accorded to, or required for patrolling new pages. Otherwise, we should avoid confusing the new right to patrol new pages with any other rights at User Group Rights
  4. Yes - I have such a page in development which is essentially based on W:en:New Pages Patrol. Again, see W:en:User group rights
  5. Absolutely not. We do not blanket accord special maintenance user rights of any kind to to all registered accounts which have met a threshold. It is essential for new page patrolling that patrollers have not only reached the minimum metrics of participation on Wikipedia, but pass an administratro's scrutiny. This is the way Rollbacker is done. 90+ days and 500+ edits is the recommendation and this is based on the criteria I proposed and was given consensus for at te far less important and less critical optional AfD process.
  6. Yes. This might have a few misfires because some of them have sice been blocked, or t-banned from patrolling new pages, but admins would have to look at that on a case-by-case basis.
  7. That is correct. I have already drafted a newsletter somewhere. I also have the list which I prepared for the Survey Monkey poll I I did with the (partial) support of the WMF in 2012 which just needs updating, and the names of other users who have patrolled pages since.

Please understand that I am not alone in proposing these reforms. I'm just the coordinator of our local task force. But I did pioneer W:en:ACTRIAL and the initiative to get the Foundation to develop The New Page Feed and its Page Curation tool.

Stages 3 & 4: Yes, we can indeed talk about these later - but not too much later. There is also the question of relaunching my initiative for a proper landing page for new, new article crators, to improve/replace Article Wizard which Brandon began but was forced to abandon. The landing page, the Draft namespace, and NPP are all the core element of controlling the quality of new pages and are inseparable. The mission is to do such contolls while avoiding discouraging new editors from creating appropriate articles. The background to all this is also in the document I sent to Jonathan. That document is a 17 page sprawl, but by using excepts of earlier Wikipedia discussions, it serves as a minutes to our Skype meeting and to bring him up to date because I believe he may be new to all this.

Quiddity (WMF) (talkcontribs)

Stage 1: Ah, I haven't had time to talk to Jonathan since your discussion with him. (So many things to do!!! For everyone!). I will followup with him, a.s.a.p.

Stage 2:

#2 & 3: The NPP software is currently restricted to usage by editors with the "patrol" user-right. However, as I noted above, that user-right is currently given to the auto-confirmed user-group (amongst others). (Ctrl-F for "patrol" in w:en:Special:ListGroupRights to check). This is silly, and should've been changed ages ago!
On Ewiki, there is not currently a user-group named "Patrollers". Some other wikis have a user-group with that name, but not Enwiki.
Hence, I'm suggesting creating a user-group with that name, and giving the "patrol" user-right to only that user-group (and admins of course).
#5, Right, I misunderstood what you'd written before. That makes sense now.

I'll talk to a dev about this, make sure that everything is accurate, and see what the next steps are. Thanks.

Kudpung (talkcontribs)

Thanks -also for explaining that patroller does in fact belong to the very basic user group - I missed that; nevertheless that is not to be confused with the user rights such as Reviewer, Rollbacker, Template Editor, Page Mover ,etc. I think it's essential you connect with Jonathan and as soon as possible , but probably the easiest thing to do would be for me to send you my minutes of that meeting. Admittedly it would take you 10 -15 minutes to read but it puts everything together, goes into explicit technical detail, and avoids any ambiguities.

This newgroup should preferably be called New Pages Reviewer, to distance it from older , pre-Curation concepts of NPP, and to maintain the distinction between it and Recent Changes Patrollers/Reviewers and Vandalism Patollers/Rollbackers.

Recent discussion among concerned members of the community have suggested that a 90/500 entry threshold might not be enough. We are looking seriously at these considerations because in actual fact, correct new page reviewing needs an almost admin-level of knowledge of notability and deletion policies. The stricter criteria of Page Mover (an essential operation for competent page reviewers) have been mentioned, but we also want to avoid overkill.

The main priority is to get the New Pages Feed and the Curation Tool debugged, updated, and the missing features inserted that were supposed to have been be done on its creation and on the creation of the 'Draft' mainspace. We were told by one junior staffer that the WMF is no longer interested in maintaining this software because it considered complete, but to many of us, such a statement was considered irrational.

That said, I'm pleased that this now appears to be making some positive steps, but the issues are getting more urgent by the day and the backlog at NPP has increased by yet another 2000 to over 11,000 since we last spoke.

I feel therefore that you and I, and perhaps DGG@DGG should not hesitate to meet over Skype the same way I did with Erik and Brandon and others while we were working on Page Curation - we want to get everything clear before we actually hand anything to the devs because their time and skills are costly and we don't want to waste it. Back in 2011, one half of the Foundation was saying there are insufficient funds available while the other half was saying that such a claim for something so critical was nonsense (diffs and/or emails available).

Also, the developing trend on en.Wiki at RfCs is to demand proposals that are compete with all points covered and pre-empted.

DGG (talkcontribs)

I've worked with Kudpung on this for several years now, and I very much support most of what he is trying to do. He has the the credit for having devised the proposals--my main contribution has been to suggest tweaks and to share experience.

I. I agree with the plan to fix the minor matters first--these are things that are immediately problems. II. I think we do need the new group, and the simplest criterion is the one being used for Extended Confirmed User, to avoid too many different standards. It has to be separate, because, as with Rollbacker, etc, admins could add people to it if their work warranted it. I would not grandfather. because there are just too many people--the ones of them who have continued patrolling will meet the new criterion & mot be affected; most, however will have stopped and will also not be affected. Those in the middle can ask for it.

III: I disagree about ending patrolling by Twinkle using the old new pages feed; I myself use it primarily, because I normally screen to find ones that either are in my field or that strike my eye, and I can do this only by scanning. Ithink we could find some way of limiting it.

IV. The really important step is merging the review of drafts and of new pages, with a common landing page and mechanism. I think it will very soon be time to begin planning this, tho I wouldn't want to implement it until the new userright had been accepted by the community and experienced for a while.

I opposed ACTRIAL, on the grounds that new users came here very often to make articles and should not be discouraged. But I have suggested directing all new users to the Draft process at least for their first article, and I'd support doing this by a script that would prevent them starting their first article anywhere else. DGG (talk) 15:41, 10 August 2016 (UTC)

Reply to "Page Curation (New Pages Patrol)"