Wikipedia:Village pump (proposals)/Archive 101

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Add a population database by country to wikidata

Hi, noticed yesterday that World Gazetteer, a highly valuable population resource website by country has announced its closure in July. I feel it would be very important to try to salvage the data and process it into wikidata before the website is shutdown and we can continue to build it and eventually try to provide population data for most settlements in the world which is there for every wikipedia to use at their fingertips. Please comment at my proposal here if you see potential in this.♦ Dr. ☠ Blofeld 10:06, 14 April 2013 (UTC)

Regarding Wikipedia Home Page

Dear Sir/Ma’am

We know about Wikipedia is hosted by the Wikimedia Foundation, a non-profit organization that also hosts a range of other projects (likes Wikibooks, Wikinews, Wikiquote, Wikidata etc.)

Now-a-days or everyday even every time technology has been changing. So, we have to change according to their path. I want to say about the home page, there should be some changes like

All tools should come under "Wikitools" In Wikitools:- Main page (Wikihome), Help, Editing (Wikiupdate), Toolbox (f_upload, pages, link, info). Similarly,

Wikilanguages: - contains all the languages. (Wikiglobe)

Wikinew: - contains innovation, research, features, May I help you (Help Portal). Note: - Wikinew is different from Wikinews.

I do not want to say that you have to accept these things but there should be change.

Parivartan sansar ka Niyam hai! (source :- Gita Saar (Bhagavad Gita)).

Thanking You

Regards Rupesh Kumar Gupta INDIA — Preceding unsigned comment added by Rupes2012 (talk • contribs) 07:38, 15 April 2013 (UTC)

Rescue the toolserver

Hopefully some WMF staff will read this. Some egoism on WMFs part wouldn't hurt here. -- Toshio Yamaguchi 16:58, 16 April 2013 (UTC)

I have no idea if it's doable or not (or, if not, why not) since that's way out of my area, but I have alerted some of the operations engineering team to the suggestion. --Maggie Dennis (WMF) (talk) 17:46, 16 April 2013 (UTC)
That thread is from six months ago. --MZMcBride (talk) 21:04, 16 April 2013 (UTC)
Mmh, well I admit I didn't notice that. Does that mean those servers have already been given somewhere else? If not, then I think using them to keep the toolserver alive would definitely benefit a number of projects/WikiProjects/editor groups. -- Toshio Yamaguchi 21:38, 16 April 2013 (UTC)
Seems a bit pointless anyway as the toolserver is being phased out over the next year or so in exchange for mw:Wikimedia_Labs ·Add§hore· Talk To Me! 13:20, 19 April 2013 (UTC)

Marathon route maps

Not a proposal. Graphics Lab is thataway. King of ♥ ♦ ♣ ♠ 12:04, 18 April 2013 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Help Wanted

Qualifications:

  • Must know graphics software

Job description:

  • Create some marathon route maps: Use a map from OpenMaps.org. Fit a route map (from an article's external link) under it. Trace the route onto the OpenMap. Save and upload to commons.

Salary:



Imagine article Northwest Passage just having images of people in boats with maps only as external links.

These major articles and others have no route maps--just pictures of people running:

See also: Talk:Boston Marathon#Map

Please help. Thank you. :) Anna Frodesiak (talk) 12:29, 17 April 2013 (UTC)

Are all marathons exactly the same route every year? Alanscottwalker (talk) 15:24, 17 April 2013 (UTC)
Sounds like a job for Wikipedia:Graphics Lab. --  Gadget850 (Ed) talk 15:30, 17 April 2013 (UTC)
Alanscottwalker: Good question. I think so. I will check. Anna Frodesiak (talk) 15:35, 17 April 2013 (UTC)
One would think it important to have a route map front and centre. But alas, no. All the more reason for Wikipedia to make such a map easily available. I gather major marathon routes are usually consistent so results can be compared.Anna Frodesiak (talk) 15:48, 17 April 2013 (UTC)
Gadget850: We have a graphics lab? (I will leave this thread and link to it. Hope that's okay.) Anna Frodesiak (talk) 15:35, 17 April 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Watchlist style

(Apologies if this has already been rejected. I did search through WP:Perennial proposals#Watchlist changes.)

When there are multiple contributors to each page the links to the articles themselves get lost in a blue sea of wikilinks. Would it be possible to display the article links in bold? Or if's already possible what am I missing? Thanks in advance. nagualdesign (talk) 00:29, 20 April 2013 (UTC)

You can do this using CSS—add .mw-special-Watchlist .mw-changeslist-line-watched .mw-title { font-weight: bold; } to your Special:MyPage/common.css file. —Theopolisme (talk) 00:38, 20 April 2013 (UTC)
See also Wikipedia:Customizing watchlists, if you'd like to have pages that you need to read listed in bold (the default on most WMF websites, but shouted down here a few months ago because change is bad) and the ones that haven't been changed since you last read the page listed in normal type. WhatamIdoing (talk) 00:42, 20 April 2013 (UTC)

CISPA Blackout

WP:SNOW —Theopolisme (talk) 01:51, 21 April 2013 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

We did a blackout in the past regarding SOPA/PIPA. CISPA has passed in the House and is up for vote next week in the Senate. I propose Wikipedia do another blackout in protest of CISPA. — Preceding unsigned comment added by Candi 2008 (talk • contribs) 21:58, 18 April 2013 (UTC)

 Comment: I'm not so sure – CISPA doesn't seem as bad as SOPA/PIPA; correct me if I'm wrong. – Ypnypn (talk) 23:12, 18 April 2013 (UTC)
  • Oppose For the same reason I opposed the SOPA action. We are here to make an encyclopedia, not news. GenQuest "Talk to Me" 00:17, 19 April 2013 (UTC)
  • Comment The reason for the SOPA black out was that it would directly affect Wikipedia. This doesn't seem true for CISPA (I could be wrong) so in such a case it's not really something Wikipedia should be rallying again, even as bad as it might be. ♫ Melodia Chaconne ♫ (talk) 02:45, 19 April 2013 (UTC)
  • Oppose - I think that the SOPA blackout was a bad idea; I think that this would be even worse, unless it threatens Wikipedia. עוד מישהו Od Mishehu 09:05, 19 April 2013 (UTC)
  • Oppose - Right. CISPA does not hurt Wikipedia in any way at all. The SOPA blackout was because the issue was so controversial as to having an impact on Wikipedia that we decided to black out. CISPA is totally different. It allows companies to send information upon the government's request if they have belief that a cyber security threat exists without the risk of a privacy suit. Wikipedia is a free and open encyclopedia; very little would fall under the "private" label except for maybe passwords. Michaelzeng7 (talk) 12:09, 19 April 2013 (UTC)
  • Oppose ·Add§hore· Talk To Me! 13:14, 19 April 2013 (UTC)
  • Oppose-As mentioned above, this is not the same as the SOPA issue. SOPA posed a genuine threat to Wikipedia. That was why we blocked out, not just because we disapproved of it. CISPA, whatever we may think of it, does not pose that kind of threat.--Fyre2387 (talk • contribs) 14:22, 19 April 2013 (UTC)
  • Comment: I don't think Wikipedia should be used for political protests. Praemonitus (talk) 21:58, 19 April 2013 (UTC)
  • Oppose--totally not the same. —Theopolisme (talk) 22:01, 19 April 2013 (UTC)
  • Oppose - Probably the most stupidest idea ever thought of! – →Davey2010→→Talk to me!→ 22:09, 19 April 2013 (UTC)

Just because it may not affect Wikipedia does not mean it should not be done. Be careful not to care only of yourself, there are many other people this would affect in a positive way.

Actually yes it DOES mean that. Wikipedia is an encyclopedia. It is not a soapbox. ♫ Melodia Chaconne ♫ (talk) 04:52, 20 April 2013 (UTC)
  • Oppose - Though I am personally opposed to CISPA, It does not impact Wikipedia as SOPA/PIPA threatened to do. I wish that other websites who care about this issue perform a blackout but a blackout by Wikipedia does not help fulfill Wikimedia's mission statement, which is:
The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally.

Available [1].

Spitfire19 T/C 07:24, 20 April 2013 (UTC)

  • Oppose Not going to happen, no point discussing it. —Tom Morris (talk) 21:17, 20 April 2013 (UTC)
  • Oppose. I supported the SOPA blackout because of the effect it would have on our work. This neither compels our action nor endangers our platform. bd2412 T 21:41, 20 April 2013 (UTC)
  • Oppose: There have been bigger threats to English speaking Wikimedians in other countries and no action taken. If the USA is the problem, the solution is to put forth a resolution to the WMF board to move the servers to a less hostile country in terms of government censorship. That speaks volumes more than a ceremonial block for all but a few Wikipedians. (Remember the last one? Where a number of admins used it as an opportunity to take admin actions without consequences?) --LauraHale (talk) 21:43, 20 April 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Deprecation of redirects

I just learned that WP:BRINT (exceptions from NOTBROKEN) misses an important case: deprecated redirects. If for 4 year Wikipedians repaired only tiny portion of about hundred bad redirects, then something is deficient in guidelines and technology. Could MediaWiki assign a special class to a redirect labelled with {{R from ambiguous page}} even if its target is not a dab page? BTW I do not think that any {{R from ambiguous page}} redirect has to lead to a dab page. IMHO this label should merely declare that the redirect may not be used in articles, on the same grounds as a (direct) link to a dab page. Incnis Mrsi (talk) 04:52, 19 April 2013 (UTC)

I have read this multiple times and still don't understand. Links to dab pages are not prohibited, sometimes they are necessary. Rmhermen (talk) 16:11, 20 April 2013 (UTC)

teaching wikipedia

What if there was a week of banner ads aimed at IP users linking them to short videos teaching basic WP skills (e.g. searching, creating an article, creating an account, patrolling for vandals)?

It could maybe be a nice way to help people heal after donation-begging season is over. 2602:100:4759:4D52:914F:C1F9:F8A3:D538 (talk) 07:34, 20 April 2013 (UTC)

We've actually tried this a couple of times in the past - I know that for at least one of those times, the stats were underwhelming. I don't know about others, because I wasn't directly involved in them. But I think any such campaign would need to be carefully conducted, and tested to see if it actually works, versus just wasting the banner space. Philippe Beaudette, Wikimedia Foundation (talk) 12:34, 20 April 2013 (UTC)
It might be interesting to try this next year, after the WP:VisualEditor has been implemented. The goal behind the VisualEditor is to make it easier for new people to edit, so it makes more sense to attempt recruiting after that change. WhatamIdoing (talk) 19:28, 20 April 2013 (UTC)

Ways to prevent new users from submitting pages with no references at the Afc

Dear technical folks:

We Afc reviewers waste a lot of time declining articles that have no references at all. Several of us have been discussing ways to discourage users from submitting such articles. I made up a proposal for an intermediate step in the submission process in which users would be warned and asked to confirm that their articles had sources. I posted it at User:Anne Delong/AfcBox and requested input from other reviewers at User talk:Anne Delong/AfcBox so that we could agree on a proposal to bring to those who implement these types of things.

Another editor, Techncal 13 has made a counter proposal that a bot be created to actively check the pages for references and abort the submission process if there aren't any. His ideas are also on the talk page above.

I would appreciate a technical assessment from someone who is familiar with the technical ins and outs of Wikipedia about the practicality of both ideas. Each proposal seems to have its own strengths and weaknesses. Or, perhaps neither is practical and we should continue manually declining the articles (sigh). —Anne Delong (talk) 20:52, 16 April 2013 (UTC)

I think the least confusing thing for the editors submitting them would be if they were allowed to submit them normally, but a bot would automatically decline articles that don't have references. It could then leave them a message telling them the reason for the decline and giving them advice on how to add references. Ryan Vesey 20:54, 16 April 2013 (UTC)
Do you mind if I copy your reply to the talk page above so that it is in context?—Anne Delong (talk) 21:03, 16 April 2013 (UTC)
How will the bot know if there are references? The presence or absence of <ref> tags is not definitive, and a lot of new users don't use them/can't figure them out. Cell-free fetal DNA is a new article with 63 inline citations, but zero ref tags. WhatamIdoing (talk) 21:07, 16 April 2013 (UTC)
I'm sorry, I messed up my message. Could you please check out the proposal first at User:Anne Delong/AfcBox and then add to the discussion at User talk:Anne Delong/AfcBox, because some of these ideas are already being discussed there? Thanks. —Anne Delong (talk) 21:16, 16 April 2013 (UTC)
  • Oh dear. I'm afraid I hadn't made my proposal clear in the primary discussion for this proposal. My suggestion was to create a JavaScript Gadget to be added as a default gadget on the site. This gadget would deactivate the save button, force users to "Show Preview" at least once to reactivate the save button, check for <ref>...</ref> <references /> and URL protocols (http(s):// - ftp:// - irc:// - etc...), and check for content categories (then make sure to add the extra ":" so they display but don't categorize) on all AfC articles and userspace drafts. Advanced editors could disable this gadget from their Special:Preferences#mw-prefsection-gadgets tab. Technical 13 (talk) 11:59, 18 April 2013 (UTC)
This still does not answer the objection. Most specifically, Not all refs are from the web, and any form of referencing is accepted if it gives the information. We already have a great deal too many AfCs being rejected because the reviewer does not like the style of references, or is ignorant of the fact that multiple ways are all acceptable. This is trying to enforce a mere optional style preference in a way not supported by policy. And even in mainspace, sourcing is not required, except for BLPs. Unsourced is not even a reason for deletion at all, only unsourceable.
Actually, the entire concept behind this is wrong. We want to encourage people to submit AfCs as best they can, and then to learn from the criticism. It should be easy to submit incomplete articles, as a way of getting advice how to complete them. Much better that they submit inadequate work at AfC than in mainspace -- that's the entire reason we have the AfC process. If someone does have a complete article with references, they would probably do well to bypass AfC altogether. Most of the articles submitted at AfC are unsatisfactory as submitted, which is just as it should be, or we'd have no need for the process. Some get improved; some don't. What we need is ways of getting more of them improved if they can be, and more accurate disposal of the ones where it's impossible. DGG ( talk ) 05:53, 21 April 2013 (UTC)
  • I agree. WP:V requires we are able to verify, not that it is verified, so we would be putting a burden on the editor that we don't put on them if they chose to not use AFC, thus discouraging its use. Of course to pass through AFC it should have one, but not to start there. The purpose of AFC isn't to filter out bad articles (CSD and AFD can do that) but is to help teach people how to conform to our standards in an environment where they are not under constant threat of deletion. Dennis Brown - 2¢ © Join WER 12:08, 21 April 2013 (UTC)

List of protected areas established in XXXX

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


There is a request for approval for a bot that will automatically create an index list for each category in Category:Protected areas by year of establishment. RockMagnetist (talk) 16:03, 17 April 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Move non-Roman translations and transliterations from lead to footnote

I have a proposal at MOS talk to reduce clutter in the lead by encouraging the use of footnotes instead of making the lead sentence a dumping ground for alternative names.

Please look it over and give me your thoughts or any alternative proposal. —Designate (talk) 15:49, 21 April 2013 (UTC)

Adding contribution pages to watchlists

I'm a relatively new user, so I'm not sure what kind of response this will get. I would appreciate comment on this proposal, and will not be offended if it is turned down, even if it happens within minutes.

My proposal is to allow users to add Special:Contributions subpages to their watchlists. This would allow users to track the edits of known vandals and disruptive editors so that their edits could be reverted more quickly and effectively. For example, if User A knew that User B had a track record of vandalism and/or trolling, User A could simply add User B's contribution list to their watchlist in order to better revert the user's edits and warn them of their disruptive behavior.
Certain restrictions could be applied to this feature to prevent trolls and vandals from abusing it. For example, users with less than a certain number of edits - for example, 15,000 - could be automatically disallowed from using it in order to prevent wikihounding. Even more restrictively, the feature could be granted to administrators alone.

I appreciate you for taking the time to read this, and would value any input that you'd like to contribute. Thank you! --Mathnerd 101 (What I have done) (What have I done?) 23:31, 16 April 2013 (UTC)

I like the idea. One way to follow a users contributions is to use Atom. Christian75 (talk) 23:49, 16 April 2013 (UTC)
Thanks! I'll go to the help desk for further info. --Mathnerd 101 (What I have done) (What have I done?) 00:26, 17 April 2013 (UTC)
This has been proposed a few times before; see, for example, this discussion. Despite concerns that this would facilitate wikihounding, there does seem to be general support for the idea. Technical feasibility is a different matter. A Bugzilla request has been open since 2004, and not much seems to have been done about it. DoctorKubla (talk) 08:00, 17 April 2013 (UTC)
I too would like such a thing, but technical issues appear to be the main problem. CtP (t • c) 21:47, 18 April 2013 (UTC)
There is the possibility to use a RSS web feed... mabdul 20:40, 24 April 2013 (UTC)

Linking lyrics from legal providers revisited

I would like to revisit a discussion that was held here last year regarding adding certain external links to pages about individual songs. These are links to websites that publish the lyrics of the songs. The proposal was successful and resulted in the introduction of User:LyricsBot which automatically adds these links from Metrolyrics, a supposedly licensed lyrics provider. In my opinion, however, there was insufficient discussion at the time regarding whether links to Metrolyrics should be allowed per Wikipedia:ELNEVER#Restrictions on linking. I raised this matter again recently at the help desk, see discussion.

In my view the problem is that there is insufficient clarity as to whether Metrolyrics really is a licensed lyrics provider. They have a licence from Gracenote, a licensing agency, but material on both the Gracenote and Metrolyrics websites (which I can't link to right now, sorry) suggests that this licence does not apply to all the lyrics on the site. Furthermore, there is no proof at the level of individual songs that the copyright holder has licensed the lyric to Gracenote, and even if they have, that Metrolyrics are allowed to republish it. We appear to be taking an awful lot on trust here and I am very surprised that no-one thought to question the validity of Metrolyrics during the previous discussion. In my view the discussion should be reopened and external links to Metrolyrics should be removed, unless it can be demonstrated firstly that the copyright holder has licensed the song to Gracenote, and secondly that the terms of Gracenote's deal with Metrolyrics allows Metrolyrics to publish the lyric for the song. --Viennese Waltz 08:08, 22 April 2013 (UTC)

  • Comment I came aware of this issue at the Help Desk notice and have to share Viennese Waltz's concerns. As I noted there, they say here that they have a legal database of 700,000 songs, but also that they have "over 1,000,000 music lyrics". It looks like 30% or more of their lyrics may not be authorized. Their FAQ says that lyric correction is disabled on songs that are "artist approved" (http://www.metrolyrics.com/faq.html), which would seem to me to suggest that those lyrics that are modifiable are not licensed - license is not likely to permit modification. (Modification is not permitted, for instance, of this Adele song, which would lend to a likeliness that Adele's song is authorized. It is permitted for this Pink song.) They allow people to submit lyrics to songs they do not find (http://www.metrolyrics.com/add.html). While I don't think we need to second-guess whether Metrolyrics is permitted by their deal with Gracenote to publish the lyrics (it's kind of hard to conceive of what else their deal would be for) I think we're going to have to stop the blanket addition of Metrolyrics links under the circumstances and come up with a more nuanced way of determining which ones may be safe for inclusion and which are forbidden by WP:ELNEVER and WP:LINKVIO. --Moonriddengirl (talk) 10:59, 22 April 2013 (UTC)
Since they have lyrics to public domain songs from the 19th century, it should not be surprising that their "legal database" is smaller than the total. WhatamIdoing (talk) 23:41, 22 April 2013 (UTC)
True. So how are we to decide which are legal and which are not? --Viennese Waltz 06:58, 23 April 2013 (UTC)
  • Difficult to tell from your comment, WhatamIdoing - is it your opinion that there is no WP:LINKVIO or WP:ELNEVER issue there? Or are you just opining that they are not including public domain lyrics in the "legal database" count, so that the 30%+ of songs not included in the count may not all be copyright issues? (Do they say somewhere that pd lyrics are not incorporated in that count? I can't find specific details on that....) --Moonriddengirl (talk) 15:11, 23 April 2013 (UTC)
I was also concerned about this and e-mailed a MetroLyrics representative some time back seeking clarification that in fact 100% of their lyrics are licensed and legal to distribute. Unfortunately the response I received was not encouraging at all - it reads as follows:
"As you may know, Metrolyrics, which was acquired by CBS Corporation in 2011 and is managed by CBS Interactive, was a pioneer in the online world of lyrics sites in that it was one of the !rst properties to directly license lyrics from copyright owners via a partnership with the licensed aggregator Gracenote Inc. and, more recently, via a partnership with the licensed aggregator LyricFind. Today, Metrolyrics exhibits over 700,000 songs through its licensed catalog and also accepts user-generated lyrics from its community, the latter of which are diligently managed in accordance with the DMCA and comparable legislation worldwide."
I was under the impression that they didn't accept user-generated lyrics, but in fact they do, and if they manage them "in accordance with the DMCA," that suggests responding to takedown notices akin to YouTube rather than some kind of careful screening process. It is possible to identify which pages come from Gracenote's database by looking for the Gracenote logo in the lower right corner, e.g. at [2]. Similarly, lyrics from LyricFind such as [3] have a line at the end of the lyrics that say "Lyrics powerd by LyricFind". I should be able to have LyricsBot go back through the links and automatically remove links to pages that don't satisfy one of these two criteria. There appears to be no reliable way to identify links to public domain lyrics, but we shouldn't be linking them anyway - we should be embedding them in articles or linking them on Wikisource. Dcoetzee 16:51, 23 April 2013 (UTC)
Yay. :) Thanks, Derrick. I wouldn't want to lose the ones we can keep and am so glad that you and your bot have a way to single them out! --Moonriddengirl (talk) 16:57, 23 April 2013 (UTC)
To be honest I'm still not convinced. In the first place, that Gracenote logo looks to have a link to Metrolyrics' terms of use, but it doesn't lead anywhere. Secondly, and more importantly, where is the proof that the artist has licensed their copyright work to Gracenote? --Viennese Waltz 20:45, 23 April 2013 (UTC)
Gracenote is a legit business - see [4], [5], and [6]. If the artists whose labels have struck deals with Gracenote object, they really need to take that up with their labels. I think Derrick has found a good way to distinguish - I note that the Adele song I suspected was licensed has the Gracenote logo; the Ping song that permits modification doesn't. --Moonriddengirl (talk) 23:52, 23 April 2013 (UTC)
Gracenote may be a legit business but I'm still not sure that Metrolyrics is a reliable source. For example, our article on King Crimson's The Court of the Crimson King includes a link to Metrolyrics. The Metrolyrics page includes that Gracenote logo stating "artist approved". But I'm 100% certain that Robert Fripp, who owns the copyright to all King Crimson songs, would never license the group's lyrics in this way (I'm awaiting confirmation of this and will post it when I get it). Anyway, I sense I'm not getting a lot of support here so this is probably my last word on the subject. --Viennese Waltz 07:51, 24 April 2013 (UTC)
It wouldn't be Fripp who had licensed it, but their record label. --Moonriddengirl (talk) 12:26, 24 April 2013 (UTC)
I deliberately chose Fripp as an example because he is a special case. Unlike most artists, he personally owns all the copyrights in his works (he has not surrendered them to a record label). Also, as I understand it (I am not a copyright lawyer), the record label only holds the copyright over the sound recording, not over the composition itself (of which the lyrics are a part). The copyright over the composition is held by the composer. --Viennese Waltz 12:59, 24 April 2013 (UTC)
Gracenotes probably also negotiates with individual artists. Unless they are licensing his lyrics to lyrics providers without his permission, which would be a very dodgy thing for a legitimate business to do, they probably have a contract with him from which he receives royalties for use of the lyrics. He would still retain rights to the composition. I don't exactly know what's typical of contracts between artists and record labels, but my impression was that labels typically assume all rights to works, including composition, sound recording, and so on. I find it very unlikely that MetroLyrics is posting the Gracenotes logo on lyrics not from Gracenotes - considering that only some pages have them and not others - unless some technical problem is involved. Dcoetzee 02:57, 25 April 2013 (UTC)

Script to open sections immediately

Right now if you were to visit Android version history and click a version in the Table of Contents (TOC), you'd be sent to a bunch of collapsed tables. Those who are not as familiar with Wikipedia may not even notice the "show" when coming in.

I made a script that would have the appropriate section open as soon as you click it in the table of contents (or if loading the page with the appropriate # hash tag). To test it out, just add the following snippet of code to your Special:MyPage/skin.js page:

importScript("Template:Headless_TOC");

importScript("User:Codehydro/Headless_TOC.js");

After doing that, make sure to shift-F5 and purge your cache. Then try this link (or anything else in table of contents): Android_version_history#Android_1.0_.28API_level_1.29

Is there any way to make the script load automatically without the script added to their layout? —CodeHydro 21:09, 23 April 2013 (UTC)

  • You really should move that script to a .js file in your userspace (like User:Codehydro/Headless_TOC.js), to prevent other people inserting malicious code into your script. Writ Keeper ⚇♔ 21:13, 23 April 2013 (UTC)
  • Done, thanks for the suggestion. —CodeHydro 21:41, 23 April 2013 (UTC)

Search results vs language

Currently: Whenever one searches in Wikipedia, only results in the current language are shown.

Proposed change: when searching, the hits in other languages are also shown. So, when searching in on de.wikipedia.org, the search results for German-language sites are shown on top, followed by high-ranking articles in other languages. This helps people that understand/read multiple languages, as they do not need to first specify the language in which the search term is entered: if the search term is specific to a language other than the current one, the wanted results still show up.

That's a lot of extra CPU time. Why not allow the user to select search results languages in their preferences page and just return those? Rklawton (talk) 15:03, 16 April 2013 (UTC)
I agree with Rklawton, and also, there are many different language Wikipedias. I doubt that there is anyone who speaks over 1/4 of the languages to a fairly good enough extent to want that, but I assume that, for your purpose, it might be better to use a script requiring the user to opt-in for that.  Hazard-SJ  ✈  03:20, 26 April 2013 (UTC)

A "Dream Big" idea to encourage readers to become editors--is it even technically possible

I've been following the discussions about Today's Article For Improvement at the Main Page and TAFI project page. I fully support the goals of encouraging readers to become editors and have been participating in the TAFI process but I do share doubts that this project will ultimately be successful. In order to motivate someone to edit you have to A.) first find someone willing to try something new like editing B.) have them be interested in the subject C.) hope that they feel they know enough about the subject to contribute and D.) Be presented with an article that is "develop-able" and not so big and complex that no one knows where to start. While I think the TAFI nominating process does a good job of working on the D issue, it's biggest flaw is that it only features 3 to 5 articles a day (Today it's Geography of Niger – Cartoonist – Pop music) and are banking on those three to strike the interest/expertize (the B/C issue) of somebody who happens to be visiting the main page that day and could be moved to edit (the A issue). That's a bit like throwing stuff on the wall and hoping that something will stick so here an alternate idea

  • Have a box on the main page titled See where you can help build Wikipedia. Tell us what interests you? where the reader types in a subject that they are interested in or know a lot about (like say Scuba diving)
  • The search engine takes the topic and then put up a random sampling of Start or Stub class articles. I envision that the best way to get this data would be pulling it from the relevant Wikiproject's and their assessments like Category:Stub-Class SCUBA articles and Category:Start-Class SCUBA articles, etc.

It's a "dream big" idea and I don't have the technical expertize to know if it is even possible but I thought I'll put it out here. I agree that there is a need to convert readers into editors but I believe we will always encounter a fundamental problem that people only want to edit stuff that they're interested in so we have to tailor our sales pitch to the individual reader somehow. If someone types something into the box then we know they can be motivated to edit (the A issue) and by tailoring the search results in response to what they put we can overcome the B, C & D issues which will greatly increase the likelihood that something will "stick". AgneCheese/Wine 19:55, 24 April 2013 (UTC)

  • Support, this is a great idea. It doesn't have to be instead of TAFI, though – we can easily have both. – Ypnypn (talk) 16:54, 25 April 2013 (UTC)
  • Hello, I would like to point out that TAFI does not feature 3 or 5 articles a day. It is 10 articles a week, and randomly shuffles every 15 minutes. Also, I like the new idea, but I would like to have the entire scheme of things centralised somewhere - We will be needing editors willing to teach the new editors through the basics and knowhow of editing, and our policies, and the difference between a constructive and a non-constructive edit. I agree with Ypnypn that it should not be instead of TAFI, but both can exist on the same main page.
    Overall, i think it should be a very feasible idea technically. But it would also make sense to have a variety of categories, than a search box. TheOriginalSoni (talk) 17:30, 25 April 2013 (UTC)
  • I don't want to derail your idea, but I'd like to suggest that you re-consider it in about six months. The WP:VisualEditor is supposed to get deployed this summer, and it's going to radically change the new-editor experience (and the old-editor experience, for that matter, although the old editor will be available for years to come). If you want to encourage new people to edit, then you're likely to have better success once the VisualEditor system has been deployed and is moderately stable. (Go to WP:VE to find out how you can be one of the testers now.) WhatamIdoing (talk) 01:50, 26 April 2013 (UTC)

Remove template deletion tag

When a template on a page is nominated for deletion, every page with that template gets this ugly bar: The template below (Foo) is being considered for possible deletion. See templates for discussion to help reach a consensus. This tag is ugly and clutters up the page. Remember when citation needed span was nominated for deletion? That cluttering tag was on most pages. It must be eliminated Revolution1221 (talk · email · contributions) 21:34, 24 April 2013 (UTC)

  • Comment On the one hand I agree that the tag clutters articles where the template is being used (I remember that happening with {{unsolved}}). On the other hand, removing this notification might lead to a lot of pissed off editors knocking on the door after a template has been deleted and arguments such as "The template has been used on page XYZ for years and had I been aware of the discussion I would have opposed it because (insert any possible reason for opposition here)!!!!" This isn't meant as an oppose vote, but only to highlight some consequences this might have. -- Toshio Yamaguchi 16:42, 25 April 2013 (UTC)
  • I don't think this has much chance of happening, for the reasons noted by Yamaguchi. However, if you are serious about it you would need to put together a specific proposal detailing why you believe this change is needed and open an RFC to discuss it. A thread here is not going to bring about such a big change. (shameless plug: see my essay on how propose big policy changes) Beeblebrox (talk) 17:45, 25 April 2013 (UTC)
  • If a bot posted a message on the talk page of articles using the nominated template, and the tfd deletion template expanded with no-include tags onto the template being nominated, it could solve this issue. It's bugged me as well, as it often breaks the template being nominated. - Floydian τ ¢ 17:49, 25 April 2013 (UTC)
  • I agree that the tag is inelegant and more esthetic indicator would be preferred. Praemonitus (talk) 18:41, 26 April 2013 (UTC)

RfC: Proposed replacement page 'Deflationism' for redirect to 'Deflationary theory of truth'

It is proposed to start a page to replace the present redirect from Deflationism to Deflationary theory of truth. An RfC can be found on its talk page at Deflationism. Please make comments and provide suggestions for improvement. Brews ohare (talk) 19:08, 25 April 2013 (UTC)

"You have new messages" alert for not registered visitors to expire after 30 days

Tracked in Phabricator
Task T49313
Clarification -- this proposal is solely to hide the "You have new messages bar" from anonymous editors after 30 days.

Many readers are receving annoying alerts linking to messages about being blocked or asking to stop trolling, so that would improve the experience. The discussion page doesn't need to be changed. Should be aplied for all language vesions of Wikipedia.--88.6.170.79 (talk) 00:11, 13 April 2013 (UTC)

That's a great idea. It should probably expire after only a day or two because we have no way of knowing if the IP belongs to a public machine. Rklawton (talk) 00:17, 13 April 2013 (UTC)
I like this suggestion as well; I'd go with the thirty days, though, if only to make sure that the mythical '29-days-later-troll-who-poor-baby-didn't-see-the-warnings' doesn't come a-knockin'. —Theopolisme (talk) 01:10, 13 April 2013 (UTC)
Would like to add the only contributions 88.6.170.79 has made recently involve only personal attacks;
Additionaly, the spamming warned about, returned recently from the same range as 88.6.170.79.--Hu12 (talk) 12:43, 13 April 2013 (UTC)
The IP's edits aside, I like the suggestion. Should help to prevent confusing situations like this. Chamal T•C 14:02, 13 April 2013 (UTC)
  • I'm mostly supportive of this, but I think it would be better if we only did it for dynamic IPs. I understand that many static IPs are in public locations, but I also think it is more obvious to someone who sees the message while in a library to assume someone else made the edit. Ryan Vesey 15:22, 13 April 2013 (UTC)
  • But how are we supposed to distinguished static from dynamic addresses? And, even if we can do that, there is a large grey area between static and dynamic. The IP address that I use from home is not guaranteed by my ISP to be static, but for many years stayed the same even if I disconnected my router and reconnected it. A few years ago, when my ISP was acquired by another, this behaviour changed, but as I usually leave my router connected for months at a time is still more-or-less static. Phil Bridger (talk) 19:18, 13 April 2013 (UTC)
  • Hmm, you can check by doing a geolocate on an IP, but I actually checked and the IP above is static so only doing it for dynamic IPs wouldn't have solved the problem. Ryan Vesey 19:27, 13 April 2013 (UTC)
  • I would oppose any such expiration measures on messages. Our obligation is to ensure our records of discussions are correct and factual.. not to make them go away. Particularly in cases like this where the message in fact worked as designed and identified a returning spammer who has been exploiting Wikipedia since 2006 and has a long history of patterned disruptive behavior.--Hu12 (talk) 12:50, 14 April 2013 (UTC)
  • How is a message seen by only one IP address a record of discussion? —Theopolisme (talk) 13:03, 14 April 2013 (UTC)
  • So, the proposal is to only remove the message bar? If so, then i'm not opposed.--Hu12 (talk) 14:59, 14 April 2013 (UTC)
  • I support this as a very positive idea. A number of times over the years I've been here I've seen anonymous newcomers confused and even upset by messages that were clearly not meant for them, and it can have a bad effect on our efforts to attract new editors. I don't think the dynamic/static distinction is worth bothering about - if the person a message is aimed at has not read it after 30 days, they're pretty much never going to. As a general point, I think anything that helps ease things for anonymous newcomers is good - I've seen far too much prejudice against IP editors (going as far as what I would call bullying, even from some admins). -- Boing! said Zebedee (talk) 13:13, 14 April 2013 (UTC)
Support. Stale messages serve only to cause confusion.—Kww(talk) 15:21, 14 April 2013 (UTC)
  • Strong support: I did not know that IP addresses can change over time, and I really got into panic when I saw this message for the first time (it was not done by me but blamed on me!). Thus, I fear to warn IPs even for blatant vandalism unless I spot it very quickly (expecting that the same IP would get the message) or the IP has done similar edits over time (enough to prove that it won't change that quickly).···Vanischenu「m/Talk」 21:33, 14 April 2013 (UTC)
  • support great idea ·Add§hore· Talk To Me! 22:18, 14 April 2013 (UTC)
  • Support Mostly per Boing! said Zebedee. Crazynas t 00:40, 15 April 2013 (UTC)
  • I was under the impression that the "new messages" bar only lasted for seven days, after which time it would just disappear if not clicked. Maybe I am just living in the past, or perhaps I made this up entirely? — This, that and the other (talk) 11:53, 15 April 2013 (UTC)
  • Support - I almost suggested the same. Marcus Qwertyus (talk) 11:56, 15 April 2013 (UTC)
  • Support Wouldn't it be sensible to choose an even shorter period, say 14 days? Or even one or two days, as mentioned above? Lectonar (talk) 12:00, 15 April 2013 (UTC)
    • Depends, if an IP is blocked for, e.g. 30 days, the message should be visible for that time in my understanding... mabdul 12:29, 15 April 2013 (UTC)
      • Apart from the block message which should be there, if he tries to edit, he will see this litte pinkish box telling about the block, so I still would opt for a shorter period. Lectonar (talk) 12:32, 15 April 2013 (UTC)
  • Support. I also like the 30 day period, since it makes it harder for a later-returning vandal (or, worse yet, a well-meaning intermittent editor making careless mistakes, who has not been blocked) to remain unaware that a notice had been provided. I would note, also, that an expiration of the notice after thirty days is an improvement over the current situation, wherein such notices expire after forever. bd2412 T 12:37, 15 April 2013 (UTC)
  • Support - sounds great!. —→Davey2010→Talk to me!→ 14:46, 15 April 2013 (UTC)
  • Great idea. ~ Amory (u • t • c) 16:49, 15 April 2013 (UTC)
  • Support -- it would prevent scaring away innocent readers. --NaBUru38 (talk) 19:31, 16 April 2013 (UTC)
  • Support I added a bugzilla ticket. -- King of ♥ ♦ ♣ ♠ 10:26, 17 April 2013 (UTC)
  • Support - chances are that if the person who the message was intended for didn't see it yet, that person won't. We would be annoying some other person with a message which was intended for someone else. (I would even cut this back to 15 days, by the way.) And I don't care who proposed it - if Grawp himself made a decent proposal and it remained unreverted for long enough for someone to support it, it should be handled like anyone else's. עוד מישהו Od Mishehu 11:26, 17 April 2013 (UTC)
  • Support 30 day expiration. Bearing in mind that the vast majority of IP users are readers, not editors, keeping the notification active forever is an unnecessary booby trap for innocent users of public or dynamically allocated connections. ~ Ningauble (talk) 12:00, 17 April 2013 (UTC)
  • Support A surprisingly good idea that I've never heard floated before (I'm sure it has been but I guess I missed it). Shadowjams (talk) 07:47, 19 April 2013 (UTC)
  • Support - but this is only a partial solution to the problem. See other ideas below. Rd232 talk 11:38, 19 April 2013 (UTC)
  • Support - This is a good idea. But other languages need to have their own separate discussions about this. Michaelzeng7 (talk) 12:16, 19 April 2013 (UTC)
    That wouldn't be necessary. Just have the devs implement it and have the default be set to indef. -- King of ♥ ♦ ♣ ♠ 22:58, 19 April 2013 (UTC)
  • Support.  Hazard-SJ  ✈  04:46, 26 April 2013 (UTC)
  • Strong support. This is a great idea. Not sure if 30 days is the right number, but the general principle is sound, and serves to address a longstanding problem in the community. One question I might have is whether the proposal is to start the 30 day countdown from the moment the banner would start being delivered, or whether it starts from the first time someone receives the notice. I can see good arguments for both, but regardless, the general proposal is sound and should be implemented. —/Mendaliv/2¢/Δ's/ 23:30, 28 April 2013 (UTC)

Partial solution only, so how about this

Removing the orange warning bar is only a partial solution (and one which requires developer intervention, so who knows how long it'll take). How about some other ways to address the "old IP messages" problem?

  1. MediaWiki:Anontalkpagetext is currently shown on the bottom of IP talk pages, but it's a bit of an after-thought and may easily be missed when the page is full of warnings. So why not use MediaWiki:Talkpageheader to display something like {{Shared IP}} at the top of anon talk pages, more clearly aimed at giving a "sorry, messages on this page might not be addressed to you" message? (See also T19705.)
  2. Use a bot to automatically archive old messages with some variation of {{discussion-top}} or even {{collapse-top}} that says "if you've never seen these messages before, they weren't meant for you, so don't worry".
    • The custom template could even apply a CSS class that would hide the messages for users who aren't logged in (so retaining the info for editors who might need it, without bothering new users). (NB This would need the orange bar deactivating after a certain time, or else careful thought how not to cause confusion if the bar's still there and the message is hidden.)
  3. any other ideas?

Rd232 talk 12:07, 17 April 2013 (UTC)

Why not simply say that you may be receiving this message in error?

Why not simply say that you may be receiving this message in error? Add something like the following to the warning message, "This message is meant for an anonymous editor. Internet providers sometimes reassign IP addresses that you may be receiving this message in error. If you log into an account, you will not see any messages that were not meant for you." Presto, users now know that the message may not be intended for them, it tells them what to do if they want to avoid seeing messages like that again, and no developer involvement is needed to change/fix basic MediaWiki programming. Banaticus (talk) 17:12, 19 April 2013 (UTC)

Well, Twinkle automatically appends a disclaimer to its warnings, if that's what you mean. It reads: "If this is a shared IP address, and you did not make the edit, consider creating an account for yourself so you can avoid further irrelevant notices." FallingGravity (talk) 04:22, 22 April 2013 (UTC)
Yeah, we have to assume that people just can't read. If they don't notice the "shared IP" disclaimer on Twinkle warnings, then they aren't going to notice the "shared IP" disclaimer on the "You have new messages" bar. Better for them to not see anything. -- King of ♥ ♦ ♣ ♠ 04:39, 22 April 2013 (UTC)
One issue here is that for non-technical editors, who know not the first thing about dynamic IP addresses, a "Shared IP address" may not mean very much - most non-technical people I know would just think "but I haven't got a shared IP address - my internet connection is only for my house". The link to Network address translation is rather spectacularly unlikely to help them either. I would suggest changing the disclaimer to something more like what Banaticus suggested. Oh, and I support the proposal of hiding the message - why make a human read something that explains why a computer is screwing something up when we can stop the computer screwing it up in the first place (exaggerated view, but I find that to be a help when thinking about usability). Developer time is important, but so is the user experience for new editors. Equisetum (talk | contributions) 23:06, 23 April 2013 (UTC)
Just wanted to add that if the issue is time to implementation I conditionally support Banaticus' proposal as an interim solution only. Equisetum (talk | contributions) 23:18, 23 April 2013 (UTC)
Twinkle takes its shared IP disclaimer from Template:Shared IP advice. Those who manually post warnings want to think about using it on their next IP revert. Michaelzeng7 (talk) 00:43, 26 April 2013 (UTC)

Removing the "Secure your account" information from the login screen

Hi. I've started a discussion at MediaWiki talk:Loginend#Future of this message about whether we want to continue including the "Secure your account" information on the login screen. Please discuss at the link provided. --MZMcBride (talk) 21:43, 27 April 2013 (UTC)

Please say yes or no to this Afc proposal.

Dear editors: Last week I posted a proposal for an addition to the Afc submission process at my user page User:Anne Delong/AfcBox and asked the reviewers on the Afc talk page to respond at User talk:Anne Delong/AfcBox. After several of the reviewers showed interest, and with support from FoCuSandLeArN and some input from mabdul I asked for a technical assessment at Wikipedia:Village pump (proposals) and also at Village pump (technical).

Since then there has been a lot of discussion on all three talk pages about various ways to improve the Afc submission process, but aside from TheDJ, who indicated that my proposal was technically feasible, and Ypnypn , who agreed that PHP shouldn't be needed, all of the discussion has centred around alternative and more complicated ideas using bots, javascript, etc. These are likely good ideas, but don't provide feedback on my original simpler proposal.

Please will someone let me know if this simple proposal (rather than the other alternative ideas) is worth pursuing, or what's wrong with it if not, by posting your opinions at User talk:Anne Delong/AfcBox. If no one likes the idea, and people instead want to go in a different direction, I will delete it. If people agree that the proposal has merit. Petrb has agreed to set it up. I am posting this on all three talk pages hoping to get a decision one way or the other. Thanks for your time. —Anne Delong (talk) 23:01, 27 April 2013 (UTC)

Thanks to those of you who have weighed in about my proposal (above). However, I've never made a proposal before, and I find that I have no idea how much support is needed before a proposal is accepted! Please advise. —Anne Delong (talk) 23:08, 28 April 2013 (UTC)
It is normal to wait for at least a week, and often for up to a month. WhatamIdoing (talk) 21:28, 29 April 2013 (UTC)
Thank you. The proposal has been up two weeks (April 15) and has only Support votes. What should happen next? —Anne Delong (talk) 21:56, 29 April 2013 (UTC)
Advertising for the proposal started only 2 days ago, and so it will be much more prudent to wait atleast until May 5th (one week) or so before deciding anything. Often, concerns on proposals tend to pile up at once, though I dont see that to be a case here.
Meanwhile, you can finalize the exact scheme of things to be followed, and have the scripting done so others can have a look at that too. TheOriginalSoni (talk) 22:24, 29 April 2013 (UTC)
Sorry, I advertised it the best I knew how at Afc, here, and Village pump technical on April 15. You were the first to tell me how I should proceed (thanks!). What exactly do you mean by scripting? (Sorry to seem so ignorant; I always seem to be asking questions.) —Anne Delong (talk) 01:48, 30 April 2013 (UTC)
I meant that the previous time you mentioned that, it was purely a discussion with hardly any way to judge consensus. This time its a direct question, which makes it a lot easier to gauge consensus.
By scripting, I meant making the javascript code necessary for implementing this proposal [Assuming we're still going by JS, and not any other way, in which case that will have to be taken care of.] Given how the proposal currently stands, its best to make that script and show a demo to everyone as early as we can[I'd say even before the RfC is closed]. That way, the final implementation for the same can be done as soon as possible. [No worries with the questions. Its always good to ask questions.] TheOriginalSoni (talk) 01:58, 30 April 2013 (UTC)
Anne, I think you've done a good job of advertising it. If you wait, then nobody can accuse you later of cutting short their opportunity to complain. If you'd like to see a suggested list of ways to advertise proposals for the future, then see WP:PROPOSAL. WhatamIdoing (talk) 03:43, 30 April 2013 (UTC)

Vandalism Checkbox & Statistical Gathering

Add a checkbox to the editing page similar to the "this is a minor edit" checkbox that could do a few things: 1) It would help to create some sort of cross-article searchable or database reference to vandalism on wikipedia that might help to create statistics on which IPs, etc. are pervasive vandals; right now it seems one only notes this when it is repeated vandalism on article(s) one watches. Hopefully such statistics across all of wikipedia could possibly lead to better handling/prevention of vandalism. 2) It would automatically create a flag/note that it is a reverted vandalism edit. Centerone (talk) 05:01, 28 April 2013 (UTC)

Have you tried Twinkle? GenQuest "Talk to Me" 06:04, 28 April 2013 (UTC)
I'm less concerned about the ease of handling vandalism on an individual basis, and more interested in the statistics and information that would be generated by the possibility of every wikimedia editor across all articles being able to easily tag those reverted edits as vandalism. Increased ease of reversion is only a fringe benefit. To answer the question, however, no I do not use such tools, but even if I did I do not believe that would accomplish what I think the effect and benefit of this would be. Centerone (talk) 07:13, 28 April 2013 (UTC)
User:ClueBot NG is quite effective at handling vandalism (> 2 million edits) but it needs people to help it improve. You may be interested in its Dataset Review Interface where editors can help build up its dataset of edits classified as vandalism. Sean.hoyland - talk 10:06, 28 April 2013 (UTC)
Perhaps Wikipedia:STiki would be relevant. WhatamIdoing (talk) 21:30, 29 April 2013 (UTC)

Proposal to improve on "read in another language"

original discussion: talk

what we need to do now to make it happen? 81.218.226.100 (talk) 04:27, 29 April 2013 (UTC) liran.

Try elsewhere. This is English wikipedia and you can make requests for things that need to be done here. Other projects are independent so ask them. Choyoołʼįįhí:Seb az86556 > haneʼ 05:09, 29 April 2013 (UTC)
I support his idea. Sometimes a reader needs information quickly and settles for reading it in another language, even though he would have preferred to read it in his own language. He's proposing that under every other language, we get a "Request this article in your language" button that adds this article to the Articles for Creation queue of your home Wikipedia. So for example, if I were a Spanish Wikipedian and wanted to read "Phrases from The Hitchhiker's Guide to the Galaxy" in my own language, then I would just press the Request button in the language bar, choose my home Wikipedia, and hopefully, the article will eventually be translated and created by the other Wikipedians. This is a cross-wiki proposal though so I'm guessing this isn't the best forum to propose it. Feedback ☎ 12:12, 29 April 2013 (UTC)

National invention categories and criteria for inclusion

Raised (yet again) at WP:Categories_for_discussion/Log/2013_April_29#Category:Inventions_by_country. Your contributions are welcomed. Andy Dingley (talk) 12:45, 29 April 2013 (UTC)

Add 'move-subpages' permission to the filemover group

Filemovers have been vetted to ensure that they can be trusted to move images, for example. I would think they should also be trusted to move subpages. Right now I am trying to help clean up categories and pages in the GLAM area, and we are renaming several project pages to use the full name of the institutions. This is extremely tedious because some of them have many subpages, and they have to be moved one-by-one.

Note that I don't as yet have 'filemover', but I just put in a request for that, since I think I'll need it anyway. It would be nice if that would include the ability to move subpages.

Klortho (talk) 15:14, 27 April 2013 (UTC)

ping This is a good idea, and I'd think it should be very easy for someone to implement who has the rights to configure it. I'd even be very willing to research exactly how to do it, if needed. Klortho (talk) 03:32, 1 May 2013 (UTC)

More visibility for featured topics

Currently featured topics have almost no visibility at all (currently just two lines on each article's talk page). Perhaps we could include a Today's Featured Topic (maybe just once a week) on the Main Page. Another possibility could be an topicon on each article – this is currently done on the Polish Wikipedia (example). -- Ypnypn (talk) 16:21, 30 April 2013 (UTC)

Proposal to restart Template:Expand

Hi I would like to propose that someone restart Template:Expand because we could include a detect code so it will detect if it is a template and show the information for the template or it can detect an article and detect that one or something else since template:expand article is being deleted we might as well restart this template I will try out a new set off codes to propose to include in template expand 90.211.52.178 (talk) 13:18, 28 April 2013 (UTC)

It is unnecessary to point out to somebody that an article is hopelessly short by stuffing an annoying template at the top. Given the presence of a multitude of stub templates, I think the Expand template is unnecessary and it should be left obsolete. Thank you. Praemonitus (talk) 15:00, 28 April 2013 (UTC)
what about recreating template:article and creating some new template expand template for expand some new one could be like template:expand template and template:expand Wikipedia - used for the project pages and more template:expand 90.211.52.178 (talk) 15:24, 28 April 2013 (UTC)
You need to start writing in proper sentences if you want people to understand what you are proposing. Phil Bridger (talk) 15:37, 28 April 2013 (UTC)
ok if I test out some new expand template in sandbox could we create the template if they are ok with you 90.211.52.178 (talk) 16:57, 28 April 2013 (UTC)
please visit User:Paladox2014/sandbox because that where I am testing the new expand templates and template:expand article 90.211.52.178 (talk) 17:31, 28 April 2013 (UTC)
The {{expand}} and {{expand article}} templates weren't deprecated because of anything wrong with the way that they were coded, but because there is no need for them. No attempt to rewrite them will change that. Phil Bridger (talk) 18:56, 28 April 2013 (UTC)
Comment: One look at an article tells you if expansion is needed. The template(s) were redundant with common sense, that's why they were retired. GenQuest "Talk to Me" 19:01, 28 April 2013 (UTC)
ok but I like the templates and yes people would know that they needed expanding but what about if it is big a ouch but has been expanded in a while and so people would know that it needs to be expanded 109.155.55.77 (talk) 19:34, 28 April 2013 (UTC)
If an article hasn't been expanded for a long time, do you think adding a template at the top will help? It doesn't. Many of these templates are four or more years old and the issues have still not been addressed. How does adding another template help, other than by adding clutter? If you find an article is too short, then do the work and expand it. Praemonitus (talk) 21:43, 28 April 2013 (UTC)
  • Support Yes, it does help. It serves as a reminder. It can even be used for a chronological category, and people who like to do this sort of work could specifically look for them. It does no harm, and if even a few percent of the articles get improved because of this, all the better. 'DGG (at NYPL) (talk) 20:09, 2 May 2013 (UTC)
  • Oppose. Articles get expanded completely independent of the existence of this template, and if the purpose is to categorize pages, we could just use categories for that. --Conti|✉ 20:14, 2 May 2013 (UTC)

Certain categories with pictures

Take this (for example): http://en.wikipedia.org/wiki/Category:World_War_II_tank_destroyers_of_Germany

It would be nice to have a small picture of each specific 'vehicle' there, a small picture, so you could then jump right to the most interesting looking vehicle (for instance), to read about. Just an idea. Makes for faster absorption of information in going through categories. You can determine more quickly from an image than from a category title, what you may want to read about (in cherrypicking, reading for entertainment). Just a suggestion. 86.145.5.117 (talk) 06:57, 2 May 2013 (UTC)

Protection of archived pages

Archived debates in AfD, MfD, and et cetera state that "this is an archived discussion......please do not modify it. Then, shouldn't archived debates be indefinitely protected by sysops the moment the debate is finished?--Seonookim (What I've done so far) (I'm busy here) (Tell me your requests) 09:56, 18 April 2013 (UTC)

I don't think the need is there, since disruptive editing of archives is rare (and like all edits, logged). There are also legitimate edits that sometimes have to be made to archives or archived discussions - sometimes extra notes on that page but not part of the archive; some technical fixes in the archive; and so on. These could be reduced by only protecting after a couple of days, but I think that would defeat the point and add to the workload. Grandiose (me, talk, contribs) 10:13, 18 April 2013 (UTC)
  • Oppose per Grandiose. It isn't really necessary, and edits that are truly disruptive can just be reverted, and single users who prove to be disruptive can be warned and blocked. This would only add to the heavy backlog of these discussion venues. Michaelzeng7 (talk) 12:12, 19 April 2013 (UTC)
  • Oppose per above. "Please do not modify it" refers to the content itself, but not such things as the categories or templates that may be used. It is merely to show that another view, or support or opposition of a mentioned view, shouldn't be added to it.  Hazard-SJ  ✈  04:49, 26 April 2013 (UTC)
  • Support, in some cases. When an archive is "closed" (i.e., Archive 5 is closed when Archive 6 is started), it could be protected, if dispruption is likely (such as archives of global-warming-related articles); the cost of having bot edits (substituting {{unsigned}}) and appropriate changes fail may be less than the cost of having to monitor the archive for vandalism and BLP violations. Those archives probably should be semiprotected, if we can ensure that bots are not prevented from operation by semiprotection.
    Sections which are archived discussions (and have that comment) cannot be protected unless the entire file is protected, which may not be appropriate. — Arthur Rubin (talk) 21:46, 1 May 2013 (UTC)
    Your caveats could be prevented easily by making SineBot, etc. admins. I support semiprotection for general archives so that temporary socks cannot interfere with them for some time, and full protection of the most contentious article archives. Wer900 • talk 23:15, 3 May 2013 (UTC)

Keyword screener for recent changes

I just recently started screening for vandalism, and I thought, "Hey, what if a bold red P came up at the end of each change which contained any sort of profane language. That could be a really neat tip for vandalism patrollers." Not all, but a lot of vandalism is simply mindless profanity scrawled across Wikipedia for novelty value. This, while not blocking profane edits (obviously, profanity could be perfectly appropriate in some situations), would provide a marked for potential vandalism and would increase the effectiveness of the humans involved in vandalism patrol. Thank you. TheOneSean | Talk to me 00:00, 3 May 2013 (UTC)

  • Support, though not bold and red, but just as another edit flag/tag/whatever they're called.  — TORTOISEWRATH 01:22, 3 May 2013 (UTC)
  • Did you actually find an edit containing profanity that wasn't tagged by the WP:Edit filter and didn't get reverted almost instantaneously by ClueBot? I don't think I've seen one of those in a couple of years. WhatamIdoing (talk) 05:40, 3 May 2013 (UTC)
  • You might like WP:LUPIN. Kilopi (talk) 06:07, 3 May 2013 (UTC)
    • The problem with WP:LUPIN is it's a script. I an proposing this as a benefit for all the Recent Change patrollers who have their own individual scripts. Not all people use Lupin. TortoiseWrath's suggestion of an edit flag/tag etc is exactly what I am proposing. TheOneSean | Talk to me 11:56, 3 May 2013 (UTC)

Free Distribution of WikiReaders to offline schools around the world, funded by Kickstarter.com or Indiegogo.com

We want to buy ALL of these and give them away to schools in far-off communities around the world that don't have internet

Hi Everyone,

So I and my partner User:Ashstar01 had an idea: We saw that the WikiReader -- an open-hardware touchscreen LCD palm-sized reader of offline Wikipedia content (and other free-content too) -- manufactured by OpenMoko in Taiwan hasn't been selling and now has dropped significantly in price - you can purchase them new for as little as $10 on Amazon.com in the United States. We had a crazy thought - what if we started a campaign on Kickstarter.com or Indiegogo.com to buy ALL of the remaining inventory and give the WikiReaders away to schools in far-off communities around the world that don't have internet? I bought one to try it out, and they run on AAA batteries that last a while. Sometimes there is missing content (like graphs) or out of date info but so much is already there. They are also easy to use. User:Ashstar01 got in touch with the manufacturer who said that he has 21,000 devices in inventory that he could part with between $15-$20 USD depending if we took 10,000 or 21,000 units. That's $200,000 - $315,000 PLUS shipping and fees that would need to be raised.

We would like to run this idea by the community for a few reasons:

1.) We would need a list of schools and addresses of schools that could use these devices - plus photos to use to make a video for the campaign.

2.) Would Wikimedia Chapters be interested and able to help distribute these readers to schools in their communities?

3.) Another potential issue is that the units seem to ship with a 4gb card with an older version of English Wikipedia on them, and the latest version in English is 5gb, so it requires a new card, and a new update of the encyclopedia. This may not be an issue assuming that the places that we are sending the WikiReaders to may appreciate information that is a few years out of date (I know when I was in school in the 1980's some textbooks said that mankind still hadn't landed on the moon).

4.) Are there better options / other devices that might work better? I think that these are the lowest-power & cheapest offline readers of Wikipedia around, but I could be wrong. They are %100 open-source too :)

5.) What would be a good price point for the campaign? I'd hate to not raise enough to be able to give them away.

We think that it's unfortunate that the WikiReaders haven't been flying off the shelves in the first place, but what's more unfortunate is that there are kids who could use them (for whom the internet and even Wikipedia Zero is not an option) and they are just sitting in inventory.

Thanks for reading!

(for clarity, I'm doing this as a volunteer, not as an employee of Wikimedia) Victor Grigas (talk) 16:42, 20 April 2013 (UTC)

This idea is greatly appreciated! Surely, there is a source, a channel and a destination for this goodwill idea to triumph! ViswaPrabhaവിശ്വപ്രഭtalk 17:55, 20 April 2013 (UTC)
Comment Sounds like a great candidate for the Wikipedia Foundation Grant Program. You should check out the program and make a dollar request there for implementation. GenQuest "Talk to Me" 20:15, 20 April 2013 (UTC)
Brilliant idea. Definitely recommend a WMF Grant as an option for funding here. Steven Zhang Help resolve disputes! 20:50, 20 April 2013 (UTC)
Awesome idea! A meta page could serve as a good co-ordination point for discussion and implementation. Also, it sounds like a perfect proposal for Wikimedia Grants. TheOriginalSoni (talk) 11:19, 22 April 2013 (UTC)
Seems like a great idea! I agree with the others you should look into the WMF grants --Cameron11598 (Converse) 21:49, 22 April 2013 (UTC)
This does sound like a great idea, but one question that occurs to me is whether the batteries are going to be an affordable commodity for people in places where there is no access to the Internet. Formerip (talk) 22:08, 22 April 2013 (UTC)
Good point, maybe it would make sense to find out if this is a problem before shipping to a particular location, and if it is, then also ship a solar-powered AAA battery charger and an appropriate number of batteries too. However, this may not be an issue depending on where they go. Victor Grigas (talk) 22:42, 22 April 2013 (UTC)
(ec) Certainly. No internet does not mean no electricity. Even in villages with no electricity, battery items like torches, and therefore batteries themselves are accessible, if not commonplace. Also, AAA batteries cost very little comparing to the 'reduced price' of the WikiReaders (around 5-6 batteries a dollar), and are going to last for some time. So I think they are very affordable. TheOriginalSoni (talk) 22:46, 22 April 2013 (UTC)
Maybe, at an appropriate juncture, seeking advice from Oxfam or someone like that would be the way to go. I hear what you are saying, TOSoni, but I wonder if even a dollar might be a prohibitive price in some communities. I do know that the wind-up radio was introduced to address the problem of people in sub-Saharan Africa not accessing AIDS education because battery operated radios were no use to them. That is 20 years ago, but I think assuming that things are different now would be rash. Formerip (talk) 23:42, 22 April 2013 (UTC)
Yes. But only in some communities. And I am not sure those communities will be most benefited by Wikipedia, as they should be able to read English first. (No offence). IMO the most benefited one will be the BPL communities slightly above the one we were talking about who can afford to educate, but not provide it adequately. Moreover, we can also buy and give the batteries, if that was the case TheOriginalSoni (talk) 02:11, 23 April 2013 (UTC)
I've worked for Oxfam Solidarité in Belgium. Well... I'm not sure Oxfam could offer great feedback, as the methods and philosophy are different: Oxfam doesn't work on a top-down approach: they don't offer projects directly from Occident, but finances project requested by locals, tailored to their needs. The top-down approach is judged inefficient (false good ideas) and too paternalist (some projects could be resented as interference, intrusion). That's in phase with the philosophy to empower development. --Dereckson (talk) 09:43, 24 April 2013 (UTC)
I'm a little confused: Why does buying them wholesale ($15-$20) cost more than buying them retail ($10)? -- King of ♥ ♦ ♣ ♠ 22:21, 22 April 2013 (UTC)
The $10 price only comes from a few retailers on Amazon who want to clear out their stock. Currently, you could likely only get a few dozen units at most at this price. Of course we could wait a few months for the price to drop even more. The $15-$20 is a first offer via email from the manufacturer who likely has a motive to move the units as soon as possible. Victor Grigas (talk) 22:42, 22 April 2013 (UTC)
What is the target language? The options seem limited. --  Gadget850 talk 02:09, 23 April 2013 (UTC)
Even if it's English-only, India definitely can use them. -- King of ♥ ♦ ♣ ♠ 02:44, 23 April 2013 (UTC) (formerly misplaced, moved 10:59, 23 April 2013 (UTC))
Yes. My point was just that most of those who can use them can afford the batteries. TheOriginalSoni (talk) 10:54, 23 April 2013 (UTC)
WikiReader have language packs for many other languages. If a local chapter wants to distribute them in another language they just need to install the right packs in the SD Card. Crang115 (talk) 20:01, 29 April 2013 (UTC)
Yes, Crang115 is correct, the manufacturer has agreed to install whatever languages we specify and the micro-SD cards hold 8gbs, so we can choose from the available languages Wikipedia available in a text-only version. This includes about 16 languages. Making experiences more meaningful and less-broken. (talk) 22:51, 30 April 2013 (UTC)
  • Do we have any update on this issue? Is the Grant for this filed? TheOriginalSoni (talk) 09:37, 29 April 2013 (UTC)
We are planning to start the Indiegogo campaign on May 6th and are currently looking into possible grants that are able to be requested in the next month or so as the manufacture is looking to move his supply sooner rather than later. If no Wikimedia grant options are possible in the near time, we plan to submit a grant proposal after our Indiegogo campaign completes for a second round of fundraising to buy more devices as there are 21,000 devices waiting to be moved by the manufacturer. Making experiences more meaningful and less-broken. (talk) 20:16, 30 April 2013 (UTC)


Hi Everyone! We started a campaign here on Indiegogo: Click for the Indiegogo campaign The campaign is 45 days, please send the link everywhere you can! Victor Grigas (talk) 04:11, 5 May 2013 (UTC)

Request for comments on the Main Page (2013 main page redesign proposal)

The 2013 main page redesign proposal is a holding a Request for comments on the Main Page, in order to design an alternative main page based on what the community asks for. Please leave feedback regarding any aspects of the Main Page you like or dislike, and discuss the Main Page's purposes and aims.

Evad37 (talk) (on behalf of the 2013 main page redesign proposal team) 00:41, 6 May 2013 (UTC)

Universal disambiguation parameter needed for templates.

Too many times I have come across a disambiguation link generated by a highly complex and multi-layered template which either has no mechanism built in for calling the correct target page instead of a disambiguation page, or has some strange and unintuitive parameter that must be inserted in some strange and unintuitive place to correct the link. I propose that we have a simple, common sense universal rule that wherever any template calls a link, it must be structured so that it is possible to add a disambiguation parameter by adding |dab=(foo disambiguator) after the location of the term which will appear in the link. bd2412 T 04:18, 4 May 2013 (UTC)

I can't say I know what you're on about. An example of a template that does something like this would help muchly. Rd232 talk 21:29, 4 May 2013 (UTC)
I can give you a perfect example. Daxuecheng Station was recently changed from a regular article to a disambiguation page, with the original page being moved to Daxuecheng Station (Chongqing). Since the original link appeared in a template, showing up on pages like Eling Station, I tried to fix the link in this template:
Village pump (proposals)/Archive 101
General information
LocationChina
Line(s)Line 1
Services
Preceding station Chongqing Rail Transit Following station
Lianglukou
towards Chaotianmen
 Line 1 Daping
towards Bishan
As you can see, Daxuecheng Station shows up in the template, but oddly not in the formatting, which looks like this: {{s-line|system=CRT|line=1|previous=Lianglukou|next=Daping}} Furthermore, because of the way the template operates, there is no link to the page needing to be changed from Daxuecheng Station's "what links here page". I therefore subst'ed the template, and then subst'ed all of the subsequent sub-templates on the page just to find the one that references Daxuecheng Station: Template:S-line/CRT right/1. I tried to fix the problem there, but nothing worked without breaking the template. I sought help, and eventually an editor familiar with these templates made the correct change - to Template:CRT stations (which previously had not mentioned Daxuecheng Station at all, but needed to have a line added to disambiguate this term. I understand that these templates are highly functional, but we have enough problems fixing disambiguate links without having templates that call links without offering a straightforward and intuitive method of fixing disambiguation links. I have had the same problem on many occasions with templates designed to call all of subject "foo" for a particular region, like Template:European topic, for which a parameter can be added to invoke, for example, "Transportation in" a list of all European countries, without offering an easy opportunity to fix an ambiguous link for a particular country. bd2412 T 00:22, 5 May 2013 (UTC)
I see, thanks. Yes, that's really troublesome. (Though the "European topic" type templates shouldn't really need disambiguating?) Rd232 talk 11:44, 5 May 2013 (UTC)
I once had exactly this problem with the Template:Oceania topic template, when editors used it to create a "Football in" series of templates. "Football" has multiple meanings depending on where you are, so some of the links generated were to disambiguation pages. bd2412 T 21:30, 5 May 2013 (UTC)
Ah. Aha. Rd232 talk 23:35, 8 May 2013 (UTC)
If we do something like this then we should allow any link target. It would be crazy to go through the trouble of editing a large number of templates and then only have the capability to pipe to a title which starts with the text you want to display. And many templates make links from multiple parameters so we would also need a universal naming system to deal with that. If X is the name of a parameter then X-link could be the name of an optional parameter saying to generate [[X-link|X]] instead of [[X]]. There is a hack which sometimes works now. If a template says [[{{{name}}}]] then name=X-link{{!}}X will use Template:! to produce [[X-link|X]]. PrimeHunter (talk) 12:53, 5 May 2013 (UTC)
I am rethinking this in light of the complexity of some templates already well established and long in use. At the very least, every such template should provide an easy way to find the location where the fix needs to be made, and should provide very clear instructions on what edit must be made to fix that link. bd2412 T 21:30, 5 May 2013 (UTC)
I wonder if some move to Lua for some of this would be helpful? The complexity of some of these template structures could perhaps be reduced that way. Rd232 talk 23:35, 8 May 2013 (UTC)

Hotcat-like editing of redirects?

Firstly, apologies if this should be at the ideas lab - I'm not entirely clear of the distinction between this page and that one. Also apologies if this idea sounds stupid (it may do :).

Is there any way of making a hotcat-like editing function for pages marked with the #Redirect markup, so that if a target page is moved, it becomes quicker and easier to repoint any redirects, in much the same way that articles can quickly be moved to a renamed category using the ± button? I suspect it's not possible, since the #Redirect lies within the body of the "article" text, but then again, so do the [[Category:Foo]] links... Grutness...wha? 13:08, 7 May 2013 (UTC)

Maybe I'm not reading this correctly, do you mean to fix double redirects? A bot takes care of those. ~ Amory (u • t • c) 17:10, 7 May 2013 (UTC)
A bot does them eventually, but surely we're always being told to do the most used ones as soon as the page is moved? Grutness...wha? 00:32, 8 May 2013 (UTC)
Frankly, I don't bother; the bots have gotten quite speedy (just a few hours). Theopolisme (talk) 10:57, 8 May 2013 (UTC)
OK - as long as I have your permission not to ;) Yeah, this task is probably quick enough automated not to cause any major problems. Cheers, Grutness...wha? 12:00, 8 May 2013 (UTC)

Restore preference

Suggesting additional option to "restore preference settings to default by page". Tito Dutta (contact) 16:22, 7 May 2013 (UTC)

Yes, that would make sense (you mean the tab-like [in Vector and Monobook, anyway]) sub-divisions of Special:Preferences sometimes called pages, I believe). Currently at the bottom of every Special:Preferences tab we have "Restore all default settings". But when fiddling with options you might well want to reset just one preference tab. Rd232 talk 16:52, 7 May 2013 (UTC)

Short definition of "Anchor text" of articles in new dialog box on the same page

Difficulty with existing format

Sometimes when we read an article and some words link to different pages, as in case of anchor texts, then for knowing the meaning of that word, or referring to the context in which that word/phrase is written, we have to go to that hyperlink, which entirely opens in a new page.

But this cause problems, because while reading on the new page, we come across such terms/phrases, for which we have to navigate to different pages. This deviates us from reading the original article, and becomes bit tough to revert back through the stack of pages.

This is the trouble I and many of my friends are facing. I suggest a minor change in the format, that would ease the users' readability:

Let the hyperlinks on the terms be as it is. But when we put the cursor or mouse pointer on that hyperlink, then let wikipedia display the "introduction" or "short definition" of the article to which that hyperlink points in a dialog box or notification box, on the same page. This way, the users shall know the term/phrase and then shall be able to continue what he was reading, and not get deviated. Whereas, he may still go to the new pages by clicking on the hyperlinks.— Preceding unsigned comment added by Shantanudesai2009 (talk • contribs)

You could try enabling the Navigation popups gadget by selecting "preferences" from the top of any page by your user id and then the "gadgets" tab. This will provide a preview when you hover the cursor over a link. I have vague memories of previous discussion about enabling this by default, but it doesn't seem to have been done. Phil Bridger (talk) 12:44, 9 May 2013 (UTC)

Unbundle autopatrolled from admin rights package

Per this thread on AN, I'd like to propose unbundling the autopatrolled right from the administrator rights package. It's one of the few rights in the admin package, if not the only right, that has little or nothing to do with admin tasks. If a person becomes an admin despite relatively little content contribution experience becomes an admin--I myself could be considered one such admin--their articles will pass through NPP because of the autopatrolled right, without them having to display the same kind of content creation skills that a normal editor with autopatrolled might have had to demonstrate. Moreover, since the barrier for removal of admin rights is much higher than the barrier for removal of autopatrolled, it is very possible for an admin to misuse the autopatrolled right--whether intentionally or otherwise--in a way such that they will not be desysopped, but they would've had their autopatrolled rights removed.

What I propose instead, at least as an interim step, is for autopatrolled to be unbundled from the admin package, but the ability to grant and revoke the right not be removed. There is a precedent for a right like this in the edit filter manager right. This way, any admin who creates many articles will simply be able to grant themselves the right as needed, any who don't need it won't have it, and any that misuse it can have it taken away from them via a community discussion, ArbCom decision, or whatever without a full-fledged desysop. (They would technically have the power to regrant the right to themselves, but it would be a breach of WP:INVOLVED similar to an admin unblocking themselves.) Presumably an admin who has had their autopatrolled right removed would also be prohibited from granting or revoking it to anyone else, but that can be a discussion for another day if need be.

I think that this is only fair. Yes, Wikipedia is not an exercise in perfect, rigorous equality, but I don't see any significant drawbacks of unbundling this right. Again, any admin who needs it can simply grant it to themselves. The knowledge and experience required for a successful RfA is much broader than what is required for a grant of autopatrolled, but it it much shallower in the field of content creation. Most admins can presumably be trusted to write decent articles, yes, but there is much less evidence that they actually can.

Should this be successful, I would be curious to know if anyone has ideas for an alternate system to grant autopatrolled, rather than having the ability to grant it as part of the admin package. However, given that this proposal provides a means to remove the right, I think this is a worthy step on its own.

Thanks, Writ Keeper (t + c) 20:46, 22 March 2013 (UTC)

  • Support. As they say at RfA, "why not?" --Demiurge1000 (talk) 21:08, 22 March 2013 (UTC)
Got any 'Barnstars of Good humour' yet? MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 21:56, 22 March 2013 (UTC)
  • Support The skill required to write appropriate articles is unrelated to the skill required to be an admin. Admins shouldn't get special dispensations in article creation; too much is bundled already. This right has nothing to do with being an admin. 88.104.27.2 (talk) 21:16, 22 March 2013 (UTC)
  • Weak Support If it's not linked to doing admin duties then some may say that they should go about gaining those rights just like anybody else should, however since AFD RfA has became so difficult that not that many Admins are pulling through now they deserve anything they get, nevertheless the removal is more justifiable than the reason to keep. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 21:56, 22 March 2013 (UTC)
    I think you mean "RFA has become so difficult". --Floquenbeam (talk) 22:36, 22 March 2013 (UTC)
    Yes, Yes I do, my bad ^^' MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 23:53, 22 March 2013 (UTC)
  • This makes sense. It's certainly crazy that I have the auto-patrolled flag. It should be granted (or removed) to admins just like it is to non-admins. --Floquenbeam (talk) 22:34, 22 March 2013 (UTC)
  • Support This 'right' unlike most others is a tool used by other editors to reduce the work patrolling. Per WP:AUTOPAT: It means that the user can be trusted not to submit inappropriate material, deliberately or otherwise, and that the user submits new material often enough that it is more efficient to mark it all as approved preemptively. It isn't a button we're taking away, but a regranting a human based quality control method. Until we have several dozen new articles as a prerequisite for adminship (unlikely at best), I agree with this proposal. Crazynas t 22:41, 22 March 2013 (UTC)
  • Questions. WK analogizes the autopatrolled right to the edit filter manager right for several reasons, one of which is that by unbundling the autpatrolled right, it's then removable as well. First question: Has there ever been a case where the edit filter manaager right was removed by community discussion? It's not an academic question. If it's never happened, should we be doing all this for something that will probably never happen or at least happen so rarely so as not to be worth it? Second question: Assuming we implement the proposal, why should it require a community discussion to remove it? Currently, for example, an admin can block another admin for edit-warring. The blocking admin doesn't need a consensus for doing so, although, as with any other block, a review of it may be requested. Why should autopatrolled be different?--Bbb23 (talk) 22:48, 22 March 2013 (UTC)
  • For your first question, I don't know of any cases of removal of edit filter manager, but you have to keep in mind that that's a right with much, much less usage and appeal; it's fairly technical and complex, so there aren't nearly as many people using it, and thus not nearly as much badness comes from it. I guess the point for me is that increasing the granularity of the rights packages allows us flexibility, and at least in this stage, there's little-to-no cost. It's a very simple change from a technical standpoint (a one-line change in LocalSettings.php), and there's no added bureaucracy, since granting and revoking the right remains the same.
For your second question, it's totally fine by me if it can be removed by another admin just like any other right; I'm not at all married to the idea of requiring community discussion for it. It's in there as an artifact of my thought process (I was thinking that, if there was a discussion already going on about an admin's articles, this gives that discussion another possible outcome), not as a necessary part of the proposal. Should I add that to the proposal proper, or is it not cool to change the wording once voting has started? Writ Keeper (t + c) 23:26, 22 March 2013 (UTC)
I think you should leave it out as it will muddle things. In addition, it isn't strictly neessary to decide it to implement the proposal. I'd be in favor of adding language to WP:AUTOPAT that gives some guidance as to when the right should be removed. Currently, it only discusses when it should be granted. At the AN discussion, TP offered his opinion on that issue, but it would be nice to discuss it a bit more and reach a consensus.--Bbb23 (talk) 23:58, 22 March 2013 (UTC)
  • Support - Everything everyone has said about article creation not being necessary for adminship, and not all admins having article creation experience stands. I would add one further point. If an admin has little understanding of a certain area, they can simply avoid working in that area (I'm not comfortable editing MediaWiki pages, so I don't). Autopatrolled is different because it is automatic: any page I create will be autopatrolled, even if I don't trust myself enough for that to be the case. Thus admins who are aware of their inexperience in this area cannot avoid using a tool that they don't feel comfortable with. ItsZippy (talk • contributions) 22:59, 22 March 2013 (UTC)
  • Support. From each according to his ability, to each according to his need. Kiefer.Wolfowitz 23:05, 22 March 2013 (UTC)
  • Support - I likely would have turned it off my own autopatrolled bit if I could have after originally passing RfA. While I don't believe that this will make much of a difference in most cases, this can only help in those few cases it would make a difference in. As Bbb23 suggests, I'd prefer that "removing the autopatrolled bit" be something that an admin can do for cause without much process, a community discussion feels kinda heavyweight for something that comes down, more or less, to "Hey, those BLP stubs you make don't have any sources, I'd prefer they go through some tagging, etc." --j⚛e deckertalk 23:09, 22 March 2013 (UTC)
  • Support - the edit filter manager is a separate flag because it's (rightly) assumed that the skills needed to admin and the skills needed to write and maintain edit filters are distinct; it seems reasonable enough to consider the autopatrolled flag in a similar vein. 28bytes (talk) 23:22, 22 March 2013 (UTC)
  • Support. The case seems obvious enough, but will it ever happen? I doubt it. Malleus Fatuorum 23:25, 22 March 2013 (UTC)
  • Support Generally speaking, autopatrolled is given in recognition of content-creation skill. Not all admins have this skill, and candidates who create few or no articles often do pass Rfa. So I don't think we should assume that a new article doesn't need to be patrolled merely because the creator passed an Rfa. Mark Arsten (talk) 23:54, 22 March 2013 (UTC)
  • I can't think of any good reason to oppose it Support. I don't know that it would actually change very much, but I certainly don't object. — Ched :  ?  23:57, 22 March 2013 (UTC)
  • Support I think this is a step in the right direction. I suspect that some other prominent WMF wikis do something similar, but I would need to do some research. --Rschen7754 00:01, 23 March 2013 (UTC)
  • Support Anything to design those infallible admins everyone secretly wanted.84.106.26.81 (talk) 00:02, 23 March 2013 (UTC)
  • Support I knew if I hung around here long enough an unbundling proposal that I could get behind would come along. As others have said, this right has absolutely nothing to do with being an admin, and it doesn't do anything to help admins do their job either, so it seems like a natural for unbundling. Beeblebrox (talk) 00:10, 23 March 2013 (UTC)
  • Support This makes a lot of sense.--Amadscientist (talk) 00:14, 23 March 2013 (UTC)
  • Um, how would this make a difference in practice, exactly? My understanding is that autopatrolled means that one can be trusted to create content that doesn't violate policies or guidelines, and I'd assume just about everyone who made it through RfA would fulfil that criterion. If an admin ends up having the flag removed via discussion, I don't think they'd have the requisite trust in their competence to do content-related admin work. I mean, if it's a symbolic thing or just sort of "why not", then by all means, but I just don't see it making an actual difference. wctaiwan (talk) 01:31, 23 March 2013 (UTC)
    And why would you assume that? Malleus Fatuorum 01:46, 23 March 2013 (UTC)
    More than one sysop above has stated they would remove this right from themselves if they could. Crazynas t 01:49, 23 March 2013 (UTC)
    I didn't read through the discussion carefully enough. I now see that it has some practical implications. Fair enough, then. wctaiwan (talk) 02:03, 23 March 2013 (UTC)
  • Support - I'm all for unbundling the tools. Keilana|Parlez ici 01:52, 23 March 2013 (UTC)
  • Support. I don't know as it solves any actual problem, but I can't see any reason not to do it, there are arguments and lots of folks (above) in favor, and in principle unbundling of rights is generally indicated, all things being equal and if it doesn't cause any problems or significant extra work. Herostratus (talk) 02:50, 23 March 2013 (UTC)
  • Support although, to be fair, if the mop wasn't focusing on content, he probably wouldn't be creating that many articles anyway pbp 04:48, 23 March 2013 (UTC)
  • Comment: I'm in favour of this suggestion in principle, but an admin can grant themselves the Autopatrolled user right whether it's included in the package or not. Wouldn't this defeat the purpose? Chamal T•C 04:53, 23 March 2013 (UTC)
Firstly, this should be good for admins who are self-aware enough to recognise that their content contributions are not always up to scratch. Good admins should be able to self-evaluate, and this will allow them to do that. Any decent admin would remove their autopatrolled right themselves if there were legitimate questions about their content contributions, so forced removed probably won't happen that often. Secondly, if we do get to the stage where the community needs to remove the autopatrolled right from an admin, for the admin to reinstate their right after it was removed by the community would be in contravention of WP:INVOLVED, WP:CON, and possible WP:WHEEL; that would be cause for further action (though I hope we'd never get to that point). ItsZippy (talk • contributions) 16:59, 23 March 2013 (UTC)
  • comment I notice that actual new page patrollers seem to be being largely ignored in this discussion which is unfortunate since they are the ones that autopatrolled is aimed at. Autopatrolled does not really apply any benefits to the user it is applied to. It simply provides new page patrollers whith a white list of users who are unlikely to be a problem. And the reality is that all active admins do belong on that whitelist. Remember New page patrols standards are pretty low. If it doesn't meet any of the speedy criteria or BLPprod, doesn't read like a copyvio and isn't a fairly straightforward hoax its going to pass (okey some other junk will be proded and AFDed but still the barrier is pretty low). While we have had admins from time to time who's had issues with copyright its not at the level that new page patrol is going to pick up. So please be aware that there is no practical benefit in doing this and any symbolic benefit has to be weighed against the admittedly small extra workload on the part of new page patrollers. It also needs to be weighed against the downside of making autopatrolled a bigger deal.©Geni 07:29, 23 March 2013 (UTC)
  • Oppose, as a person who has patrolled hundreds of pages. C'mon, guys, think about it: The primary task of page patrolling is to find newly created articles that qualify for CSD. if you're not capable of creating an article that doesn't qualify for CSD, then you need to turn in all your admin bits, not just this one, because that means you don't understand our most basic policies. You should not be needlessly increasing the NPP workload and backlog just to make a point about being "fair" (in that even-Steven notion of fairness that is popular among five year olds, rather than among adults). WhatamIdoing (talk) 19:35, 23 March 2013 (UTC)
  • WhatamIdoing, have you read Wikipedia:New pages patrol? The primary task is not to find newly created articles that qualify for CSD. It is to find (and hopefully fix) obvious problems in new articles. See Wikipedia:New pages patrol#Patroller checklists. Ryan Vesey 20:45, 23 March 2013 (UTC)
    I've not only "read" but also "helped write" that page. When you decide to mark a page as patrolled, the decision you are making is "I don't believe this page qualifies for speedy deletion". If it's not CSDable, then it should get marked as patrolled. (If you tag it for PROD or AFD, the page is automatically marked as patrolled.) The rest of the stuff about tagging various problems is superfluous. We trim it down every now and again, but it WP:CREEPs back in. WhatamIdoing (talk) 23:22, 23 March 2013 (UTC)
  • Support This isn't really an unbundling as Autopatrolled is already unbundled, like Rollback all admins have it as part of the admin toolkit but it can, and often is, be issued to non-admins. So to be pedantic I would call it a removal. However I'd support it for the simple reason that getting notability right is a skill that not every RFA candidate has to have demonstrated. It would be perfectly possible for an experienced vandalfighter who has assisted in some GAs to pass RFA without ever creating an article from scratch. Or indeed gained deletion related experience as to where we draw the line between articles that belong and those that don't. I'd not expect such an admin to then submit hoaxes or copyvio, but I wouldn't be upset or surprised to find a new admin whose first article creations then showed them to be overly inclusionist re their favourite subject area. ϢereSpielChequers 19:53, 23 March 2013 (UTC)
  • Question The comment here at WP:NPP that this removes "the autopatrolled right from all admins" is far from the way I read this proposal, but it does raise the question of what we do with the existing couple thousand admins. Obviously admins who had autopatrolled before adminship on their own should have it after debundling, but there's still the question of what to do about those who didn't have autopatrolled before adminship. I'm open to a wide range of answers, from "none of them has it until someone looks" to "all of them have it until/if someone looks", but we should probably figure out which it is. --j⚛e deckertalk 20:21, 23 March 2013 (UTC)
  • The answer is that any admins who want it/think it would be good for them to have can have it, for this proposal at least. It's the same way that any admin can freely give themselves edit filter manager. The point is that separating it from the default admin package allows us to remove it from admins if it's necessary, and for admins (including possibly myself, and others who have said the same here) who would rather their contributions not pass through NPP without review. (As Ryan says above, NPP is not only for CSD patrolling.) Since any admin who should have autopatrolled will still be able to have it, the impact on the workload of NPP should be minimal. As I say, I'd be interested in an alternate system for granting autopatrolled, which could have an appreciable impact on NPP, but that's out-of-scope for this proposal. Writ Keeper (t + c) 21:26, 23 March 2013 (UTC)
See Wikipedia:Requests for permissions/Autopatrolled unless that was the system you meant we needed an alternative to. Ryan Vesey 21:47, 23 March 2013 (UTC)
It's not exactly that; I meant that we should take a look at the standards for granting/removing it and the like. Again, that's another conversation for another day. Writ Keeper (t + c) 21:57, 23 March 2013 (UTC)
As an aside, if and when this proposal gets implemented, we should advertise it in some way, so that any admin who feels they should have it knows to grant it to themselves; alternately, we could go through and grant the autopatrolled right to all current admins with an adminbot, and then any admin who doesn't want it can remove it from themselves. Writ Keeper (t + c) 21:28, 23 March 2013 (UTC)
Indeed. If an admin bot were called for, I could certainly put one together. --j⚛e deckertalk 21:54, 23 March 2013 (UTC)
  • Support I can't really expand on any of the above comments. Assuming this isn't incredibly difficult to do, I'd support it if even one administrator didn't want it. Ryan Vesey 21:47, 23 March 2013 (UTC)
  • Oppose NPP here. The point of of patrolling new pages is checking articles for obvious problems. Notice the emphasis on the obvious? I think admins can be trusted to write articles with no obvious problems (attack pages, gibberish, etc.) If they can't, they probably shouldn't be admins. Plus, us patrols have enough to work with already. Our backlog has been at a month for nearly 18 days now. Revolution1221 (talk) 22:02, 23 March 2013 (UTC)
  • That's a nice idea in theory, but in practice, it would never happen, since removing an admin bit requires Arbcom intervention. And again, note that this should have little to no actual impact on NPP, at least initially, and especially if we re-add autopatrolled to all admins via an adminbot and let any that don't want it remove it themselves. Writ Keeper (t + c) 22:10, 23 March 2013 (UTC)
I wouldn't want to burden new page patrol, but admins are not supposed to have any special authority, real or implied, when it comes to actual content and we do have a lot of admins who would not otherwise qualify for this userright, in fact I think I am probably one of them. Frankly I like the idea that any page I might create will be double checked, I mostly do admin work these days as opposed to content work and they are two very different skill sets. Like anything else, if you don't use it you tend to get a little rusty and make mistakes you might not have made when you were using those skills more regularly. Beeblebrox (talk) 22:15, 23 March 2013 (UTC)
Do you believe that you have "special authority" when editing a page under WP:Pending changes? Admins don't need to have a second editor manually check their changes to PC-protected pages. This is really no different. Having this right on all the admins means that no second editor needs to manually check the new pages created by admins. That's all it does. It does not prevent someone from seeing that you've created a page (it's still listed in the same queue, just not highlighted in bright yellow) and it does not prevent someone from sending it for deletion. WhatamIdoing (talk) 23:22, 23 March 2013 (UTC)
I don't buy the premise of your comparison at all, they are quite different. The purpose of PC is to prevent vandalism, which an admin is in fact expected to have a solid understanding of. Also, the reviewer right is deliberatley very easy to get, about the same as rollback. Autopatrolled has much higher requirements. Beeblebrox (talk) 17:59, 24 March 2013 (UTC)
The primary purpose of NPP is to find articles that qualify for speedy deletion, which admins also ought to have a solid understanding of. WhatamIdoing (talk) 02:04, 29 March 2013 (UTC)
  • Support as an admin - this isn't directly related to admin tasks, so admins shouldn't have it automatically. I have no opposition to admins granting it to themselves on a 0RR basis - if an other admin revokes it, they don't take it back themselves. עוד מישהו Od Mishehu 22:24, 23 March 2013 (UTC)
  • Comment1st para/Oppose2nd para: The ground is not prepared to cultivate this idea at this moment. In a recent RFA, where I was nominator, the candidate had 100,000+ edits but not too many project space edits and NO bot/automated edit. There it was told, he does not need the admin tools since he has not worked too much there (not a bad point though). But, all the user rights we have are administration/management related. There is nothing for content creators other than this autopatrolled. In future, I hope to see user rights are being divided into two groups a) management related b) content creation related (to explain the second, "Content dispute", where a non-admin editor who is regularly doing studies and research to create/expand articles might be helpful, but, we have no such right). Unbundling only one right (i.e. autpatrolled, because it is not directly related to adminisration) does not make proper sense. Prepare the ground first and unbundle content creation related rights as a whole.
    From another point of view, I'll not like to see someone's user rights in the TParis's or similar page: User:Example "Sysop, autopatrolled"! Autopatrolled should be bundled with with admin's rights. But, there might be an option that they can remove that right/other rights (like Filemover, I think there are admins who don't need that tool) if needed. But, removing it by default does not sound fair (per WhatIamdoing)! --Tito Dutta (contact) 00:03, 24 March 2013 (UTC) oppose strike-through, signed --Tito Dutta (contact) 18:13, 24 March 2013 (UTC)
  • Tito, your second to last sentence ("But, there might be an option that they can remove that right") is the point; this proposal is what will enable that to happen. The point is not to disallow admins from having autopatrolled until they apply for it. The point is that it is currently impossible--literally, there-is-no-physical-way-to-do-it impossible--to be an admin without also having the autopatrolled right. By removing the autopatrolled right from the admin package, we stop forcing admins to also have the autoconfirmed autopatrolled right. As the proposal says, any admin can freely give themselves the right; we can and will go through and manually (well, through a bot, but still) add the "autopatrolled" right to all admins, so that their rights will have effectively not changed. The only things that will have changed are that a) admins who don't want the right--there are several, including myself--gain the ability to turn it off without having to surrender all their admin rights and b) the right can be removed from admins who shouldn't have it without having to completely desysop them (which is not an implausible scenario). It's Zippy makes an excellent point above: the reason autopatrolled should be singled out is that it is a right which an admin cannot avoid using. All the other rights in the kit are very specific; avoiding the use of the right is simple, just don't use it. With autopatrolled, however, currently the only way to keep from using it as an admin is by either never creating any articles ever again, or by resigning all of the admin tools. This proposal gives us more flexibility than that. Writ Keeper (t + c)
forcing admins to also have the autoconfirmed right... Crazynas t 04:23, 24 March 2013 (UTC)
Not sure if this is what you were pointing out, but yes, I did mean "autopatrolled", not "autoconfirmed" there, thanks! Writ Keeper (t + c) 04:33, 24 March 2013 (UTC)
Indeed. Crazynas t 05:03, 24 March 2013 (UTC)
  • Support - I agree that admin user rights are overly broad. If the privilege were removed tomorrow there probably wouldn't be anything more than a marginal uptick in workload at NPP since admins are doing very little article creation. Marcus Qwertyus (talk) 05:07, 24 March 2013 (UTC)
  • Conditional support Makes sense, but support only if any admin gets the right automatically granted, who have hold it before being promoted. Armbrust The Homunculus 11:37, 24 March 2013 (UTC)
  • Support as an admin for 8 years, I support this. While it would be awesome to assume that all admins are capable of perfect judgement and would never make a bad article, that just isn't true. Andrew Lenahan - Starblind 15:19, 24 March 2013 (UTC)
  • Support. Quite reasonable to allow admins not to assume the right unless they feel comfortable taking it on. Choess (talk) 17:36, 24 March 2013 (UTC)
  • Oppose Just what problem is this supposed to solve? From time to time i check patrolled articles on NPP to see if there is any abad patrolling, and also to see if there are any problems with those having the right, and I do not remember seeing any problems with administrators. I suppose there must be some, or what would this proposal have been initiated. DGG ( talk ) 20:12, 24 March 2013 (UTC)
  • Oppose. Given that most NPPs say there are no problem to be solved by this, then this looks like a useless move; or it may be an attempt (not necessarily by the starter) to unbundle whatever "something" out of the admin rights to establish a precedent, in which case it would be worse. - Nabla (talk) 20:34, 24 March 2013 (UTC)
So you don't believe administrators should have the right to not use one of their tools? (as pointed out numerous times above, this is the only right in the administrator package which is a passive 'status' as it were, not an active button you can choose not to use.) I was also unaware that consensus was binding.Crazynas t 21:10, 25 March 2013 (UTC)
As you clearly say, it is not a "tool" it is a "flag", a sign that this one is a unlikely problematic article creator, by definition a admin (supposedly someone how knows and abides by policy) is one such user. - Nabla (talk) 17:45, 28 March 2013 (UTC)
  • Oppose. Not because I'm an admin who wants to keep his rights, but because of the opposition from the newpagepatroller people. New users are more likely than admins to be creating problematic pages, and if the patrollers don't have time to keep up with just the new users and non-new people without autopatrolled, they definitely don't have the time to keep up with the new users, the non-new people without autopatrolled, and lots of the non-new people who would lose autopatrolled because of this proposal. I'm an admin, but I wouldn't mind losing the right if necessary. Nyttend (talk) 21:35, 24 March 2013 (UTC)
  • There wouldn't be a lot of people losing autopatrolled because of this proposal. Admins who didn't want the right could get rid of it on their own account. Admins who shouldn't have the right can have it taken away by community consensus. The vast majority of administrators will have and keep the right. Ryan Vesey 01:15, 25 March 2013 (UTC)
  • Support for many of the reasons already given above. I would also like to see more proposal along these lines.Volunteer Marek 21:38, 24 March 2013 (UTC)
  • Support - There are doubtlessly administrators who are proven vandal fighters who may or may not understand the fine points of notability or copyright law. It makes sense separating advanced editing rights from advanced site maintenance rights. Grandfather in all current admins. Carrite (talk) 01:07, 25 March 2013 (UTC)
  • Support Not specifically related to administrator work, and, for what its worth, the right should be optional anyway. If they would like the right and their understanding of policy can be proven, then an administrator as any other editor may have the autopatrolled right. TBrandley 01:15, 25 March 2013 (UTC)
  • Support this proposal, seems sensible, logical, and rational. — Cirt (talk) 03:26, 25 March 2013 (UTC)
  • Oppose nobody has presented any evidence that this proposal is desirable or necessary, and it seems to be proposed for political reasons rather than as a result of a genuine need on the ground. It's been a while since I did any new page patrolling, but the barrier to getting an article patrolled is very low - a check to see if the article should be speedily deleted and possibly common cleanup tags or formatting problems. On the other hand this proposal will increase the workload of NP patrollers, which is already very high. Hut 8.5 10:52, 25 March 2013 (UTC)
    • When BLPprod came in we removed AutoPatrolled status from several editors, and I seem to remember we had issues with one admin, others may remember other incidents. As for the burden on newpage patrollers, I would anticipate that the number of new articles created by admins who didn't have this right before their RFA would be quite low. ϢereSpielChequers 11:07, 25 March 2013 (UTC)
      • We once had problems with one admin? That's it? Wow! It is a serious problem we must address it right away! Also, you say this about to change almost nothing. Why change then? - Nabla (talk) 20:59, 25 March 2013 (UTC)
      • Do you have any links? One vaguely remembered incident from several years ago (which from your description seems to have resulted from a change in community expectations) isn't a very compelling case. Regarding pages created by administrators, while many administrators probably don't create pages very frequently (including me), the standard for getting the autopatrolled right is low (you need to demonstrate an understanding of BLP, verifiability, notability, and copyright) and I imagine administrators will meet it. This will be particularly true of recently appointed administrators given the steadily rising standards at RfA. Hut 8.5 21:09, 25 March 2013 (UTC)
        Not as low as you think. You need to have created a minimum of 50 articles, something that very few administrators have done. The point of unbundling in this case is one of natural justice; a non-admin who creates a non-compliant article will have the autopatrolled user right removed, but the only way an administrator guilty of the same offence could have the right removed would be a desysop. Malleus Fatuorum 21:16, 25 March 2013 (UTC)
        The 50 article rule is only a "suggested standard". You have to demonstrate you "are familiar with Wikipedia's policies and guidelines, especially those on biographies of living persons, copyrights, verifiability and notability" (Wikipedia:Autopatrolled). With the possible exception of notability, a basic understanding of those named policies ought to be a prerequisite for adminship. Proposing changes for political reasons - including perceived "justice" - isn't a very good practice. We ought to change things based on evidence that they are actually causing a problem. Hut 8.5 22:31, 25 March 2013 (UTC)
        The constant cry at RfA is that you must have demonstrated your understanding of all the super important stuff that admins do by, you know, actually doing it. Why is autopatrolled different? You demonstrate a understandng of deletion policy by taking part in AfDs, for instance, and your speedy deletion nominations are examined in infinite detail. Similarly, your understanding of article creation guidelines ought to be demonstrated by actually creating articles. But content creation isn't considered to be important for an RfA candidate, so why allocate a user right they have exhibited no understanding of? Malleus Fatuorum 22:52, 25 March 2013 (UTC)
        There's content creation and there's content creation. Administrators certainly ought to have some understanding of our core content policies, if only because they tend to crop up everywhere. On the other hand because they tend to crop up everywhere most experienced editors will already have that understanding. The trend at RfA is for the much higher requirement of GAs and FAs, which is excessive (in my opinion, anyway - lots of people disagree [7]). The requirement for getting autopatrolled is similar to the lower of these two. After all most NP patrol deals with very new editors who know almost nothing about our standards. Hut 8.5 11:13, 26 March 2013 (UTC)
        " After all most NP patrol deals with very new editors who know almost nothing about our standards." That's not true. Take a look at the number of articles J3Mrs (talk · contribs) has created for instance, or Parrot of Doom (talk · contribs). Many prolific content creators don't have the autopatrolled user right. Malleus Fatuorum 11:52, 26 March 2013 (UTC)
        I'm sure there are many prolific content creators who don't have the autopatrolled right. That doesn't mean that most NP patrol work isn't concerned with new editors. Hut 8.5 12:24, 26 March 2013 (UTC)
        Just saying it doesn't make it so. Looking at the top 20 or so articles most recently created I see quite a few written by editors with thousands of edits who've been here for years, some with as many as 76,000 edits. Malleus Fatuorum 12:57, 26 March 2013 (UTC)
        Looking at the 20 most recently created unpatrolled pages I can only see one created by someone with over 500 edits (they had 1890). On the other hand I see 6 pages created by people with under 10 edits. Looking at a raw list of new pages isn't going to give a very good indication of the problem here because it includes pages created by people with the autopatrolled right. Hut 8.5 17:28, 26 March 2013 (UTC)
  • Support. People who are given the mop who have already created more than 50 articles should also be granted autoreviewer status, and admins who want are serious about content creation will get right soon enough. Andrew327 15:31, 25 March 2013 (UTC)
  • Support - Really don't see too many flaws in this idea, can't add much more than most of the supports here. It doesn't detract from anyone's abilities to work, after all. Lukeno94 (tell Luke off here) 16:44, 25 March 2013 (UTC)
  • Support, not required for admin work. Lectonar (talk) 16:50, 25 March 2013 (UTC)
  • Support As a general rule, I'm not sure why rights that exist as their own flags should be swept up into the admin flag. Courcelles 17:50, 25 March 2013 (UTC)
    Because there's a cultural inertia at work. To take another example, why should admins be allowed to give themselves the edit filter user right, rather than be asked to request it in the way that non-administrators are required to do? There are several levels of answer to that question, but they all boil down to "admins good, non-admins bad". Malleus Fatuorum 23:03, 25 March 2013 (UTC)
  • Oppose Absurd considering the size of the NPP backlog. Once we get it down to a reasonable length (less than 10 days), we could consider this. ⇌ Jake Wartenberg 23:09, 25 March 2013 (UTC)
    What effect will this proposal have on the NPP backlog? Nobody is proposing taking the autopatrolled user right away from all administrators, simply unbundling it so that it can be removed if desired or necessary, just as it can with regular editors. Malleus Fatuorum 23:12, 25 March 2013 (UTC)
    Based on the wording above and the discussion that follows that is exactly what is being proposed. To take it away from all admins and then give it back to those who should have it. -DJSasso (talk) 12:53, 26 March 2013 (UTC)
    I suggest you try reading all the words in the proposal, assuming you've actually read any of it, which frankly seems unlikely. Malleus Fatuorum 04:04, 27 March 2013 (UTC)
    The proposal is to remove the autopatrolled right from the administrator user access group. Unless someone writes an adminbot to give all current admins the separate autopatrolled right this will result in all administrators losing the autopatrolled right, at least initially. Administrators will retain the ability to grant autopatrolled to themselves, but unless and until an admin does that then any pages they create will have to be reviewed by NP patrol. It's a good question how many admins will grant the right to themselves, since most won't even realise it's gone. Hut 8.5 11:50, 27 March 2013 (UTC)
    Then I suggest you brush up on your reading level and on how the wiki software works. As Hut 8.5 mentions unbundling it will require it being removed from all admins as a function of how the software works. So unless an admin gives it back to themselves or someone else gives it to them such as an admin bot. All admins will lose the right as part of this proposal. -DJSasso (talk) 11:56, 27 March 2013 (UTC)
  • Weak to moderate support. In the end, I think this is just a token move. I doubt it will make much difference in practice: I can't properly imagine a situation where this bit won't be handed out to a newly chosen admin. But it's not a bad token, and the workload it generates will be negligible. On the question 'what problem does this solve', I think the answer is that it will make admin less of a big deal (it's too much of a big deal at the moment), it will lower the perception that Admins are godly creatures that can only do correct things that some may have. Those are not very strong points IMO, but points nonetheless. The NPP backlog is One Of Those horrible horrible backlogs. A responsible admin doing a lot off article creation will probably have already requested that bit, or should request it ASAP (actually, with or without admin bit, if you create a lot of articles, request it ASAP.). We pass about 4 admins a month. We can deal with handing out 4 extra autopatrolled bits a month, if every admin were to request one. Martijn Hoekstra (talk) 23:20, 25 March 2013 (UTC)
  • Support A very reasonable proposal and I doubt that it will create that much more work for NPPers. AutomaticStrikeout (T • C • AAPT) 02:30, 26 March 2013 (UTC)
  • Oppose This is a solution in search of a problem. And besides, autopatrolled criteria are already too strict. I've made 20-30 articles; I know better than to make something that can be CSDd. Content creation might not be in the admin job description, but it's a basic of Wikipedia which potential admins should show competency in. If you can't trust an editor to make good articles, you shouldn't trust him or her to be an admin in the first place. --BDD (talk) 20:05, 26 March 2013 (UTC)
  • Oppose - Would cause an unnecessary increase in the number of articles that need to be patrolled. And, the vast majority of those articles should not need much help. So, this is essentially an exercise in increasing the inefficiency of NPP. Per WP:AUTOPATROL, having the autopatrolled user right "...means that the user can be trusted not to submit inappropriate material, deliberately or otherwise..." I'm reasonably sure we can trust admins to not submit inappropriate material as much as we can trust any non-admin that already has the autopatrolled right, although I suppose you could accuse me of being biased in that regard. ‑Scottywong| prattle _ 21:17, 26 March 2013 (UTC)
    That would only be true if the proposal were to remove the autopatrolled user right from administrators, but it isn't. Malleus Fatuorum 21:32, 26 March 2013 (UTC)
    That's not really made clear in the proposal. It is never clearly stated that the proposal is only to unbundle the right, not to strip every admin of the right and force them to apply for it if they want it. The proposal contains statements like, "any admin who needs it can simply grant it to themselves" which implies that we would need to grant it to ourselves if this proposal were to succeed. Furthermore, my gut reaction is that if an admin does something so abusive that we agree that he should no longer have the autopatrolled right, then I would probably be in favor of desysopping that admin. If an editor isn't capable of creating an article that doesn't violate core policies, then they probably shouldn't be admins. Note that I'm not saying that an admin who creates an article with spelling/grammar errors, poor wording choice, bad formatting, etc., should be desysopped, because none of those minor issues are requirements for getting the autopatrolled bit. But, if an admin makes a habit of creating articles with copyvios, or libelous unsourced BLP's, then they should probably not be an admin. Therefore, the unbundling is unnecessary. ‑Scottywong| chatter _ 22:11, 26 March 2013 (UTC)
    Really? The title of this proposal is "Unbundle autopatrolled from admin rights package", not "Remove autopatrolled from admins". The edit filter user right is already unbundled, for instance. Would you equally propose that administrators unable to write regular expressions ought to be desysoped, rather than have that user right removed? And please don't give me any guff about "trust"; the overwhelming majority of administrators were promoted before that user right existed. Malleus Fatuorum 22:16, 26 March 2013 (UTC)
    That's not a valid comparison. The edit filter right doesn't come with adminship, whereas autopatrolled does (and you're claiming that you're not trying to change that). There are tons of user rights that you don't automatically get as an admin, here's a partial list: bigdelete, checkuser, hiderevision, importupload, abusefilter-modify, oversight, renameuser. There is a reason why these user rights don't come with adminship, mostly because they each require specialized knowledge (like regex) and/or an advanced level of trust (which may or may not include identifying yourself to WMF). The autopatrolled user right requires neither specialized knowledge or an advanced level of trust. It requires a simple level of familiarity with Wikipedia core content policies, which every admin should have. If you don't know that copyvios are bad, then you shouldn't have passed RfA in the first place. If you knowingly commit a copyvio as an admin, you shouldn't be an admin anymore. That's all there is to it. ‑Scottywong| squeal _ 22:37, 26 March 2013 (UTC)
    I thought you retired, anyway. You must hear that a lot. Glad to see you're back, doing useful things like badgering opposers of this thinly veiled attempt at a political statement useless proposal. ‑Scottywong| prattle _ 22:57, 26 March 2013 (UTC)
    I doubt you thought at all. I bet you hear that a lot. Malleus Fatuorum 23:48, 26 March 2013 (UTC)
    Scottywong: What is you're opinion on the administrators above who wish to remove (give up) the right themselves? cf. ItsZippy, joe decker and Beeblebrox, regards, Crazynas t 00:35, 27 March 2013 (UTC)
    Probably unsurprisingly, I can be added to that list. Writ Keeper (t + c) 01:02, 27 March 2013 (UTC)
    Me too. Lectonar (talk) 11:42, 27 March 2013 (UTC)
    Perhaps it's a result of a misunderstanding of what actually happens at NPP in reality. Typically, each article is briefly checked to ensure it doesn't qualify for speedy deletion. Cleanup tags may or may not be added to the article if it has glaring problems (i.e. no references, no categories, not neutral, reads like an essay, etc.). If it's a stub, a stub tag might get added to it. The most ambitious patrollers might actually spend a few minutes fixing some major problems (adding footnotes, categories, etc.). However, it is extremely unlikely that a patroller is going to spend a half hour examining your article and making detailed fixes to minor problems. That's just not a realistic expectation. There are far too many articles coming through the fire hose for a patroller to spend more than a minute or two on any one article. So, considering that reality, if an admin truly believes that he/she is incapable of reliably creating an article that doesn't qualify for speedy deletion, or creating an article that doesn't have major problems with it... then perhaps that admin should simply not create new articles at all, and perhaps they should question why they are an admin or why they are here in the first place. Look, I'm no great writer, nor am i a prolific content creator, but I'm confident that I can create an article that doesn't suffer from major problems. Any admin should be able to get over this very low bar, and therefore should not be concerned with their autopatrolled status. ‑Scottywong| spout _ 03:34, 27 March 2013 (UTC)
    More likely it's ignorance of what actually happens at NPP in reality, or what should happen. Malleus Fatuorum 03:55, 27 March 2013 (UTC)
    What should happen at NPP and what does happen are different things, without a doubt. That is a consequence of the practical realities of how NPP works, the number of editors that actively patrol new articles, and the rate of article creation. ‑Scottywong| comment _ 04:36, 27 March 2013 (UTC)
    I agree with Scottywong here: The reality is that NPPers normally spend one minute or less on patrolling a page. Click here to see whether anyone is active; if someone is patrolling pages right now, then you'll be able to see what the average length of time between pages is. WhatamIdoing (talk) 02:14, 29 March 2013 (UTC)
  • Oppose - Any user who can't be relied upon to create valid pages is a user who should not be trusted with speedy-deletion determinations -- that is, a user who shouldn't be an administrator. Furthermore, since administrators now have the capability of granting or revoking the "autopatrolled" user right, unbundling this from the admin tools package would also logically mean that admins also should not be able to grant this user right, meaning that there would need to be a whole new bureaucracy created to grant/revoke "autopatrolled". --Orlady (talk) 21:53, 26 March 2013 (UTC)
  • Oppose - If an admin creates problematic new articles, then the first thing to do is to warn them. If that doesn't work, and their problem just keeps getting worse, I see no reason not to desysop: 1) They technically have abused the admin right, specifically the autopatrolled portion of it; 2) Someone who repeatedly makes the same lapse in judgment really does not deserve to be an admin. Admins have been desysopped in the past for things like copyright violations, so removing the tools for content-related issues is not unheard of. -- King of ♥ ♦ ♣ ♠ 22:04, 26 March 2013 (UTC)
    • All of this is irrelevent for the issue at hand - whether the "autopatrolled" ability should be part of the admin package. Should any article I (an admin) create automatically be marked as patrolled? I, personally, think not. That's the issue here. עוד מישהו Od Mishehu 11:49, 2 April 2013 (UTC)
  • Support - If an admin creates problematic new articles then we should be able to remove this right without having to go through the whole desyop process. AIRcorn (talk) 23:53, 26 March 2013 (UTC)
    Quite simple really. I'm rather surprised to see so many admins Hell bent on the idea that rather than have their autopatrolled user right removed they'd prefer to be desysoped. Malleus Fatuorum 03:59, 27 March 2013 (UTC)
    The issue is that if admins cannot be trusted to create articles without issues, then they also cannot be trusted with the delete tool. -- King of ♥ ♦ ♣ ♠ 04:19, 27 March 2013 (UTC)
    That's an entirely separate issue. Would you equally say that administrators unable to write regular expressions cannot be trusted with the delete tool? Have you forgotten that content creation is considered to be irrelevant at RfA? Or do you just not care about making Wikipedia a more rational environment as opposed to a petty feudal oligarchy? Malleus Fatuorum 04:28, 27 March 2013 (UTC)
    Content creation is not "irrelevant" at RfA. It may not be as relevant as you personally want it to be, but it is far from irrelevant. ‑Scottywong| gab _ 04:50, 27 March 2013 (UTC)
    Perhaps you missed Wikipedia:Requests for adminship/Jimp. Candidates are indeed promoted based on the skill and cluefulness that they've demonstrated in areas other than content creation. Having created zero articles doesn't mean they're a bad admin; we all have different strengths and weaknesses, and requiring a desysop rather than turning off the autoreviewed flag for admins who haven't demonstrated article creation skills seems to me to be throwing out the baby with the bathwater. 28bytes (talk) 05:03, 27 March 2013 (UTC)
    Huh? ‑Scottywong| chat _ 05:09, 27 March 2013 (UTC)
    I don't think article splits and disambiguation pages (while useful) are what are traditionally considered "content creation." Should someone who has never added a source to an article be exempt from having new page patrol check their article creations? Sometimes, sure. But deciding that on a case-by-case basis seems more reasonable to me than the status quo of "only if they're an admin." 28bytes (talk) 05:26, 27 March 2013 (UTC)
    Are there any examples of articles created by an admin that slipped through the cracks and persisted for an extended period with major, policy-violating problems? Perhaps if someone can demonstrate that this is a problem that happens with some regularity, it might indicate why there is a need for this proposal. ‑Scottywong| yak _ 09:59, 27 March 2013 (UTC)
    Yes there are, and even at least one arbitrator. I don't want to point the finger at anyone for past mistakes, but many will know who I'm referring to. Malleus Fatuorum 15:38, 27 March 2013 (UTC)
    You don't want to point out other people's mistakes? When did that start? Anyway, were these isolated, one-time mistakes or were there demonstrated patterns of were any of the admins/arbitrators sanctioned or desysopped for these mistakes? I'm not aware of the event(s) you're talking about because I generally don't follow arbcom cases very closely, but it would be helpful to see a specific case, so that we could judge for ourselves if it was actually an edge case where it would be appropriate to remove autopatrolled rights but not desysop. ‑Scottywong| confabulate _ 15:57, 27 March 2013 (UTC)
    I suggest that you consider very carefully whether your usual attack dog style is appropriate before making any further personal remarks. But as you seem to be ignorant of the potential problem here you could do worse than investigate the background to the case of Grace Sherwood. Malleus Fatuorum 16:06, 27 March 2013 (UTC)
    That article was created by an IP, so it wouldn't have mattered whether or not the admin had autopatrolled rights. It would have been patrolled (if NPP existed back when that article was created). Any other examples? (Given that this proposal would only protect us from admins who specifically create new articles that are problematic, it would be more helpful to see examples of admins actually creating new articles that are problematic, rather than examples of admins making problematic edits to existing articles, since this proposal doesn't address that problem.) ‑Scottywong| comment _ 17:00, 27 March 2013 (UTC)
    That example isn't relevant at all. The article was created five years before the offending admin touched it, so new page patrol didn't have a chance to spot any problems. The admin concerned had written over 100 articles as well as a number of FAs and DYKs, so they would certainly have qualified for autopatrolled through the normal process. Even if none of that was true a quick look by a new page patroller couldn't possibly have caught problems that were missed by FAC. The ability to remove autopatrol without desysopping wouldn't have helped either since the admin resigned shortly after the problems came to light. Hut 8.5 17:26, 27 March 2013 (UTC)
    And, that article was never patrolled, since NPP and Special:NewPages didn't exist in 2005. I believe what Malleus is trying to show us is that there is at least one example of an admin adding content to an article that violates copyrights. The example situation given, however, would not be fixed by this proposal, and furthermore, I doubt that such events have happened with sufficient frequency to actually show up on the radar as a legitimate problem that needs to be solved with this unbundling. Frankly, I see this as yet another attempt by Malleus to posit that content creators are better than and/or more valuable to the project than administrators, perhaps motivated by a deep-seated resentment of his own failed attempts. If anything is pushing Wikipedia closer to being a "petty feudal oligarchy", it is this type of attitude. I believe that Writ Keeper started this proposal in good faith, but the original AN discussion certainly shows the motivations for suggesting that this idea be proposed by someone, and Writ Keeper simply took the bait. ‑Scottywong| chatter _ 17:37, 27 March 2013 (UTC)
    Your persistent personal attacks demonstrate very clearly that your opposition to this proposal is based solely on your dislike of me. All I can say is the feeling is most definitely mutual. Malleus Fatuorum 17:45, 27 March 2013 (UTC)
  • Oppose - Anyone who becomes an admin should be capable of judging submitted material, otherwise they shouldn't be granted the admin tools at all. To be trusted with posessing the admin tools in my opinion also includes the ability to judge article content. -- Toshio Yamaguchi 11:14, 27 March 2013 (UTC)
  • Comment I'd like to address some spoken and unspoken questions about my motivations for proposing this. Someone above suggested that this is a political statement, which presumably means they think I'm trying desperately to kiss Malleus's ass for some reason. Not sure why I would want to do that, but it doesn't matter, because it ain't true. What happened was that while I was reading the AN thread, I thought to myself, "Hmm, this sounds like a really good idea, and I can't really see any significant downsides to it if properly implemented; someone should act on this." When Malleus said he wouldn't propose it himself, I thought "Damn, I really would've liked to see that go through." Then I realized the obvious that I could actually get off my lazy butt and propose it myself, so I did.
My real motivation is that it has bothered me for some time at how little sense the admin package makes, if you look at it in terms of the rights it contains compared to the taasks usually thought of as admin tasks. Autopatrolled is one of those rights, and it's the easiest one to unbundle from the admin rights package, since there's already a framework for providing it outside of the admin package. Someone above mentioned that this could be setting a precedent: actually, I personally hope so, but not perhaps in the way one might think. I'd like to see other rights not closely associated with admin tasks be removed from the admin package, as well. The two others I've thought about are editinterface and edituserjscss. Now, both of those are different from autopatrolled in that there's no mechanism for providing them outside the admin framework, so a proposal for them would have significant bureaucratic overhead. Also, they're both pretty destructive rights; so is editfiltermanager, though, so I would think they could follow the same model.
Now, I didn't emphasize this line of thought in my proposal (though I touched on it briefly), because I didn't think it would have very much appeal to other people. It's the kind of thing where people might say, "yeah, that kind of makes sense, but there's no urgent problem so no". I know the old maxim "if it ain't broke don't fix it", but in this case, I personally don't think mere inertia and resistance to change for its own sake is a good reason to oppose, when we can confidently predict that there will, in fact, be little to no negative impact, on the NPP backlog or anything else (cf. the discussion above around Joe Decker's !vote, where we discuss making an adminbot to go around and manually add autopatrolled to all current admins and let them opt out of it if they like.) Writ Keeper (t + c) 13:27, 27 March 2013 (UTC)
    • The proposal will undoubtedly have some negative impact. If we don't make an adminbot then the number of pages needing patrolling by new page patrol will go up, at least until some editors run around giving autopatrolled flags to admins who create large numbers of new pages, or remind those admins to give themselves the flag. If we do write an adminbot then someone will have to write it, host it, review its output to make sure it's working properly, approve it (which per policy would require a separate community discussion), and it would generate about 1500 useless log entries. The benefits of the proposal, on the other hand, are purely hypothetical at the moment. Hut 8.5 13:59, 27 March 2013 (UTC)
      • Well, considering that we need devs to make this change for us, we'd have time for all that. Is that really a drawback if someone's willing to do it? Writ Keeper (t + c) 14:13, 27 March 2013 (UTC)
      • Better still, when you make the change leave autopatrolled flipped on for all admins who were Autopatrollers before they became admins. I doubt that the rest of us actually create many new articles. ϢereSpielChequers 14:32, 27 March 2013 (UTC)
        • What's the adminbot for? According to Malleus (in response to my vote above), this proposal is only to unbundle the user right so that it can be removed if necessary/desired, not to remove it from every admin account by default. ‑Scottywong| confabulate _ 14:34, 27 March 2013 (UTC)
          • As a purely technical consequence of unbundling the right from the admin package, it would be removed from all admins, since there aren't any admins who currently hold the admin package and autopatrolled separately. So, we use the adminbot to go and readd the autopatrolled right separately, since as Malleus correctly says, this proposal is not aimed at removing it from every admin account by default. (If it's not clear, the adminbot is a one-time thing, not something that would be run continuously.) Writ Keeper (t + c) 15:25, 27 March 2013 (UTC)
  • Oppose with understanding of supporting viewpoint. Though I commend the proposer for such a well though-out and rationalized proposal, keeping the autopatrolled permission reduces the workload of anti-vandal editors such as myself; I come across far too many ClueBot NG flagged administrator edits, and I've never had a single one that I wanted to revert (and it has nothing to do with them being administrators - they simply tend to make good edits due to the fact that they have to establish a history of positive edits in order to become an administrator). The benefits of removing this permission do not supersede what we stand to lose in time resources. On the rare instances where administrators are "abusing" (even inadvertently) the right, I posit that, odds are, they will, eventually, be caught and that there are few enough administrators that, when this occurs, it will be dealt with appropriately and not become and epidemic. Jackson Peebles (talk) 17:01, 27 March 2013 (UTC)
  • The autopatrolled permission has literally nothing to do with anti-vandal efforts. Ryan Vesey 17:13, 27 March 2013 (UTC)
  • Support Far too much OWNing of the current package without thinking of other possibilities. Intothatdarkness 18:08, 27 March 2013 (UTC)
  • Support - heh, I didn't realize previously that "doesn't qualify for autopatrolled" could be technically legitimate grounds for oppose vote in RfA. Also per Kiefer.--Staberinde (talk) 18:11, 27 March 2013 (UTC)
  • Support - per most support !votes. Mlpearc (powwow) 18:31, 27 March 2013 (UTC)
  • Oppose. Another solution in search of a problem. Ruslik_Zero 19:25, 27 March 2013 (UTC)
  • Oppose – Will create extra work with no practical benefit. Graham87 13:26, 28 March 2013 (UTC)
  • Weak oppose There's no admin task that I'm aware of for which autopatrolled is required, or even helpful, and it's totally correct to say that a good admin does not necessarily make a good content producer. However, it's taken as read that any admin has a fairly comprehensive knowledge of the minimum requirements of article creation, and one would expect them to adhere to those requirements in their article work (besides which, content creation stills carries considerable weight at RFA, see: just about every single RFA ever filed). As such, whilst there's no self-evident reason for them to have it, I can't see any particularly convincing reason for not giving admins the AP right as part of the package, though I'm happy to reconsider if someone can point to an admin with a disasterous record of post-mop article creations (*quickly checks own contrib history; no, looks ok...*). Yunshui 雲‍水 13:38, 28 March 2013 (UTC)
  • Oppose on two grounds:
    1. If a person is not trusted enough to have the auto patrolled bit then they should not be an admin in the first instance;
    2. Because, "Any administrator can grant this right at their discretion..." Therefore an admin can simply grant it to themselves.
    The latter point is the most significant as it makes the proposal moot. --<spayn style="color:black;">RA (talk) 13:56, 28 March 2013 (UTC)
    • It's also technically possible for an admin to unblock themselves if they've been blocked; that doesn't mean they're allowed to do it, or that such an action would be tolerated. Writ Keeper (t + c) 14:18, 28 March 2013 (UTC)
      • Yes, I'd say that if we allow admins to give themselves the right only on a 0RR basis, then your second issue is no longer correct. עוד מישהו Od Mishehu 12:20, 29 March 2013 (UTC)
  • Oppose. I am an admin, but I don't see having autopatrolled as a benefit to myself, since I don't notice it. Rather, the fact that some people have autopatrolled is a benefit to new pages patrollers. If the impetus for this proposal were coming from new pages patrollers who were saying, "Hey, too many people have autopatrolled. Some admins are creating new articles that are crappy, and they ought to lose the autopatrolled right," then I could understand the proposal. But I don't see that as being the situation here; most of the new pages patrollers participating here don't seem too enthusiastic about this proposal. --Metropolitan90 (talk) 04:09, 30 March 2013 (UTC)
  • Support. I am an admin who had this right before passing RfA. I sympathize with the New Page Patrollers; reducing their workload a bit was one of the reasons I wanted the right (especially since some of the articles I write are on very recondite topics that can't have been much fun to check). My support assumes the creation of an adminbot either to restore the right to all current admins or to restore it to those of us who already had it, as discussed above. However, I believe this is indeed an "in case we need it" change; it would be far better not to have to try to desysop someone in order to get their potentially problematic articles checked (both because it's a tremendous hassle to get someone desysopped, and because we then lose the benefit of their administrative actions afterwards), but there is no implication that it would be frequently needed. Also, unless something radical has happened there since I stopped looking to see whether I dared apply, the bar for autopatrolled is way, way higher than many commenters here seem to realize. When I was unexpectedly given the right, I had noticed the number of articles required was rising faster than I could write them. I saw someone declined who had 80 or 100, I forget which ... so I gave up. Realistically, adminship appeals to a lot more people who spend most of their time doing different things, like making non-admin closures at AfD, dispute resolution, and vandal fighting ... even NPP. So long as autopatrolled is going to require a higher standard than basic knowledge of the notability and reliable sources guidelines and the ability not to commit copyvio (and I think it should, but not as high as it does/did), it's a higher standard than should or can reasonably be required at RfA except as an individual !voter preference. And indeed, while I've seen some requiring GAs, an FA, or maybe a few DYKs, I don't recall anyone ever mentioning autopatrolled as a requirement. I support this as a sensible unbundling, although I hope no need to pull it from an admin ever arises. (And I do expect that bot, to save the NPP folks from having again to read the output of admins like me.) Yngvadottir (talk) 16:34, 30 March 2013 (UTC)
    By the way, I've written a script that will re-add the autopatrolled flag. I don't think it counts as a bot, since I'd be doing it on my own account under supervision, but should this pass, I'll probably run it by BRFA anyway, just to be sure. Writ Keeper (t + c) 15:42, 2 April 2013 (UTC)
  • Support After seeing a couple of epic cases, I truly believe that some admins simply need their creations patrolled. — ΛΧΣ21 13:49, 2 April 2013 (UTC)
  • Oppose per User:Ruslik0: from the way the proposal is presented, I cannot see any pressing need for this change – i.e. any actual cases in which Sysops have misused their Autopatrolled right. It Is Me Here t / c 14:45, 2 April 2013 (UTC)
    I agree that there's no pressing need for this, but is a pressing need really the only reason we can use to make a change? Isn't just being a good idea/the right thing to do enough? (Assuming for the sake of argument that you think it is either of those things, of course.) Writ Keeper (t + c) 14:48, 2 April 2013 (UTC)
  • Oppose per Jake, Scotty, etc. - a solution in search of a problem. As has been said numerous times here, if we are going to trust someone to speedily delete pages with (let's be honest) almost no oversight, that person should have a solid, foundational understanding of what articles should and shouldn't be. Anyone who should be an admin should know whether or not they should create a given page, so the issue is one of bad admins not good admins who create bad pages. If a sysop creates bad pages s/he should stop being a sysop because s/he clearly doesn't understand policy. The autopatrolled right is usually given out at around 50 pages created, but that can be done on discretion if the user is clearly clueful. Sysops should be the ultimate in cluefulness. ~ Amory (u • t • c) 02:31, 3 April 2013 (UTC)
  • Support On some projects, where virtually all administrative tasks are related to the core mission, this bundling makes sense. However, as the largest project, we require significant manpower in various matters only tangentially related to building an encyclopedia. Clearly this dichotomy has been the cause of substantial conflict over time, but in my opinion it boils down to this: We will always have technical or "gnomeish" or what-have-you things that need to be dealt with, and some of these will require administrative access; and we will always, of course, have an encyclopedia to build. I think that if we allow admins to remove autopatrolled from their accounts at their own discretion, we'll take a small but important step toward peaceful coexistence between our content creators and our non-content-creators (/me waves to camera). We'll have a little less "hasn't written an FA" votes at RFA, and maybe, eventually, less of a BIGDEAL complex surrounding admins, which I think is one of the greatest contributors to our somewhat toxiv editing environment. — PinkAmpers&(Je vous invite à me parler) 07:47, 4 April 2013 (UTC)
I believe admins already have the option to remove their own AP status, leastways Writ's tests seems to show that they do. Yunshui 雲‍水 08:22, 4 April 2013 (UTC)
The issue isn't whether they can remove their own, but whether it can be removed from them. Malleus Fatuorum 18:20, 6 April 2013 (UTC)
Yes, but with AP still bundled to adminship, adding or removing it to a sysop account currently has no effect (unless I seriously misunderstand the nature of user rights... in which case you're to blame, Yunshui, seeing as you gave me half of mine). Just like if you were to remove my completely redundant "autochecked" right, my edits would still be marked as reviewed through my autoconfirmed status. My reference to self-removal was because I imagine this will be the most prevalent type of removal. — PinkAmpers&(Je vous invite à me parler) 22:21, 7 April 2013 (UTC)
  • Oppose per Orlady. If an administrator cannot be trusted not to create unsuitable articles, then they cannot be trusted to be administrator. KTC (talk) 19:34, 5 April 2013 (UTC)
  • Support - I support almost any opportunity to unbundle tools form the admin toolset that will make things more efficient in this place. Long overdue. Kumioko (talk) 20:27, 5 April 2013 (UTC)
  • Support - autopatrolled has got nothing to do with admin, and there are many of us who have created very few articles. -- Boing! said Zebedee (talk) 17:46, 6 April 2013 (UTC)
  • Comment Preference would be for all articles (no matter who created them) get such a cursory once over from another User. Alanscottwalker (talk) 18:07, 6 April 2013 (UTC)
    Why create yet more busy work? Wikipedia has way too much of that already. Why is it that only administrators are trusted, even though many of them clearly ought not to be? Malleus Fatuorum 18:16, 6 April 2013 (UTC)
    Reading does not seem like busy work. Articles are meant to be read by readers, so it's good having other eyes take a look at it, and say, 'ok.' Alanscottwalker (talk) 18:45, 6 April 2013 (UTC)
    Have you ever patrolled new pages and seen how many of them are never read by patrollers? Malleus Fatuorum 19:14, 6 April 2013 (UTC)
    Yes. And assuming you are referring to unpatrolled backlog, and not what other patrollers do or not do, yes. Alanscottwalker (talk) 21:49, 6 April 2013 (UTC)
    We don't have enough patrollers to look at every new article. Hence we have the Autopatrolled right for those who create lots of articles. If we abolished the Autopatroller right and said that all new articles should be checked, then a lot more bad ones would slip through unchecked even than happens today. We would probably have even more incorrect deletion tags than we do now as the Autopatrolled flag does keep a lot of our patrollers away from the regulars. ϢereSpielChequers 19:39, 6 April 2013 (UTC)
    We don't have enough, allot of things. 'We would probably . . .' is a tad unconvincing. But fine, the autopatrolled right does not keep patrollers away and it does not prevent bad articles from slipping through. Not much of an endorsement for it, though. Alanscottwalker (talk) 19:48, 6 April 2013 (UTC)
    New page patrol is a flawed system and has been a problem area for us for years. But having prolific article creators whitelisted is one of the most sensible bits of it. Whitelisting at Newpage patrol works in a similar way to Huggle, patrollers are diverted away from the articles that are unlikely to merit deletion and towards the ones that are more likely to be problematic. We know that we don't have enough patrollers to check all new articles so even with the current system some complete rubbish will get through. But without the Autopatroller system more bad pages will get through and we will probably get more tagging errors. This particular debate is about removing Autopatroller from a number of people who don't really qualify for it. the vast majority of articles that are currently Autopatrolled would continue that way. If you really want to ditch the whole Autopatroller system then file a separate RFC for that, but unless you make a very good case for having extra attack pages and hoax articles in Mainspace I would predict snow.... ϢereSpielChequers 20:10, 6 April 2013 (UTC)
    I did not propose ditch the whole thing. But it does not follow that because there are more fine articles in the que, more bad articles would get through, the bad articles would be judged by comparison with more fine articles. Alanscottwalker (talk) 20:15, 6 April 2013 (UTC)
    Unless you find extra patrollers to patrol more articles at Special Newpages, then yes it does follow that if you put all the ones that are currently Autopatrolled back in the queue the number of bad articles that get through unchecked will increase. Remember we usually don't have enough parollers to check all the unpatrolled ones, so logically if you create extra work for them there will be more bad articles getting through unobserved. ϢereSpielChequers 20:39, 6 April 2013 (UTC)
    Well, it would be relatively simple to reshuffle the que re new users, who have never been patrolled, users who have been patrolled less the x times, and users that have been patrolled more than x-times, if it is that large of an additional burden. How many more a month? Alanscottwalker (talk) 20:48, 6 April 2013 (UTC)
    I don't know how many extra articles a month, but unlike new articles by newish editors it isn't predictable as some long established editors will go on sprees and add articles for every village in an area. More importantly as we don't have the volunteers to patrol all unpatrolled articles if we want to patrol thousands more articles then we would have to accept that a load more vandalism and spam would get through. Sorting things by number of articles created rather than by recency would be a problem as some editors take longer than others to get to the point where their articles don't need checking. There is also the problem that we prioritise deleting attack pages, and though most attack pages will be from people who have never contributed an article that has stuck, there are exceptions. So a system that put the complete newbies first would sometimes see a delay before attack pages went, and of course it would be a less effective spam filter. Using the Autopatroller flag rather than a simple metric re number of articles created allows for the fact that some editors grasp what sort of new articles we want quite quickly, and others take much longer. ϢereSpielChequers 23:22, 6 April 2013 (UTC)
    If you don't know, how is it thousands? If someone creates attack pages or spam pages, they should be at the front of the que, if they still have article creation rights at all. Such as now one can sort for blocked users. If someone creates 25-50 perfectly fine articles, they will go rogue, on the 51st?
  • Oppose The proposal is practically useless and therefore should be rejected as practically useless. Alanscottwalker (talk) 00:21, 7 April 2013 (UTC)
    I know that there are thousands of new articles created every day, that there are thousands of editors with the Autopatrolled right and that between them these editors create many thousands of new articles per year. As I explained the number of new articles created by Autopatrolled editors per day is a highly variable as some will produce whole batches of similar articles. As the number of articles by Autopatrolled editors will vary, and the number of people active at newpage patrol also fluctuates so the number of articles that under your proposal would go into mainspace without any patroller looking at them would vary day by day. On some days, days where they currently reduce the backlog, the patrollers might even be able to check everything that comes in. But with what we know about the New page patrol system it is reasonable to assume that if we follow your suggestion and scrap Autopatroller entirely, then unless you find a way to recruit lots more patrollers there will be many thousands more completely unchecked articles slipping through to mainspace.. ϢereSpielChequers 17:15, 7 April 2013 (UTC)
    Just as I noted, you have convinced that the proposal to remove autopatrol rights is practically useless or harmful in its effect. Alanscottwalker (talk) 17:24, 7 April 2013 (UTC)
  • Neutral. I don't think we should be giving people admin tools (particularly delete) if they cannot be trusted to create pages within policy. There again, I don't see any need for bundling the tool with the admin package. If this does pass then it would be courteous to notify all admins that the right has been removed, so that those of us who do create articles can apply for it. Espresso Addict (talk) 15:59, 9 April 2013 (UTC)
    If it passes, I'll be going through and regranting the permission to all current admins myself; I've already worked out a script for it. I can probably put in a talk page notification, too. Writ Keeper ⚇♔ 16:08, 9 April 2013 (UTC)
  • Oppose per others before me. Can't see what this would achieve - there is something seriously wrong if someone given the power to speedy delete articles, decide the result of PRODs/AFDs, and other such privileges can't be trusted to create appropriate articles. This has the potential to increase backlogs and waste editor's time with very few real upsides. CT Cooper · talk 13:23, 12 April 2013 (UTC)
  • Oppose per BDD, Scottywong, et al; although I'd consider it if the bit about removing it from admins is dropped. IOW, it remains something admins get unless community consensus is to remove it - not unless one admin removes it; as Malleus puts it "Unbundle autopatrolled from admin rights package", not "Remove autopatrolled from admins". Unfortunately, as now proposed, it is the latter as well as the former. This will cause more problems than the theoretical rare problem it might conceivably solve. One puppy's opinion. KillerChihuahua 17:34, 12 April 2013 (UTC)
  • Oppose They who cannot be trusted not to create articles which require speedy deletion should not be trusted as admins. I doubt that there are any persistent gibberish or attack page creators among the admin corps; if there are, notify arbcom pronto. DavidLeighEllis (talk) 03:17, 15 April 2013 (UTC)
  • Comment: There's a common theme that the only purpose of autopatrolled is to avoid CSD tagging (and by extension, the only point of New Page Patrolling is CSD tagging). A) That's not really true; there are lots of other tags in the NPP interface than CSD tags. But whatever. B) If the only purpose of autopatrolled is to avoid CSD tagging, then why is the bar for granting the autopatrolled to non-admins so high? WP:AUTOPATROLLED says: " A suggested standard is the prior creation of 50 valid articles, not including redirects or disambiguation pages." (emphasis original) Is 50 articles really necessary to prove that one won't create a CSDable page? If NPP really is just CSD tagging, then we definitely need to revise the expectations for autopatrolled downward. Writ Keeper ⚇♔ 15:19, 15 April 2013 (UTC)
    Admins have a natural propensity to try and keep all user rights to themselves and to deny them to non-administrators, so of course it has to be difficult for a non-admin to gain any user right. Simple really. Malleus Fatuorum 16:08, 15 April 2013 (UTC)
    The standard used to be higher. It was lowered without the sky falling, and it could probably be lowered again. However, there's a certain amount of overhead involved in reviewing and granting the right, so that has to be balanced against the NPPers' time saving. If you're only likely to create one new article a month, and if it takes only ten minutes to review your contributions to see whether you qualify, then we've actually lost time overall: six minutes (or less) saved for NPPers this year versus ten minutes to decide whether to save those six minutes. Additionally, the fact that NPPers can add more tags doesn't mean that spamming tags into new articles is either a good idea (some NPPers' frequent creation of edit conflicts over trivial tags is one of the most common complaints from frustrated new users) or a necessary component. WhatamIdoing (talk) 16:17, 15 April 2013 (UTC)
    I didn't mean that things like the notability tags are necessary, just that it is a thing aside from CSD that NPP does; CSD is not NPP's only function. Certainly I personally don't use the non-deletion tags much through NPP. Strictly speaking, though, I do put things up for PROD and AfD not infrequently, so that's an example of non-CSD NPP activity.
    I see where you're coming from with the overhead argument, but I don't really buy it. It seems to me that the point of autopatrolled, as has been mentioned several times by people on both sides here, is trust, not pure efficiency. I think that, if we trust someone to make good articles, and they ask for the flag, we should give it to them regardless of their rate of article creation. I know the whole theory that rights aren't hats to be collected, but this right in particular is one that represents the community's trust in a user, since it's not as who should say a tool to be used. (Not to mention that the right never expires, so in your example, it's not six minutes saved, but as many minutes as articles the user will ever create throughout their entire Wikipedia career; also, I myself generally spend more than one minute on patrolling a page.)
    All that said, in light of this, I'm going to boldly revise the number down from 50 to 5. If 5 articles is enough for a user to pass the content-creation side of RfA (and I passed my RfA with exactly two articles to my name, so...), then it should be enough for a user to get autopatrolled. BRD as necessary, of course; since it's worded as a suggestion, not a hard and fast rule, I don't feel that it's necessary to go through another RfC beforehand to bring the suggestion in line with what appears to be people's expectations, but I am, of course, open to being reverted and discussing if people disagree. Writ Keeper ⚇♔ 16:37, 15 April 2013 (UTC)
  • Oppose Being an administrator doesn't confer some kind of capability to develop decent articles. Point given. However, being capable of developing a halfway decent speedy-deletion avoidable, non WP:BLP infringing, third party sourced, neutral article should be a prerequisite to an RFA. I can only think of one RFA where content contributions were completely ignored because the user needed to tools to do template maintenance. I'm also not going to support a proposal that was suggested during a user's anti-administrator axe grinding whether or not another user started the proposal in good faith.--v/r - TP 19:00, 15 April 2013 (UTC)
    That seems to be a rather typical view among administrators: "I don't like you and I therefore intend to oppose you every chance I get, no matter what you say." Shame really. Malleus Fatuorum 19:06, 15 April 2013 (UTC)
    Yes, I do believe that was exactly the attitude you had on the AN thread that led us here.--v/r - TP 19:27, 15 April 2013 (UTC)
  • I think you need to wake up kiddo. When Writ Keeper asked me about this proposal I advised against it, as I was absolutely certain that clowns such as yourself would oppose it for whatever reason first came into their heads. Had I thought otherwise I would have proposed it myself. Malleus Fatuorum 19:32, 15 April 2013 (UTC)
  • @that last sentence: really, TParis? Really? You know, all these insinuations that I'm merely a puppet dancing on Malleus's strings--wittingly or otherwise--kinda piss me off, and I find it very difficult to read things like that any other way, even if that's somehow not what you meant. I am not a number, I am a free man; I don't run on clockwork. Writ Keeper ⚇♔ 19:08, 15 April 2013 (UTC)
    (edit conflict) I didn't even hint at that idea and I don't know where you got it (having not read all the previous comments I assume someone else said it) but I very clearly said you did it in good faith (not even a subsequent edit suggesting I changed the wording after the fact). The point I'm making is that the idea came up by someone else who was critical of the idea for criteria for removing the tool from non-sysops that I had put forward in the original AN thread. The idea that you, or even that your a Malleus puppet which has never occurred to me (nor have I seen it elsewhere, so it's not such a wide-spread opinion as you seem to think), is not even part of the equation. I'd think you'd know I had a higher opinion of you than that. And although I dislike the guy, I have a higher opinion of Malleus than to think he needs puppets to do whatever it is he wants.--v/r - TP 19:27, 15 April 2013 (UTC)
    Then why did you bring it up? What possible other purpose could that statement serve? At its absolute most generous, assuming you didn't intend anything about my motivations, that sentence says to me: "Well, I'm not going to give your proposal full consideration, because it happens to be shared by someone I don't approve of." I don't think that's cool. I think that's a terrible attitude. So terrible that I doubt it's the opinion you actually hold. But I can't see any better way to interpret it. I saw that you said "in good faith", and I did appreciate that, but all that little disclaimer says to me is "he was unwittingly duped, rather than being a willing accomplice", and--surprise--I still take offense at that suggestion.
    Never turn away an idea solely because of its source. Ever. That is an ugly, ugly road to go down, one that leads to utter stagnation and decay. If you disagree with the proposal on its own merits, then that's completely fine. God knows you won't be alone there, and nor should you be; reasoned opposition is the fundamental building block of dispute resolution, and by extension, civilization. But let your opposition stand on its own merits in turn; don't bring ugly partisan politics into it.
    As an aside, I don't share Malleus's disdain for either people associated with the military or for administrators; in either case, I would then be hating myself. But it would be a lie to say that I don't see how he got there, or that either is unfounded. Writ Keeper ⚇♔ 19:56, 15 April 2013 (UTC)
    I have no idea if or why Malleus does or would have disdain for the military and it doesn't matter. I don't put it on my userpage as some kind of status symbol, I put it there because it's who I am. He's welcome to dislike me just as I enjoy the freedom to dislike him. Anyway, I'm not turning the idea away because of it's source, my first several sentences spelled out the reason. But the source isn't completely abstract from the idea either. You should read my last sentence as "Despite that I think Writ is a smart and competent guy who I have respect for and he genuinely likes the idea on it's merits, I feel like the original idea only came up from another user because of a distaste for administrators rather than actual concern." But if that still doesn't satisfy you, then I'll offer to buy you a drink if we ever meet at a Wikimania or something.--v/r - TP 20:02, 15 April 2013 (UTC)
    Okay. I might take you up on that drink offer, but thanks for explaining. Writ Keeper ⚇♔ 20:13, 15 April 2013 (UTC)
    Be assured that the dislike is mutual Staff Sergeant. Malleus Fatuorum 19:43, 15 April 2013 (UTC)
    Good? I don't know how to respond to that.--v/r - TP 19:47, 15 April 2013 (UTC)
    TParis is an annointed member of the body, so any fault must clearly lie with you, not him. Malleus Fatuorum 19:18, 15 April 2013 (UTC)
    Of course, I tool the anti-Malleus sysop oath upon condition of death.--v/r - TP 19:27, 15 April 2013 (UTC)
    How do you "tool" an oath? Is that an American thing? Malleus Fatuorum 19:39, 15 April 2013 (UTC)
    The same way you has a thought. I just didn't think the edit conflicts were worth the minor change.--v/r - TP 19:47, 15 April 2013 (UTC)
    @TParis: and please look above, even some (dare I say: uninvolved) admins support the proposal. I will of course defend your right to say what you want, but I can understand Writ Keeper here. Lectonar (talk) 19:23, 15 April 2013 (UTC)
    I'm not required to share their views.--v/r - TP 19:27, 15 April 2013 (UTC)
    (ECx2)I agree with Malleus and Lectonar, And for the record, neither Malleus nor Writ keeper are alone in their feelings that there is a growing rift between admins and editors here in Wikipedia. My own own problems with many of the admins and their attitudes and actions are often lamented facts of Wiki lore and we are only three voices. There are a lot more who prefer to stay quite and not comment because they fear being blocked or banned. Whether this RFC has merit is beside the point. Many admins, most even, will fight tooth and nail to ensure that the power they have doesn't get limited by others. The whole we can't trust you so you can't have the tools is utter nonsense and only proves that we need to debundle the toolset completely. Its even more insulting when admins are allowed to do and act however they want once they get the tools without any fear of the tools being removed. Virtually the only way for an admin to be demoted is for a Major arbcom case or if they just stop editing. Many admins don't even create articles and many of those that do aren't very good at it. This is a very valid RFC and if it means that some admins actions need to be reviewed then the community needs to review if they should be an admin. Maybe this will help facilitate getting rid of some of the dead weight and shabby admins. Kumioko (talk) 19:25, 15 April 2013 (UTC)
  • (edit conflict)*3 Oppose Very confused about what benefit this is supposed to bring to the community. If it's the fact that a editor hasn't shown consistently good choices in creating content/articles, they're not going to pass RfAdmin plain and simple. It's been my understanding that we want Admins to be well rounded editors that have worked in multiple different portions of the encyclopedia regardless of their desire to work in a specific area. Autopatrolled is already attainable through RfPerm for regular editors who frequently create articles that know what they are doing and consistently follow the best practices (Rules/Guidelines/MoS/etc.) so I'm slightly confused as to what benefit we get out of unbundling a permission that makes sense to still be bundled (and would expect that the user would already have prior to RfAdmin). Hasteur (talk) 19:27, 15 April 2013 (UTC)
    That's clearly untrue, as content creation is widely disregarded as a criterion at RfA. Malleus Fatuorum 20:00, 15 April 2013 (UTC)
    I don't believe that the community chooses admins who have a long history of creating inappropriate content, e.g., CSD-able articles. Content creation is not disregarded: we reject candidates who create policy-violating content. Content creation is only disregarded when the content is neutral, good, or nonexistent. WhatamIdoing (talk) 20:12, 15 April 2013 (UTC)
    Certainly true and I really don't think anyone debates that. However there have been a number of exceptions over the years wouldn't you agree? All this allows is that the right be separated to allow that it can be removed if necessary. It certainly much easier to remove that, than to get a sysops tools taken away. Kumioko (talk) 23:56, 15 April 2013 (UTC)
  • Support. I agree with Orlady and others that admins should know how to write a decent article, but there is nothing inherent in the bit (or most of the bit's parts) or the nomination process that guarantees that they can. Also, I think it's no big deal, and unbundling makes the status of sysop a bit more unassailable: appearances matter. Drmies (talk) 19:49, 15 April 2013 (UTC)
  • Support. While all admins theoretically should be able to create articles that the NPP folks don't need to worry about, it's not actually a requirement of the RfA process. --SarekOfVulcan (talk) 22:05, 20 April 2013 (UTC)
  • Comment as one who has written loads of stuff off wiki, and who has proof read loads of other people's stuff, I'm always be happy to have something of mine checked. I'm not against the separation of the autopatrolled right from the admin package (count me in with the voluntary abjurers) but when I get round to filling out my latest article (a rare thing, that for me, and I'm not afraid to say so), and whichever way this goes, I will ask someone I trust to go through it before launching it. It's much easier to find the bloops in someone else's work than in your own. You know what you meant to say, and you tend to read what you meant rather than what you wrote. Peridon (talk) 18:43, 23 April 2013 (UTC)
  • Support. Unlike Delete and Block, this does not seem logically, inherently integral to adminship. Sure, it should correlate, but patrolling is an ordinary editor's action. --SmokeyJoe (talk) 13:48, 25 April 2013 (UTC)
  • Oppose I don't see anything that would be solved by this. And per the NPP I can see there actually being issues caused by it. Thus the balance of pros vs cons points me towards an oppose. Admins should already have a firm grasp of what is speedy deleteable since they have the ability to delete speedies. -DJSasso (talk) 14:40, 25 April 2013 (UTC)
  • Support. Grumble. I don't know what the requirement for auto-patrolled should be, so I would neither issue the flag nor wish to take advantage of it. There are times when I would remove some obvious errors from a new article, but not make an effort to remove all of them, so I wouldn't want the flag. — Arthur Rubin (talk) 23:27, 1 May 2013 (UTC)
    Autopatrolled has exactly one effect, and it only applies to the creator, not to subsequent editors. So the example you give is completely irrelevant. The one effect is this: Should the article you created (NB: not "edited") be highlighted as something that desperately needs to be checked for probable speedy deletion as a hoax, serious BLP violation, etc, or not? It's actually easier to understand if you look at Special:NewPages: if you create a new page, should it be highlighted in yellow for urgent review, or is it good enough just to have it listed as one of the many new pages? If you never create a new page, then it doesn't matter whether you have the right or not. All the right does is tick the box that makes yours listed as a new page not requiring urgent review. The people who do those reviews would like to believe that admins don't create hoaxes and attack pages. I hope that you are able to confidently say that they needn't concern themselves overly much with any pages you created, and that they could instead focus on non-admins. WhatamIdoing (talk) 05:34, 3 May 2013 (UTC)
  • Strong Oppose: User:WhatamIdoing made a huge point here and almost everyone seems to have ignored it. I read the policy on marking new pages as patrolled and realised that new pages that are not speedily deletable indeed should be marked as "patrolled". As long as an article has appropriate tags for them, other issues (unless they're really serious) do not matter when it comes to marking new articles as "patrolled". Now I'm more than sure that an admin can not be expected to create pages with issues without appropriately tagging the pages for them. It's as simple as that. I don't know why some admins are supporting this; they don't seem to understand what patrolling is actually used for. I mean, can't you admins tag pages you create if they have issues? That's the only reason new pages are marked as "patrolled". smtchahal(talk) 15:52, 8 May 2013 (UTC)
  • Strong Oppose: Simply because one of my main criteria when !voting at RfA is to establish whether or not a candidate who is going to be expected to delete new articles or close AfD etc, should at least know how to create articles that demonstrate good knowledge of policy and what makes a reasonable (if not GA or FA) article that does not need to be tagged for anything. Adminship competency is a broad requirement (yeah, I know, too broad for the ant-adminship crusaders, and those who will never get the bit) which encompasses that knowledge, after all, Wikipedia is a content project and not onepeople should join because they want to be 'moderators' on one of the world's largest websites - all editors alread y have more powers here than they would get as regulars contributors to their local football forum. Some people, especially WhatAmIdoing, appear to have fully misunderstood the aims and purposes of of NPP - at least from my point of view as one of the editors, along with WereSpielChequers and Scottywong, et al, who researched, campaigned, and called loudly for years for its improvement. This RfC is a solution looking for a problem. What we need is more direct information aimed that those new editors/page creators before they start to make an article but these suggestions either fall on deaf ears or are neatly sidetracked by the stats-obsessed Foundation who at the end of the day appear to care only for increased figures for creations and new editors and not for quality control. Kudpung กุดผึ้ง (talk) 05:38, 12 May 2013 (UTC)

Idea?

Instead of unbundling the right, what if there were an option sysops could check/uncheck when starting a page that would leave that page unpatrolled, somewhat akin the redirect when pagemoving option? That would leave it up to the individual admin, which may seem counter-intuitive, but I think serves everyone's concerns:

  • Admins who would have or should have had autopatrolled outright will not add to the NPP backlog (true of this, the proposal, or no change).
  • Good admins with good intent but not-so-strong creation history can have articles patrolled by someone else if they ever create something.
  • Admins misusing/abusing the right, which is the concern the initial proposal sought to fix, will be able to be held far more accountable; it should be a lot easier to prove poor understanding of policies or even malintent.

What say you all? ~ Amory (u • t • c) 22:36, 6 April 2013 (UTC)

It certainly doesn't address my concern. Malleus Fatuorum 22:45, 6 April 2013 (UTC)
Admins are already able to create alt accounts and use those when we create articles. But that doesn't really address the issue of admins getting this right via RFA despite RFA rarely if ever paying attention to whether the editor is ready for the Autopatroller flag. ϢereSpielChequers 23:04, 6 April 2013 (UTC)
A much simpler way of accomplishing this is for any admin who wishes extra eyes to post a note asking for someone else to look it over. They'll likely get much more out of that request than out of the NPPers. Look at the rate that NPPers process articles. Someone's listed at the moment as having done 28 articles in the last 11 minutes. They're looking for CSD candidates (the main job of NPP). They are not giving a lot of attention to article development. This is reality, and this is what we want from the NPPers. If you want a major review rather than a quick "is this CSDable?", then you want WP:Peer review. WhatamIdoing (talk) 00:19, 7 April 2013 (UTC)
+1. Another thing to note is that while there are some articles that never get patrolled (as the option expires after 30 days), in reality if a page isn't CSD'd within 6 hours at most (on a slow day), it almost definitely doesn't meet an applicable criterion. I'll confess that sometimes I'll find a decently written article that makes a half-ass claim to notability but is CSD-ineligible, and simply leave it for someone else (often an AWB user) to tag and clean up. — PinkAmpers&(Je vous invite à me parler) 22:29, 7 April 2013 (UTC)

The wrong question

Surely the question we should be asking is whether anyone who can't create an article that meets basic requirements should be trusted with adminship? I would have thought that the answer to that should be obvious, but many of the people in the oppose camp above are the same ones who jump on anyone at requests for adminship who opposes on the basis that the candidate has little content writing experience, so it seems that it's not so obvious to everyone, and there are certainly a few admins promoted in the last year or two who don't have such experience. Decent content creation ability should be a sine qua non of adminship. Phil Bridger (talk) 19:55, 15 April 2013 (UTC)

But it's not, hence the proposal. I'd have thought that many more administrators would have voted in favour frankly, because the only other way they could could have their autopatrolled user right revoked would be a desysop. Their choice of course. Malleus Fatuorum 20:04, 15 April 2013 (UTC)
As I alluded in a comment above, I don't think it's so much whether admins should or shouldn't have basic article creation ability. Rather, it's more a question of: "how much content creation ability does the "autopatrolled" right actually require?" Many people seem to be saying that it requires no more than a very basic level, and yet the suggested bar for non-admins to receive the right, at the time I made this proposal, was 50 articles created. I think that requirement suggests a significantly more advanced level of experience/skill with article creation, and that disparity is much of the problem. (The rest of the problem, and the major bit as far as I'm concerned, is the dissonance of including a right so unrelated to admin work in the admin package, but I can appreciate that that doesn't bother everyone as much as it bothers me.) Now, as I also say above, I've since changed that (suggested) requirement to 5 articles created, to bring it more into line with the minimum amount of content creation that people seem to expect from an admin (though some, like myself, passed RfA with even less than that; I had 2 DYKs as the sum total of my content creation at the time of my RfA). So that relieves a part of the need for this proposal, if it sticks (it didn't). Writ Keeper ⚇♔ 20:08, 15 April 2013 (UTC)
I don't think five articles gives the reviewing admin enough material to work on to be sure that the editor understands relevant policies (particularly towards BLPs). Five impeccably sourced GA-quality articles including bios of controversial living people, sure, but usually we're talking stubs & starts on non-controversial topics. I agree 50 is overkill though -- I've just tried editing the guidelines down to 30; we shall see how long that sticks. Espresso Addict (talk) 21:23, 16 April 2013 (UTC)
I don't feel like reverting you too, so did you read my comment on WK's talkpage? I think there's enough disagreement here that it would be reasonable to start an RfC on the correct threshold for autopatrolled once this is done with, but I think it's safe to say that we're at the D part of BRD. ~ Amory (u • t • c) 21:55, 16 April 2013 (UTC)
Sorry, didn't see that discussion (I did check the guideline's talk page). Some form of centralised discussion would indeed seem appropriate, given the different opinions being offered as to the appropriate threshold. Espresso Addict (talk) 22:55, 16 April 2013 (UTC)
One reason for not wholeheartedly supporting this proposal is that I fear it will result in even less agreement among RfA participants that admins should have a reasonable history of content creation. Espresso Addict (talk) 21:09, 16 April 2013 (UTC)
I simultaneously oppose this proposal and do not believe that significant content creation is required for RfA. To me, the key point is that an admin ought to know how to create a decent article and be able to evaluate the quality of articles; whether they actually create a lot of articles is not important. If you can't write a proper article, then I won't trust you to pass judgment on others' articles. It's the ability that counts, not the number. -- King of ♥ ♦ ♣ ♠ 10:09, 17 April 2013 (UTC)
As I said somewhere in a long conversation above, administrators ought to have a basic understanding of our content policies. That's a long way away from our standards at RfA. If you haven't written a GA and don't spend most of your time writing content, someone's probably going to oppose your RfA for lack of content creation experience. Even if you have written a GA you still might get opposed for lack of content creation experience. These standards are, in my view, wildly excessive and completely disconnected from the kind of work that the vast majority of administrators do. On the other hand, the barrier for getting an article past NP patrol is very low. So long as it doesn't qualify for speedy deletion, cites some decent-looking sources, and doesn't have any obvious formatting problems an article will be waved through. This is much, much closer to the "basic understanding of our content policies" criterion than the standards used at RfA. Hut 8.5 18:06, 17 April 2013 (UTC)

Acknowledgement required messages - a proposed new capability for admins

"I didn't see that message" is a common response to an inquiry as to why an editor did or didn't do something requested in a message left at that editor's User Talk page. Sometimes the response is in good faith, sometimes not. It's especially difficult and frustrating to deal with an editor who habitually ignores User Talk messages and keeps on doing whatever it is that appears disruptive. Often the only thing that can be done is to bring it to the attention of admins (probably at WP:ANI) and the only tool admins have in this situation is a block, with a requirement for that editor to be unblocked to acknowledge the message.

Some editors state that the big orange "You have new messages" bar isn't visible enough in the first place, and with the latest changes coming with Echo (the new notifications system) the orange bar itself might be going away (it's already gone as of the writing of this proposal).

This proposal intends to provide admins with a new tool to require the attention of an uncommunicative editor before that editor may resume editing, and would not require a block:

  • Add a new technical capability for admins to leave "Acknowledgement required" messages.
  • The editor would not be able to proceed with any editing capabilities without being shown the message and clicking on "I acknowledge receipt of this message". There may be an explanatory note stating that it is not necessary that the editor agree with the content of the message, just that it was acknowledged as received.
  • There will be a user log record for the editor of having done so when acknowledged. This audit trail would increase accountability, would increase the likelihood that the editor would actually change their behavior, and would be useful in providing a history in support of further remedial action if not.

Note - although this proposal was prompted by a discussion over Echo's removal of the orange bar, it is not dependent on it: if the orange bar comes back, this proposal still stands.

Input appreciated... Zad68 15:32, 1 May 2013 (UTC)

  • Support There have been times when I've been forced to block an uncommunicative user just to get their attention, which is a bit fly/sledgehammerish. I think there will have to be some form of guidance on when and how to use it (it could be abused fairly easily), but there are situations where it would be valuable. Acroterion (talk) 15:43, 1 May 2013 (UTC)
  • Support Removes plausible deniability about warnings etc. Gaijin42 (talk) 15:44, 1 May 2013 (UTC)
  • Good idea, with the caveat that any prevention of editing due to a new "acknowledgement required" message should ensure that the user doesn't lose what they were working on. Probably in practice this would be similar to what happens now when a page becomes protected whilst someone is trying to edit it (which I've never seen but assume is handled sanely...). The problem though would be implementation - probably it would end up being something to do with Blocking, but with special blocks, logged separately, where the user can unblock themselves after being shown the message. Rd232 talk 15:46, 1 May 2013 (UTC)
    • Problem: as with the #.22You_have_new_messages.22_alert_for_not_registered_visitors_to_expire_after_30_days issue, such messages directed at IPs might require someone other than the intended recipient to acknowledge receipt. Rd232 talk 15:54, 1 May 2013 (UTC)
      • ...yet still an improvement over how the same situation would have to be handled today. Right now, if you have diruptive editor "D" using dynamic IP 1.2.3.4 to make problematic changes that aren't quite vandalism to article X, an admin would have to block that IP for a certain amount of time. If during that time of being blocked, IP 1.2.3.4 gets reassigned to potentially productive editor "P", that new editor is stuck and can't edit.

        With acknowledgement required messages ("ARM") in place, edits through that IP can be initially stopped without a block. If editor D is still at that IP, D is required to acknowledge receipt of the message, and if D continues at it, the IP can be blocked with good justification. If D goes away and the dynamic IP gets reassigned to P, editor P at least has the opportunity to acknowledge the (irrelevant) ARM, and then can go to productive editing on article Y. We can put a note in with messages for IPs like "If this message doesn't seem relevant to you, please disregard" or an explanation along the lines of what we have in {{Anonblock}} or {{Mobile IP}}. The bottom line is if a strongly-worded ARM* is acknowledged and yet the bad behavior continues, then a block would be justified.

        *I can already see the shortcut WP:STRONGARM being created to point the documentation for this new feature, and used in conversation like, "That editor won't stop making those changes without consensus, and won't respond to requests to stop and discuss it? Better WP:STRONGARM that editor into getting the message..." Zad68 17:28, 1 May 2013 (UTC)

      • Adding: Rd232, if as you suggested the implementation is done with special blocks, that would actually tie in nicely with this feature: The ARMs could be "indef", meaning there is no expiration on the amount of time editing is disabled until the message is acknowledged, or they could be given expiration times. Zad68 17:58, 1 May 2013 (UTC)
  • Support - This is a great idea. Mlpearc (powwow) 15:47, 1 May 2013 (UTC)
  • Support Great idea; can't see any substantial drawbacks. Nyttend (talk) 17:27, 1 May 2013 (UTC)
  • comment: Wikipedia:Notifications was just added. --  Gadget850 talk 17:38, 1 May 2013 (UTC)
  • Strong support, in fact I urged Zad to take it here, when he floated the idea in passing in the Echo discussion on AN. My thinking is that it probably wouldn't be used very often, but would be extremely helpful for instance in cases of not-listening edit-warring SPAs (who are not necessarily always IPs); very good for everybody involved, as the editor may never have found their talkpage, and be blissfully unaware that edit warring and name-calling are offenses — until they're blocked for them. Why don't we already have this very convenient feature? I hope it's technically feasible. Bishonen | talk 19:32, 1 May 2013 (UTC).
  • Support. Thinking out loud here, the only possibility of any abuse would be an admin (or group of admins) constantly re-messaging the user as soon as they confirm receipt, which wouldn't be any different from the possibility of abuse via an indef, no-talk block (except harder to accomplish). Ignatzmice•talk 21:38, 1 May 2013 (UTC)
  • Support as yet another great idea. Theopolisme (talk) 22:22, 1 May 2013 (UTC)
  • Seems pointless to oppose this the way it's going. Plus, several people above me are almost always right about things, and I'm surprised to disagree with so many of them. And I seriously doubt it is easy, technically, anyway, so it will probably never happen. But... I really don't like this idea. It makes my skin crawl. It's going to start out with the best of intentions and "limited use", but I guarantee it is going to quickly degenerate into "all admin communication must always be acknowledged by the peons". Either that, or a 15-page manual for when it is appropriate to use, and a separate log, and arguments about whether it was appropriate or not, and lost edits when they try to save a page with a pending "respect mah authoritah" message... same old same old, but with another layer on top. If you give someone a final warning, and they ignore it, block them. If they claim not to have seen the final warning in an unblock request, then unblock, and it worked. I've blocked several editors before for not responding to talk page messages, and almost always that was all that was needed to get them to realize the error of their ways and start responding. This would theoretically solve an actual small problem, but at a big risk of creating a bigger one. --Floquenbeam (talk) 22:40, 1 May 2013 (UTC)
    • But you speak lightly of blocks there, Floq. "I've blocked several editors … and almost always that was all that was needed to get them to realize the error of their ways." — All? I think it's important to avoid any blocks that can be avoided. Blocks hurt. A block log is not a good start here. Go see the headmaster. P.S. But I do see the problem. We should perhaps have a trial period, with complementary coming-down like a ton of bricks on any admins that overuse the feature. Bishonen | talk 23:01, 1 May 2013 (UTC).
      • A block should be expected if lots of messages are being ignored. My position is complicated by this new notification thing - in the old days you couldn't plausibly claim that you didn't know you had messages - but I expect they'll fix that. if I had some assurance that this would only be used in lieu of a block, I'd support it. But it won't, it will be used more and more by admins to make mere mortals acknowledge that they've been put in their place. I can feel the truth of this in my bones, although I obviously can't prove it. --Floquenbeam (talk) 23:50, 1 May 2013 (UTC)
        • acknowledge that they've been put in their place - you make it sound like recipients would need to write out in their own words what they think the message means and how it applies to their behaviour, and then have that acknowledgement approved by the admin before they're unblocked. Ironically, that's a closer description of the status quo than the proposal! The proposal would see messages "acknowledged" by merely clicking a button (something like "yes, I've read this", presumably). Rd232 talk 23:59, 1 May 2013 (UTC)
    • "all admin communication must always be acknowledged by the peons". - language aside, let's look at that worst case scenario. Let's say, to make it practical, that every standard warning message issued by an admin needs an "I read this" click action, without which the user can't edit. Is that really so terrible? As long as "you can't save because you need to read this message" actions are handled well, I don't think it would. Remember this is far into the future in terms of ever happening - years. So it would be part of the new Echo notification system, which means you can imagine a flyout over your Save Page form, "read this message, then click OK, then you can Save". Having said all that, if Floquenbeam's concerns are widely shared, then much the same could be achieved by allowing admins to send those intrusive "you should read this" flyouts, without any logging or blocking of Save. Rd232 talk 23:17, 1 May 2013 (UTC)
      • Yes, I think it would be a horrible thing if all admin messages had to be acknowledged by mere mortals. Admins already have heads that are way too big. I assume you wouldn't support everyone having this ability, just admins. --Floquenbeam (talk) 23:50, 1 May 2013 (UTC)
        • When the acknowledgement is really easy, I don't see why it's that terrible that we shouldn't even introduce the feature in case that's how the community ends up using it (which is what you seem to be saying). As for admin-only: probably (for simplicity), though in principle it could be extended to other sufficiently trusted users, perhaps as a new (and therefore revokable) user-right. Rd232 talk 23:55, 1 May 2013 (UTC)
    • Floquenbeam, keep in mind that any admin tool could be abused, so that criticism would apply equally to blocks or deleting pages. We trust the community to give the tools to those who can be trusted to use them responsibly, right? In the case where this tool is used, you're probably avoiding handing out a block. And given what this tool will most likely be used for, whatever edit was in progress and failed when the tool is enabled was probably one of the troublesome edits that caused this tool to be used in the first place. Zad68 23:39, 1 May 2013 (UTC)
      • Yes, but abusing this tool would be so much easier, and so much easier to brush off as harmless. If I want to do something to piss off an IP editor, and so I block them for no reason, I'll be given a good thrashing at ANI. If I leave a message that requires them to ackowledge it, I can put on my puppy dog face and say "well geez, it was just a message." --Floquenbeam (talk) 23:50, 1 May 2013 (UTC)
        • So make it applicable only to standard warning notices. You can already abuse those (with admin heft behind you), and having to click "yes I've read this" doesn't really change that. Rd232 talk 00:01, 2 May 2013 (UTC)
  • Cautious Support In general, I think this is a great idea. However, it hasn't taken long to point out some potential pitfalls. IPs are an issue. Rd232 points out a concern about edits in progress. So whatever it done should be trailed and tested before fully implemented, but worth pursuing.SPhilbrick(Talk) 22:41, 1 May 2013 (UTC)
  • Neutral leaning oppose Floq's concerns scare the heck out of me. In addition, I imagine this being thrown around a lot more blocks to get peoples' attention. The big problem with this is the conflict that will occur when editors receive an acknowledgement required while they are in the middle of a large edit. Ryan Vesey 22:46, 1 May 2013 (UTC)
  • Support - Brilliant idea! →Davey2010→→Talk to me!→ 23:07, 1 May 2013 (UTC)
  • Support - Though I'd also say that Admins need to be able to force previously dropped notices by users (i.e. DS or GS notices) to be acknowledged, but that's just me Hasteur (talk) 23:52, 1 May 2013 (UTC)
  • Cautious support - I think this is a good idea for dealing with vandalism and other problems, but I'm worried of the possibility of overuse. There should definitely be a policy governing its use. Also, it should be possible to set expiry times on the message, for example when giving it to IPs. Actually, given this proposal I think the "You have new messages" expiry proposal given above is no longer necessary. Admins should use discretion for the expiry time, defaulting to something like 24 hours but varying it based on how dynamic the IP is and past history of disruption. The expiry should almost never exceed 30 days, just like it is technically possible to block an IP indefinitely but it is highly frowned upon. It should also be possible for an admin to remove an acknowledgement requirement from a user. -- King of ♥ ♦ ♣ ♠ 00:03, 2 May 2013 (UTC)
  • Conditional support—this proposition has merit. However, I agree with Floq about the potential for abuse. I would be in favor of such a right only if it could be given in conjunction with a level 4 uw, and made automatic. I think that would remove the danger for undue pestilence, as it would only be used in situations that would call for it, while keeping in the spirit of the proposal, for increasing user accountability and avoiding unnecessary blocks/unblocks. Deadbeef 00:12, 2 May 2013 (UTC)
  • Oppose. Here's what's gonna happen: a) "I don't have to give a shit about any message unless it's from an admin." b) "Why did you block so-and-so without leaving an ARM first?" Choyoołʼįįhí:Seb az86556 > haneʼ 00:18, 2 May 2013 (UTC)
  • Support - a brilliant idea, can't believe nobody thought of it before. GiantSnowman 09:59, 2 May 2013 (UTC)
    Support - This will prevent a lot of blocks, for a variety of reasons. Sounds like Registered mail for admin, and yes, a brilliant idea as it will help to start discussions, particularly with new editors who may be unknowingly coloring outside the lines. I disagree with Seb, although his concern has merit with editors with pre-existing behavior issues. This would mainly be good for newish editors. As for Floq, good points but we admin must police each other's use and have clear rules for its use. Dennis Brown - 2¢ © Join WER 11:16, 2 May 2013 (UTC)
      • "Admins policing each other" is great in theory, but in practice it simply doesn't happen here. You know that. In one day it has already morphed into a suggestion by at least one admin that it be used for all warning templates issued by admins, which means admins will be even more inclined to communicate via template than via human-speak. That's after one day; I can see where this is headed. Can't you? --Floquenbeam (talk) 12:49, 2 May 2013 (UTC)
        • Floq, after I saw the last few diffs here I'm getting a better understanding of why you might be making the comments you're making... sorry to see the bloom's really come off the rose for you... Zad68 13:31, 2 May 2013 (UTC)
      • (*I dunno Floq, you make a good point that many might take the easy way out, even if I would like to think they wouldn't. I seldom use templates myself excepting very mundane things like CSD, AFD, but I'm probably in the minority. I have to admit I would like the ability to get a confirmation and would use the code buried in my own handwritten notes, but not everyone like to hand write those kinds of notifications I've found, so it might end up making it even less personal. I dunno. Withdrawing my !vote for now. Dennis Brown - 2¢ © Join WER 03:02, 3 May 2013 (UTC)
  • Oppose after discussion above and thinking about it longer. It would be handy, but it would also be very easy to misuse. Dennis Brown - 2¢ © Join WER 20:59, 4 May 2013 (UTC)
  • Weak oppose There is already a feeling of "us" and "them" around concerning "mere" users" and admins, and this will only widen this perceived gap, in the long run. Lectonar (talk) 12:59, 2 May 2013 (UTC)
  • Comment This discussion is really interesting... It's like someone offered, "Here are some sticks!" and the responses are ranging from "Great, we can use them to knock apples down from trees and burn them in fires to keep warm," to "Terrible, all that's going to happen is we're going to use them to beat each other up." Both could be true, but I'm not sure it's the fault of the sticks... Zad68 13:05, 2 May 2013 (UTC)
    (edit conflict) No, it never is...the problem is the, let us say ingenuity, of some people to come up with fabulous new uses for seemingly harmless things (be they sticks, or a new tool to used to drive someone up the wall in the most inconvenient moment.....by forcing him to acknowledge to have read a message, by an admin to boot). Lectonar (talk) 13:16, 2 May 2013 (UTC)
    Nicely put. Rd232 talk 13:54, 2 May 2013 (UTC)
    I disagree; like nearly all Internet analogies, this one doesn't even begin to address the nuances of the issue. It doesn't address the fact that the sticks can only be held by some people, and that the sticks also have the magic power of preventing others from doing work, etc., etc. I think there's a reason why we don't see a lot of analogies in policy discussions here. Regards, Orange Suede Sofa (talk) 16:10, 2 May 2013 (UTC)
    Analogies often turn out to have pitfalls, yes. But... the sticks can be held by anyone in principle; that we don't want to hand them out to everyone is a reasonable choice, but not intrinsic to the stick. And the sticks don't have the power of preventing other from doing work exactly, only to cause a slight delay. Rd232 talk 16:31, 2 May 2013 (UTC)
  • Strong Oppose per WP:BURO. It's another waste of time, and it's easy to abuse (think Wall of Text). It's nobody's business if and when I read messages. If someone systematically ignores important messages for whatever reason, they can already be dealt with under WP:COMPETENCE, not to mention WP:IAR. --Stephan Schulz (talk) 13:14, 2 May 2013 (UTC)
    • It's not necessarily easy to abuse - at this point both the capabilities of the putative system and the policy for when and how to use the tool are completely unknown. As to "waste of time" - I don't think most people regularly dealing with IPs and new users would think so. However that's probably a fair description of this discussion; we might as well file a bug now, put it on WP:MediaWiki enhancement requests (re-examine status in 2020) and get back to other things for another 7 years. Rd232 talk 13:54, 2 May 2013 (UTC)
  • Oppose. I find Seb az86556's argument extremely compelling. In particular, I'm concerned that this would lead to a perception that ordinary talk page messages (including all messages sent by non-administrators) are insignificant and may be ignored without consequence.
    As a possible alternative, perhaps it would be feasible to create a feature enabling admins to tag an existing talk page section (written by anyone) in this manner. Hopefully, that would convey "you need to acknowledge this message from the community" instead of "here's a special message from an administrator". —David Levy 15:08, 2 May 2013 (UTC)
  • Oppose. I sympathize with the idea that we want to reduce the number of blocks, but it's not clear to me that this proposal will actually achieve that goal without introducing additional drama and confusion. The only thing a button click indicates is that a button has been clicked. It does not show that the editor has understood or even actually read the message; research in software interaction design has demonstrated that quite amply ([8], [9], just to get started). The only way we can be sure that an editor has gotten the point (or not) is to examine their actual behavior on-wiki. Regards, Orange Suede Sofa (talk) 15:57, 2 May 2013 (UTC)
    That's a good point, but even if we don't know if the editor has understood or read the message, we at least know that they've been confronted with the fact that there is one. Rd232 talk 16:31, 2 May 2013 (UTC)
    I guess what I don't understand then is how that is helpful in making a block/no block decision. If an admin issues a user a final warning, whether that be a standard lvl4 warning or a hand-crafted one, and then the editor engages in the same action once more, then that warrants a block, right? Would knowing that the user clicked on a button change that decision? If they read it or not, they are continuing their behavior, and per the principle of "blocking is preventative", a block would be justified whether or not the user actually read and understood the message. Regards, Orange Suede Sofa (talk) 18:59, 2 May 2013 (UTC)
    The situation does arise where there's an editor making problematic edits and it's not really clear whether they're receiving the messages intended for them. With this tool, it would remove all doubt as to whether the editor saw the message, and if the behavior continues, the subsequent block would be well-justified, and better justified than the block in the situation you're describing. Take a look at the response from, for example, Acroterion, Bishonen and Dennis Brown above - they're indicating that, based on their own experiences as admins, they could see a use for this tool to possibly avoid a block just like the one you're talking about. Avoiding blocks and getting the needed behavior change are good, right? Zad68 19:09, 2 May 2013 (UTC)
    Yes, of course blocks should be avoided. And I read Bishonen's and Dennis Brown's supports. What they seem to to be saying (and hopefully they will correct me if I'm wrong) is that the benefit of this proposal is that it creates one last step before blocking where we do our level best to communicate with the editor before blocking. But then I'm seeing supports with comments like "removes plausible deniability" and I just don't see how anything that happens after the message is displayed (besides the editor's concrete on-wiki actions, of course) would have any impact on anything.
    Maybe the best way for me to put it is that I agree with the goal of block reduction, but I'm just not sure if this is the right way to do it, given the potential for additional drama and complexity. Regards, Orange Suede Sofa (talk) 19:44, 2 May 2013 (UTC)
    I understand your viewpoint... thanks for your considered response. Zad68 20:14, 2 May 2013 (UTC)
  • Comment I think it would really hamstring the usefulness of this tool to make it allowed only for template messages. The point would be to make sure that a message explaining exactly what the issue is and why it needs to stop right now could be delivered to the editor, and the template messages are a very limited palette. Zad68 19:13, 2 May 2013 (UTC)
  • Support However, in addition to adding it as an administrator privilege, it should be offered as a standalone feature, much like rollback, for users who fight vandalism and are perennially bugged by this problem. TheOneSean | Talk to me 00:05, 3 May 2013 (UTC)
  • Comment: The recent move to Facebook-style notifications rather than the "You have new messages" bar has made it even harder for newbies to notice that they have new messages, especially if they've never used Facebook. If they see a giant orange "You have new message," it's entirely unambiguous that they have a new message to read. Now it's just a tiny red number in the upper right. Vandalism, fine, blocking without them seeing a warning is tolerable, because it's bad and they know it. But 3RR? That's like arresting someone for an arcane law that no reasonable person would expect to know. We cannot block someone for 3RR unless we make every effort to make them aware of it, and at a minimum it includes displaying a prominent orange bar but ideally stops whatever they're doing and makes them acknowledge the policy. -- King of ♥ ♦ ♣ ♠ 02:32, 3 May 2013 (UTC)
    • Maybe so, but just because someone decided to get rid of the orange bar doesn't mean that from now on we can all ignore each other unless an admin tells us to do so. Choyoołʼįįhí:Seb az86556 > haneʼ 02:41, 3 May 2013 (UTC)
      • I'm not talking about established users. In my opinion this should only be used for the newest of users, just to make sure they actually realize there's a message for them. -- King of ♥ ♦ ♣ ♠ 03:06, 3 May 2013 (UTC)
        • You been here since when? When there is the possibly to game the system, people will game it. Just like people now come up with "Wasn't given 4 warnings, is therefore allowed to continue until after warning #4" (we even have a template for that!), people will go "Didn't receive ARM or hasn't acknowledged it, therefore cannot be blocked until notice is received.". When blocked anyways, admins will be dragged to ANI with the requirement to explain why they had the audacity to block without prior ARM. Non-admins will eventually be told that warnings left by them are without teeth and therefore without merit and thus shouldn't be given at all. We will then need the Wikipedia:Administrators' Noticeboard for ARM to be given where people ping admins to give such a warning before one is allowed to report at WP:ARV. Choyoołʼįįhí:Seb az86556 > haneʼ 03:19, 3 May 2013 (UTC)
          • First of all, if they haven't acknowledged ARM, then of course they shouldn't be blocked. They're already blocked, until they acknowledge it. Also, we could consider giving this tool to trusted non-admins. -- King of ♥ ♦ ♣ ♠ 03:39, 3 May 2013 (UTC)
            • Ah! A special class of users called "Warners". And if you're not a warner, you have no business warning at all. We'll need the Warners' Noticeboard (WNB) where non-warners will need to justify why the warners warn on the non-warners behalf. Too many unjustified warn-reqeusts will lead the warners to warn the non-warners about false warning-requests on the False Warners Noticeboard (FWNB), the consequences of which will be discussed at the Warnings for Non-warners' Wrong-warnings Warning Board (WNWWB). Magnificent. Choyoołʼįįhí:Seb az86556 > haneʼ 03:56, 3 May 2013 (UTC)
  • Oppose per Choyoołʼįįhí:Seb az86556. He hits the nail on the head: the problem of unintended consequences here. The issue is not the potential for abuse by admins (since this is essentially "block lite" there's nothing an admin could do here that they couldn't do with a block) but with the potential for gaming the system and wikilawyering over admins that don't use this option should it be implemented. No, this is entirely unnecessary. --Jayron32 03:52, 3 May 2013 (UTC)
  • I'm really torn here. The utility of such an ability is hard to ignore, and in point of fact we already do something not unlike this when we tell users "do that again and you will be blocked" and the sudden absence of the hard-to-say-yu-never-saw-it-orange-bar-of-doom certainly helps make the case for it. However, the potential for abuse seems high, and the potential for claims of abuse higher still. I don't happen to agree with it, but many users treat WP:TEMPLAR as if it were actual policy, so its easy to imagine how infuriated they would be when presented with a template that they must acknowledge reading lest they be blocked. I'd rather just see the orange bar come back and be an "opt-out" only feature. (and as for the idea presented above that "trusted non-admins" be able to do this, hell no. Blocking, which this is essentially a form of, is not an admin tool we should unbundle, as the community has made clear in many previous discussions) Beeblebrox (talk) 03:53, 3 May 2013 (UTC)
  • Support if the orange bar goes away. If that happens, then blocking may have to be used more frequently, which isn't desirable. Certainly only for Admins. Using it for IPs is obviously problematic and there need to be guidelines on this, perhaps some form of time limit. Having said this, Seb's points need to be considered. We could have guidelines that clearly restrict it's use. Any editor that has had x warning on their talk page and has never participated in talk page discussions? Dougweller (talk) 05:04, 3 May 2013 (UTC)
  • Oppose Reminds me of all those user agreements on websites that we are forced to click on that I never read. If an editor really was unresponsive, I believe they should usually be blocked and their unblock request would need to demonstrate that they understand the problem. I've honestly yet to encounter a situation where an editor used the "never got the message" alibi.—Bagumba (talk) 07:31, 3 May 2013 (UTC)
  • Very tentative support In principle, a good idea; in practice, may cause more issues than it solves. I'd like to see a draft of the proposed usage policy/guideline before committing anything more than token support. Something like this would need very clear guidelines on when it could and couldn't be used, and they should be pretty restrictive. Yunshui 雲‍水 07:59, 3 May 2013 (UTC)
  • Support. Can't hurt to have the tool in the box. bd2412 T 04:13, 4 May 2013 (UTC)
  • Translation Yes, there are certain users that are hard of hearing and sometimes admins have to use the block button to get their attention. It would be nice to have an alternative to blocking. But allow me to translate this in to how this proposal would be perceived by some people.

    Fear me for I am GOD
    Thou shalt not be allowed to edit until
    a) You acknowledga that I am your superior, and
    b) I have issued a commandment for you to obey
    Click the button below to agree. Have a nice day and thanks for volunteering at Wikipedia. —signed GOD.

    This is how some fraction of non-admins will view it. This is also how some small fraction of admins will use it. It's a good idea in theory, but in practice it will be far different. I'm sure people can imagine how this would have worked during the civility case at ArbCom. 64.40.54.55 (talk) 01:14, 5 May 2013 (UTC)
  • Strong Oppose This is basically blocking someone for not reading their messages. Wikipedia is not a democracy, but it's definitely not a totalitarianism either. This is just a very silly reason to block (block = remove editing capabilities) someone. Feedback ☎ 16:05, 5 May 2013 (UTC)
  • Undecided: It's a slippery slope. If it is allowed, it should only ever be applied in cases that would warrant a block, but where an Admin wants to try to work things out before going to that extreme. It should not be used because of Admin "frustration". Misuse should be sufficient grounds for removal of Admin privileges. Praemonitus (talk) 19:45, 5 May 2013 (UTC)
  • Oppose. Administrators should have fewer capabilities, not more. Malleus Fatuorum 20:00, 5 May 2013 (UTC)
  • Oppose This is weird. It seems like a block without a block ("I didn't do anything wrong, I didn't even block 'em!") and seems too easy to be abused. Seb's got it down pat. We don't need to give sysops a shady way to control editor's behavior. ~ Amory (u • t • c) 23:25, 5 May 2013 (UTC)
  • Oppose. Great idea, and I would have supported if I'd participated before 00:18, 2 May 2013 (UTC), but Seb's comment about unintended consequences trumps all the benefits. Yes, this would help in some ways, but it would have the potential for leading drama and other chaos that can't currently happen (or can't happen to the current extent) right now. Nyttend (talk) 05:15, 6 May 2013 (UTC)
  • Support. We should pile and pile more and more capabilities on administrators until they crash Wikipedia into the ground, and we can start afresh with a decent admin system. --Epipelagic (talk) 06:32, 6 May 2013 (UTC)
  • I can't believe I'm actually reading this oppose: Blocking someone until they click a button? This is what is being proposed here. It is nothing less than blocking. Blocking someone because you want to get their attention is...well, it's borderline at the best of times. I am ashamed to see so many administrators actually pretending that this is not blocking someone. Risker (talk) 22:48, 6 May 2013 (UTC)
    The difference would be that this kind of block could be undone automatically by the user just clicking a button. I agree though that most users would think of it as a block. —Soap— 03:10, 12 May 2013 (UTC)

Suggested new user right: "Referee" (or something like that)

Vandalism is still a big issue for us and it takes up admin resources that can be used elsewhere. I think that patrolling AIV and blocking vandals is a "dirty job" for most admins. I therefore propose the creation of a "Referee" user right (a referee in sports makes quick decisions, and makes sure no time is wasted) that can be granted to users in good standing and with experience in fighting vandalism.

The Referee would be able to preemptively block users and IPs for up to 24 hours, as long as a level 3 or 4 warning has been issued previously to the user or IP. They shall then report it to a purpose-created noticeboard if the behavior is recurrent, where an administrator can deal with setting the duration of the user/IP's block.

I believe that this will greatly ease the work load of our administrators. When a user or IP is reported to AIV, it may take up to several hours before the request is seen by an admin and the user can be blocked. The vandal has then often in the meantime left a big mess that has to be reverted and cleaned up. LiquidWater 20:43, 4 May 2013 (UTC)

  • Support - once a level 4 warning has been issued, blocking should be a given once vandalism continues, no matter who first notices it.  — TORTOISEWRATH 21:17, 4 May 2013 (UTC)
    • I'm afraid blocking is not that simple. You have to check if the warnings were appropriate, if the edits are actually vandalism and not a good faith editor screwing up, if the behaviour actually does warrant a block, judge if the disruption is likely to continue based on their past editing patterns in case the disruption has already stopped etc etc. A block is never applied just because somebody has been issued a level 4 warning. Chamal T•C 03:22, 5 May 2013 (UTC)
      • Sure, but I don't feel it beyond the capacity of the average editor to determine whether the warnings were appropriate.  — TORTOISEWRATH 04:27, 5 May 2013 (UTC)
  • Support, but extend to 31 hours. Blocking admin like that one because they may show up at the same time in school the next day with the 24 hr. block expired.--Canoe1967 (talk) 21:52, 4 May 2013 (UTC)
  • Oppose. This seems a solution in search of a problem; vandalism has, year on year, been going down. Yes, a lot of admin time is spent handling vandalism - but there's no indication that they'd engage in other activities were they to suddenly find themselves unable to contribute in a major focus area. Unless you can show that there's genuinely a crisis - that stuff is getting missed, or that admins are burning out - I don't see a need for this. Ironholds (talk) 23:00, 4 May 2013 (UTC)
  • Comment Thanks for offering the suggestion, but most likely this proposal will not pass. Similar proposals have occured every few months for the last 4 or 5 years and have always been rejected. The community is very reluctant to unbundle the block button mostly because if somebody can be trusted with the block button, they can be trusted will all of them. So this would be the same as running for adminship and only using the block button meaning there's no need for a seperate right. 64.40.54.55 (talk) 01:47, 5 May 2013 (UTC)
  • Comment: I doubt this was your intention, but this suggestion is very similar to a failed proposal from last month. The reasons for why it failed can be found on that page, because I'm too lazy to list them out here :) Chamal T•C 02:14, 5 May 2013 (UTC)
  • Oppose The proportion of bad reports to AIV is very troubling. If we can't trust them to be admins, then we can't trust them to handle AIV. -- King of ♥ ♦ ♣ ♠ 02:50, 5 May 2013 (UTC)
  • Oppose per User:King of Hearts!. →Davey2010→→Talk to me!→ 14:52, 5 May 2013 (UTC)
  • Oppose Of all the tools in the admin kit, deletion and blocking have the highest potential for misuse and should not be unbundled. The idea that blocking vandals is a dirty job that no admin wants to do is utterly without merit, backlogs at AIV are rare. Seems more like a good way to WP:BITE a lot of new users who may not actually be acting in bad faith. Beeblebrox (talk) 22:07, 5 May 2013 (UTC)
  • Comment: This proposal is a complete waste of time and should be closed. Admins never relinquish controls they already have or allow other groups to use them, they only add to them. And this proposal makes the current crazed system even more crazed by allowing yet another group of unsuitable users, such as schoolboys and users with no experience or understanding of content building, to run around blocking the experienced editors. There should be an entirely separate group tasked with the discipline of experienced editors. Experienced editors are not in the same category as vandals. A point which seems to be lost on the mover of this proposal as well as many administrators. --Epipelagic (talk) 23:23, 5 May 2013 (UTC)
    • Did you read the proposal in its entirety? Nowhere in the above paragraph does LiquidWater propose unbundling the block button for liberal use, nor would the "referee" user right be intended for inexperienced editors. Kurtis (talk) 10:20, 6 May 2013 (UTC)
  • Oppose per King of Hearts. Besides, reports to AIV that are truly active vandalism rarely take that long. ~ Amory (u • t • c) 23:31, 5 May 2013 (UTC)
  • In practice, I suspect that this access level would only be granted to editors who have proven highly competent and trustworthy in fighting vandalism (ie. knowing exactly what vandalism is), so I doubt there would be a sudden dramatic increase in unjustified blocks of well-intentioned new contributors. However, I don't really see the point of this user right. There is seldom a particularly pressing need for extra hands at AIV, and blocking petty vandals is generally among the easiest jobs an administrator does (assuming that the user's edits are clearly intended to disrupt the project and they have been given enough warnings already). If someone is trusted enough to have this hypothetical "referee" user right, why not the full sysop package? Oftentimes other features of the administrative toolset are also needed in when dealing with blatant vandalism (ie. deleting pages, viewing deleted pages, deleting revisions, semi-protecting articles, etc). The block button would be limited without them. Kurtis (talk) 10:20, 6 May 2013 (UTC)
  • Oppose. I have a lot of experience (not recent) at anti vandalism, and can get a trigger finger. We need a third party to look at the issue from a disparate position, rather than someone who is on recent patrol. Things like this need someone who has had there history checked out, rather than an easily obtained user right.Martin451 (talk) 02:13, 7 May 2013 (UTC)
  • Oppose. From my experience as an editor, such a status would add very little, if the person is that reliable, why not grant him/her full admin status, even if they only use it for blocking vandals - my real problem is dealing with sock-puppets. Martinvl (talk) 06:07, 7 May 2013 (UTC)
  • Oppose Is AIV that backlogged? --Jayron32 06:34, 7 May 2013 (UTC)
  • Support simply because I love the idea of Wikipedia having referees! AutomaticStrikeout  ?  03:09, 15 May 2013 (UTC)

Wikipedia Editor's Email OR OTRS Reach Out

I regularly send emails to request for permission (generally images). But, my success rate is alarmingly low. So far, I have sent 53 emails, have received only 6 replies and I could collect only 1 image. Someone gave their phone number in reply email and asked to me to call the number, which I did not do. I use the draft email posted at Wikipedia:PERMISSION.

I personally feel, one reason of such low success rate is my Gmail domain's email. In one email, my request was rejected with the comment they would think if they get a request from Wikimedia officials (yes, they don't understand how Wikipedia works, I tried to explain, but, no luck), in another conversation, the requested party was surprised to see my gmail email.

Suggestions
a) Create an email domain like username@wikipedia-editor.org so that the approach becomes more professional. The main domain page may have information on how Wikipedia works, who are Wikipedians etc.
b) Create a separate section in OTRS— "OTRS reach out" which will work on requesting content permission. General editors will request "OTRS reach out" members and they'll attempt to collect permission from third parties.

Feasible? --Tito Dutta (contact) 08:24, 5 May 2013 (UTC)

I like the editor e-mail idea.
As to the permissions, it also depends upon the type of images you are seeking. Celebrity photos tend to be worth a lot of money, and it is unlikely photographers will give them to you for free. There is a Wikipedia editor, however, who does shoot red carpet shots. I have not dealt with him in years, but I see he is still editing, and when I asked him before he had no trouble getting shots for the articles I was creating. User:David Shankbone
Science pictures are much easier to get. I have never been turned down, except for temporarily. When I am dealing with non-scientist photographers, like National Geographic photographers, however, I also offer the option of submitting a low-resolution version of a good image.
  • Yes, most of the images I requested were celebrity images. --Tito Dutta (contact) 05:06, 7 May 2013 (UTC)
It is cool that you take the time to ask. It's a great way to get images. -68.107.137.178 (talk) 14:42, 5 May 2013 (UTC)
  • Comment I can't seem to find it, but Ithink the WMF already nixed this idea because of the possibilty of abuse and their legal requirements. In general people are always skeptical about emails from Wikipedians. The best way to handle this is to start a disussion on the approriate page and link to that page in your email. That way the recipient can see there is actually a discussion on Wikipedia about the picture/issue/proposal or whatever. Linking to the related policies, such as WP:PERMISSION, in your email also helps. Contacting the right people can help too. If it's a corporation, contacting their public relations/sales/customer support department is often helpful. This usually changes the 90% failure rate in to a 90% sucess rate. Cheers. 64.40.54.43 (talk) 16:37, 5 May 2013 (UTC)
  • Discussion in talk page has been tried, does not work. I can find this at this moment. There are 1-2 more. Moreover it makes thing more complex. A good number of people don't understand creative commons, Wiki policies and when you start talking on these in details, they want to leave. Someone told me in an email "You want image, just collect it from internet. I don't mind if someone uses my image for an article on me."! -- Tito Dutta (contact) 05:06, 7 May 2013‎ (UTC) (signed at 16:16, 7 May 2013 (UTC))
  • Comment / Suggestion Doesn't OTRS have a generic email @wmf.org or something? Couldn't users fill out a form and let an OTRS bot of some kind actually "send" the original email and CC it to the requester? I would think that would alleviate any hesitations of authenticity because it would be from "Permissions@Wikipedia.org" and it could include a "reply to" link back to the requester so that communications would be initiated from an authentic MW entity, but all communication would be with the individual editor. Technical 13 (talk) 01:00, 6 May 2013 (UTC)
User:Technical 13, Excellent suggestion! Can it be done? --Tito Dutta (contact) 05:06, 7 May 2013 (UTC)
I don't ask for OTRS permissions very often, but when I do, I send it directly from the system. This is a great idea, as it will allow people without OTRS accounts to do the same. -- King of ♥ ♦ ♣ ♠ 05:28, 7 May 2013 (UTC)
Hmm, is letting anyone send an email with WMF-looking authenticity that great an idea? It would need to include some boilerplate "This is NOT an email from the WMF, content not endorsed by us etc. etc." to guard against phishing and maybe other legal issues, kinda nullifying the authenticity Jebus989✰ 18:18, 7 May 2013 (UTC)
A disclaimer is good. Also, we probably shouldn't be allowing anyone to just send such an email. Maybe there can be an approved list of users that people can request that their names be added to. -- King of ♥ ♦ ♣ ♠ 12:14, 10 May 2013 (UTC)
  • Support Technical's idea. I'm uncomfortable with a username@WP address, simply because it would potentially require lots of maintenance for something that's not our core purpose; imagine it becoming someone's primary email address, for example. Conversely, as long as we can figure out how to make it so that you can view emails related to ones that you've sent and not be able to view emails related to ones others have sent, the permissions@WP idea is great; far fewer people would question its origins. I also agree with 64.40's point about on-wiki things; my requests for permissions generally have to do with illustrating US historic sites, and I'll customarily include a link to the unillustrated article with the implication of "just imagine how much nicer this would look if you donated your picture". Nyttend (talk) 12:23, 6 May 2013 (UTC)
  • I have had reasonable success with: Subject:Wikipedia
Hi Betty, (the PR person)
Vicky doesn’t have a picture for her Wikipedia article. You are very welcome to provide one but we need the permission of the copyright holder which is usually the photographer. They would need to release it under a ‘free license’. See: http://commons.wikimedia.org/wiki/Commons:OTRS for details. If you email one to me with verbal permission of the photographer then I can have it in the article within minutes and we can wait for them to fill the form out and email it to OTRS. They have a large backlog so sending it to me may be the fastest and easiest for you. This should prevent some fool from uploading a lame image that they snapped in a grocery store, etc.
V/r (my real name and phone here)--Canoe1967 (talk) 05:22, 7 May 2013 (UTC)
  • I am intrigued by this discussion. I have a hit ratio of about 50%, which disappointed me, but perhaps I should feel better about it. However, I'm not going after celebrities, I am generally looking for images of basketball coaches, and I am a member of the professional society, so that may help. However, I wonder if an email address associated with Wikipedia would help. I fully understand the concerns about making this too easy, I appreciate that it should be done with care, if at all, but I'd be curious to see if an email from a Wikipedia address would improve the hit ratio.--SPhilbrick(Talk) 16:45, 14 May 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_101&oldid=1150986342"