Wikipedia:Village pump (proposals)

Would a system of specialized blocks be helpful? Dustin (talk) 02:41, 24 July 2014 (UTC)[reply]

Note: This was partly discussed beforehand at Wikipedia:Village pump (idea lab)/Archive 14#Specialized blocks, and I have decided to bring my proposal here. Please read that page first, though. I have started this as an RfC because I consider it to be of significant importance.

(The following has been copied from the idea lab)

The following is a proposed change to the MediaWiki software.

I don't know if something like this has already been proposed, but a brief search on my part didn't turn up something like this, so I will put forth my ideas. Here is my possible proposal, but I am going to give it here first just so we can discuss it and refine the idea beforehand. I would propose that we modify the MediaWiki software as to allow for specialized blocks. Blocks currently only have two options: a block on editing all pages except for a user's own talk page, or a block on all pages, including the user's own talk page. In my new "specialized" block system, there would be many more options.

1. An administrator could block a user for disruption from editing either a specific, individual page, or the block could apply to a selection of pages. In cases where a user cannot be trusted to follow a topic-ban or does not feel that he/she can follow his/her restrictions, then an administrator could simply block that user from editing a list of manually selected pages which are "at risk".
2. An administrator could block a user from editing all pages (minus manually chosen exceptions) that have a certain prefix. For example, if one user was being overly disruptive on SPI pages (and I am not talking about vandalism), then an administrator could block that user from editing all pages starting with "Wikipedia:Sockpuppet investigations/".
3. If there were situations where it was desired that an editor requesting an unblock edit one page apart from his/her talk page similar to this recent instance (but where the user could not be yet trusted to stay on only his/her talk page and the one exception page), then the block could be modified to ignore that one page.

I do not know how we would implement this because it is necessary that someone would develop this feature, but that is something to consider at a later point. I just want to know the opinions and/or ideas of editors. Dustin (talk) 02:42, 24 July 2014 (UTC)[reply]

• I support the general idea, though the specifics of what kind of granularity we want is up for grabs. In particular, one thing I definitely would find useful is the ability to block IP ranges (perhaps as large as /8) from specific pages. Currently the only way to do this is with an edit filter, which impairs performance. -- King of ♥ ♦ ♣ ♠ 02:50, 24 July 2014 (UTC)[reply]

  Actually, what Graeme Bartlett said makes a whole lot of sense. And it should be possible to select an IP range as the user to be restricted by the filter. -- King of ♥ ♦ ♣ ♠ 03:43, 26 July 2014 (UTC)[reply]

• Oppose because it would require development support from the WMF. These are essentially topic-bans with supporting block. Robert McClenon (talk) 02:52, 24 July 2014 (UTC)[reply]
• Strong oppose The discussions on blocks have been extensive and the community has been pretty clear...no further options are required or needed. No support from me. Sorry.--Mark Miller (talk) 02:59, 24 July 2014 (UTC)[reply]
  • You obviously have neither looked at the previous discussion like I suggested, nor at the links at that discussion. Back in 2005, nine years ago, there was another proposal like this one, and it received over 80% approval. I know that was a long time ago, but why should we not reconsider? Dustin (talk) 03:04, 24 July 2014 (UTC)[reply]
    • I don't give a crap about that as you don't give a crap about other discussions so just stop complaining and let this go to the community now. You said your piece. If that isn't enough, you failed.--Mark Miller (talk) 03:08, 24 July 2014 (UTC)[reply]
• Having this discussion here somewhat clouds the purpose of the discussion. If the goal is simply to come up with a technical specification of what such a system would look like, mediawiki.org would be a better location. A discussion here will inevitably involve local policy implications and we need to have some concrete idea of what the feature's capabilities are before such a discussion could reasonably proceed. Mr.Z-man 04:20, 24 July 2014 (UTC)[reply]

I would wonder if this is actually a local issue for Wikipedia as proposed by Dustin. I may think that dragging a discussion from 9 years ago, into this discussion isn't even relevant today but hey....lets let this go its course and see what happens.--Mark Miller (talk) 04:27, 24 July 2014 (UTC)[reply]

• Support As I said on the idea lab this could be an edit filter just applying to one user (or IP). When optimised so that the filter only ran for 1 user there would be no performance impact on the rest. There would be plenty of fine grain here, denying uploads, moves, use of interaction banned users talk pages and so on. Graeme Bartlett (talk) 07:28, 24 July 2014 (UTC)[reply]
• Support However, like Graeme Bartlett I would suggest to go into the direction of edit filters that apply to individual users or IP ranges. --AFBorchert (talk) 08:41, 24 July 2014 (UTC)[reply]
• Not persuaded that usefulness outweighs the effort and complexity. For logged-in editors, this idea is a non-starter for me. If a particular user is subject to a topic or interaction ban, then either they stick to the terms of their editing restrictions, or they get blocked entirely. A user who lacks the maturity or restraint to adhere to an editing restriction (and, for that matter, who edited in a manner sufficiently disruptive to earn such a restriction in the first place) doesn't need additional technical constraints, they need to stop editing until they can control themselves.
  For IP addresses, I can see some argument for this as a way to reduce collateral damage (particularly when placing rangeblocks), but I suspect it will be more complicated than it's worth. Semi-protection already exists as a solution, though it does affect all IP editors of an article. (It's a bit blunt as a tool, but we already tolerate even long-term semi-protection of articles where warranted by circumstances.)
  From an admin standpoint, I can see this becoming rather complicated to manage and track. If I block an IP range from editing a particular article, does it show up in the IP's block log, or in the article's logs, or both, or neither? TenOfAllTrades(talk) 17:52, 25 July 2014 (UTC)[reply]
• Oppose This is a solution looking for a problem. It introduces complexity where none is needed. If a user will not follow restrictions then a conventional block will work. Either a user is willing to follow community expectations or they are not. Specialized blocks would result in gaming of the system. Chillum 18:06, 25 July 2014 (UTC)[reply]
• I wonder: Could selective whitelisting be used to keep someone blocked, but make it possible for them to clean up their own copyvios on specific, identified pages? That might be desirable. WhatamIdoing (talk) 18:49, 25 July 2014 (UTC)[reply]

  This goes to the point I made above. If we can't trust someone to follow editing restrictions without building a technical wall around their editing, I can't imagine we would trust them to perform a task requiring careful judgement like cleaning up copyvios—especially where they were the ones who introduced the copyright violations or plagiarism in the first place. TenOfAllTrades(talk) 19:03, 25 July 2014 (UTC)[reply]

  It's not unusual to see a request for someone to be fully unblocked so that they can help with copyright cleanup. That requires a lot more babysitting than providing access only to specified pages would. WhatamIdoing (talk) 23:16, 25 July 2014 (UTC)[reply]

• Support the idea, assuming it is technically possible. This would make more sense than existing practice in a number of areas. In the case of 3RR violations, for instance, if an editor is causing problems by edit warring on an article then our only option for stopping them is to prevent them from editing every single page, anywhere, even though they are only causing problems on one page. It would make more sense to prevent them from editing the one page where the edit warring is taking place. Hut 8.5 10:54, 26 July 2014 (UTC)[reply]
• Support - this would allow bans to be more-easily enforced, as well as a list of situations where it would be useful regarding blocked users (e.g {{2nd chance}}, unblock discussions in locations other than the user's own talk page). עוד מישהו Od Mishehu 19:56, 27 July 2014 (UTC)[reply]
• Support Seems like this would be a valuable addition to the admin toolbox. Toohool (talk) 01:18, 31 July 2014 (UTC)[reply]
• Support, ignoring the technical design requirements of which I know very little, but I think any idea worth implementing is worth doing the technical work. I'm a little concerned about difficulty using this for "broadly-construed" topic bans, but maybe we can implement a way to block users from editing pages in a particular category. It's a good idea, anyway. However, I also agree with what another user said above that if an editor can't play by community rules then full blocks and/or community bans are coming anyway. Ivanvector (talk) 15:41, 5 August 2014 (UTC)[reply]
• Support. I like the idea behind this, in principle. Calidum ^{Talk To Me} 01:31, 18 August 2014 (UTC)[reply]
• Strong oppose. This is not a good idea at all. Bans exist both to prevent disruptions to the community, and to give infringing editors the opportunity to remain a part of the community. They do this by abiding by the restrictions of their ban. If they are unable to do this, we gave them the WP:ROPE, and they have chosen by their actions to set themselves as being outside the community. Blocks are for those people who chose not to be a part of the community, either by contempt for the bans that the community has imposed on their editing, or by simply breaking obvious rules, eg vandalism. There is no "partial" being a part of this community. You either abide by the rules, or you don't get to participate here. Selective blocks just prevent those people who consider themselves outside of this community to demonstrate to us their decision to stand apart by violating their ban. Selective blocks open up a huge pandora's box of wikilawyering possibilities, and do nothing to promote the community. This is just plain a bad idea. VanIsaac_WS^cont 01:46, 18 August 2014 (UTC)[reply]
  • Using the word "strong" doesn't give your !vote any more weight (I don't see why "strong support" and "strong suppose" are ever used), but that being aside from the point, I don't think you considered proposal #3. Dustin (talk) 16:31, 18 August 2014 (UTC)[reply]
    • The word "strong" indicates that it is a categorical objection or support of the proposal, rather than, say, a preferential or logistical consideration behind a person's position. And since this is a !vote, of course every !vote is weighted; that's the entire point of it being a !vote. Even though I don't understand how situation #3 can even come about - if we can't trust someone whose contribution history is logged in one place (so it's easy to revert) to have access to more than one page, how could their actions on that one page possibly instill enough trust to allow them access to any more of the project? - #3 can still be accomplished with the current permission scheme by simply copying that article content to their talk page, where they can edit away. VanIsaac_WS^cont 18:59, 18 August 2014 (UTC)[reply]

Not sure if this is a proper format for an RfC, but here we go. Admins(explicitly not EFMs) are now permitted to make an edit filter that can block a user from editing certain pages while allowing them to edit others. This is to be treated as seriously as a block(admins are explicitly not to use these for TBANs unless a user made a TBAN infraction normally warranting a block.) For example, if a user requests to have their block discussed at ANI, that user would be unblocked and the filter modified so that the appealing user is blocked from editing any page except ANI. (To avoid confusion that would otherwise arise, admins would create one or two filters that would contain the entire system for blocking edits, something like: ((user_name==appeallingeditor) & (article_prefixedtext !='Wikipedia:Administrator's noticeboard/Incidents')) | ((user_name==TBANnededitor) & (article_prefixedtext =='ContentousArticle' | ...)) then block action, which would prevent appeallingeditor from editing any page but Wikipedia:Administrator's noticeboard/Incidents, and prevent TBANnededitor from editing ContentousArticle. (I'm sure someone can come up with some better code, I was just messing around) Cheers and Thanks, L235-Talk Ping when replying 21:31, 8 August 2014 (UTC)[reply]

• I see that you got more into the code than I ever did... at least from the way it appears, I think I would support this proposal because it would allow for stronger enforcement by administrators, and it would meet some of the goals of my main proposal above. Dustin (talk) 21:44, 8 August 2014 (UTC)[reply]
• Support in theory, but in practice, this may end up causing more trouble than it's worth if the number of edits which hit the EF condition limit is too hig (right now, it's at 0.77%, but it occasionally gets above 5%). עוד מישהו Od Mishehu 08:19, 13 August 2014 (UTC)[reply]
• Well the hitting the EF limits is why I suggested getting special support for edit filter per user or IP in the code. This would make it very efficient, as it would only run for the affected user. Graeme Bartlett (talk)
• This bot keeps on archiving this discussion, which is definitely an issue. What next now? I seem to have received at least some degree of support, so I don't think we should just archive this away. Dustin (talk)

  You could try filing a feature request at bugzilla and see if someone wants to program this functionality. And then perhaps another RFC to see if we want to enable it here if it ever gets programmed. –xeno^talk 03:12, 3 September 2014 (UTC)[reply]

Should the CSS-hidden navbar be removed from the base Stub (1.8 million pages) and WikiProject banner (5.5 million pages) templates? -- Netoholic @ 19:16, 30 July 2014 (UTC) (re-signing to keep from being archived early -- Netoholic @ 01:46, 15 August 2014 (UTC))[reply]

• Remove - This {{navbar}} template call was added to the WikiProject banner back in 2008, but then immediately hidden by CSS (display:none) in {{WPBannerMeta/core}}. The same thing exists in the Stub base template {{Asbox}}. There is a CSS trick which editors can add to their custom CSS files, but this trick hasn't been publicized and is in use by only a handful of already experienced users. Even though it is hidden by CSS, it still adds a few hundred characters to every stubbed or bannered talk page download (and pages with multiple banners add it multiple times). The navbar template transclusion itself is called every time a page is saved (which for talk pages can be alot). Now, normally, we don't worry about performance, but in the template design space we do have to weigh the costs vs benefits, and since these templates are so widely used, I think every small efficiency we can do deserves consideration. The people that know about this hidden trick or would use it, are also experienced enough to get by without it on the rare occasions they need to edit a particular stub or WikiProject template. -- Netoholic @ 19:16, 30 July 2014 (UTC)[reply]
• Keep and add the code to view the links to MediaWiki:Group-templateeditor.css. I'm basing this on the discussions about this I found (Template talk:Asbox/Archive 2#Navbar & Template talk:Asbox/Archive 4#Why the navbar ?) which were sufficient enough to convince me it is a good idea to have the links. I'd be happy to brief over other discussions if you care to link them. Also, I'm not sure if you've notified the people involved in the previous discussions (if you even found all of the discussions, which I'm sure I haven't and don't expect you have), a quick group ping (MSGJ—Xeno—Amalthea—TheDJ—Happy-melon—Topbanana—Grutness—WOSlinker) should do it. — {{U|Technical 13}} ^{(e • t • c)} 14:36, 1 August 2014 (UTC)[reply]
• Neutral. A few facts I can throw at this discussion; firstly the hidden navbar edit links are used by 8 Wikipedians. Per WP:PERF, we should be prioritising pretty much everything over efficiency; there is some discussion here about the impact of this feature - despite the implementation being truly and absolutely awful, it's trivial in the bigger picture of Wikimedia ops. On balance, if there's a better way to do it, we should. If not, we keep it as is. - TB (talk) 09:48, 2 August 2014 (UTC)[reply]
  • (Pinging a few more possibly interested parties: User:MSGJ, User:Borgarde, User:Redrose64, User:Quest for Truth)
• Remove. It was never really necessary to have this on stub templates in the first place. As Netoholic points out, if you're editing stub templates, chances are you've got enough nous here to know how to do that without having to resort to the embedded links. Similarly, if you're editing a wikiproject's banner, chances are you know what you're doing. I've added the necessary coding in monobook to be able to use them myself, but I can't remember the last time I've actually edited a template this way - it's only the barest fraction quicker than simply editing direct from the template's page. Having the links there, if anything, encourages people to edit the templates - and while editing article pages should be encourages, making changes to heavily-used templates is beyond the scope of "be bold", since it can have far-reaching consequences. So no real benefit, and potential for trouble = ditch it. Grutness...wha? 11:34, 2 August 2014 (UTC)[reply]
• Comment - I don't know enough about this template and its uses to opine about it specifically, but I would like to make a general comment. WP:PERF tells regular editors not to worry about performance because it's beyond their ability to do much about it, since their permissions have been deliberately limited to prevent project-wide impact. While it's true that the "IT professionals" or others with special permissions may be needed to make changes such as the one being discussed, they rely on us to decided which features are important. More and more readers are viewing Wikipedia pages on mobile devices, and I've been reading a lot of comments from editors about page load times on these devices. If a template is being called a gazillion times and is rarely used, I think that efficiency should be considered as well as utility. —Anne Delong (talk) 10:31, 7 August 2014 (UTC)[reply]
• Keep When stub templates and WikiProject banners break page layout, or put pages in incorrect categories, which they sometimes do when somebody (either with good or bad intentions) has been playing with the markup, these links make it much quicker to go straight in and fix. @Topbanana: - I only just noticed this (I came looking for this thread, and searched for my own name to see if I'd already commented), please note that this attempt to ping failed because you didn't sign it at the same time. Accordingly, I'm pinging MSGJ, Borgarde, Quest for Truth again, with my signature. --Redrose64 (talk) 15:13, 1 September 2014 (UTC)[reply]

Some time back, there was a proposal to give Commons admins the right to view deleted content across all WMF wikis; I can't find it, or I'd link it. It gained broad support, but WMF vetoed it on technical grounds, as (if I remember rightly) it wasn't possible to get the software to grant rights to a user on one wiki just because the same user had been granted a different set of rights on another wiki. As far as I remember, WMF wasn't objecting to the idea; I got the impression that it would have been accepted had it been possible to implement.

With this in mind, I wonder what people would think about a request to developers for a new userright that admins here could grant: the right would be called "Commons admin", with just the ability to view deleted revisions of files (both the log entries from the history page, and the actual contents of text revisions and uploads), i.e. vaguely comparable to WP:Researcher in that viewing is the only additional ability, but more viewing ability than Researcher in filespace and no viewing ability in all other namespaces. Upon creation of this userright, we would grant it to any Commons admin who requested it, but under no circumstances would it be granted to anyone else, and (aside from gross abuse) the only reason for removing it would be that the user was no longer a Commons admin. As the biggest WMF project, we're probably the biggest source of images that get transwikied to Commons, so if creating this userright is practical, we'd be able to resolve a big portion of the difficulty that prompted the proposal. I understand that we currently don't have any admin-grantable userrights that involve deletion, basically because admin-type rights are typically granted only after a substantial community discussion, but this is different: we'd simply be allowing our admins to implement what our software would do if it were possible, and anyway people don't become admins at Commons without a substantial community discussion. Nyttend (talk) 14:58, 14 August 2014 (UTC)[reply]

• As long as Foundation Legal is ok with it. (there are legal reasons why view deleted needs to be restricted to a limit number of people, but past discussions haven't given much guidance on how limited, a handful of commons admins who request it should probably be fine) I don't see any reason not to do it. That said, I've very rarely come across requests for that sort of info, do commons admins need it often? Monty₈₄₅ 16:00, 14 August 2014 (UTC)[reply]
• I would personally not have any objections, on the other hand, I am a Commons admin, and I needed this right only a couple of times in my life. Those who transfer a lot of files or those who are superactive on FFD may need the right more often.--Ymblanter (talk) 16:53, 14 August 2014 (UTC)[reply]
  • Monty, I suspect that this wouldn't be a Legal concern, since Commons admins already have viewdeleted over there; my proposal, if successful, wouldn't expand the number of trusted users WMF-wide. Both of you address the "how many people" issue, so I've left an announcement at Commons:COM:AN — hopefully we'll hear from more Commons admins. Nyttend (talk) 19:23, 14 August 2014 (UTC)[reply]
• Sounds like a good idea. Having done almost 170000 deletions and 1400 undeletions on Commons, there've been plenty of times when I could have used this to determine whether to restore/delete/DR an image, but instead had to wait for an en.wiki admin to check a file and reply back with the needed info (except for the 6 months when I was an en.wiki admin myself of course). There aren't many admins regularly involved in deletions/undeletions/DR/CSD at Commons, so the right would only likely be given to a small number of Commons admins. INeverCry 20:08, 14 August 2014 (UTC)[reply]
• User:Jalexander knows a lot about what's possible with user rights as well as what's likely to wash with the legal team, so let's see if he's got any suggestions. Nyttend, how many years ago was "some time back"? Whatamidoing (WMF) (talk) 22:34, 14 August 2014 (UTC)[reply]

• If I knew, I'd tell you; I'm sorry. I don't think I participated in the discussion; if I did participate, I've thoroughly forgotten. If I remember rightly, I first became aware of it upon reading that the technical staff had declared it impossible. Nyttend (talk) 22:37, 14 August 2014 (UTC)[reply]

• @Whatamidoing (WMF): @Nyttend: @Jalexander: here's the Meta poll from 2008. INeverCry 23:42, 14 August 2014 (UTC)[reply]

Just a guess, but I wouldn't be entirely surprised if the technical problems were no longer so difficult. Whatamidoing (WMF) (talk) 02:17, 15 August 2014 (UTC)[reply]

Thanks, INeverCry, for finding that! Having seen that date, I was able to find Wikipedia:Wikipedia Signpost/2008-06-26/Global groups. I've checked every Signpost through the end of September without finding further coverage, so I'm guessing that they didn't cover what happened at the end of the poll. Nyttend (talk) 04:00, 15 August 2014 (UTC)[reply]

• Support - English Wikipedia is just one part of the Wikimedia project; to the degree that we can help other parts of the project, we should. This proposal would cause little harm to us (presumably, any user capable of becoming a Commons admin should be trusted to merely view our deleted media and its descriptions), and significant benifit to the Commons, an other part of the project. עוד מישהו Od Mishehu 03:50, 15 August 2014 (UTC)[reply]
• Seems reasonable. I am sure they don't let just anyone be a commons admin. Chillum 04:28, 15 August 2014 (UTC)[reply]

Well, they let me be an admin there...but, then again, they let me be an admin here for a while too... INeverCry 07:00, 15 August 2014 (UTC)[reply]

• No opposition from my side, but how is a local group any different from a global group, from a technical point of view? Note that there is also some information at m:Global deleted image review. --Stefan2 (talk) 17:25, 17 August 2014 (UTC)[reply]
• The commonadmin name is too confusing, as they won't be common nor an en-admin; could be fine, under "imagehistory" right, or the like. Those who want it and will use it should apply individually, like "reveiwer" right. Alanscottwalker (talk) 18:03, 17 August 2014 (UTC)[reply]

  I said "Commons admin", so your comments aren't quite accurate, although it was a vague suggestion and I expected someone to propose a different name. Perhaps "imagehistory" as you suggest, or perhaps something like "fileviewer"? Nyttend (talk) 13:47, 20 August 2014 (UTC)[reply]

• Comment. This is a redundant proposal. This idea was proposed 6 years ago and was even approved in an RFC. Then a bug report was filed, which unfortunately has not been fixed yet. There are some related bugs that need to fixed before this feature can be implemented. Ruslik_Zero 19:42, 17 August 2014 (UTC)[reply]

• Please re-read the proposal. I'm proposing a technical workaround for manual implementation of the 2008 proposal, since it can't be implemented automatically. I'm suggesting the creation of just a local userrights group, which shouldn't be too hard; during discussions related to Wikipedia:Requests for comment/Template editor user right (I can't find the precise spot), someone observed that creating the TE userright wouldn't be that difficult for the developers. Should all aspects of my proposal be implemented, we admins will be able to grant it just as easily as we grant rollback, although of course relevant policy will place much greater restrictions on who gets it; requests from "hat collectors" will automatically be declined. Nyttend (talk) 13:47, 20 August 2014 (UTC)[reply]

• Umm, how does that work around the technical problems exactly? We'd still need to create a "viewdeletedfile" to add to the enwp group, and at that point we might as well just put it in a global group. Legoktm (talk) 17:37, 21 August 2014 (UTC)[reply]

• As I understand it, in 2008, the idea was as follows. Legoktm is an ordinary Commons user and Wikipedian without admin rights, so he can't see anything that's been deleted on any projects. He passes the Commons equivalent to RFA, and with a single click of the button by a Commons bureaucrat, he's able to view all deleted revisions in the file namespace of all WMF projects; here at en:wp, he can't delete or undelete anything, and he can't view deleted content in mainspace or portalspace, but he can view deleted revisions of files. Such an idea was rejected by WMF, and if I understand rightly, the idea was simply that it couldn't be done — the ru.wikibooks and ang.wikisource servers have no way to understand changes to your userrights on Commons. My proposal is basically a manual workaround, since a human can look at your Commons rights log and make relevant modifications to your rights on other wikis. I know absolutely nothing about global rights, so I can't make any solid comments. Are you basically suggesting that this be a steward-grantable thing, with the provision that when a steward hits a button on Meta, you immediately can view all deleted revisions in the file namespace of all WMF projects? If that's what you mean, I would say that it was even better than my proposal, but again I have no idea whether things work that way. Nyttend (talk) 02:01, 23 August 2014 (UTC)[reply]

• Support either a local user right "viewdeletedfile" or similar, to be given to commons admins at their request. Or some other magic that allows them to view deleted files here. —Kusma (t·c) 13:34, 21 August 2014 (UTC)[reply]
• Quid pro quo, if we do this, Commons should be willing to grant the same right to en admins at Commons on request. We sometimes need to investigate the disappearance of an image from a Wikipedia article, and that is made ten times more difficult if it was deleted on Commons. SpinningSpark 14:57, 23 August 2014 (UTC)[reply]
• Granting the ability to view deleted files on a case by case basis to commons admins (or an editor here who just wants to work on file stuff, I guess) is a good idea. I'd prefer if we could set it up such that there's some input for the community, but I don't want to create another mini RfA process. Protonk (talk) 15:20, 27 August 2014 (UTC)[reply]

Would the reasearcher right already do the job? It allows you to view deleted pages and their histories? Should we just clone this right, and rename it something like "commonadmin"? --Mdann52talk to me! 15:54, 27 August 2014 (UTC)[reply]

As I noted above, researcher is different: it covers all namespaces, but it provides far less information about deleted pages than admins are able to get. In particular, a researcher cannot see the contents of deleted revisions, and the Meta proposal that I'm trying to implement concluded that Commons admins should be able to see everything that local admins can see — the only difference is that the Commons admins wouldn't be able to undelete files. Nyttend (talk) 03:52, 2 September 2014 (UTC)[reply]

A bot trial to generate a very limited sample set has begun, please see Wikipedia:Bots/Requests for approval/EranBot. This trial is to determine what the output type of operations will be to create a reference sample. However, additional discussion as to if the task should be performed at all, and if so under what conditions, may need additional discussion. Please see the bot request and feel free to add any questions for the operator, ערן. — xaosflux ^Talk 15:51, 22 August 2014 (UTC)[reply]

This is one of the initial tests of WP:TURNITIN (proposed), an Internet-based plagiarism-detection service run by iParadigms. The brief overview is that the bot will take edit content, submit it to the third party for scoring, and post a report here. Current examples are here User:EranBot/Copyright. Technically the trials are operating without any issues, however community consensus for this task is unclear, comments at the bot request, or here, are appreciated. — xaosflux ^Talk 11:00, 26 August 2014 (UTC)[reply]

The bot is only running on medical articles as the community supports it use their. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:08, 26 August 2014 (UTC)[reply]

Here we have consensus for this bot [2] from WP:MED. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:59, 27 August 2014 (UTC)[reply]

• I've always thought Turnitin violates the copyrights of everyone whose work is added to its database. If Turnitin hashes, or whatever the technical method they use to add it to their database, that portion of the database should be made available under a compatible creative commons license. AFAIK, no one has every succeeded against them, but that doesn't change the fact they are taking our work, making profit off it, and not resharing or attributing. Monty₈₄₅ 23:00, 30 August 2014 (UTC)[reply]

• This is a good example of fair use. They're taking large amounts of content, but that's because they need to: while they're on the "expression" side of the idea-expression divide, they're only concerned with the expression, and the whole process depends on the precise text itself. Look at the fair-use test: (1) Purpose and character — they're definitely not competing with copyright holders, and it's quite obviously transformative. The fact that it's used to detect infringement will probably play into this as well. (2) Nature of the copyrighted work — not particularly relevant, aside from the fact that they're only working with stuff that's already been published. (3) Amount and substantiality — they take lots, but in this case, it's definitely true that "the secondary user only copies as much as is necessary for his or her intended use". (4) Effect upon work's value — nobody's going to use Turnitin as a substitute for a copyrighted work, and as it's used to find infringements, it's quite clearly having a positive effect upon a work's value. Final note This is analogous to Google itself, which downloads massive amounts of content to permit searches, but the ability of search engines to do this was ensured by Kelly v. Arriba Soft Corporation. Nyttend (talk) 14:55, 1 September 2014 (UTC)[reply]

An example of what this could look like is on the article on heart failure. If there is support for this proposal the word "authors" and link to the list of authors would go within the line of code that creates "From Wikipedia, the free encyclopedia".

When a person clicks on the word author it takes you to X! tool here [3]. Preferably the heading "top editors" would be changed to "authors" and that section would be moved up to below "general statistics". I am not sure what punctuation should be used and am open to suggestions / variations.Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:15, 23 August 2014 (UTC)[reply]

There is a common misunderstanding regarding who writes Wikipedia. All we state now in the byline is that the text is "From Wikipedia". Adding the word authors and having this word link to a list of authors would increase transparency to our readership.

Another potential benefit is that making it clear that Wikipedia is written by people, people likely very much like the person reading the article in question. It may thus increase people's willingness to edit and this could be easily studied.

Yes I do realize that one can find this information other ways. One can click on the "history" tab. Than click on "revision history statistics" but that does not clearly lead people to whom the authors of the text are. The word history does not lead me to think of authors or editors. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:15, 23 August 2014 (UTC)[reply]

In the history page, we can customize everything on the page legend, it is stored in MediaWiki:Histlegend, changing the external link anchors is quickly done if that will help? — xaosflux ^Talk 23:25, 23 August 2014 (UTC)[reply]

The place one expects to see the authors listed; however, is in the byline. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:27, 23 August 2014 (UTC)[reply]

I don't really have a strong opinion on if this should be adopted, but if it is I'd suggest it's placement either be a page tab (perhaps incorporating Special:Cite), or else incorporated in to the tag line area From Wikipedia, the free encyclopedia. Having it floating up in the area you have it now seems out of place, especially when used in other display layouts such as mobile view. — xaosflux ^Talk 23:55, 23 August 2014 (UTC)[reply]

So by "would go within the line of code that creates "From Wikipedia, the free encyclopedia" i mean as you suggest "incorporated in to the tag line area From Wikipedia, the free encyclopedia". The example you see on heart failure is just a mockup of how it could look and only works for desktop and with vector. It was not a suggestion on how it would be programmed. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:14, 24 August 2014 (UTC)[reply]

I think it would look better there, perhaps along the lines of:

From Wikipedia, the free encylopedia (contributors)

Using PAGENAMEE, and making the external tools more prevalent on the top of the Cite tool? — xaosflux ^Talk 01:13, 24 August 2014 (UTC)[reply]

N.B. that is the MediaWiki:Tagline page. — xaosflux ^Talk 01:14, 24 August 2014 (UTC)[reply]

Yes I like the "contributors" in brackets. I still think going to the list of authors is best. We could than add the Special:Cite to that page. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:25, 24 August 2014 (UTC)[reply]

Changing the tagline is highly visible, to may even need an RFC to run for a bit; if that is where you want this to end up, you should start a section over in MediaWiki_talk:Tagline and link in from locations interested parties will visit (like here). Note, there are translations of that page in to many languages. — xaosflux ^Talk 01:38, 24 August 2014 (UTC)[reply]

Yes agree a RfC will likely be needed was just going to allow some initial discussion first. Only discussing this for English Wikipedia at this point in time. Have added a link here from meta. I guess we could consider broadening the discussion to all languages of Wikipedia thought. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:42, 24 August 2014 (UTC)[reply]

Oh no, I mean on enwiki we have additional versions of that page based on user language preferences, no big deal,just will need translators for each. — xaosflux ^Talk 01:52, 24 August 2014 (UTC)[reply]

Strongly opposed. It's a pathway to egotrippers and gloryhounds, a feature just begging to be gamed to increase their "rankings" on prominent or notorious articles. ("I'm the lead author on penis enlargement!") --Orange Mike | Talk 22:40, 25 August 2014 (UTC)[reply]

People who wish can do this already. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:17, 26 August 2014 (UTC)[reply]

• Oppose because the history tab exists. --Jayron32 22:41, 25 August 2014 (UTC)[reply]
• Strongly support because a) to the casual reader, there is no intuitive way to see who is responsible for the content and b) whether we like it or not, many people, especially those with knowledge of topics sorely lacking in Wikipedia, need to have some kind of credit. This is simply more in line with what is done in many of the publications we rely on.Thelmadatter (talk) 00:38, 26 August 2014 (UTC)[reply]
• I dropped a few notes at mailarchive:wikimedia-l/2014-August/074133.html. --MZMcBride (talk) 01:54, 26 August 2014 (UTC)[reply]
  • If Willy on Wheels drops by and adds the word "scrotum" to a random article (assume it is not appropriate to the article), does he get counted as an "author" in this scenario? bd2412 T 04:16, 26 August 2014 (UTC)[reply]
    • If Wikipedia were to consistently hide (revdel or whatever the term is) vandalistic edits, would that have the side effect of ensuring the people who made them weren't listed as "authors"? -sche (talk) 04:26, 26 August 2014 (UTC)[reply]
      • • For a brief period of time they would have been an author of the article. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:23, 26 August 2014 (UTC)[reply]
      • Yes that would likely work however it is sometimes useful to be able to see most vandalism. And it is more work to revdel.
      • We could use the term (contributors) instead of authors. Would potentially look like this [4] Doc James (talk · contribs · email) (if I write on your page reply on mine) 04:30, 26 August 2014 (UTC)[reply]
• Oppose. Not because of the history tab - I'm actually a really big fan of increasing the prominence of the fact that did you know you can edit and this was made by people just like you because however much we assume we're good at that, we actually do a surprisingly poor job. But the current implementation seems likely to interfere with readership - we're directing people to a potentially-unstable labs tool that forces them to navigate away from Wikipedia and all of its links to other knowledge and other content. We are a project dedicated to knowledge and the interconnectedness of all things, and this setup sends users to a dead end. I'd be really supportive of, say, an experiment to gauge the impact of including a link that pointed at...I don't know. A quick summary of how WP is written by random joes and can be edited by you, too. But it would have to be an actual experiment. This looks likely to do unexpected things to readership that we can't currently track, and produce (potential) positive results we have no way of measuring. Generally-speaking I'd like UI changes to be both measurable and measured. Ironholds (talk) 06:41, 26 August 2014 (UTC)[reply]

We could put the list of authors / contributors within a Wikipedia page and thus not send someone to Wikimedia labs.

The whole point is Wikipedia is NOT written by random joes and this is a misconception that is spread not only by the media but many others. Our core community of medical editors is about half health care providers and 85% have at least a Bachelor. Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:15, 26 August 2014 (UTC)[reply]

Okay. What advantage do we get from solving this, then? It seems to actively contradict the potential advantage you raise around editor engagement; I strongly doubt 85% of potential editors have bachelors, or that 50% are nurses or doctors. Ironholds (talk) 14:48, 26 August 2014 (UTC)[reply]

These are not the stats for potential editors. These are the states for the current core editors of Wikipedia's medical content. Do not understand you comment about "contradicting the potential advantage". Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:07, 28 August 2014 (UTC)[reply]

• Oppose per Orange Mike and the fact that we have a history tab... not to mention that I am not at all sure about where this would really link. Off wiki to some form of statistical data seems out of the ordinary to me.--Mark Miller (talk) 06:57, 26 August 2014 (UTC)[reply]
• Comment Remember that most "authors" will not be identified by their real names as on a book cover or journal article, but only by usernames that are variously silly, enigmatic or unreadable and mean nothing except to Wikipedia regulars: Noyster (talk), 08:04, 26 August 2014 (UTC)[reply]

A number of the core members of WP:MED use their real names. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:15, 26 August 2014 (UTC)[reply]

• -1. Wiki by definition means attributing my text as Wikipedia. Quoting Wiki:

"While a wiki is a type of content management system, it differs from a blog or most other such systems in that the content is created without any defined owner or leader, and wikis have little implicit structure, allowing structure to emerge according to the needs of the users."

WP:REUSE does allow to attribute by linking to the article. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]

• -1. Oppose listing top editors only; WP:REUSE requires (as an alternative to linking to the article) listing them all with a "Any list of authors may be filtered to exclude very small or irrelevant contributions." comment; this, I understand, implies listing around 99% of the contributors. Every small contribution should count. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
  • No one is being listed on Wikipedia. The proposal is to a link to another page that lists the authors. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:52, 26 August 2014 (UTC)[reply]
• -1. Additionally, people would try to get onto the 'top editors' lists, count the amount of articles they 'co-authored'; this all has negative implications (see Karma). Every small contribution should count. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
  • This can occur right now. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:52, 26 August 2014 (UTC)[reply]
• On a related note, if you'd like to raise awareness, just make the edit button bigger and put a reasonably well-visible "anyone can edit" line into the interface. Use the space wisely. That'd suffice. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
• If you go into it, please allow people to opt out. I'd not like to be, personally, subject to being listed in such author bylines selectively (i.e. only at those where I got into a top editors list). --Gryllida (talk) 12:33, 26 August 2014 (UTC)[reply]
  • We already have ways of determining who has edited an article. Opting out is not currently an option. We are NOT listing any authors by name in the by-line, we are only providing a link called authors or contributors. You can see it on the page heart failure Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:52, 26 August 2014 (UTC)[reply]
• Support This would be an excellent way of encouraging content contributions. Note that staff such as EpochFail are working on ways of improving attribution for our content and there is external research too; for example, see this paper, which states

  The Wikipedia Reuse Policy requires people reusing Wikipedia material to either provide a link to the original article and revision history, or to cite the most prominent authors of the content. Furthermore, in the Wikipedia community it is felt that proper content attribution is an important way to acknowledge and reward contributors, and to foster participation and contributions from communities where authorship has been traditionally recognized and rewarded, such as the academic community.

If these ideas are brought together then our contributors will get the credit that is their due and that the licencing requires. The history page is currently quite inadequate for this as its purpose is to show the detailed history of changes and so the authorship of our articles is obscured by this mass of fine detail. Andrew (talk) 12:38, 26 August 2014 (UTC)[reply]

Er. Well, people are working on research around editor engagement and attribution, but the paper you've cited doesn't seem to support that at all. Moreover you're not actually citing a part of the paper subject to experimental conditions, you're citing a background section, which is best understood as the author's impression of how Wikipedia works - and surely we're the people who get to decide how much that reflects reality? Paper citations aren't useful for that point. And just to clarify, if the history page didn't do what licensing required we'd have a far bigger problem. Ironholds (talk) 14:50, 26 August 2014 (UTC)[reply]

• We do have significant attribution problems. For example, I was recently working on yacht delivery. There's a challenge to the copyright status of our text in that article but it's not clear whether the other site got it from us or vice versa. Or there's all those thousands of books produced by VDM Publishing. Ostensibly these were written by the prolific authors Frederic P. Miller, Agnes F. Vandome, &c. but the content is actually taken from Wikipedia and was written by our contributors. Why is "Frederic P. Miller" getting all the credit for our work? When our contributors get little acknowledgement and then see someone else taking the credit for their work, it's not surprising that they decline to do more. Andrew (talk) 15:57, 26 August 2014 (UTC)[reply]

• Except first, this proposal wouldn't solve for the example you bring up, and second, none of the work on editor or edit decline has suggested a problem around lack of motivation in existing contributors. In fact, our strength is that the survival rate of existing contributors is incredibly high: it's attracting newcomers we fall down on. Ironholds (talk) 16:00, 26 August 2014 (UTC)[reply]

Yup and we plan to look at if this increases the attracting and retainment of newcomers.Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:08, 28 August 2014 (UTC)[reply]

• I could support something like this. I would call the link "credit" and I would link to just a list of the contributors. Alanscottwalker (talk) 13:31, 26 August 2014 (UTC)[reply]

Would be happy with that too. Doc James (talk · contribs · email) (if I write on your page reply on mine) 13:50, 26 August 2014 (UTC)[reply]

Well, viewing some of the additional comments below, I think I should expand on what I mean by list of contributors. It would include the owners of the image files, as well as the writers. Now, perhaps this does not all need to be done at once but that is what I would like to see. Alanscottwalker (talk) 14:45, 26 August 2014 (UTC)[reply]

Yup if this idea received support should be easy to do. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:04, 26 August 2014 (UTC)[reply]

• Support not authors, but contributors for transparency sake (and likely to improve licensing compliant reuse). Identifying the removers of text is fine as they do contribute to the appearance of the article; in another category altogether, identifying vandals is fine, as they should be identified. It should be expanded to image contributors but the perfect should not be the enemy of the good (transparency). Alanscottwalker (talk) 11:18, 31 August 2014 (UTC)[reply]
• Support – Wikipedia is loosing productive editors at an alarming rate. Anything that can help motivate participation is a good idea and giving credit where credit is due is an effective way of accomplishing this. While there are other ways of determining contribution, this is the most direct way I have seen. Boghog (talk) 14:06, 26 August 2014 (UTC)[reply]
• Support as "contributors" - Makes what is already available in two clicks (Page information -> Contributors) available in one click instead, and makes that link more visible. As this information is already available and all this proposal is doing is making the access to it easier, I don't understand the arguments that this will somehow be dangerous or encourage glory-hounds, at least not any more than what the normal page presentation already does. Would be very happy to see this deployed in a trial run on selected WP:MED articles, for example, and see what the feedback is, or see whether the contributor profile of those articles changes (RCT anyone)? Zad68 14:33, 26 August 2014 (UTC)[reply]
• Concerned Wouldn't this give credit not only to contributors of lasting content but also to contributors of large-scale copyright violations, essays, rants and protracted edit-wars? How would, for example, Audit Commission (United Kingdom) appear? X!'s tool shows one editor has made 41% of the edits and 70% of the text additions by bytes, but doesn't show they have all been reverted. NebY (talk) 15:15, 26 August 2014 (UTC)[reply]

• A crude edit count is obviously unsatisfactory, as you say. What's required is a more sophisticated metric and people are working on this. See Attributing Authorship of Revisioned Content for more details and references. Andrew (talk) 16:05, 26 August 2014 (UTC)[reply]

• So should we oppose this proposal until the edit count is not obviously unsatisfactory? NebY (talk) 16:32, 26 August 2014 (UTC)[reply]

• We could right now without to much difficult remove the two edits involved in a revert from the numbers. Please keep in mind that if everything on Wikipedia had to be perfect before it goes lives we would obviously not have Wikipedia.
• By the way the tool lists contributors by both number of edits and by bytes contributed. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:06, 26 August 2014 (UTC)[reply]

• Would such edits be removed automatically, and would this include cases such as my example above of Audit Commission (United Kingdom)? If so, would this be done using an existing solution or is it something that should be feasible but has not yet been accomplished? We've been shown a research paper from 2013 but no progress report.
• By the way, as you'll see from the way I presented the example, I do realise the tool lists contributors in two ways. I do also realise that we can't wait for perfect solutions, but I was startled that a supporter of the proposal would still describe the existing count as "obviously unsatisfactory". I hope you don't think it obstructive to consider potential problems and discuss overcoming them. NebY (talk) 14:42, 27 August 2014 (UTC)[reply]

Yes thanks. While it is not perfect this it is simply a single word in the byline. I would imagine it would result in improvements in our analysis of who has edited an article.Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:24, 28 August 2014 (UTC)[reply]

• Support - clarification on this and a link to the authors would benefit the reader. QuackGuru (talk) 03:16, 27 August 2014 (UTC)[reply]
• Support Small unobtrusive link that provides "byline" type info. I think this would be useful to those checking to see which editors are most involved in developing an article. Also useful for general attribution. I think this is consistent with what is found in reliable sources. - - MrBill3 (talk) 06:02, 27 August 2014 (UTC)[reply]
• Support. It adds to transparency. Most casual readers wouldn't know where to find the main authors of an article. --Anthonyhcole (talk · contribs · email) 09:28, 27 August 2014 (UTC)[reply]
• Support - While far from perfect, I'd actually like to see this added or enacted as an option on the left column, perhaps in the tools section. Gathering details of the page's history from the "view history" section seems a bit silly for attribution and while this tool is not perfect it still represents an improvement. ChrisGualtieri (talk) 12:59, 27 August 2014 (UTC)[reply]
• Oppose. We have 'history' and other tools for those who need to know this info—the average reader does not. There is no benefit to the average reader knowing who contributed to an article using a pseudonym. And, by-lines are for newspapers. Edit counts are worthless as an edit can introduce incorrect information, be poorly written, vandalism, or just plain bad. The encyclopedia is a community project, not individually driven, and the focus should remain as a collective work, not a personal one. GenQuest ^{"Talk to Me"} 13:23, 27 August 2014 (UTC)[reply]
• Support This might be fun! Also, open source projects often list contributors in a similar manner. It's harder to do when contributions aren't subject to some central authority for acceptance, but it's not without precedent. Protonk (talk) 15:06, 27 August 2014 (UTC)[reply]
• Oppose per GenQuest. (1) It may be that many contributors to medical articles use their real names as usernames, but the proposal appears to apply to articles on any topic. (2) I can't imagine an automated tool that could reliably make the qualitative judgement on the value of every edit in an article's history: Noyster (talk), 15:48, 27 August 2014 (UTC)[reply]

We could just introduce this on medical articles if this is a concern for the wider community. Our authors are as you mention more transparent and our lack of transparency is criticism I have to deal with when I speak about Wikipedia and medicine. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:27, 28 August 2014 (UTC)[reply]

Then yes, that sounds like you're trying to generalise specific criticism you have heard voiced (around the primacy of attribution in a medical context, so patients/readers can understand who is providing information) to the project as a whole. How much was this proposal driven by those (very subject-specific) concerns? Ironholds (talk) 07:21, 28 August 2014 (UTC)[reply]

I believe that this is an important move for medical articles. I have no strong feelings regarding the rest of Wikipedia (but lean towards it being a good idea). We could apply it only to medical articles and then present something in 6 or 12 months on the effects it had (we do have fairly good data on editor numbers and could study the effects on a random selection of articles versus a group of controls). Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:47, 28 August 2014 (UTC)[reply]

• Support per Zad 68's point. Also, a fairly new change to the mobile version is that it now displays the name of the most recent editor. I think that should occur on the desktop site as well. Increasing transparency of Wikipedia's authorship is key to its legitimacy. --Holdek (talk) 17:23, 27 August 2014 (UTC)[reply]
• Oppose authority from names was tried on Google's Knol and it failed, people who really want to know it will open the edit history anyway for clues or visit the talkpage where the editor names are well visible. Mion (talk) 18:14, 27 August 2014 (UTC)[reply]

This is not about authority from names. This is about transparency to our readership. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:13, 28 August 2014 (UTC)[reply]

Right, because pseudonymous nicknames and arcane IP addresses are transparent. --Jayron32 13:43, 28 August 2014 (UTC)[reply]

Not all of use use IP addresses and nicknames. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:04, 28 August 2014 (UTC)[reply]

Mark Twain is a pseudonym.Thelmadatter (talk) 15:29, 29 August 2014 (UTC)[reply]

Excellent point. We are not unique in allowing their use. Doc James (talk · contribs · email) (if I write on your page reply on mine) 19:54, 29 August 2014 (UTC)[reply]

Samuel Langhorne Clemens wrote original content. We do not. GenQuest ^{"Talk to Me"} 12:47, 1 September 2014 (UTC)[reply]

Ah, we very much do write original content. That is how we are able to put it under a CC BY SA copyright. We are not simply a collection of plagiarized content.Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:51, 1 September 2014 (UTC)[reply]

No. Authors are original content providers, of ideas, stories, theories, whatever. Such original research, or content which goes beyond sourcing, would be quickly removed here. As Wikipedia volunteers, we only summarize (or edit) into our own words what has been already been written in primary or secondary sources about any given subject. That is why we are referred to as editors, and NOT authors. GenQuest ^{"Talk to Me"} 19:19, 2 September 2014 (UTC)[reply]

We don't do "original research" but wikipedia editors write gobs of original content just as any encyclopedia editor does. Protonk (talk) 13:59, 4 September 2014 (UTC)[reply]

• Comment - If I were a major contributor to an article that I researched, wrote and continued to refine by hand and then suddenly an editor with automated functions "moves" up to a "by line" level...I would be more than a little concerned and annoyed. That would discourage further input and contributions from editors not using tools to edit.--Mark Miller (talk) 20:55, 27 August 2014 (UTC)[reply]

Please note the suggest is NOT to add anyone user name to the "by line". It never has been. The suggestion is just to add a link to "contributors". See example at the top. The data is given both by bytes contributed and number of edits. Thus if you contributed most of the text you would still be linked higher. There is NO moving up to a byline level. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:13, 28 August 2014 (UTC)[reply]

I can not support ANYTHING which used number of edits as a measure of excellence, per my comments above. And number of bytes is no better as a measurement, per the same criteria. For instance, some of us actually improve the encyclopedia by removing many, many bytes of badly written prose, comments, narratives, editorializing....etc.; the list is almost endless. Both proposed parameters are pretty much meaningless in the encyclopedia, and wholly not tenable as a measure of article improvement for the reasons I stated. And I have to ask, just what is gained by allowing the average reader, here for information only, to have an instant link to (for example) the list of the last five "contributors" (or prolific serial vandals who have targeted the article)? If Wikipedia were trying to be a primary informational source, I would understand and support this; however, Wikipedia is a tertiary information source—we report what others have written—we just do it in our own words. Authorship is meaningless here (except for those that would revel in their article / edit / byte counts). Given the stated purpose of Wikipedia, this proposal makes no sense. GenQuest ^{"Talk to Me"} 14:45, 28 August 2014 (UTC)[reply]

They may not be perfect but they are far from meaningless. These are not measures of excellence but measures of contributions. Many of our articles are far from excellent and still have contributors / authors. It also gives the time line for contributions.

Yes agree that improvement often involves removing large amounts of poorly written text. When article are brought to GA / FA the major contributors are usually listed among the first few editors (at least for all medical articles I have looked at).

Are authors / editors / contributors meaningless? After having dealt with a fair bit of COI I would say that is not the case. The people who write the content are exceedingly important. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:03, 28 August 2014 (UTC)[reply]

Strong Support (of the "wtf didn't we do this year's ago?" type). It is just so sensible! Over the years I've been involved with WP you wouldn't believe how often readers / press don't understand where the content comes from or what the history tab signifies. There has been a continuous problem with proper attribution of our content for so long and this is a simple and neat way to do something about that. (btw, on my browser, the text on the test page overlaps with other text) --AlisonW (talk) 23:24, 29 August 2014 (UTC)[reply]

Strong support I delete a lot of text, and I am not entitled to copyright for that, so I won't rank highly for number of bytes (nor edit count) Yet I am delighted that those who do contribute prose and images will get clear credit from this. A 'Contributors' link has plenty of meaning and value to anyone who reads the written word (as does the analogous 'credits' when we enjoy TV, movies and podcasts), and even more meaning to those who actually contribute. It will never be perfect. If we copy and paste a sentence from another Wikipedia article, or from another free source with a compatible license, that won't be automatically attributed. Neither will text from the 1911 Encyclopaedia Britannica. (For those reasons, I think the current proposal of 'Contributors' is far better than the original 'Authors'.) Yet despite some small weaknesses, which I are largely fixable later, this is a fantastic idea that is far more digestible than the remote possibility that a reader follows 'More/View history' and realizes that tells them not only what was written, but by whom. Is this really the first time in our history that this has been proposed? By the way, the edit count tools have been around for 6 or 7 years, so I don't consider them to be experimental or unstable. Hroðulf (or Hrothulf) (Talk) 16:20, 30 August 2014 (UTC)[reply]

Comment. My opinion is that this type of link should stay on-wiki, perhaps to the Special:Cite tool if it will be implemented. — xaosflux ^Talk 14:49, 1 September 2014 (UTC)[reply]

• Note: Wandering editors have seen this in wider production and were confused, just answered at WP:VPT. — xaosflux ^Talk 14:38, 1 September 2014 (UTC)[reply]
• Oppose (FYI, I'm the wandering editor), because that's why we have the history page. If you don't know how to find the history page, you won't know to look immediately below it to find the Contributors link. And I didn't see it in Vector; why are we producing something for newbies and non-editors if one must be familiar with Special:Preferences to see it? Not a big deal, but it's somewhat in the way, and I can't see how it will accomplish the goals mentioned above. Nyttend (talk) 14:44, 1 September 2014 (UTC)[reply]

• Oppose We already have a history button. I don't like the idea of a computer sorting the value of contributions based on volume. Volume is not an accurate measurement of contribution quality. It could lead to gaming to get to the the high score position by making lots of small edits. Chillum 14:42, 1 September 2014 (UTC)[reply]
• Oppose because of problems exposed here. First, we don't have the technology to do this satisfactorily and without crediting large-scale copyright violations, essays, rants and protracted edit-wars. Second, the premise that a "list of authors would increase transparency to our readership" is dubious; only an experienced editor of Wikipedia would find that a typical list of Wikipedia pseudonyms increased transparency or confidence. NebY (talk) 15:35, 1 September 2014 (UTC)[reply]
• Comment I removed this experimental hack trough the template. Absolutely not acceptable from a technical perspective. If you want to experiment with something like this, write a gadget and enable it by default, but we are not adding more of this relative positioned UI elements that are a hell to support in skins, alternate views and and that are defined in CONTENT. —TheDJ (Not WMF) (talk • contribs) 21:54, 1 September 2014 (UTC)[reply]
  • • Consensus for it on medical articles is here [5]. If you have a better way of implementing it happy to look at. Right now it is being tested to see if any of the concerns raised are legitimate. After this data has been gathered (3 month or so) we can have a wider ranging RfC. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:04, 2 September 2014 (UTC)[reply]
• Support - but consider using wording like "written by contributors like you", to nudge people towards becoming editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 1 September 2014 (UTC)[reply]
• Oppose. I just stumbled across this on some medical pages, and at first I thought it was some kind of bugzilla thing. Personally, I hate the idea of placing the link so prominently, because this is supposed to be about the content, not the editors. Readers already know that it's "the encyclopedia that anyone can edit", so they can figure out that those "anyones" must be some people. It's not rocket science. As for giving credit to which editors it was on a given page, if I wanted credit, I wouldn't be calling myself Tryptofish. And I have a big objection to the way it has been implemented, by tying it into some infoboxes, so it appears on some pages and not others. Either there is widespread consensus to have it all across the English Wikipedia, or it shouldn't be plopped out on an ad hoc basis. All in all, this thing seems to me to be a slap in the face to everything that Wikipedia stands for. --Tryptofish (talk) 18:23, 2 September 2014 (UTC)[reply]

Comment And, the whole "It won't fly with wiki-wide community consensus, so damn the torpedoes, let's start another discussion elsewhere (stacked with 100% supporters), and we'll just do it in our project" thing speaks to the whole system-gaming that is denied elsewhere in this very discussion. GenQuest ^{"Talk to Me"} 19:19, 2 September 2014 (UTC)[reply]

• Strong oppose I also stumbled on this on Tularemia and went to MediaWiki talk:Gadget-ContributorsHack.js asking that is be turned off. I have the following concerns: 1) the information is already accessible in the history tab (both by looking through the page and the first external link on that page; 2) its current location interferes with at least one other gadget; 3) it presents as an internal wikilink but instead directs to an external site not under Wikipedia's control, principle of least astonishment seems to apply; 4) this should be a sitewide approach or at least tied to MediaWiki:Tagline rather than a "hack" attached to an infobox but hovering somewhere which makes it hard to know where the thing is coming from (I found it by searching for the URL in MediaWiki space). Having said that he we included in the tagline in brackets as suggested above a link to the page history not an external link manifesting as an internal link I think that would be a good idea. Callanecc (talk • contribs • logs) 13:21, 4 September 2014 (UTC)[reply]

  @Callanecc: It's not MediaWiki:Gadget-ContributorsHack.js. That is a test gadget, enabled for about two users (I'm one of them) showing how the links currently built in to {{infobox disease}} could be done in a different, less controversial, manner. More at User talk:TheDJ#Gadget, Template talk:Infobox disease#Position of floating contributors link and Wikipedia:Village pump (technical)#Contributors link. --Redrose64 (talk) 14:48, 4 September 2014 (UTC)[reply]

• Comment Evidently this is now being inserted in a template on certain articles. Protonk (talk) 13:43, 4 September 2014 (UTC)[reply]
  • Yes there was consensus [6] to trial it locally and thus we are. I agree maybe this is not something that is needed on non scientific articles. We are also looking at improving the page that it links to. Doc James (talk · contribs · email) (if I write on your page reply on mine) 15:12, 4 September 2014 (UTC)[reply]
    • You wrote elsewhere that We are now testing the concerns on medical articles to see if they are legitimate[7] and Currently we are looking to see if it generates any of the concerns that were brought up during discussion a WT:MED[8]. Can you explain how you will determine if those concerns are legitimate or the problems raised are occurring, and how you will determine the efficacy of this insertion in meeting its stated aims? NebY (talk) 15:46, 4 September 2014 (UTC)[reply]
• Strong support Definitely needed to get information out to the general public of how a Wikipedia article is formed. -- CFCF 🍌 (email) 16:44, 4 September 2014 (UTC)[reply]

I've sat back and commented mostly from a technical point of view, but think there is are some components of this discussion that should be directly addressed:

Should non-content features such as this be consistent across all articles? My inclination is that yes they should, and "consensus" driving for this type of change should be project wide on these non-content components of pages. A discussion on WT:MED determined that there was consensus to make these types of changes, but only to articles that those project members were looking at. This can open the door for a lot of scope creep, if every project team rolls out their own layout changes, especially as many articles overlap multiple projects. Not to wander too far down the slipper slope, but where would this project-specific page layout decision making process end? Should all non-content components of articles be consistent is a question that deserves some more discussion. — xaosflux ^Talk 14:49, 1 September 2014 (UTC)[reply]

Sadly, some projects already so that. And the wider community is unwilling to address, or incapable of addressing, the matter. Even Arbcom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:22, 1 September 2014 (UTC)[reply]

These can easily get at odds with eachother, and the overlap potential is huge, not to mention if someone decides to create Wikipedia:Wikiproject User Interface ... — xaosflux ^Talk 22:41, 1 September 2014 (UTC)[reply]

Well some appear to be arguing that:

1. People do not care about who the contributors of the text are except maybe in medicine
2. Very few people use real names so this is a bad idea
3. People will game this

So as we at WPMED think it is a good idea. We believe people do care who writes the content in questions. Many of us do use our real names. And if people try to "game" this by writing good and featured medical articles we do not have an issue with that. So we are testing it out on medical articles to determine if these concerns exist. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:00, 2 September 2014 (UTC)[reply]

That's not really what I'm talking about, yes those are valid concerns related to this specific feature, and I don't really have a strong opinion on the matter...my point is that the user interface should be consistent across the entire encyclopedia, and that the consensus required for this level of change is far beyond the agreement of topic-specific editors. Say you had a medical article that is also a stub, and the stub project agreed that stubs should have something else in the tagline, it makes sense to them, but will having different UI's across articles benefit the reader? — xaosflux ^Talk 01:27, 2 September 2014 (UTC)[reply]

That is not a proper comparison. Disease related articles that contain infobox disease are primarily medical in nature. These articles have primarily been edited by members of this project. Thus the group that has developed this content has weighed in in supporting a trial of this idea.

We also do not want a situation like were an outside group like the WMF telling the German Wikipedia that they must have Media Viewer because we need consistency of UI between all Wikipedias.

Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:46, 2 September 2014 (UTC)[reply]

It doesn't need to be hacked into {{infobox disease}}: it's a script hosted at Labs (specifically toollabs:xtools/articleinfo/), so it could be built into a gadget. There is already at least one gadget that amends the tagline: at Preferences → Gadgets, enable "Display an assessment of an article's quality in its page header (documentation)" and view any article, e.g. Lionel Palairet. --Redrose64 (talk) 08:17, 2 September 2014 (UTC)[reply]

And I already built it. See gadget prefs. Not yet enabled for all yet, and triggers on the hidden category Category:Articles with contributors link, but the idea is clear. Example page. —TheDJ (Not WMF) (talk • contribs) 09:24, 2 September 2014 (UTC)[reply]

Animated GIF really sucks. Everyone knows it. It has limited colour depth and inefficient encoding, meaning large file sizes. Surely it can't be the future of a media-rich internet?

What do you think of the idea of allowing silent autoplay looping WebM/Theora video, as a replacement for animated GIF? An example use case would be File:Lunar libration with phase Oct 2007 450px.gif which is currently on Moon.

Implementation details: some special parameter on the File: link would activate the feature, maybe [[File:Foo.ogv | autoloop]]. If a sound stream is present in the file, it would automatically be stripped in server-side transcoding. -- Tim Starling (talk) 08:33, 26 August 2014 (UTC)[reply]

I like the stripping of the audio channel. I wonder about browser (and mobile device) compatibility, how many people would see "broken plugin" or something like that? Anomie⚔ 10:18, 26 August 2014 (UTC)[reply]

Judging by commons:Commons:Media help, IE and Safari (iOS and OSX) users would be in trouble, but everyone else would be fine. -- Tim Starling (talk) 16:37, 26 August 2014 (UTC)[reply]

people who voluntarily use IE have personal issues beyond the scope of Wikipedia to fix... --Jayron32 19:21, 26 August 2014 (UTC)[reply]

Maybe we could transcode from WebM/Theora to GIF as a fallback for IE, iOS etc. -- Tim Starling (talk) 20:42, 26 August 2014 (UTC)[reply]

If nobody cares (excepting people on my team) then I don't think I will do it or push for it. Plenty of other things to work on. -- Tim Starling (talk) 00:16, 1 September 2014 (UTC)[reply]

I find the looping videos very annoying. We need a way to set the default to "not playing" so that people need to click the image to turn it on. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:39, 1 September 2014 (UTC)[reply]

You're saying that all animated GIFs should be treated in this way? -- Tim Starling (talk) 01:35, 1 September 2014 (UTC)[reply]

All animated GIFs on a page can be stopped by pressing a key (although Firefox now needs SuperStop for that). After admiring a looping autoplay video, how could it (or all of them) be stopped? Johnuniq (talk) 02:23, 1 September 2014 (UTC)[reply]

What a number of us are requesting is a parameter that requires GIFs to be clicked before they play. So that editors of an article can decide if the want it to play continuously or only play when clicked on.Doc James (talk · contribs · email) (if I write on your page reply on mine) 11:59, 1 September 2014 (UTC)[reply]

If we did that, and also implemented feature parity between animated GIF and looping video, we would also need a non-autoplay loop parameter for videos, right? Say, "clickloop" and "autoloop", and the default would be autoloop for animated GIFs and single play for videos. You say "a number of us", do you know where this was discussed? -- Tim Starling (talk) 22:47, 1 September 2014 (UTC)[reply]

Yes discuss is here Talk:Multiple_sclerosis#Animation Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:28, 2 September 2014 (UTC)[reply]

Auto play is extremely annoying, let's avoid it please. --NaBUru38 (talk) 19:26, 2 September 2014 (UTC)[reply]

Yes, it soaks up bandwidth, pages take much longer to load, and while they're loading you can't scroll down. All you can do is try the "back" button and hope that the video player hasn't hijacked it so that you can't get off the page until the adverts have played through. --Redrose64 (talk) 22:16, 2 September 2014 (UTC)[reply]

Adverts? What? It sounds like you're complaining about something that is not likely to be what we'd ever have here. Anomie⚔ 23:27, 2 September 2014 (UTC)[reply]

Following a misunderstanding on my part about an editor modifying an {{OTRS permission}} template on a file page, I propose that a new user group be created for OTRS members similar to the one on Commons so that such editors can be clearly identified. Personally I've grown used to hovering my mouse pointer over an editor's name and seeing a pop-up box that contains basic details including the user groups that editor is a member of. In this instance I saw only the word "rollbacker" and forgetting to check the actual userpage, I asked a question at the OTRS noticeboard about whether the license for a particular file was correct because it had been added by someone I thought wasn't an OTRS member. I'm sure I'm not alone in having this bad habit of using pop-ups rather than clicking on a page and checking it more thoroughly, but it occurs to me that we should have a separate user group for these editors because they are a trusted group and they have access to classified information. If it avoids another embarrassing episode on my part, I think it will be worthwhile to have this group. Green Giant (talk) 14:26, 30 August 2014 (UTC)[reply]

I was actually drafting a proposal at the same time. The full draft is at this page, but a summary is as follows: Create an "otrs-userright" on enwiki as well, that applies "autoreview" (same as what reviewers have to mark edits to pages under PC as reviewed. Then, create an edit summary to pick up any addition of {{permissionOTRS}} or {{ConfirmationOTRS}} by users not in the groups (like this one). This would both help with the issue that Green Giant mentioned, and reduce the number of false taggings that happen. --Mdann52talk to me! 18:15, 30 August 2014 (UTC)[reply]

In that case I defer to Mdann52's superior knowledge and am willing to wait for the RfC to be published. Green Giant (talk) 21:59, 30 August 2014 (UTC)[reply]

I agree that we need to open an RFC for this. Whenever it is read. Cheers, TLSuda (talk) 01:57, 31 August 2014 (UTC)[reply]

If anybody wishes to participate in this discussion, it is now located at Wikipedia:Volunteer Response Team/Userright RfC. Green Giant (talk) 11:52, 3 September 2014 (UTC)[reply]

Is there any way that a semblance of common sense could be applied to the current designations of user status, and, relatedly, to how article protection is done?

Currently we have "autoconfirmed users". To be "autoconfirmed" on English Wikipedia you have to have been registered for 4 days and made at least 10 edits [9]. Ten freakin' edits. How long does it take you to make ten edits? I can make ten edits in under five seconds (I am 100% certain that most users can beat that time easily). I really really hope that this is some archaic throwback to the early days of Wikipedia, like 2002, when very few people edited the encyclopedia, and did so rarely, so back then this low threshold made some sense. Otherwise it's just some supreme nonsense. We are not in 2002 anymore and this requirement is completely superfluous.

So here's proposal #1, the Minimal proposal: Drop the "10 edits" requirement from what it takes to be autoconfirmed. This is just common sense which shouldn't even have to be explained and doing so will have no real effect on editors what so ever. It's just recognizing that... it's not 2002 anymore.

But obviously, having an edit requirement is actually a good thing, which is why this now-ridiculous threshold of 10 edits was put in there in the first place. It's just that now, the threshold should be much higher. And in fact, other language Wikipedias do set a much higher level (usually these are the ones with some kind of flagged revisions). So how about getting realistic and setting the auto-confirmed standard at at least 300 hundred edits. Even that is ridiculously low. If it takes me less than 5 seconds to make 10 edits, it will take me less than two minutes to make 300 edits. Any person who wishes to cause trouble around these parts has only to exert minimal effort to meet that (proposed, higher) standard. Really, the threshold should be at 1000 or more edits. But I understand there's institutional inertia here and all that, so... baby steps.

Second, under the generous assumption that it's recognized that the current system of "autoconfirmed users" is just plain idiotic, we need to revisit article protection. Right now we have either semi-protection or full-protection. These are about the two worst options that could be implemented.

Under semi-protection, disruptive users just have to wait four days, go to effort of making ten edits, and then they're free to go. Of course, somewhat smarter disruptive users, will start an account, make ten edits and then just let it sit there for a year or two, then utilize them again when the real edit warring/disruptive activity needs to be done. Anyone who's been involved in content writing or even content supervision knows very well that this is a very common phenomenon (throw away sleeper accounts) across the encyclopedia. Hence, semi-protection doesn't do crap. It's really "nothing".

At the other extreme we have full-protection. Here, only admins are allowed to edit articles, and any proposed changes by non-admins need to be floated on the talk page first. Under ideal circumstances this would work IF: 1) admins who full-protect pages actually bothered to keep track of these pages and, again relateldy, 2) the admin corps was skilled in content-related edits. We can AGF the first part, but it's clear as day that most admins do not become admins because they are familiar with content editing. There's actually nothing wrong with that. Different people have different skills, some people are good at writing content and others are good at administrative work. The problem is that "full protection" forces the people who are mainly good at administrative work to engage in the content work which they are completely not suited for. So mostly... they don't do it.

The end result of this - the combination of the fact that troll-ish new accounts can easily bypass the joke that is "semi-protection" and the frustration with being unable to edit a page which is "fully-protected" by non-admin but established users is that serious editors are leaving Wikipedia. More and more, which is something we're all aware of.

What we need is an intermediate level of protection and a new level of status, which is higher than the presently silly "autoconfirmed" user one, but not "admin".

So here is proposal #2: establish a status which requires 1 year on Wikipedia, 1000 edits and a minimum threshold of these in article space. Establish a protection level which allows these users but not the "I made 10 edits four days ago, now I get to vandalize Wikipedia articles all I want" ones edit.

 Volunteer Marek  00:47, 31 August 2014 (UTC)[reply]

• I think what you are talking about is fundamentally a "vested contributor" status. While I don't really have a fully fleshed out opinion on this proposal, the one unintended consequence I think this may overlook is that, right now, full protection is actually quite rare an occurrence, and tends to get withdrawn very quickly, largely because it is so onerous for admins to maintain. The low bar to autoconfirmed status means that by default, en.wikipedia is about as strikingly close to the ideal of "the encyclopedia anyone can edit" as can be done feasibly. I think that any conversation about implementing a new "highly protected" status would need to address the possibility of disturbing that equilibrium that so effectively encourages open editing on en.wikipedia in practice as well as in theory. VanIsaac_WS^cont 02:07, 31 August 2014 (UTC)[reply]

Thanks for the input. A couple of points.

First, overall, given that Wikipedia has more than 4.5 million articles I'm sure that full protection is indeed rare. However, if we limit the scope to critical, or highly viewed, or controversial articles - or some combination of these - the situation is different. On these, it's frequent enough to be a hindrance or at least an annoyance.

Second, you're also right in that full protection tends to get withdrawn very quickly. But that's a symptom of its dysfunctionality rather than a perk. Basically what happens is that an important article suffers disruption, it gets fully protected, serious editors then cannot edit the article and get extremely annoyed so then they bug and harangue the admin who fully protected it, so then after some back and forth (and some potential and unnecessary drama, even AN/I discussions) it gets lifted. The fact that full protection is "quickly withdrawn" is evidence of the fact that it sucks and that it doesn't work. Not a testament to its viability.

And you're also right about the third issue - the lowbar to autoconfirmed status does mean that pretty much "anyone can edit". Ok, having admitted that, we can go two ways. One: if it doesn't mean anything why even bother with it? Why even have "autoconfirmed status"? If we really want "everyone to edit" why bother with the hypocrisy of this label and why even semi-protect articles? (A more honest approach would be to simply ban unregistered IPs from editing certain articles). Two: despite the high falutin' rhetoric, we actually DON'T want "anyone" to edit the encyclopedia. We ban people all the time. We waste tremendous amounts of time reverting vandalism. And disruptive edits. And sock puppets of banned users. And sock puppets of vandals. And sock puppets of banned vandals. Etc. We obviously WANT a certain threshold of edit quality to exist and if somebody cannot meet that they're not part of that "anyone" that can edit. That "ideal" that you mention is a "founding myth" which was actually never true in the first place (even back in 2002 they blocked people). It's time we grow up and admit to ourselves that certain standards are necessary (we even have essays, like WP:COMPETENCE or WP:NOTHERE) which pretty much say it).

Finally, and this is in some ways fundamental, the problem is that this is NOT an "equilibrium". An "equilibrium" implies a state of stasis, a constant, a situation which can be expected to persist for the foreseeable future. This isn't it. We're loosing editors, and what's worse, we're loosing *quality* editors. And a lot of that has to do with the issues outlined above. I'd elaborate on this point but we'd be getting off topic. What we have now is an *outcome*, not an *equilibrium*. A bad outcome too, and more importantly an unsustainable one.

 Volunteer Marek  03:42, 31 August 2014 (UTC)[reply]

@Volunteer Marek: would something like pending changes level 2 work, if the bar to the userright was raised to reflect the new level required by such edits? Alternatively, we could create something like TemplateEditor, and use it on protected pages more (like it seems to be on a few pages now). --Mdann52talk to me! 07:04, 31 August 2014 (UTC)[reply]

@Mdann52: That would definitely be a step in the right direction, although if it were up to me I'd move that green box one more square to the right (I'm not clear on why Reviewers wouldn't be allowed to edit - presumably because this Template Editors would be a newly created category?). Those charts actually make my point very nicely - there's semi protection and then there's full protection, and then there is this huuuuggggeee area in the middle. Right now we have a "it really has no effect" policy and we have a "it has a devastating effect policy". Common sense should tell you that we need a bit more... nuance. Very very rough kind of nuance. Volunteer Marek  07:56, 31 August 2014 (UTC)[reply]

template editor is a reletively new right, that was created for this very reason (a lot of non-admins were better at editing templates than admins). If you can get support for introducing, lets say a "protected editor" user right (to allow fulfilling edit requests and making uncontraversial changes on full-protected pages), then it should be fulfulled with little complaint on the dev side of things. --Mdann52talk to me! 08:45, 31 August 2014 (UTC)[reply]

Though I don't feel like supporting the main proposal, I think spinning out the edit full protected right from the admin package is something worth looking into. Obviously such users would have to act as admins in that situation, i.e. not make controversial changes or any significant ones without talk page consensus; also, a policy about granting the right would be needed, say, answering x semi-protected edit requests correctly, demonstrating respect for consensus. Perhaps make this a separate proposal, Mdann52? BethNaught (talk) 10:39, 31 August 2014 (UTC)[reply]

@BethNaught: I'm currently working on another similar proposal (#OTRS members above), but will get round to this once that one is RfC'd and in progress. --Mdann52talk to me! 17:49, 31 August 2014 (UTC)[reply]

• A valuable proposal. This could lead to a desirable simplification of the user rights system: we could create a general "trusted editor" status, amalgamating:

• rollbacker
• reviewer (i.e. can approve or reject pending changes)
• autoreviewer (i.e. own new pages not patrolled)
• can edit semi-protected pages
• more controversially - can delete pages.

The pending-changes system would then be abolished as identical in effect with semi-protection.
Approval for the trusted-editor right would be by (1) a certain number of edits, (2) a certain time since account opened, (3) in-depth examination of editor's record by an admin (two admins?); and the right could be withdrawn by any admin with reasons given to the editor: Noyster (talk), 10:00, 31 August 2014 (UTC)[reply]

@Noyster: are you proposing we get rid of the reviewer/rollback usergroups, or have another one that incorperates the rest of them? FYI, the request to delete pages will not be added to the group by the foundation dev's, because the ability to see deleted content requires a RfA-like process, so I feel that there is little chance of the last point being implimented sucsessfully... --Mdann52talk to me! 17:49, 31 August 2014 (UTC)[reply]

I actually really like this proposal in concert with a "high protection" level; it both simplifies the current cadre of advanced user rights (reviewer? rollbacker? autoreviewed?) and provides a means of relaxing the overkill of many long-term fully protected pages. As to your concern about viewing deleted material, Mdann, I guess the fundamental question here is whether there is a reason why the ability to delete pages needs to be bundled with the ability to view deleted content. If these were, in fact, decoupled from each other, what would be the obstacles, both technical and practical? As far as I can see, the biggest hassle would be the creation of Criteria for Speedy Undeletion to complement the current WP:CSD, perhaps as a subsection of that policy, for cases when material is accidentally deleted by someone who is unable to undelete (undeletion is fundamentally an ability to view deleted content). It would also introduce a small deletionist bias in the system, so it would need a pretty extensive review process. I certainly think it's an idea worth exploring in more depth. VanIsaac_WS^cont 21:28, 31 August 2014 (UTC)[reply]

@Vanisaac: I believe (I may be wrong) that they are bundled together on the MediaWiki side of things. I'll look into it. --Mdann52talk to me! 06:02, 1 September 2014 (UTC)[reply]

Regarding the trusted-editor right, a similar user right was proposed in April 2013 and did not gain consensus. SiBr₄ (talk) 20:26, 31 August 2014 (UTC)[reply]

More generally, see also Wikipedia:Perennial proposals#Hierarchical structures. The community has historically been wary of adding more levels of protection to articles and to giving people some parts of the core admin toolkit without the rest. Anomie⚔ 11:46, 1 September 2014 (UTC)[reply]

• Marek, you can make ten edits, I can make ten edits, everyone here can make ten edits, in maybe a minute. A newcomer who is barely grasping wikimarkup can't. More importantly, no, there's no indication that new vandals are anything to do with why people are leaving Wikipedia. Long-term contributors actually have a remarkably high retention rate - it's the newcomers who are struggling - and blocks for vandalism or disruptive behaviour have been going down continuously, in absolute terms, since 2009. Ironholds (talk) 15:21, 1 September 2014 (UTC)[reply]

The 10 edits are nothing, but the 4 days are significant. I was an admin prior to semi-protection and auto-confirmed. It sucked.

Those 4 days make a huge difference. Yes it is easy to wait 4 days but it takes 10 seconds to block someone. Since semi-protection and autoconfirm came in it has gone from very difficult to very easy to stay on top of socks.

Even if the person makes 20 sleeper accounts it is still easy to revert/block/ignore in minutes and they still need 4 days to make more.

I think the threshold needs to be kept low in order to encourage new users. Even a brief delay is enough for most socks to get bored and move on while giving admins a lopsided advantage over them. Chillum 15:31, 1 September 2014 (UTC)[reply]

• Oppose any changes mostly per Chillum, but also because we shouldn't make fundamental changes to how Wikipedia operates and it's philosophy merely because of vandals. The low threshold allows good faith editors easy access to all of Wikipedia with a minimal effort, and balances that with enough of a restriction to avoid the throw-away accounts Chillum notes. While certainly annoying, these persistently socking vandal is less of a problem, in terms of volume of people, than are the newbies who want to contribute in good faith. We should be doing everything we can for the second group. The first will always be with us, and isn't worth alienating the newbies to institute such a drastic change. --Jayron32 02:38, 3 September 2014 (UTC)[reply]

• Comment: The 1000 edit criteria is a crude way to compensate for the fact that it's possible to deliberately spam worthless edits. For a good editor who spends time on good edits, 1000 is a pretty substantial bar to pass. What's really needed (if something like this is done) is some criteria that isn't as trivially easily gamed as simple edit count. Alsee (talk) 21:25, 3 September 2014 (UTC)[reply]
  • Reply comment: Every single admin knows the tell-tale signs of a vandal account eating through their first ten edits, as do most non-admin vandalism patrollers. Without delving into WP:BEANS-type stuff here, it's really obvious when we see this, and not hard to identify. The 1000-edit count doesn't help us stop bad-faith accounts (of which account for a tiny fraction of all new accounts created at Wikipedia anyways), as much as it does to discourage new users from becoming full contributors. A balance needs to be struck, and 1000 edits is WAY too much in terms of harming new user participation, against the small benefit of stopping a few vandals. Even if it stopped a lot of vandals, we do fine enough doing that using traditional means (AIV, etc.) Contrary to popular belief, we're not being overwhelmed, the system keeps up and squashes most vandals within minutes, and those of us that have been here for many years aren't even annoyed by them anymore. This is using a shotgun to do a flyswatters job, and has too much collateral damage to be useful. --Jayron32 23:44, 3 September 2014 (UTC)[reply]

I'm perhaps a bit of idealist, but find it odd that only economical ranks (GDP, Gini) or ranks based mostly on economic performance (HDI) are shown at the {{Infobox country}} table. I suggest adding information about state of democracy, state of freedom of speech and level of corruption the the table, right below the GDP, HDI and Gini ranks. These give a much wider view to the society than just economical.

Especially prosperous East Asian countries seem to be like Western countries based on the table and the introduction part in the article, but they have significantly lower political freedoms than their Western counterparts and are often more corrupt. The table in the article Singapore according to my proposion would look like this: [10] Giving the three ranks of Democracy Index, Press Freedom Index and Corruption Perceptions Index would help understanding the Singaporean exceptionalism, where the 3rd highest GDP and the 5th best rank in the Corruption Index is combined with an authoritarian regime, the Press Freedom being lower than in Russia. /á^(!) 00:48, 1 September 2014 (UTC)[reply]

The problem is that those other indexes are incredibly subjective. Even when it comes to a concept such as freedom, different people can consider the same factor as adding to, or detracting from freedom. Is a society that protects your religious beliefs from criticism more free as a result, or less free because to do so infringes on the freedom of someone who would criticize your beliefs? Do we measure freedom as negative rights against government, do we include positive rights, what about "rights" that restrict what other individuals or associations can do? Monty₈₄₅ 14:35, 1 September 2014 (UTC)[reply]

I agree that general most free countries indexes are quite subjective, but these three indexes are subjective only to some level. In the Press Freedom and Corrption indexes information is gathered from many sources – from 13 sources in the Corruption Index –, and in the Democracy Index, the criteria are openly shown at their website, and the criteria are measuring solely level of democracy, not things like religious freedom. If the elections are not plagued by fraud and oppression of voters and the opposition is not harrassed, then the country is more democratic.

If you compare the Democracy Indexes made by Economist Intelligence Unit and World Audit, they look very similar. EIU ranks Singapore as #81 and World Audit as #71. EIU ranks Norway, Sweden, Iceland, Denmark and New Zeeland as the most democratic countries, while World Audit ranks Sweden, Denmark, Finland, Norway and New Zeeland as most democratic countries. There are similar small differences between GDP ranks. IMF ranks Qatar, Luxembourg and Singapore as the wealthiest countries, the top 3 of World Bank rank is Qatar, Luxembourg and Kuwait, and CIA ranks Qatar, Liechtenstein and Monaco as the top 3.

On the other hand, if you look at the page List of countries by income equality, the amount money the richest 20% gets compared to how much money the poorest 20% gets gives a different list than the list of countries with lowest Gini. The 20/20 ratio gives Japan, Czech Republic and Finland as the countries with least income equality, while Denmark, Sweden and Norway have the lowest Gini coefficients. The Gini index is a subjective presentation of income equality level – just as right as the 20/20 ratio –, and yet is it shown in every article. /á^(!) 21:46, 1 September 2014 (UTC)[reply]

I support adding the Democracy Index, but not the other two. Press freedom is a very specific issue, whereas perception isn't reliable data. --NaBUru38 (talk) 19:46, 2 September 2014 (UTC)[reply]

This would be already quite good, because the Democracy Index reveals the remarkable difference between Qatar and Luxembourg, or between Brunei and Norway, respectively, and there is a significant correlation between freedom of speech and level of democracy. (The Press Freedom Index was proposed as a proxy of freedom of speech.) /á^(!) 22:44, 3 September 2014 (UTC)[reply]

I first placed this at the Idea lab but I think this is a better place.

When I add a page to my watchlist I would like to be able to put a comment which would appear next to each item on my Edit watchlist page. This would be used to remind me when and why I put it there. Often when I look at this list I find that I have forgotten the reason it's there if it's been a while since I looked at it especially if I didn't make an edit at the time. I could put this info in my sandbox or on another subpage but this would be a much more convenient method. Jodosma (talk) 08:57, 2 September 2014 (UTC)[reply]

• Support This is a good idea. I just checked Comilla, which I added to my watchlist (sometime before my recent months-long absence from WP), and for the life of me, I don't know why I had added it. GenQuest ^{"Talk to Me"} 15:25, 3 September 2014 (UTC)[reply]
• Support - provided that the reason is only readable by the editor who added it. I sometimes follow badly-written articles but would not want those involved to know this. S a g a C i t y (talk) 15:51, 3 September 2014 (UTC)[reply]

Now that Wikidata handles FA and GA badges and Dexbot is removing the templates, the badge appearing next to interwiki links on en.wikipedia is now a silver star (see the badge next to the German and Japanese links at Oxygen for an example). I propose that we request that it remain the green plus symbol (File:Monobook-bullet-ga.png). The request can be made at Meta:Wikidata/Development/Badges#Requests for different icons. 130.88.141.34 (talk) 09:27, 2 September 2014 (UTC)[reply]

It seems we could easier just put the correct image in MediaWiki:Common.css. Along those lines, I see the new badges aren't showing up at all in Monobook because for some reason MediaWiki:Monobook.css is already overriding the bullet images. Anomie⚔ 11:55, 2 September 2014 (UTC)[reply]

Anomie there is a known bug. I informed the wikidata guys in the IRC channel. -- Magioladitis (talk) 11:58, 2 September 2014 (UTC)[reply]

Anomie https://bugzilla.wikimedia.org/show_bug.cgi?id=70280 -- Magioladitis (talk) 12:03, 2 September 2014 (UTC)[reply]

I hope it was not a mistake I approved this task. Please inform me quickly so we can act if there is any problem. -- Magioladitis (talk) 12:01, 2 September 2014 (UTC)[reply]

Dear all,

I would like to propose adding an extra button to the top of the page when viewing a history. For example this request page. On the top there are 3 links: "Older revision, Latest revision, Newer revision". However, if you want to know what happened to a request on that page, using the older/newer revision buttons is too slow, moving 1 step at a time, when 100 edits might be in between the request and the answer. You can go to the history section and start going back, but this means searching, and on larger pages it takes some time. I suggest adding an extra button that immediately sends you to the "history section" of that edit, so you are directly at the right spot in the history tab, and can see the 50 edits directly around the edit.

This same request was made to wikimedia-tech on Bugzilla 7 years ago, see [11]. They stated "This would probably not be very hard to implement", however up to date nothing has been done. I am not a Bugzilla user or developer, yet I think this change is usefull and I think we should have it. It gives no disadvantages. I think the only way to get this change is to get some attention for it. I have posted a request on meta ( that can be edited by all, unlike bugzilla) and suggest that people reply there to state their opinion on the change. Thank you very much,

Sincerely, Taketa (talk) 10:15, 2 September 2014 (UTC)[reply]

Following a discussion at the idea lab, I would like to propose specifying that New Page Patrols are patrols, not reviews, in user notifications. A common question I see asked at the Teahouse, Help Desk, and IRC help channel is from users who are confused about why their article draft/user page/sandbox has been 'reviewed' and yet they can see no change. This is particularly confusing for new users who have submitted an Article for Creation - their article being reviewed seems to suggest that an accept or decline decision has been made, and they are confused when no such decision is obvious. This stems from both New Page Patrol and AfC reviews being described as 'reviews'; when a page is patrolled the user receives an email and notification informing them that their "page has been reviewed" when in fact it has been patrolled. I suggest changing the following interface messages (thanks to Jackmcbarn for finding them) to specify that the page has been "patrolled" not "reviewed":

• MediaWiki:pagetriage-notification-mark-as-reviewed2
• MediaWiki:pagetriage-notification-mark-as-reviewed-flyout
• MediaWiki:pagetriage-notification-mark-as-reviewed-email-subject2
• MediaWiki:pagetriage-notification-mark-as-reviewed-email-batch-body
• MediaWiki:pagetriage-notification-add-maintenance-tag2
• MediaWiki:pagetriage-notification-add-maintenance-tag-flyout
• MediaWiki:pagetriage-notification-add-maintenance-tag-email-subject2
• MediaWiki:pagetriage-notification-add-maintenance-tag-email-batch-body
• MediaWiki:pagetriage-notification-add-deletion-tag2
• MediaWiki:pagetriage-notification-add-deletion-tag-flyout
• MediaWiki:pagetriage-notification-add-deletion-tag-email-subject2
• MediaWiki:pagetriage-notification-add-deletion-tag-email-batch-body

Additionally it could be beneficial to include either a brief explanation of what NPP is or some link to WP:NPP in the notification or email. Sam Walton (talk) 22:40, 2 September 2014 (UTC)[reply]

Hear hear, this word "review/reviewed/reviewing" has too many meanings in Wikipedia, as also seen in a recent discussion on user right naming: Noyster (talk), 09:37, 3 September 2014 (UTC)[reply]

Support, this also makes it consistent with the autopatrolled right. BethNaught (talk) 10:05, 3 September 2014 (UTC)[reply]

• I would certainly support getting the terminology right. As one user who has been extremely concerned about NPP for many years I have never referred to NPP as anything other than 'Patrolling'. As I never create pages as a new user, I was oblivious to the confusion that it causes among the newbies. Kudpung กุดผึ้ง (talk) 10:54, 4 September 2014 (UTC)[reply]

The Draft namespace was enabled in December 2013 (see Wikipedia:Drafts) and some WikiProjects (currently 0) have opted to use the Draft-class assessment to keep track of draft articles within their scope. The advantage is that it facilitates editors in a project to work on improving draft articles within their knowledge and interest to get them ready for mainspace.

This proposal is about whether this usage should be widened by making it one of the default assessment classes used by projects. There are 3 options:

1. Status quo: projects can opt-in to using Draft-class.
2. Add Draft-class to FQS: all projects currently using the "Full Quality Scale" (approximately 1300) will automatically have Draft-class enabled, unless they choose to opt-out.
3. Add Draft-class to all: all projects using the standard quality scale (approximately 1900) will automatically have Draft-class enabled, unless they choose to opt-out.

For more details (including how this would be done), see Template talk:Class mask#Protected edit request on 1 September 2014

• The Draft namespace is here to stay and is proving to be a useful place to develop articles. Currently, virtually all namespaces (e.g. templates, portals, categories, project pages) have their own assessment class and are included in the full quality scale. The File-class was the most recent one to be added. Therefore projects which have selected to use the FQS are probably interested in using the Draft-class, so I think option 2 is probably the most sensible. — Martin (MSGJ · talk) 13:22, 3 September 2014 (UTC)[reply]
• I choose Option 2 (Add Draft-class to FQS). --Redrose64 (talk) 13:58, 3 September 2014 (UTC)[reply]
• Good thinking, Martin. I support option 2. --122.109.102.172 (talk) 11:19, 4 September 2014 (UTC)[reply]
• Well, on the one hand, there are already a lot of rating classes as it is, but on the other hand, "Full" should really mean "Full", so I guess I would weakly support Option 2... Cooljeanius (talk) (contribs) 16:01, 4 September 2014 (UTC)[reply]

Have a prominent button at the top of each article that says, "We can alert you when this page changes." If you're signed in and have email enabled, clicking the button adds the article to your alert list, and you'll get an email when the article changes. If you don't have an account, clicking the button takes you to a sign up page and then, once the sign up is complete, you're presented with "Would you like us to email you when [article name] changes?" If you select yes, the article is added to your alerts list and you're presented with "Done." Instead of "We can alert you when this page changes," articles on your alerts list will have a button saying, "Remove from alerts." --Anthonyhcole (talk · contribs · email) 13:14, 3 September 2014 (UTC)[reply]

Excuse my ignorance - what's an alert list? Is it similar to your watchlist? — Martin (MSGJ · talk) 13:46, 3 September 2014 (UTC)[reply]

As I read it, this is already possible using the watchlist. Preferences has an option for email notifications of changes to watched pages. SiBr₄ (talk) 14:00, 3 September 2014 (UTC)[reply]

Yep, Martin. A list of articles you want to be notified about when they're edited. AiBr4, I'm aware of that. (I explained the process to a new editor a couple of days ago.) I'm looking for something a lot more obvious and somewhat simpler, for readers who don't know our arcane ways. And I'm suggesting a separate list from the watchlist because I've got lots of articles on my watchlist, but there are only a couple that I would want to be notified by email about. Using the present setup, I think you get emailed every time anything on your watchlist changes. --Anthonyhcole (talk · contribs · email) 16:45, 3 September 2014 (UTC)[reply]

Might I suggest that all A-class articles got their own icon in the right upper corner like FA-class articles get. Today it is hard to tell if an article is A-class or not. I think that it should be more visible that an article was A-class. --BabbaQ (talk) 18:04, 3 September 2014 (UTC)[reply]

A similar proposal was made less than a month ago and is now at Wikipedia:Village pump (proposals)/Archive 113#Show article quality to readers?. SiBr₄ (talk) 18:36, 3 September 2014 (UTC)[reply]

@BabbaQ: Go to Preferences → Gadgets and enable "Display an assessment of an article's quality in its page header (documentation)". You won't get an icon, but the page title will turn this colour. --Redrose64 (talk) 18:44, 3 September 2014 (UTC)[reply]

It would be nice to have the watchlist NOT broken by day. When I log in in the morning, I want to see all changes for the last X hours. Not all changes since midnight, and then changes up to midnight somewhere else. Thoughts? Gaijin42 (talk) 14:38, 4 September 2014 (UTC)[reply]

There is a movement called 'Go-Slow Day' where websites will purposely slow down in a protest to the FCC, to show them what kind of negative impact can come from their decision. Larger tech companies are already joining in, and more can be found here on reddit: http://www.reddit.com/r/news/comments/2fg8ky/large_us_tech_firms_plan_go_slow_day_in_protest/ If Wikipedia joined in that would be amazing. It is one of the largest sites in the world, and many would follow in their footsteps.

Thanks for your time.