Jump to content

Wikipedia:Village pump (proposals)/Archive 94

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, 213, 214

Allowing users to keep private drafts of their work

There is a clear support for this extension. Armbrust The Homonculus 11:02, 6 November 2012 (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.

Per request on bugzilla:37992, it seems appropriate to discuss some questions with the broader community:

  • How good/bad would it be to have the mw:Extension:Drafts installed on English Wikipedia (and WMF wikis in general)?
  • What kind of improvement would it need before been enabled here?

Helder 22:18, 15 September 2012 (UTC)

Note that this testwiki has a version of the extension deployed - you can test it if you log in :). Okeyes (WMF) (talk) 22:23, 15 September 2012 (UTC)
I'm getting "Uncaught ReferenceError: wgDraft is not defined" when editing a page that wiki. This may be breaking some of the features of the extension. Helder 23:18, 15 September 2012 (UTC)
Weak oppose Saving it to userspace would be nice, but it'd really increase the chances of edit conflicts. Personally, I don't think it'd be worth it. • Jesse V.(talk) 22:32, 15 September 2012 (UTC)
It is not saved to userspace as far as I know. Helder 23:11, 15 September 2012 (UTC)
  • Seems like a reasonable MediaWiki enhancement to me. This kind of auto-save feature is common in other editors: Microsoft Word has this feature enabled by default, WordPress has this feature enabled by default, even modern Web browsers have some kind of auto-save/auto-recovery feature built in. I think it's common for users to want to make a draft of something that they're working on and I think there's an expectation that reasonably built modern editors won't allow a user's work to completely disappear without warning. --MZMcBride (talk) 23:26, 15 September 2012 (UTC)
  • From what I understand, such drafts would simply provide users with a more convenient and private way to save drafts of things without having to manually do so on another page or a file elsewhere. Seems useful. Has a few issues to work out, but that should certainly be doable, and the bug about it on bugzilla concerns specifically what does need doing before deployment; it is not likely to be put here as is. Mind, if y'all do see issues that need addressing with it... well, that's the stage we're at, no? Right? -— Isarra ༆ 04:33, 16 September 2012 (UTC)
Strong support I just spent over an hour this morning working on revising an article and I had my X-server crash and lose it all. Such a feature is used with great success by Google Mail, so why not here? Yes edit conflicts are annoying, but losing and hours of irreplaceable editing work due to a technical problems is devastating. I would like to propose that mw:Extension:Drafts be installed and allow users to optionally enabled the feature through Preferences and also label it as beta initially. - Stillwaterising (talk) 17:57, 16 September 2012 (UTC)
Another example of how you could lose your work is bug 22680. Helder 22:50, 17 September 2012 (UTC)
Support autosaving with a question: is this saved only on a time basis, or each time Preview is hit? GMail and Google doc saves are time-based; not sure which I prefer. Userspace would be fine for the temp file, but I wouldn't want them to stay around long after the user successfully saves.--Lexein (talk) 18:58, 16 September 2012 (UTC)
  • Not sure I understand this... Are these drafts going to be saved whether I, the user, want it or not? Are they only accessible to the user who wrote them? Has the user any ability to "speedy delete" a draft they don't want hanging around on the system? I usually write stuff off-line and sometimes try them in preview mode just to check what they will look like. I wouldn't really appreciate if the system saved the text for me whether I had actually wanted that or not. --Hegvald (talk) 19:30, 16 September 2012 (UTC)
I'm going to try to answer some of Hegvald's questions to the best of my understanding:
  1. Are these drafts going to be saved whether I, the user, want it or not? - From the developer: "We are going to make some aspects of this extension configurable, however this will be done in coordination with a general improvement of the flexibility and general architecture of the preferences special page which should happen soon if not later."[1] Addition: Feature can be disabled by going to Preferences/Editing
  2. Are they only accessible to the user who wrote them? should be[2]
  3. Has the user any ability to "speedy delete" a draft they don't want hanging around on the system? if you press Discard your draft is immediately deleted[3] - Stillwaterising (talk) 00:01, 17 September 2012 (UTC)
Stillwaterising, almost all of those comments are very outdated (2-3 years old), and this hasn't been used on Wikimedia wikis at all as far as I can see. There are also differing responses to some key questions, including whether or not the results are publicly visible. Bugzilla 37538, which you quote above, applies to Git/Gerritt, not to this process. Having said that, I'd like more information about this extension. I'm not yet convinced that a UI change requested by a handful of users over the course of years should be getting 20% paid developer time, but I could be persuaded. I have commented further at the Bugzilla. Risker (talk) 02:24, 17 September 2012 (UTC)
If I try to close out of an active editing window, Google Chrome always informs me that I've made some changes and that I need to confirm leaving the page or choose to stay on it. • Jesse V.(talk) 02:46, 17 September 2012 (UTC)
If the option is turned on, FireFox also does the same thing. Kudpung กุดผึ้ง (talk) 03:41, 17 September 2012 (UTC)
  • Support I tried the Drafts extension on one of the test wikis before and really thought it would be useful. It can autosave copies of whatever you are working on. In event that the browser crashes, you don't lose your work. You can also intentionally save a draft and come back later, which would also be nice. --Aude (talk) 06:18, 25 September 2012 (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.

RFC requesting your assistance

| This RFC deals with our current licensing. Your input is requested. "....We are all Kosh...."  <-Babylon-5-> 11:30, 26 September 2012 (UTC)


Using the search function recently, I have noticed that there is a number of articles which violate WP:SPAM by including phrases such as "for further information visit www.examplewebsite.com". While this isn't a particularly large-scale problem in the scheme of things, I was wondering if there's a way that some sort of extension or bot could flag up these up with the advert template or something similar, and make it easier for editors to address this.--Donkey1989 - talk 14:48, 26 September 2012 (UTC)

usually the problem is just the wording. I've seen it used for perfectly valid external references, that merely need to be written properly. Sometimes it's on equally valid external links. When I encounter it, i rewrite. But it does serve as an indication that the article may possibly have been copied from a website, or is promotional. But such is the prevalence of promotional writing in the RW that many perfectly straightforward and non-COI editors know no better than to use the sort of wording they have seen widely elsewhere DGG ( talk ) 18:05, 26 September 2012 (UTC)

WikiTimelines

WikiTimelines is working to visualize the sum of human knowledge. We've developed a program that interprets wikipedia articles for events, then displays the events on interactive timelines. History can be intimately explored through chronological scopes like centuries, decades and days. In order to allow editing and customization we've created a markup where people can edit icons, timebands and event titles on the timeline. All this and more can be explored on http://wikitimelines.net/ . We believe strongly that wikitimelines can contribute to the wiki community. We really want to know what you gals and guys think about wikitimelines, and if an interactive/visual interface could ever find its way on wikipedia. What do you think? We want to set up Wikitimelines as an extension that can complement articles on timeline articles .

Our team is interested in integrating it into Wikipedia as a mediawiki extension and we're looking for help. Is anyone interested? — Preceding unsigned comment added by TheKaramanukian (talk • contribs) 07:50, 19 September 2012‎ (UTC)

I think you meant to link to Timeline of the Great Depression.
Note: this site/software was also mentioned at Wikipedia:Village_pump_(idea_lab)/Archive 9#Proposing a Major New Feature, in mid-August. —Quiddity (talk) 21:16, 28 September 2012 (UTC)

Automatic diacritic redirect?

It has been recommended (Tea House) that I post my "suggestion" at the Village Pump. I hope this is the proper way to do this. My suggestion: allow for a system of automatic redirect to/from names with diacritics / diaeresis that have been Anglicized. For example: Willy Stoewer → Willy Stöwer (this one has already been done manually). Thanks, Eric F 74.60.29.141 (talk) 06:30, 24 September 2012 (UTC) ~(primary talk)

I don't think there's any feasible way to do this. Some articles are better served with the diacritics, some without, so it isn't always obvious which way the redirect should go. Furthermore, it also isn't always obvious how to deal with diacritics. The "oe" or "ue" convention from German and some other languages doesn't apply to, say, the French trema even if it does to the German umlaut. So, I'm not sure there is any way to automate the process. One just has to be mindful of the fact that there are different ways of spelling, and do their best to create all reasonable redirects. After all, redirects are cheap. --Jayron32 06:44, 24 September 2012 (UTC)
How would you go about automating this without ending up with poetry → pötry? In other words: What is the system that you wish to allow? --LA2 (talk) 06:46, 24 September 2012 (UTC)
I'm a pöt but I don't knöt. -- Hex [t/c] 09:31, 27 September 2012 (UTC)
Not sure of algorithm specifics, but Google seems to have figured out a way (not that Wikipedia has the same resources available). ;) Anyway ... just an idea. ~E 74.60.29.141 (talk) 06:54, 24 September 2012 (UTC) 06:56, 24 September 2012 (UTC)
Yeah, it should be noted that compared to Wikipedia, Google essentially has infinite resources to implement these things. They don't share their code or methods with the world, and developing a similar tool for Wikipedia which is reliable enough to be useful is likely well out of the scope of the money and manpower Wikipedia has availible to dedicate to it. --Jayron32 20:01, 24 September 2012 (UTC)
While there's no automatic redirection in place, our search function already finds entries with differing diacritic spellings. For example, a search for "Steven Seägal" brings up Steven Seagal as the first result. Similarly the other way around. Jafeluv (talk) 09:56, 24 September 2012 (UTC)
What Jayron32 said. An automated system is going to fall down, especially since the same character can be transliterated in different ways depending on the language (or even on where the letter appears within a word or name). For example, the Scandinavian surname Öberg is often anglicized as Ohberg (and occasionally as plain Oberg), whereas the aforementioned German Stöwer becomes Stoewer. What should we be converting our Ö to? TenOfAllTrades(talk) 14:24, 24 September 2012 (UTC)
A semi-automated bot for all of those little brothers to operate? Theopolisme 22:01, 24 September 2012 (UTC)

RFC requesting your assistance

− − | This RFC deals with our current licensing. Your input is requested. "....We are all Kosh...."  <-Babylon-5-> 11:30, 26 September 2012 (UTC)

Nostalgia Drive

As a person who grew up in the 90's, I have fond memories of the culture of the time period - the fads and fashions. While some remain very well-known even to this day, unfortunetely over time many have died or gone into obscurity. A nostalgic look at the Wikipedia pages for various media from days gone by has led me to believe that a lot of extremely popular series have poor coverage. In particular, a series that I think this proposal would work really well for is Carmen Sandiego, an extremely successful 80's & 90's game/TV franchise that I absolutely adore, and which has a very loyal following. I looked at the GoogleNews archives, and there is a wealth of information there about its history/games etc., and I just think there is a massive market here that we simply havent tapped into yet. All we have to do is say: "why not find out as much about this thing you already have a passion for, and then make a formal record here of what you find". Poeple will actually be inclined to research. It won't be a chore. It will be a wonderful endevour - requainting oneself with the old series.

A major concern of Wikipedia these days is that people are not editing because they have nothing to contribute - they dont have an interest on any of the topics left to cover, and due to the increasing levels of quality expected, they find it too hard. Well, what if the topics worked on were not history, or sea, or physics? What if they are things the people grew up with? Things within the public consciousness that will cause everyone to actually be excited when starting to research and finding out more about this thing that they have very fond, albeit vague memories? I think this idea has loads of potential, and could be a great way to get newbies into the groove of editing. What better way than with something they actually like, with lots of others who like it. I would like to see the idea of some sort of nostalgia drive explored further - it could be featured on the main page for, say, a week, andaim to get a bunch of popular past series to a better quality.

P.S I think an important thing to note is that the way this proposal differs with other similar ones, is that it has a specific focus, and can be branded very effectively (through colours/imagery etc.), perhaps in such a way to solidify it as a unique Wikipedia opportunity to take part in. --Coin945 (talk) 02:26, 18 September 2012 (UTC)

You could start an article drive for classic/retro video games, perhaps with the help of Wikipedia:WikiProject Video games/Retro games. Fences&Windows 07:23, 19 September 2012 (UTC)
I think such an editing drive is a great idea, but for many of these things sources are very hard to come by (see e.g. the article on The Littl' Bits that I worked on, which to this day only has two refs). Even primary sources are hard to verify since we're not allowed to link to illegal redistribution (see WP:ELNEVER), and many of these works are no longer legally distributed at all. The world has a short memory even for things we may remember well. Dcoetzee 00:48, 24 September 2012 (UTC)
The reason people edit less is that the editing environment sucks more. That more topics are already covered is a lesser issue. Many existing topics can use huge amounts of improvement, that they would have gotten back in the day, but it's no longer worth the hassle. 67.117.130.72 (talk) 04:58, 1 October 2012 (UTC)

Pre-approval of collaborations

Should we have a process for checking and approving in advance proposals for joint projects with outside bodies?

This question is provoked by the GibraltarpediA project, which has been extensively discussed over the last few days at WT:DYK, Jimbo's talk page, WP:AN, Talk:Gibraltarpedia and probably other places as well, not to mention the outside press (links from here). I do not intend this to be yet another discussion of that project - if you want to comment on it, please do so at one of those other places.

There have been many and successful GLAM projects, partnerships with Galleries, Libraries, Archives and Museums. I don't know how they have been set up and approved, but they are not problematic, because the aims of those institutions agree with ours - to make knowledge freely available. GibraltarpediA is different, because the partner organization, the Gibraltar Ministry of Tourism, is not a GLAM and is explicitly in it with the aim of "marketing Gibraltar as a tourist product through Wikipedia.". In the various discussions, some people have seen no difficulty with that: "We want articles about Gibraltar, they want articles about Gibraltar, what's the problem?" Others, including me, and including some outside commentators, think that Wikipedia's reputation for independence and neutrality will be compromised if we are seen as partners in a boost-tourism project for a particular destination, or in any commercial project, and that we should not do this sort of thing, for just the same reasons that we do not accept advertising.

GibraltarpediA was set up by Roger Bamkin (user Victuallers (talk)) with at least moral support from Wikimedia UK. Questions of COI have been extensively discussed, which once again I do not wish to re-hash here. I am sure that all those concerned thought they were doing Wikipedia a service, but it is far from clear that they were, and it would have been better if these issues had been raised before we were committed.

It is reported that Roger Bamkin has been "flooded with invitations from places around the world" who would like to exploit Wikipedia in this way, and I think we need to decide our attitude now before any more commitments are made. My proposition is that neither an individual, nor a country chapter like WM-UK, should have the authority to commit the English Wikipedia to non-GLAM joint projects without prior discussion and agreement.

I don't know how this should be done: it is not really within the scope of either WP:WikiProject GLAM or the WikiProject Council. Perhaps we need a Joint Project Approvals Group like the Bot Approvals Group. Please make suggestions, and this could become an RFC - not, I repeat, an RFC on GibraltarpediA, but on the general question of pre-approval of non-GLAM outside partnerships. JohnCD (talk) 22:27, 23 September 2012 (UTC)

I have "led" or been very close to three projects and involved in an advisory way to maybe 6 or 8 overseas. My first project was with Derby Museum. In that case I just knocked on the door and suggested we collaborate. We put together an MOU (actually it was a press release) and that led to a successful collaboration which gave them 50 e-volunteers, we wrote 1200 articles and we created the first museum that you could access in maybe 12 languages. If I had had to get prior agreement then I might not have bothered - however other types of people might need this to gain confidence. Next was Monmouthpedia. Here we introduced the county council to the Foundation and they signed an agreement at almost the last minute as we moved so fast. In the case of Gibraltar we managed to get an agreement signed before the first press release. Possibly a bit too quickly. Agreements with other groups have less formality but we have had some form of supportive statement from Morroco, Catalonia and we are talking to other groups to. Hope that helps. Victuallers (talk) 23:39, 23 September 2012 (UTC)
Thanks for raising the question, JohnCD. Any major non-GLAM project like Gibraltarpedia which will be widely publicised through PR measures should undergo pre-approval through a community RfC. I would say that the articles are not so much the problem, but the type of publicity that is generated is. JN466 01:32, 24 September 2012 (UTC)
  • Strong support for pre-approval discussion of collaborations, prior to outreach, for non-GLAM title entities. The scale of a museum (and associated risk of damage to the sense of Wikipedia's independence, credibility, neutrality), is vastly less than that of a government. I also encourage disclosures such as that posted by Victuallers at WT:DYK: A short History of DYK - where are the people in charge?. If this had existed on the WP:Gibraltarpedia project page, it would have been as public as the articles, on the same platform (rather than split WMUK/Wikipedia). It would have allowed many-eyes checking for possible unnoticed issues. Its existence, clarifying all relationships first, could have a) calmed any in-house concerns about (perceived) impropriety, b) been sufficiently informative to prevent the dramatic blog post, c) been instantly available for press release in the event of such a post, d) (most importantly, to me) avoided or reduced the risk of loss of public confidence in Wikipedia's integrity due to the post. --Lexein (talk) 01:53, 24 September 2012 (UTC)
  • Yes, get pre-approval in any situation where foundation or chapter personnel are accepting money to arrange competitions, even if there are no tangible incentives offered. It's not clear to me whether UK charity directors are even allowed to accept money to further the commercial interests of a client by way of their influence with the charity. Is there anyone who would have approved of that if they had known about it ahead of time? —Cupco 02:49, 24 September 2012 (UTC)

(Given time, consideration and public discussion) I'm confident that good measures can be adopted to protect Wikipedia's credibility, independence, and neutrality, and to avoid erosion of public confidence in the encyclopedia. Gibraltarpedia would have been initially opposed due to its nature outside the GLAM canon, but further protective measures might have been proposed and adopted to allow it to proceed. For non-GLAM entities (NGE): 1) Better on-wiki public disclosure and reporting (above), 2) Put new articles through AfC, to assure high quality upon publication, maybe tag them as Project-related, to be graded by DYK standards (this benefits WP and NGE alike), 3) Dilute the concentration of project-topic articles being created/expanded and squeezed through WP:DYK, by time, say, one per 7 days, 4) Dilute by density: write-N-to-get-one. To get one externally-supported Project article (e.g. Gibraltar-related) through DYK, also create/expand N non-Project DYK-ready articles from (say) the WP:Requested articles queue. This serves WP expansion, makes NGEs accountable for expansion beyond self-interest, and eliminates that appearance of impropriety, without raising costs. It's a PR tax, and an influence tax. The ratio can be adjusted: the greater the expected WP PR value to the NGE, the higher ratio of articles the NGE should time-invest in the overall project. For Gibraltarpedia, the ratio might be 4:1, but that's just my valuation. My key point is that NGEs should support the whole encyclopedia, not just the part that stands to benefit them; this is just one way to do that. --Lexein (talk) 04:45, 24 September 2012 (UTC)
  • Cautious support for an (External Organisation Project) Approvals Group, but hasten to add that pre-approval should only be required after some clear parameters have been agreed upon. The WP:BAG model is a good one. Tiny projects should not be hampered by the need to fill in paperwork. Only major projects need oversight, especially when people are being paid to promote or undertake a project, or when PR is being amped up. The community needs the option of saying "This project is becoming a burden; please halt it and lets review it". This also helps the external organisation, who blindly believes that the Wikipedians they have put in charge will ensure the community keeps loving the project. They need to know, early, when they are in troubled waters, and they need to know that there is a project evaluation process, how long it will take, etc, so they can plan around it, and so they know that the volunteers are happy donating their time. I think the same approval process should apply to GLAMs, as not all GLAMs are benevolent, and some non-GLAMs are more clearly aligned with our mission than most GLAMs; irrespective of what sector they come from, if the projects objectives and methods are as aligned with our mission as we hope they are, then they will not have any significant issues obtaining approval. John Vandenberg (chat) 03:28, 24 September 2012 (UTC)
  • I don't think "let's halt the project and review it" is feasible - once such a project is under way there is no real way to stop it. It has to be got right in advance, or called off. The main parameter for needing approval is plans for "PR being amped up", and arrangements for vetting the publicity should be one of the key factors, to ensure it does not imply that Wikipedia endorses the partner or that the partner will control Wikipedia's content (it hasn't helped the Gibraltar situation that only a few days ago their press release referred to "Gibraltar's Wikipedia site" which in the Gibraltar Chronicle became "Gibraltar's own Wikipedia site"). JohnCD (talk) 22:16, 24 September 2012 (UTC)
  • A content collaboration is nothing else than editing Wikipedia, and we don't need to "approve" new editors. On the contrary, everybody can edit. You can even edit anonymously, and we don't know who pays the lunch for the editors. The only approval is for the content, which must follow Wikipedia's rules and guidelines. --LA2 (talk) 06:49, 24 September 2012 (UTC)
  • Comment I think what we have here is a major case of why wasn't I consulted?, which happens a lot on Wikipedia. The problem is however many layers of approval one puts in place, when a project goes awry, the community will still throw a fit about how they weren't consulted. This happens with technical stuff like WMF features development (I was sitting in a Wikimania discussion when someone said "hey, the Foundation never talk to the community about this stuff", to which I had to pipe up "hey, I closed a damn RfC on this exact subject!"). That said, I do think collaborations need to get more community buy-in. Not just to avoid situations where there is either the potential existence or appearance of impropriety but even when that isn't a problem, to get existing editors to participate. Perhaps one way of doing it wouldn't be so much to make it into an approvals process, but simply have an announcements process and strongly recommend that all non-minor content partnerships (say, more than three people involved, affecting more than five articles, or lasting more than one week) that intend to edit on English Wikipedia need to announce their existence on the announcements page. There shouldn't be a BAG or RfA style approval process, because that would get in the way of actually getting on with the project, but it'd give the community a chance to raise concerns. One aspect of this is the GLAM collaborations are discussed in the excellent This Month in GLAM, but this is both on the outreachwiki ghetto and only read by people in the GLAM community. There was some discussion internally in the GLAM community about whether or not TMIG should be merged into being part of Signpost. —Tom Morris (talk) 08:37, 24 September 2012 (UTC)
I don't want to be consulted. I just want there to be a way where officials can accept money to make improvements on behalf of a client which doesn't place their interests in opposition to those of the community. Asking if anyone objects is the easiest way. Let's say the next paying customer is the Nationalist Party, which wants to pay $20 for every Nationalist politician Good Article. Would a mere announcement process suffice for that? How about if it was Hostess, offering a year's supply of Twinkies to everyone who gets a Hostess snack featured and on the main page? What if it's the Church of Scientology offering airfare to Clearwater for DYKs on any volume of their instructional literature? I suggest that an approval process would be superior to an announcement process. —Cupco 13:48, 24 September 2012 (UTC)
It's not about WWIC, not for me. Wikipedia got pasted in the press internationally, solely due to the appearance of impropriety, combined with journalistic aggressiveness, fed, if you'll recall, by in-house confusion and discussion about what was going on. The mess could have been prevented by best practices (better disclosure internally, on wiki) before the press fiasco. The fiasco could have been cut short mid-stride by rapid disclosure, but it was not. It appears that there are new (to us) best practices to consider here; to pretend otherwise is to, in my considered opinion, put WMUK, WMF, and the encyclopedia's reputation at risk over and over. Pre-action discussion minimally provides an opportunity to remind of best practices before kickoff. --Lexein (talk) 14:15, 24 September 2012 (UTC)
  • Oppose This all seems very vague. What is being proposed could be read in any number of ways, from a request for disclosure to an effective ban on being hired to edit. Take it away, be specific, bring it back, we'll talk. Collaborations defined how, by the way? Chapters associating themselves with outside groups, or individual editors choosing to contract with outside groups?-Wehwalt (talk) 08:40, 24 September 2012 (UTC)
The OP proposed discussion, and requested suggestions to help focus the discussion. Why oppose right out of the block when you could make the suggestions which could improve the discussion? IMHO at the moment it is focused on any editor or group of editors planning to contract with non-GLAM outside entities. The bigger the non-GLAM outside entity, the bigger the need for pre-action discussion, in my opinion. See my point above about dilution of possible COI and PR effects on the content itself. --Lexein (talk) 14:15, 24 September 2012 (UTC)
  • Just say no. Since when did Wikipedia start having approval and oversight power on non-wiki real world matters? Give me more power, give me more, you can't do anything without my say so! We have guidelines and policies on the content of articles, the process of editing, and editors behaviour itself. Let's leave it at that. -- KTC (talk) 09:57, 24 September 2012 (UTC)
  • It's not non-wiki real world matters if that activity generates on-wiki articles and DYK traffic for the purpose of publicity. The encyclopedia should have a say in activities done in its name, which, if they have an appearance of impropriety, pose a risk to public perception of the encyclopedia's content, as pay-to-play. Best practices can reduce the risk of the perception of impropriety - see above, too. --Lexein (talk) 14:15, 24 September 2012 (UTC)
  • Comment There is also a more fundamental question to be cleared up about the ownership of qrpedia.org and qrwp.org, the sites that facilitate Wikipedia access in projects like Monmouthpedia and Gibraltarpedia. According to a discussion on the Wikimedia UK website, both of these domains, which are privately owned by Roger Bamkin and Terence Eden, were to be transferred to WMUK (negotiations have apparently been ongoing for the past year). It now turns out that QRpedia.org will not be transferred to WMUK, but will remain privately owned. According to WMUK chair Chris Keating last week [4], links to QRpedia.org resolve to qrwp.org. If the QR codes placed in locales like Monmouth and Gibraltar point to a private website (which in theory could add advertising at a later date, etc.), this needs to be understood beforehand, before the community and the movement as a whole endorse such a project. JN466 11:17, 24 September 2012 (UTC)
    • On the QRpedia front, I do think Wikimedia UK need to get this sorted out. When Roger first started experimenting with QR codes at Derby Museum, I pointed him towards Terence, who I have known professionally and personally as a software developer for quite a few years (there's a reason I'm in the credits). I wouldn't worry too much about the theoretical possibility of advertising on QRpedia. In general, I subscribe to the cockup-not-conspiracy view of history, and the fact that Wikimedia UK haven't transferred ownership of QRpedia is probably just bureaucracy related to things like hosting and the like. Terence has worked for a few of the big mobile companies like Vodafone. Developers who do things like this don't benefit from it by covering it in slimy adverts but by using it as basically a portfolio piece. The value of a few crappy "punch the monkey" adverts for an individual developer like Terence is much lower than the value as basically having this as an open source feather in one's cap when talking to future employers. WMUK still should bloody well get on and move the domains. —Tom Morris (talk) 11:39, 24 September 2012 (UTC)
      • It's not about potential ads, just that it is a point of principle within the movement not to use proprietary elements in its projects. Have you read the discussion at the water cooler? It sounds like the transfer of QRpedia.org to WMUK is definitely off the cards now; it will remain privately held. What is unclear is where the QR code plaques point to and how they are redirected. From what Chris Keating said last week, it sounded like they pointed to QRpedia.org and were then redirected to qrwp.org. --JN466 11:44, 24 September 2012 (UTC)
        • Oh, that's easy. The QR codes point to qrwp.org. So, if you generate a QR code for the enwiki article for London points to the URL http://en.qrwp.org/London which will then redirect to the Mobile version of Wikipedia for the most appropriate language. —Tom Morris (talk) 12:25, 24 September 2012 (UTC)
          • Cool. So what does QRpedia.org do, and why did WMUK want to have it? JN466 13:22, 24 September 2012 (UTC)
            • qrpedia.org is simply the website you go to that generates the QR codes. You paste in a Wikipedia URL and it generates the appropriate qrwp.org QR code. You don't have to use qrpedia.org to generate QRpedia codes: you can use any QR code generator. But if WMUK are to have control over QRpedia (which they, or another chapter, or the Foundation, probably should), it kind of makes sense to have both. —Tom Morris (talk) 13:31, 24 September 2012 (UTC)
              • Thanks Tom, that's helpful. I've taken the liberty to copy your comments to the discussion on the WMUK wiki, as there seemed to have been confusion about this point. --JN466 13:53, 24 September 2012 (UTC)
  • Oppose I agree with the comments about this being vague and adding another layer of bureaucracy is going to hurt the project, not help it. I have never liked many of the COI arguments because they so often seem to be some kind of "purity test." Outside organizations, be they museums, governments, tourism boards or whatever, collaborate with Wikipedia because it is in their interest to do so. Even "holier-than-thou" editors gain something from all the time they put into the project, be it self-satisfaction, or promotion of a topic they think is neglected in the world. We cannot spend a lot of time and accusations on people's motives, which really cannot be objectively quantified or qualified. We can only really judge the results. If the resulting content is in line with Wikipedia's objectives and interests, why is the fact that someone else benefits a problem? This is the real world. We are in much the same position as universities and other research institutions which must rely on outside entities such as corporations, governments, institutions etc in order to perform their own research goals. Does this sometimes cause problems? Sure, and there are channels to handle those, however imperfect. There are topics on Wikipedia which are sorely lacking simply because the average editor does not have the knowledge of the topic in order to work on them.

Does this mean there is no place for the "average editor"? Of course not. I suspect that many who are suspicious to hostile to GLAM and the like are worried that they will be pushed out of the project. However, most institutions have narrow fields of interest and no one is proposing that they take any kind of ownership of any material produced, never mind topics. In a sense, the "average editor" is the editorial board for Wikipedia through crowdsourcing (you dont need technical expertise to recognize POV or peacock terms and the like). If any kind of personal or institutional gain (including a sandwich!) is cause for qualification, then we wont have much of an encyclopedia. You have to end not only GLAM, but the Education program as well, because I can tell you as a teacher myself, I would not put in so much time and efforts incorporating Wikipedia with my teaching if there wasnt some kind of benefit for me as well as my students (career development).

However, I do think a set of guidelines are in order as to what activities are COI and what are not. if nothing else to not constantly have this discussion on various boards.Thelmadatter (talk) 13:48, 24 September 2012 (UTC)

Hi Thelmadatter, in regards to "We are in much the same position as universities and other research institutions which must rely on outside entities such as corporations, governments, institutions etc in order to perform their own research goals. Does this sometimes cause problems? Sure, and there are channels to handle those, however imperfect." I am sure you're aware that universities and other research institutions will require many levels of approval for any reasonably sized collaboration between them and another entity, especially if the other entity is for-profit, and it is often mandatory if there is any IP that might be transferred in the process of collaboration.(Ordinarily I would think that the notion of IP being generated by a WikiProject being "owned" by a for-profit was impossible, but enter Gibraltapedia, and that is exactly what has happened.) In my experience, small projects at universities with for-profits are not cost effective, as the approval process costs outweigh any benefits the project could provide. Obviously any solution we implement needs to be more 'wiki' than the university red tape generators, but if we don't have any centralised management/oversight of these projects we are going to see more messes like the current one. (and by 'mess' I am purposely avoiding specifics of the current situation, as it is complicated, and the next one will be something sufficiently different that the good intentions of everyone involved will blind them from the similarities and the community will scream 'didnt you learn from the last time this happened') We also need to consider that problems of this kind result in poorly used donations and volunteer time. Consider how much WMF and WMUK paid staff resources is being used resolving this mess, and if confidence is lost in the encyclopedia (I'm not sure this will happen) or in 'the movement', these organisations will need to spend lots more donation dollars funding human resources that work on rebuilding relationships with other organisations and potential partners who will shy away from existing projects. Consider how much volunteer time is misused in unproductive discussions because nobody out here on the project knows the specifics and the community members are not responding well to "we're compiling that information now" responses when the information requested should have been public from the outset. etc. John Vandenberg (chat) 06:10, 25 September 2012 (UTC)
  • Strong support - I want to make sure there's no way where Wikimedia officials, admins, etc. can accept money to make improvements on behalf of a client, which is inherently damaging to the reputation of the entire project, and thus leaves the person taking money inherently in opposition to the interests of the community. --Orange Mike | Talk 14:20, 24 September 2012 (UTC)
    Really? Imagine that I said to you, "There's a bunch of poop-related vandalism in the article about my company, and I don't want to learn how to fix it myself. If you fix it, I'll send you $20 via PayPal". In fixing that vandalism, would you actually be working "inherently in opposition to the interests of the community"? I rather thought that having things like that done was very obviously in our own best interests. WhatamIdoing (talk) 18:33, 24 September 2012 (UTC)
    • Seeking (or even merely accepting) money to do what should be done anyway sends a very bad message that you have to pay to get this done. That message is very much not in the interest of the project and the community. --Orange Mike | Talk 19:06, 24 September 2012 (UTC)
      So if I'm looking at poop vandalism, and it's not being fixed, and then your solution is what, exactly? Leave it there, possibly for weeks or months, until a volunteer sees it? Spend several hours learning how to fix it myself, and then probably having to fend off accusations from a power-tripping teenager about my supposed "conflict of interest"? Congratulate the community for preferring poop-filled articles over the dreadfully contaminating presence of small sums of money?
      Personally, I wouldn't take the money: it's probably ten seconds work and an income tax hassle. But I wouldn't condemn someone else for taking it, either. And I certainly wouldn't condemn someone for taking money to teach someone else how to improve the English Wikipedia. WhatamIdoing (talk) 20:13, 24 September 2012 (UTC)
      What Wikipedia needs is an efficient complaints system for people who have poop on their page. Right now, there really isn't one. Responses to talk page posts can take months, and even OTRS can take days or weeks (if people even find it in the first place). JN466 21:55, 24 September 2012 (UTC)
  • Comment: I should make clear that my concern is not so much with COI or with the fact the the other partner may have something to gain as with the association of Wikipedia's name and prestige with objectives which may not have much to do with our role as provider of free and unbiased information. Consider the possible press releases:
  • "Wikipedia in joint venture with Derby Museum" - no problem
  • "Wikipedia in joint venture with Ministry of Truth, People's Republic of Totalitaristan" - not so good
There is a slippery slope there. One can argue about whether or not "Wikipedia in joint venture with Gibraltar Ministry of Tourism" is too far down it, but there is no doubt it is possible to go too far down it, at great cost to our reputation, and my point is that we need to decide who has the authority to commit us to relationships like this. JohnCD (talk) 16:32, 24 September 2012 (UTC)
  • Oppose - It seems to me that all the discussion about COI, etc., is simply a result of the enormous success of recent projects based on the use of QR codes. If there had not been a huge number of new articles (including DYKs) in various languages, the issues would not have been newsworthy. I am also convinced there are lots of "experts" who are already being paid (either as consultants or simply as part of their normal work) to help write Wikipedia articles for public authorities, political parties, private companies or even individuals. They seldom get into the news but they nevertheless do a good job of enhancing Wikipedia. If stringent new procedures are introduced, these and future activities will suffer to the detriment of the WP project. I would also like to point out that Bamkin's three recent projects were all essentially with the GLAM community. Museums and libraries were the driving force behind them all. Wikipedians in residence are also remunerated for their efforts -- so why not consultants? This does not mean to say that conflicts of interest should not be discussed up front, they should and the rules are already pretty clear. But I strongly believe that most Wikipedians act in good faith and that above all they simply want to improve the coverage and use of the encyclopedia. So if there really is such widespread interest in developing "Wikipedia cities", let's keep the ball rolling. New York and all the other cities showing interest should be encouraged to adopt the approach so as to ensure Wikipedia remains in the forefront of digital encyclopedic development. --Ipigott (talk) 16:37, 24 September 2012 (UTC)
  • See my note just above - timed just before yours, so you probably did not see it when you wrote. This is not about COI, or about remuneration - we have ways to deal with those, based mainly on prompt and full disclosure and the normal WP:BESTCOI practice. Nor is it about genuine GLAM projects with museums and the like. What concerns me is Wikipedia being seen to get into bed with commercial organizations like tourist boards which have aims other than free dissemination of knowledge, and the question is who should have authority to commit Wikipedia to such relationships. JohnCD (talk) 21:15, 24 September 2012 (UTC)
  • Oppose - Unworkable, arrant nonsense. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:33, 24 September 2012 (UTC)
  • Comment. For good or ill, there's little chance of this being accepted. It's a wiki, and (with certain exceptions) people can write what they wish for whatever reason they wish. If and when the entity involved is not the government of Gibraltar but the government of (say) the People's Democratic Republic of Korea, maybe people'll feel differently. And this will happen sooner or later, I suppose. Will it be too late then? Maybe. Probably. But nothing to be done about it, I don't think. Herostratus (talk) 03:59, 25 September 2012 (UTC)
Really? Not even proper disclosure before (or during) the inevitable repeat of the press fiasco (when I'll remind folks, Told you so again)? Not even slowing the rate of DYKs for promotional purposes? Not even tagging non-GLAM project-created articles as part of a promotional project? Not even excluding such projects for non-GLAM entities? Huh. Interesting. I wonder when Google will start algorithmically deprecating Wikipedia results for what are obvious SEO gaming attempts. I'll say it then, too: told you so. --Lexein (talk) 20:39, 30 September 2012 (UTC)
I predict we get a religion and a few major commercial consumer brands before the DPRK tries it. —Cupco 08:17, 25 September 2012 (UTC)
There is a world of difference between someone writing a few articles, and a global publicity campaign announcing that a chapter has entered a partnership with an outside agency to give them low-cost PR through Wikipedia. We're talking about the latter, not the former. JN466 09:11, 25 September 2012 (UTC)
Yes, the articles are not the problem: if they are advertisements or unduly promotional that can be fixed by normal editing, though the "client" may be disappointed or angry. The problem comes if the publicity campaign gives the impression that Wikipedia endorses the client, or that the client in some way controls the relevant parts of Wikipedia's content. JohnCD (talk) 10:06, 25 September 2012 (UTC)
Agree with JN466 and JohnCD. --Lexein (talk) 20:39, 30 September 2012 (UTC)

Articles for creation bot job

First, if this post does not belong in this place, I'm sorry. I didn't know where to put it.

I have an idea. Out at Wikipedia:Requested articles, if you click on one of the subpaages, you will see a list of articles that have been requested. Fortunately, some of them have been created. Unfortunately, that means that some of the links on the requested articles page are blue links- when all links there should be red links. These blue links must be removed by manual editors. What if someone could employ his bot to the task of cleaning up those pages? Legolover26 (talk) 14:18, 28 September 2012 (UTC)

A better place to request this would be at WP:Bot requests, but the idea sounds good. LegoKontribsTalkM 18:27, 28 September 2012 (UTC)
Some of the blue links are not articles but redirects. Apteva (talk) 23:05, 29 September 2012 (UTC)
Some. Even many. But not all. Legolover26 (talk) 12:35, 30 September 2012 (UTC)

RfC on creation of a new thematic organization to continue the work of the United States and Canada Education Programs

The Wikimedia Foundation formed a Working Group in May 2012 to propose a future structure for the United States and Canada Education Programs. The Working Group, through in-person meetings and task force work, now proposes that the United States and Canada Education Program be operated as a Thematic Organization operating as a fully independent non-profit entity.

There is an RfC on this proposal at Wikipedia:Education Working Group/RfC; please read the more detailed information and consider supporting or opposing. If you have questions, please post them at that page rather than here in order to keep the discussion centralized. Mike Christie (talk - contribs - library) 16:38, 29 September 2012 (UTC)

Proposal: enable HotCat for all editors by default

==== Proposal 3—Enable Hot Cat by default for all registered users on the English Wikipedia—wins on votes and weight of arguments. ====
  • Original proposal: no consensus, with objections pointing to potential vandalism.
  • Convert Hotcat to a user right: Snowed under
  • Proposal 1: Three votes, two first-choice and one second-choice. All ask for a trial period to check if the scheme works.
  • Proposal 2: Shot down
  • Proposal 3: Four votes, two first-choice and two second-choice. Three reasons: registered users less likely to vandalize; if user makes a mistake, editors can provide feedback if account is registered; used on Polish WP effectively for over a year per nom.
  • Proposal 4: Four votes, one first-choice, two second-choice and one third-choice. Safest option per first-choice voter.
  • Proposal 5: Not a meaningful proposal with its impossible wording and consequent light-hearted discussion.
Churn and change (talk) 04:44, 2 October 2012 (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.

I think that Wikipedia:HotCat is a very useful gadget. It makes adding categories much easier. It is enabled by default on pl wikipedia. Why not on en wikipedia? It is a pure UI improvement. A lot of new or first time editors I talk with complain they cannot "tag" Wikipedia articles, and when I shown them the HotCat they ask me why such a useful tool it hidden in the depths of the preferences. Let's make it available to all by default (most inexperienced editors don't bother with preferences). --Piotr Konieczny aka Prokonsul Piotrus| reply here 18:02, 26 August 2012 (UTC)

Proposals
  • Original proposal: enable HotCat for all editors by default
  • Another proposal: Convert Hotcat to a user-right
  • Revised Proposal 1: Enable Hot Cat by default for all editors, but add a confirmation page (diff showing, save button needs pressing) for all non-autoconfirmed and (if possible) for all first time editors.
  • Revised Proposal 2: Enable Hot Cat by default for all editors, but for all non-autoconfirmed redirect them to a new appropriate page based on Wikipedia:Edit requests.
  • Revised Proposal 3: Enable Hot Cat by default for all registered editors.
  • Revised Proposal 4: Enable Hot Cat by default for all autoconfirmed editors.
  • Revised Proposal 5: Oppose any change to make Hot Cat more accessible.
Extended content
I wish someone would fix HotCat to stop allowing people to place maintenance categories directly on articles. Anomie⚔ 18:43, 26 August 2012 (UTC)
I also agree with others that a save step should be added. --Timeshifter (talk) 15:31, 28 August 2012 (UTC)
To avoid IP vandalism I support it being on by default only for logged-in users. --Timeshifter (talk) 06:51, 30 August 2012 (UTC)
  • Oppose. It allows category removal with one click, no confirmation. Readers should not have a default setting that will cause them to edit accidentally, either due to stray clicks or 'what does that (-) mean' curiosity. They might not even notice after the fact that they edited the page until they get a warning for it. Kilopi (talk) 04:05, 27 August 2012 (UTC)
  • Strong Oppose - And further, there should be a way for admins to remove the ability from editors when it's abused, just like rollback can be. - jc37 17:02, 27 August 2012 (UTC)
    You know, you might get more conditional support for your proposals if you weren't so unconditionally negative about others' proposals. Why not say "Conditional support if a save step is added, and if admins had a way to remove the ability from editors when it's abused, just like rollback can be." --Timeshifter (talk) 15:29, 28 August 2012 (UTC)
    First, I have commented on several proposals on this page alone, varying from support to oppose. But even if I hadn't, these aren't popularity contests, nor should they ever be quid pro quo or "I'll support yours if you support mine". Someone should support or oppose for honest reasons, not for some tactical reason. I'm honest in my dealings here, and I will try to continue to be so. If this means that you or other may oppose some proposal I have in the future, so be it. Wouldn't be the first time I've seen people oppose for such reasons, and unfortunately, probably won't be the last. - jc37 18:16, 28 August 2012 (UTC)
    It's not a tactical thing. It is a cooperative thing. And you did not address my main point about whether you would support this if a save step were added, and if admins had a way to remove the ability from editors when it's abused, just like rollback can be. --Timeshifter (talk) 01:19, 29 August 2012 (UTC)
    "Cooperation" which suggests if I support others' proposals, they may be more likely to support mine? How is that not tactical : )
    Anyway, you want to see what I would likely support? Ok, I'll start a sub thread. - jc37 20:16, 29 August 2012 (UTC)
  • While I love HotCat, the lack of a save step makes it very easy to make mistakes by accident, especially when navigating a cluttered category box (and god help users of touchscreens). We need to make it easier to have these tools available to new users, but this is one where turning it on outright might cause more problems than it solves.
  • Conditional support/oppose. I support having HotCat as a default for placing in new categories, but oppose having it for category removal. The latter can be easily abused. Perhaps HotCat can be tweaked for this?--SGCM (talk) 17:50, 29 August 2012 (UTC)
  • Oppose, as I recognize the idea in good faith. I have a good deal of concern that this would introduce a new wave of "category vandalism", from editors who would choose to remove reams of categories from articles by mass-clicking the minus feature. This would often be really hard to spot for patrollers et al. because category removal is at times a good faith activity, sometimes en masse. In other words, this could be an easy way to facilitate sneaky vandalism, which is the reason why I cannot currently support even if there was an 'are you sure' confirmation. I'm also not too big on having just the 'add' feature enabled by default - it is my general impression that we would get a lot of red-link categories on articles from newbies, who would not know what they are doing and fail to actually create the relevant cat page itself. Not to mention that many of these would be useless and redundant categories, though not all. Generally, I think the 'cutoff' works well - people who know HotCat exists in gadgets are generally smart enough to use cats appropriately, those who don't know it exists, well, are more likely to make mistakes, potentially outweighing the benefits of the people who wouldn't. I suppose too I'd rather not add HotCat abuse to the frontlist of things administrators should be monitoring for, whether or not there is a way for them to remove it on people. NTox · talk 05:11, 30 August 2012 (UTC)
It is not easy to create red-link categories with HotCat. One has to ignore the suggestions that pop up. I think the benefit of making the addition of categories easier would outweigh the problems caused. HotCat makes it easy to see what categories exist. Maybe HotCat should be enabled by default only for logged-in users. Then the problem of category deletion vandalism is greatly lessened. Category deletion is necessary if one is changing from one category to a more apt category. --Timeshifter (talk) 06:47, 30 August 2012 (UTC)
The 'add' feature is something that I would be more comfortable with, and I agree that this change would increase constructive categorization activity. However, it would also increase non-constructive uses - the trouble is the speculation on these costs v. benefits. You are right that it is difficult to ignore HotCat's suggestions, however, people who are not familiar with the naming conventions would have trouble finding what they want anyway. All in all, I don't absolutely disagree with you - there is a lot of good that would come out of this, but I regret to say that I am concerned about the drawbacks, even if it only contained the 'add' feature, or if it was only activated on logged-in users. Lucky for us, unregistered people who love cats would still after all be able to work with them manually. NTox · talk 16:36, 30 August 2012 (UTC)
Why deny logged-in users this tool by default? We trust them to add and remove categories now, but make it unnecessarily difficult to do so many things on Wikipedia. This is just one more reason, among many, that there is a decline in active editors. We can always turn this back to being an optional gadget if the cost-benefit analysis is unfavorable. --Timeshifter (talk) 02:47, 31 August 2012 (UTC)
  • Oppose as per User:Kilopi. I think anyone who purposely activates this gadget is more likely to familiarize him/herself with its features and is more careful in applying it than occasional editors or vandals. -- P 1 9 9  ✉ 14:06, 30 August 2012 (UTC)
Would you support it if it were only turned on by default for logged-in users? Kilopi was worried about category removal. If it causes more problems than it solves it can always be put back to being an optional gadget. Category removal is necessary when changing from one category to another. --Timeshifter (talk) 03:34, 31 August 2012 (UTC)
I think having it limited only to logged in users is reasonable, I think this is the approach they have on pl wiki. --Piotr Konieczny aka Prokonsul Piotrus| reply here 15:52, 11 September 2012 (UTC)

Convert Hotcat to a user-right

  • Remove hotcat as a gadget. Make it an integrated part of the mediawiki software. (So that it doesn't require JS, etc.)
  • Implement it as a user-right (like rollback). In which hotcat is the only right in that user-right package. This user-right is added to the administrator package. Admins can grant/remove this user-right at their discretion per whatever criteria is set (similar to other admin-given user-rights).
  • Add in preferences the ability to have a save/edit summary. Have this default to on. Only advanced users should be turning the edit summary part off. And of course, abuse can lead to removal.

There may be other details which may need to be ironed out, but this is what I would prefer. - jc37 20:16, 29 August 2012 (UTC)

  • Oppose We have a lot of user rights already, and they should be saved for things that can't easily be handled with an occasional WP:TOPICBAN. WhatamIdoing (talk) 22:19, 29 August 2012 (UTC)
    You're preachin' to the choir here : ) - I'm merely responding to what I would support related to hotcat. Gadgets should be removable in their design, since they're apparently not, I proposed something which is. - jc37 03:41, 30 August 2012 (UTC)
  • Oppose, for now. While there is a part of me that likes that user rights can be inducers of (good) behavior, I am not aware of very many cases in which HotCat has been significantly abused. Therefore, I would be concerned about restricting its use if there are not many that it needs to be restricted from. If there is sufficient evidence that the abuse of HotCat is a significant problem, I may reconsider. NTox · talk 04:37, 30 August 2012 (UTC)

Revised proposals

After reading the above comments, here is are modified proposals that I hope will be a step closer towards obtaining consensus in support:

Proposal 1: Enable Hot Cat by default for all editors, but add a confirmation page (diff showing, save button needs pressing) for all non-autoconfirmed and (if possible) for all first time editors.

Comment: majority of the concerns raised were about the possibility of 1-click vandalism. Adding the need to confirm this change would make using hotcat similar to editing the page (for new editors), although still making working with categories easier in general. The technical implementation should not be difficult; hot cat asks for confirmation of all changes other than 1-category anyway, this would simply eliminate this exception for non-autoconfirmed flags. It would be nice if Hot Cat could do it for all first time users too, but this may be more difficult to implement, so I treat this part as more of a "it would be nice but not necessary" clause. --Piotr Konieczny aka Prokonsul Piotrus| reply here 16:35, 24 September 2012 (UTC)

Support
Oppose

Proposal 2: Enable Hot Cat by default for all editors, but for all non-autoconfirmed redirect them to a new appropriate page based on Wikipedia:Edit requests.

Comment: this would allow everyone to use the tool to suggest changes, but would prevent them from making them. I am not very fond of it, as it imposes more burden on the community, but it would still be better than the current situation where most readers have no idea how to deal with categories. --Piotr Konieczny aka Prokonsul Piotrus| reply here 16:35, 24 September 2012 (UTC)

Support
Oppose
  • I don't think it makes much sense to use the edit request page for this. Non-autoconfirmed editors are both allowed and technically able to add categories by hand, after all. Jafeluv (talk) 10:14, 25 September 2012 (UTC)

Proposal 3: Enable Hot Cat by default for all registered editors.

Comment: this would prevent anonymous editors from using Hot Cat. Personally I am not very fond of it, as it would remove the ability of most Wikipedia readers to become aware of this useful tool. --Piotr Konieczny aka Prokonsul Piotrus| reply here 16:35, 24 September 2012 (UTC)

Support
  • First choice. If you screw up, we can explain, and give you directions on how to turn the gadget off in My Preferences. WhatamIdoing (talk) 18:28, 24 September 2012 (UTC)
  • Second choice. This is what Polish Wikipedia has been doing for over a year, and I don't hear any grumbling there about abuse or such. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:54, 25 September 2012 (UTC)
  • On balance, I think this is the best solution. Since we require every page to be categorized, it makes sense to provide an easy way to do this right from the start. I assume the risk of one-click vandalism is significantly lower for new accounts than for anonymous editors, which is why I prefer this rather than #4. The typical reader cares little for our categorization structures, and it only takes a few clicks to create an account anyway. This option would allow a more effective categorization interface for editors while avoiding the worst downsides. Jafeluv (talk) 10:56, 25 September 2012 (UTC)
  • Second choice. I don't think the risk of "category vandalism" is all that much. — Hex (❝?!❞) 09:18, 29 September 2012 (UTC)
Oppose

Proposal 4: Enable Hot Cat by default for all autoconfirmed editors.

Comment: progressing in restricting access, this would make this tool as restricted as the move option. Still better than the current situation, where a majority of registered and constructive editors is not aware of it. --Piotr Konieczny aka Prokonsul Piotrus| reply here 16:35, 24 September 2012 (UTC)

Support
Oppose

Proposal 5: Oppose any change to make Hot Cat more accessible.

Comment: to gauge the extent to which the community rejects the use of Hot Cat. --Piotr Konieczny aka Prokonsul Piotrus| reply here 16:35, 24 September 2012 (UTC)

Support
Oppose
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.

Fact sheet, a new type of article

Someone decided to create a fact sheet about a country, namely Fact sheet on India. The page has some POV issues, so it should not be considered the ideal example, but what I want to discuss here is desirability of having separate pages for numerical data (statistics) about a country. It seems to me that such a practice would be running foul of Wikipedia:NOTSTATS, but perhaps we should discuss seriously creating creating Category: fact sheets and agreeing what kind of info Wikipedia fact sheets should contain. Tijfo098 (talk) 06:29, 22 September 2012 (UTC)

The problem is, once you start, when do you stop? If countries, why not cities. If cities, why not cars. If cars, why not video game bosses. Who will draw the subjective line for what is and what is not acceptable? India is notable but so is Bowser. —  HELLKNOWZ  ▎TALK 07:10, 22 September 2012 (UTC)
Well, we already have a form of mini-factsheets for all that, wp:infoboxes. Except we include them in articles for now. We also have in-article lists, but also stand-alone lists. So, it's not a question of limiting their application to countries only. The fact sheet article has some external links with examples for planets, etc. Some of our more elaborate infoboxes could well be stand-alone fact sheets if it weren't for the narrow formatting. See {{infobox cadmium}} for example. Tijfo098 (talk) 07:19, 22 September 2012 (UTC)
Not all statistics about a topic are necessary or desirable for an encyclopedic overview: just a selection, and that's what infoboxes are for. It would be worthwhile in itself to have a free, constantly updated set of data about notable things, but that sounds like a job for Wikidata rather than Wikipedia. MartinPoulter (talk) 08:48, 22 September 2012 (UTC)
Wikidata sounds promising. When/if it becomes available we may be able to have some more separation of presentation and content. I can imagine fact sheets like those infoboxes pulling data from there. Tijfo098 (talk) 04:12, 23 September 2012 (UTC)

Comment I already thought about something like that myself, mainly in connection with some mathematics articles, where such a page could hold eg. some computed data, that is too excessive for the article, but might still be interesting for a reader. Would it be acceptable for those pages to also contain original research? In that way, I could, for example, compute some data, which would not be encyclopedic, because it has not previously been published, but might still be interesting for a reader. -- Toshio Yamaguchi (tlk−ctb) 08:52, 1 October 2012 (UTC)

The idea of including original research raises a red flag: summarising information already published in another source is good, and that can include obvious calculations, but we shouldn't go beyond that. . dave souza, talk 09:18, 1 October 2012 (UTC)
Okay, I agree. So summarizing verifiable, published data that is too excessive for an article seems to be a useful purpose. -- Toshio Yamaguchi (tlk−ctb) 19:27, 1 October 2012 (UTC)

Flagging comment errors

Hi, occasionally I come across errors where an HTML comment <!-- .... --> is accidentally not closed, causing a large chunk of the article to disappear. Sometimes this can go unnnoticed for a long time. I wonder if there could be some kind of alert to prevent this happening. 86.177.105.72 (talk) 03:17, 28 September 2012 (UTC)

We have a problem with unpaired <ref> tags, too. WhatamIdoing (talk) 19:12, 1 October 2012 (UTC)

Ask for an edit summary when rollback in used from watchlist

Consensus not to change current behavior, as rollback is meant to be fast, and edit summary is not useful for rolling back vandalism. One editor mentioned the change helping mobile users, but got no support from anyone else. Churn and change (talk) 23:36, 1 October 2012 (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.

I've noticed a big difference in the way rollback acts between your watchlist and when viewing a diff. In the latter case, it asks for an edit summary and there is an 'ok' and 'cancel' button, effectively given you an opportunity to stop the rollback. The former does not provide this prompt - it just goes. Often this can lead to frustration, accusations, and general bad faith assumptions.

I don't figure this needs support of the community, but I figured its best to have this formal discussion just for future referencing.

I'd like to propose that:

  • A) The watchlist rollback be adjusted to act like the diff rollback
  • B) That both highlight 'cancel' by default in the prompt, providing another level of protection from misclicks or misenters.

-- Floydian τ ¢ 16:55, 18 August 2012 (UTC)

Extended content
I just get "Rollback successful" either way - and that's the way I want it, if I'm using rollback I want to spend as little energy as possible reverting vandalism. Maybe you have a custom gadget or script running? Franamax (talk) 17:38, 18 August 2012 (UTC)
You sure it's not undo that's giving you the change to 'stop' and add a summery? The whole point of rollback is that it's a one step action. ♫ Melodia Chaconne ♫ (talk) 17:41, 18 August 2012 (UTC)
I haven't noticed that. Are you confusing server rollback with Twinkle rollback? Let me run a quick test. Can someone make any old edit in my sandbox so I can revert it? elektrikSHOOS (talk) 17:52, 18 August 2012 (UTC)
(Thanks, Franamax, for any old edit.) I'm not noticing a difference on server rollback. Twinkle rollback, however, presents an edit summary box when you click that one. elektrikSHOOS (talk) 17:59, 18 August 2012 (UTC)
  • I don't know about anyone else, but I've never intentionally used the rollback link from my watchlist. The times I've wanted raw rollback have all been from user contribution pages, for the vast majority of vandalism reversion I prefer at least a generic vandalism removal summary. That said, if someone is clicking on a an raw rollback link for some reason, it should respond the same everywhere, which by default is to roll back without further inquiry. What may be a good idea would be to educate editors about the .css code to remove rollback links from their watch lists, and maybe adding it to a preferences menu. — Preceding unsigned comment added by Monty845 (talk • contribs) 04:30, 19 August 2012‎
OpposeVandalism is pretty obvious. Can't imagine an edit summary needed for the stuff that I have rollbacked. I am very conservative about it but curses and filthy language do not need an explanation. Vandalism seems to explain it well enough. Actually it is self-explanatory.Mugginsx (talk) 22:36, 23 August 2012 (UTC)
  • You've sidestepped the issue being raised here. It's not about needing an edit summary to explain the rollback; it's about adding a prompt so that when you accidentally click rollback, you aren't rushing to revert yourself before getting mugged by the community.
  • Comment: Sorry, I have not had that problem yet. Mugginsx (talk) 18:49, 8 September 2012 (UTC)
  • Oppose - I know LTA when I see it, even when just seeing it on my watchlist. Whenever an edit summary is needed, Rollback is not used, plain and simple.--Jasper Deng (talk) 22:47, 23 August 2012 (UTC)
    You've completely sidestepped the point here and likely voted based on the header of this section. In either case it needs to be removed from the watchlist. No rollback should be performed without checking an edit anyways, and all too often it bounces around as your watchlist loads and gets clicked on, instantly rolling back without any check. - Floydian τ ¢ 14:48, 24 August 2012 (UTC)
    I'm sorry but I also have to oppose that. I don't need annoying prompts wasting my time especially when I have LTA. If this becomes a feature it must allow an opt-out for me.--Jasper Deng (talk) 23:58, 24 August 2012 (UTC)
  • Oppose. Rollback is designed as a tool for cleaning up clear and/or large-quantity abuse or vandalism. Adding the option for an edit summary changes the tool. If I need an edit summary, I just use the undo button if it's one edit to revert or the edit button from a comparative view to revert several edits at once, like I did here. —C.Fred (talk) 14:38, 24 August 2012 (UTC)
    And if you don't notice that you accidentally clicked it, you're chastised. I know it is designed for vandalism, but its placement at the end of an entry in the watchlist makes it very susceptible to moving around as the page loads. - Floydian τ ¢ 14:48, 24 August 2012 (UTC)
    That sounds like a problem with the js used on the watchlist, although from what I understand someone recently committed a fix for at least some of the problematicness there. As for accidental clickings, just explaining that it was an accident should be enough; such happens, and given the thing on this project about assuming good faith, folks shouldn't be jumping to the chastising in the first place, so that likewise seems more their problem than one with the tool. Or am I mixing this up with a less habitually backstabbing project? -— Isarra ༆ 17:06, 7 September 2012 (UTC)
  • Decided to voice a formal oppose. Server rollback is designed to be a quck, one-step action. That's why it's only supposed to be used in certain ways, and is only given to trustworthy editors who ask for it. If you would like the option of adding an edit summary, use Twinkle instead, which can perform more or less the same way (albeit implemented slightly differently) or undoing the edit manually. In response to the watchlist concerns above, there do exist cases where rolling back directly from the watchlist is acceptable, such as obviously vandalistic edits like page blanking or repeated vandalistic edits from the same editor. elektrikSHOOS (talk) 15:01, 24 August 2012 (UTC)
As I noted in my testing above, the rollback button in your watchlist functions identically to the rollback button in a diff, so I'm also not entirely sure what you're intending this proposal to address, either. elektrikSHOOS (talk) 15:04, 24 August 2012 (UTC)
I suppose the Twinkle one is the one that does it properly. Again, if you aren't checking the edit, you shouldn't be rolling back - Why does it exist on the watchlist? The point, again, is not about wanting to add an edit summary, but to not have a series of edits performed without even a simple "You are about to rollback X edits. Continue?". Perhaps I'd like an opt-in to the link on the watchlist... - Floydian τ ¢ 00:07, 25 August 2012 (UTC)
You're kind of missing the whole point of rollback, though - it's designed to be used in situations where speed is more important than leaving an edit summary and explaining yourself. This has been well established by years of consensus to be an acceptable response to certain edits. By prompting the user to leave an edit summary, you essentially turn it into the undo button, which defeats the purpose of its existence. (Also, just a helpful reminder to you, you can hide the rollback button from appearing on your watchlist by adding .page-Special_Watchlist .mw-rollback-link {display:none;​} to your vector.css page.) elektrikSHOOS (talk) 00:14, 25 August 2012 (UTC)

I agree that this would defeat the purpose of rollback. Gigs (talk) 13:25, 28 August 2012 (UTC)

  • Strong support - This would be a great boon to touch pad/screen users. For those who oppose, would you support if there was an option in preferences to turn edit summary prompt back off (though with the default set to on)? There are many ways to implement this if adding preferences. Such as having preferences for: whether the link should or should not show on the watchlist; whether there should be an edit summary prompt when clicked on from the watchlist (or recent changes, for that matter), etc. I would think that this would be the best of all worlds. And I think edit summary usage should default to on, both for several of the reasons already noted, and because only experienced rollbackers should be rolling back with no edit summary. And doing so would only be a quick trip to preferences. - jc37 20:32, 29 August 2012 (UTC)
    • I would prefer to have default off as I don't believe the majority of admins and rollbackers use a mobile device. In your situation, it's already possible to turn it off with a CSS trick.--Jasper Deng (talk) 00:45, 30 August 2012 (UTC)
  • Oppose per Jasper Deng's "Whenever an edit summary is needed, Rollback is not used, plain and simple." Sven Manguard Wha? 14:42, 3 September 2012 (UTC)
  • Oppose - Rollback is the most straightforward way to revert nonconstructive edits. If you need to ask for an edit summary, it isn't so straight forward anymore. There's always undo, Twinkle and of course, manual reversion. Michaelzeng7 (talk) 20:56, 15 September 2012 (UTC)
  • Oppose - Using the revert edits is the most easy way to press one button and all the edits be reverted. It is fast and easy and I wanna keep it that way.--Astros4477 (talk) 03:26, 16 September 2012 (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.

Orange fixit box on mainpage

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the debate may be found at the bottom of the discussion.

Hi all, I originally floated this idea at Talk:Main_Page/Archive_165#An_idea_for_converting_readers_to_editors....3F and gathered some positive feedback there but nothing eventuated, so I will structure it a bit better here. The idea is to try and engage more readers into writers (but try and do it a bit better than it was done many moons ago.

So we have a small pale orange box which lists maybe 2-5 articles identified as good, broad candidates for fixing - thus maybe articles such as pink, North Island or Screwdriver rather than, say, quantum theory or some esoteric maths/physics/ sociology etc. We select them on a page similar to Wikipedia:Today's featured article/requests and load them up for 24 hours. The aim would be to see how many constructive edits we could get to articles.

Other question is, how would we fit it in...so folks can vote below....If cautious, we could run as a three month trial only, so if you oppose setting it in stone it'd be great to at least give it a time-limited trial.Casliber (talk · contribs) 01:46, 25 August 2012 (UTC)

Support

  1. I think this would be a good idea - we could do it as a banner ad - "Here's five articles that could use improvement - please join us and help us build this encyclopedia" or something. Maybe put a banner on the left side by the toolbox links that would only show to IP users. Ego White Tray (talk) 04:19, 25 August 2012 (UTC)
  2. I think this is the best suggestion for converting readers into editors that I've heard for a long time. If we could organize a "coaching" team - of Wikipedians with a reputation for helping newbies and not biting them then we could shepherd them through the process. So instead of getting a wild collection of crappy edits that would have to be reverted, we could encourage people through the process. Adjusting the number of articles presented (and picking the kind that newbies do best at) would allow us to control the flood of edits to those small numbers of articles. We could even have the links go to "sandbox" versions of those articles, which the shepherding Wikipedians could "promote" to the live articles when they feel that a good point has been reached. That would imply less panicky reversions and allow more time for constructive advice. At any rate, I think it's well worth some serious discussion followed by a trial period. SteveBaker (talk) 14:25, 25 August 2012 (UTC)
    The above comes across as a radically different (and much better) proposal — one to develop a process in which newcomers are given advice and assistance instead of being sent to "shoddy" articles with the vague instruction to improve them. —David Levy 15:42, 25 August 2012 (UTC)
    I agree it has merit - does the Wikipedia:Teahouse have sufficient emphasis on article work? I have not looked at that aspect in detail.....I know it is a focussed place to help new editors and seems to be helping with retention rates, so building on this is a very good idea. Casliber (talk · contribs) 10:18, 26 August 2012 (UTC)
  3. This is an interesting idea, and well worth giving it a trial. There would be nothing to lose (any vandalism likely would be watched and reverted quickly) and much to gain (new editors). We need to be more open to finding ways to attract new editors. First Light (talk) 15:15, 27 August 2012 (UTC)
    Did you read my comments (in which I explained why I believe that we would lose potential editors, whom the proposed setup would frustrate, confuse and alienate)? If so, I'm interested in learning why you disagree. —David Levy 15:48, 27 August 2012 (UTC)
  4. Tentative support as a trial - As long as it's clear that the over-riding main goal here is to provide opportunities for editors to help edit the encyclopedia. I can think of several ways to implement this, but I'll save that for some other discussion : ) - jc37 17:17, 27 August 2012 (UTC)
  5. Support if low-key I think we can try it as long as it's low-key. Gigs (talk) 13:23, 28 August 2012 (UTC)
  6. A small box, as described, would fit to the right of "Other areas of Wikipedia" (at the bottom) without making the page much busier than it is. All the best, [[User:Miniapolis|/b> 17:17, 27 August 2012 (UTC)
  7. Tentative support as a trial. After reading all the good pro and con arguments, I'm supporting a trial period because there is merit in this idea. Having such a box may attract new editors, but also bring it to the attention of experienced editors who may be induced to improve the articles. I like to see a trial period only, because we don't know if it will work or just attract vandalism and/or unconstructive edits. If it doesn't work out, we can stop the trial before we lose to many frustrated editors (as referred to by David Levy. -- P 1 9 9  ✉ 23:43, 29 August 2012 (UTC)
    How would experienced editors benefit from such a setup? They can easily find articles in need of improvement (including ones whose topics interest them) via other means.
    You note that "if it doesn't work out, we can stop the trial before we lose too many frustrated editors". But how will we know how many users are leaving in frustration stemming from edit conflicts? (They might not even manage to edit before this occurs.) —David Levy 20:21, 4 September 2012 (UTC)
  8. Tentative support as a trial I was thinking about how we could use banner ads to encourage more editors yesterday, in fact, and am glad to see this here. Word it so people will feel their contributions are important somehow... it doesn't need to be for all viewers, either, right? They have the ability to try it on 1% or so of people to figure out how well it can work without a major rush of potential vandalism. PhnomPencil (✉) 04:21, 1 September 2012 (UTC)
  9. Support as a trial. The six content boxes ensure that relatively polished content attracts a lot of attention, and I'm completely unconvinced by the suggestion that we should deliberately give the impression that most of our content is brilliant. I see that as counterproductive.

    David Levy correctly points out that people prefer to contribute to prominent topics which they can easily add to, but the solution is to prioritise plugging those sorts of gaps. To my knowledge, there are no glossaries at Wikipedia:Featured Lists – in my experience some worthwhile glossaries haven't even been created yet, and they make great collaborations. List of national flags currently redirects to Gallery of sovereign-state flags: surely there is room for the redirect to become a vexillology list, and I can't think of a better way to kick it off than by asking for help on a high profile international page. There is also plenty of low-hanging fruit at Wikipedia:Vital articles/Expanded, such as East and square mile.

    I do recognise many of David's concerns. In particular, we would need to carefully monitor what help is given to those who land on the page: would we need special edit notices for instance? Or a dedicated help banner at the top of that article? These things would need to be worked out before the trial started. But weighing the worries against the potential benefits in content improvement and editor recruitment/retention, I can't see a good reason not to at least try this. —WFC— 21:03, 1 September 2012 (UTC)

  10. Support trial It would be nice for everyone to get a sense of what others see as lacking. May recruit good people. May develop as an episodic addition to the main page.
  11. Support trial One of the biggest hurdles new contributors face is not knowing what is best to help work on. For many years now, we have removed any substantial mention of community work that needs doing from the Main Page and moved it to the Community Portal. With the number of active editors shrinking, I think it's time the Main Page got an invitation to help included again. I'd also like to offer my help with such a trial, as part of my work at the Foundation on the experiments team. Steven Walling • talk 00:36, 3 September 2012 (UTC)
    I support the idea of actively recruiting new editors via the main page. But why, in your view, does it make sense to send them directly to articles without any guidance beyond a vague instruction to improve them? —David Levy 20:21, 4 September 2012 (UTC)
    There are many types of people who could possibly register, but we know that there are two types that definitely make up some of new editors: A) people who've edited anonymously before, and have gained some experience even if it appears they are new, and B) people interested and knowledgeable about the subject at hand. People in the first category have some basic editing skill, but need to figure out the subject matter and how to deal with it. People in the latter category just need editing skills. How people learn these two things is by doing. If there are articles that need obvious help (i.e. not asking for GA/FA here), and there are people who are willing, we should be definitely directing new editors there. There is too much that needs cleanup for us to wait for every new person to become an expert editor before diving in to serious work. Steven Walling • talk 21:45, 9 September 2012 (UTC)
    If there are articles that need obvious help (i.e. not asking for GA/FA here), and there are people who are willing, we should be definitely directing new editors there.
    But why should we discourage them gaining a basic understanding of Wikipedia's editorial practices first?
    There is too much that needs cleanup for us to wait for every new person to become an expert editor before diving in to serious work.
    Who said anything about "expert editors"? I've repeatedly and unambiguously referred to "a basic understanding".
    We don't require users to read the introductory pages, but nor do we instruct them to skip directly to editing instead. That's what's been proposed here. Readers arriving at the main page would be told to ignore the help pages and jump straight to editing. Why is that desirable? And what about the edit conflicts? —David Levy 05:23, 12 September 2012 (UTC)
  12. Support trial, the Ambassador program had a lot of success with events where experienced got together to work on articles. One article that turned out really well is Tradition, though not a GA or FA by any means, it became a much more useful and well rounded article because of the editing team, Sadads (talk) 17:53, 3 September 2012 (UTC)
    You meant to write "experienced editors", yes? (That seems consistent with the explanation provided at Wikipedia:Ambassadors/Editing Fridays.) How is that relevant to a proposal to send newcomers to articles, with no preparation apart from a vague instruction to improve them? —David Levy 20:21, 4 September 2012 (UTC)
    Generally, we have millions of people who have created accounts which means they are mildly aware of the opportunity to contribute. Inviting people to improve (and presumably having links to learn how to improve or find a tutorial in the box), would encourage them to reengage, and help make the public a little bit more aware that an editing community exists (which most people are ignorant of), whether or not they help contribute. Did you read how I said "trial"? If there is a serious problem that arises with this action, then we put a stop to it, but for now I am going to be influenced by the attempt to do good, instead of being a Debby downer. There is always the possibility of unintended positive consequences to every attempt at greater inclusion! Sadads (talk) 19:41, 13 September 2012 (UTC)
    Inviting people to improve (and presumably having links to learn how to improve or find a tutorial in the box), would encourage them to reengage,
    Agreed. I support such efforts. That isn't what's been proposed here. The idea is to send users directly to articles with a vague instruction to improve them, effectively discouraging them from visiting Wikipedia:Introduction (already linked at the top of the page).
    Did you read how I said "trial"? If there is a serious problem that arises with this action, then we put a stop to it,
    As I asked above, how will we know how many users are leaving in frustration stemming from edit conflicts? They might not even manage to save any revisions before this occurs.
    but for now I am going to be influenced by the attempt to do good, instead of being a Debby downer.
    But I'm not simply saying "let's not do this". In the "Discuss" subsection, I suggested an alternative implementation that I believe would work better. No one has replied to that message (timestamped "15:42, 25 August 2012 (UTC)"). —David Levy 00:44, 18 September 2012 (UTC)
  13. Support Seems like it could help people get engaged and build the project--new users are not the enemy and we shouldn't be afraid of them. Mark Arsten (talk) 15:47, 4 September 2012 (UTC)
    You've addressed a straw man instead of the actual arguments against the proposal (based upon concerns that the new editors will be adversely affected, not that they pose a threat). —David Levy 20:21, 4 September 2012 (UTC)
  14. Tentative support of trial with the condition that it is toward the bottom of the main page, not the top. We don't want the first thing people see to be "here's some crap that needs shoveled, have at it." --Nouniquenames (talk) 14:47, 10 September 2012 (UTC)
  15. Support trial conditionally. The main thing I want to see added to this: each article listing should describe (briefly!) one concrete way in which the article needs improvement. A specific call to action would be much more effective than a general "hey guys here's some shitty articles help us out." I would also add a message reminding people that they don't need user accounts to edit. Besides aiding conversion, I think this would be great for normal editors who have no clue what to edit and want to pitch in on a group effort. There is the risk that the articles may receive too much attention, particularly from newbies, and end up requiring cleanup or getting edit conflicts. But that's what trials are for, gathering data. Dcoetzee 00:21, 18 September 2012 (UTC)
    How do you propose we gather data on the number of edit conflicts that occur and the number of new editors who frustratedly quit as a result? —David Levy 20:14, 19 September 2012 (UTC)
    I expected experienced editors to also participate. They would be likely to offer constructive feedback on their experience with technical issues and how much cleanup was required. Dcoetzee 01:26, 24 September 2012 (UTC)
  16. Support it sounds sort of like a collaboration of the day effort.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 14:05, 18 September 2012 (UTC)
  17. Mostly support; I mostly agree with the support !votes above, but there's a problem. I feel that the main page is a place to showcase some of our best content. (Some might gripe that DYK criteria are not high enough, but if those articles have a page of readable sourced content and no serious warning templates &c then they're already several rungs higher up the quality ladder than the average new article). On the flipside, the best place to recruit new editors is where the need for improvement is clear even to those who doesn't know our rules & tools. Asking random strangers to work with templates or MOS arcana would be a recipe for disaster, but they're more likely to succeed in improving an article full of typos or obvious lies. So that means... we'd be choosing content for the front page which has basic flaws that laypeople could point and laugh at. So, I think the proposal needs some improvement, but it's promising. bobrayner (talk) 12:18, 20 September 2012 (UTC)
  18. Support - on the condition that (as noted in the 'Oppose' section) it is presented in a way that doesn't encourage those who are unfamiliar with what is expected of a Wikipedia article to edit the concerned pages. This is certainly something that could do a good service in pushing up the standard of some articles on the wiki, as long as it is implemented properly. --SUFC Boy 22:31, 23 September 2012 (UTC)
  19. Strong support for the principle of having more Get Started Editing content on the Main Page. Weak Support for this particular implementation of it: I think the opposers' concerns about sending many people to a few articles, with problems not necessarily easily fixable, is not great. But I'd rather have that, and establish the principle and then try and improve on it, than not have it at all, and have the concept languish another year or three. As to what we ideally would do: present random selections from a suitable list of candidates with clearly identified problems, together with specific guidance on solving that type of problem. For instance, "random article that needs wikifying", + "how to wikify". "random article with a missing source" + "how to solve a missing source problem". etc (ideally categorised by topic, so people can identify areas of interest and not just work on random tasks). This may muck up the Main Page caching unless done with some clever tech (Javascript?), but it's absolutely worth doing. Rd232 talk 13:31, 26 September 2012 (UTC)
  20. Support We have a "featured article of the day", an "image of the day" and DYK of the hour. A targeted 3 articles changed daily to encourage fixing would be good, worth a trial. Not as many as 5; too much choice tends to deter. FT2 (Talk | email) 12:07, 4 October 2012 (UTC)

Oppose

  1. We already encourage editing, less directly, by prominently referring to Wikipedia as "the free encyclopedia that anyone can edit" (linked to Wikipedia:Introduction) and linking to numerous editable articles.
    The concern, I take it, is that some potential editors are reluctant to dive in. But that isn't entirely bad, as this motivates them to familiarize themselves with our basic principles and practices beforehand.
    Sending newcomers directly to articles specifically for the purpose of editing them will generate primarily unhelpful (even if well-intentioned) results. And when we have to revert the good-faith (but inappropriate) changes, many of these users will become discouraged and never edit again. This already occurs to some extent (an unavoidable consequence of operating a wiki), and I see no reason to exacerbate the problem. —David Levy 02:20, 25 August 2012 (UTC)
    But what we're doing patently isn't working. We're losing editors at an unprecedented rate - while the encyclopedia continues to grow and need more maintainers. We do need a new approach of some kind. The "status quo" argument doesn't hold water. I have some ideas for improving this proposal that may get around some of your concerns...see my "Support" !vote above. SteveBaker (talk) 14:30, 25 August 2012 (UTC)
    But what we're doing patently isn't working. We're losing editors at an unprecedented rate - while the encyclopedia continues to grow and need more maintainers.
    Much of that decline is attributable to the fact that fewer and fewer topics (particularly those widely familiar to persons fluent in English — an unavoidable systemic bias) have yet to be covered. It's unfortunate that editors are departing, but it's fallacious to assume that we're failing them in some way. For better of worse, many people simply aren't interested in sticking around to maintain articles.
    We do need a new approach of some kind. The "status quo" argument doesn't hold water.
    It's an argument that I haven't made. I don't oppose the idea of expanding efforts to recruit new editors, including on the main page. I oppose this proposal to send unprepared newcomers directly to "shoddy" articles with the vague instruction to improve them.
    I have some ideas for improving this proposal that may get around some of your concerns...see my "Support" !vote above.
    I don't believe that your ideas belong under the "Support" heading, as they appear to constitute a radically different (and much better) proposal. —David Levy 15:42, 25 August 2012 (UTC)
    Much of that decline is attributable to the fact that fewer and fewer topics (particularly those widely familiar to persons fluent in English — an unavoidable systemic bias) have yet to be covered.
    That has got be stopped being used as an argument across Wikipedia. It is simply not true. There are so many articles on "mainsteam" concepts that have very bad content, that nobody knows about or bothers to change. Habitat, Daughter, Son (actually, all the family articles are rubbish at the moment - things that you would've thought would be some of the first concepts to have articles created), human body, sadness (a lot of the emotion articles are rubbish too), analysis, letter (alphabet)... and the list goes on and on. The point is that these article were created once upon a time probably like 6 years ago, and then fiddled with with minor edits up until now, with the quality basically unchanged. There are sooo many articles like this lying around that noone know/care about. I think in general people are scared of the more general topics so focus on the more obscure, specific stuff. You only know what to include in art until you've made articles on all the different types of art, right? But we can let that fear go away, by making this sort of thing the norm. I had a similar proposal about half a year ago and that got shut down. Don't let this one get shot down too. It will help immensely in the process of converting readers to editors (or, in my vocabulary, allow people to realise that there is no dichotomy, and that they are in fact edi-readers). Why not bring important topics to peoples attention and get them going? --Coin945 (talk) 17:08, 25 August 2012 (UTC)
    What needs to be stopped is denying the obvious on this issue. Here is the first example, Habitat, in 2006; of course it's harder to improve it in 2012. This is not a comment on the orange box. Art LaPella (talk) 19:22, 25 August 2012 (UTC)
    That has got be stopped being used as an argument across Wikipedia. It is simply not true.
    You dispute the assertion that fewer notable topics (particularly those of greatest interest to the site's editors) lack English Wikipedia articles than did before?
    There are so many articles on "mainsteam" concepts that have very bad content, that nobody knows about or bothers to change.
    I'm well aware that much of the encyclopedia is in a state of disrepair. As I noted, "many people simply aren't interested in sticking around to maintain articles".
    At some point, Wikipedia lacked the 697 articles currently tagged by WikiProject Buffyverse. Fans of the Buffyverse have striven to ensure that a Wikipedia article be written for every series, film, television episode, book, music album, video game, major character (and actor portraying him/her) and notable behind-the-scenes contributor.
    Are all of these articles in good shape? No, of course not. Here's one that I loaded at random. It's just sitting there, tagged for multiple issues (as is the Buffyverse article, I noticed). I'm sure that certain members of the aforementioned WikiProject are working on improving these articles. Other editors, conversely, set out to author unsourced plot summaries and never intended to contribute anything else. As far as they're concerned, now that the articles have been written, their work here is done. We did nothing to drive away these individuals.
    Why not bring important topics to peoples attention and get them going?
    We should, but not in the manner proposed above. —David Levy 21:19, 25 August 2012 (UTC)
    I honestly believe jumping in and doing some editing, without any familiarity with policy, is the best way for people to learn. The feedback they receive allows them to learn policy in a personally relevant context, which reading a bunch of long, intricate policy pages could never do. Some will inevitably be discouraged, and that's okay. Even if every newbie edit gets reverted, as long as they get good explanatory talk page messages we are making a big investment in our human capital that will pay off in the long term. Dcoetzee 00:24, 18 September 2012 (UTC)
  2. Right now the main page gives Wikipedia a certain polished respectability. Adding a box implicating that we're broken and need fixing may discourage those who actually want to use it as an encyclopedia. In business we call it, "airing our dirty laundry"; it's generally not something you want to do. Beyond that, I'm in accord with David above. Sending new editors to the introduction page has the helpful benefit of exposing newcomers to the Wikipedia philosophy. On the other hand, adding a big Try it! button that spoon fed a candidate editor through the process of picking a few pages to edit would probably be good. I don't why we don't have a simple device like that already. Regards, RJH (talk) 16:41, 25 August 2012 (UTC)
    Wikipedia is a work-in-progress. It is not finished. Why are we presenting ourselves to the public as if we are? And when you start to bring the public into the picture, you get an even more important question: why are we excluding our readers (our potential editors) from the site? We set up this horrifically bureaucratic system, totally unwelcoming to newbies because we create this huge dichotomy of editors & readers (even thoguh in reality they're one in the same), and then moan and complain when everyone starts to leave. Hmmm... i wonder why. I say there's nothing wrong at all with showing off our "dirty laundry". We are not supposed to be perfect or complete. That is false advertising. If anyone wants my opinion, that's the sole reason why Wikipedia gets so many complaints about false/misleading information - we "claim" to be this brilliant complete source (through both what we do say... and what we choose not to), and then not deliver in many respects. There is something so intrinsically wrong with this sentiment, and noone has been able to change it. Actually i kid. Many have tried, but they are stopped by the worst philosophy of all in modern-day Wiki... which brings me back to the other point: why don't we (instead of chatting about all this theoretically, which is unfortunately what wiki has become: a place of all chat and no action), just charge head and see how it goes? It may fail miserably, yes indeed. But there's only 1 way to know for sure.--Coin945 (talk) 17:19, 25 August 2012 (UTC)
    Wikipedia is a work-in-progress. It is not finished. Why are we presenting ourselves to the public as if we are?
    On several occasions, I've expressed the opinion that we should convey this more clearly on the main page. In particular, I've supported the idea of displaying the featured article and good article counts alongside the total article count (mock-up), thereby eliminating the implication that we care solely about quantity (as conveyed by the message's current text, in which featured articles, unsourced stubs and everything in between are lumped together as "6,912,364 articles in English").
    And when you start to bring the public into the picture, you get an even more important question: why are we excluding our readers (our potential editors) from the site?
    I agree that we should do more to recruit new editors. Sending newcomers, en masse, directly to "shoddy" articles, with the vague instruction to improve them (despite their unfamiliarity with Wikipedia's editorial standards, which obviously can't be extrapolated from the articles themselves) is not a viable means of accomplishing this. It strikes me as a surefire way to lose potential editors (for the reasons that I've cited).
    why don't we (instead of chatting about all this theoretically, which is unfortunately what wiki has become: a place of all chat and no action), just charge head and see how it goes?
    That might have made sense a decade ago, but a community of this size is unsustainable under such a system. If we were to simply implement every big idea (even on a trial basis), the site would collapse under their weight. I agree that we sometimes get hung up on bureaucracy, but some discussion/filtration is essential. —David Levy 21:19, 25 August 2012 (UTC)
  3. Oppose. The front page is our opportunity to put our best work forward. Putting articles in trouble there isn't conductive to that. Nearly everyone knows they CAN edit Wikipedia, that isn't really the issue. Andrew Lenahan - Starblind 14:48, 29 August 2012 (UTC)
    Actually 19% of readers surveyed were unaware that anyone could edit Wikipedia. the wub "?!" 11:00, 30 August 2012 (UTC)
    They can be divided into three categories:
    • Readers of non-English Wikipedias only
    • Readers of the English Wikipedia who don't visit the main page
    • Readers of the English Wikipedia who visit the main page but fail to notice/understand the prominent "free encyclopedia that anyone can edit" description at the top
    There's no reason to believe that the proposed change would assist any of these individuals in realizing that they can edit the site. (I realize that you were addressing a more general statement, so my reply isn't intended to rebut yours.) —David Levy 13:25, 30 August 2012 (UTC)
  4. Oppose. My feeling is that is will not succeed in attracting more editors - which is the aim of the proposal. Editors are more likely to do what they want to do rather than do what is needed. The huge backlog of maint work is case in point. The main page is visited by millions of readers and that vast majority of them have absolutely no interest in editing WP so I don't want to see any additions cluttering up the main page. Finally, there are sufficient avenues available that can attract editors already - virtually all pages on WP have a Talk page so it is already easy for any reader to jump over to the editing side. -- Alan Liefting (talk - contribs) 00:11, 18 September 2012 (UTC)
  5. Oppose Do not think it will achieve its purpose. Mugginsx (talk) 15:18, 18 September 2012 (UTC)
  6. Oppose. Look, I of all people want more editors. But there are right ways to achieve that and wrong ways. We don't have decent help pages, we don't have a friendly editing environment, we don't have any community processes for dealing with the massive influx of new people that such a box would create - not that most of them will make their edits, because more than 2 at the same time creates an edit conflict. This is the wrong way to go about it; it's going to leave potential new editors confused, frustrated and not wanting to come back. Lets talk about ways to fix how we deal with newcomers before we talk about ways to invite more of them in. Ironholds (talk) 05:32, 23 September 2012 (UTC)
  7. Oppose: I get very much what Casliber is looking for. I also get that having a tiny number of articles in the list will be a disaster, and that three months for any experiment is excessive. Three days will tell us if it is making a difference, to be honest. What I'd prefer to see is a radical rewriting of the help pages first, though, so they're actually helpful. And then either at the top of the page (or the bottom, beside the "Privacy Policy - About Wikipedia - Disclaimers - Mobile view" bit) a link that says "Become an editor". If this does go ahead, how about creating a queue of 3000 - 5000 articles that need improvement, with randomization to give people 5 choices? (All BLPs excluded, as well as topic areas under any community or Arbcom sanctions: think geography, flora and fauna, business...) And I do not think the trial should last anything more than one month, at which time it will be turned off no matter what, until someone writes an actual report on its effects. Risker (talk) 05:55, 23 September 2012 (UTC)
  8. Oppose encourages people to edit without reading the manual. --Rschen7754 06:28, 23 September 2012 (UTC)
  9. Oppose. The intent is good. The methodology is wrong. As wisely noted above, what this amounts to is "sending newcomers, en masse, directly to 'shoddy' articles, with the vague instruction to improve them (despite their unfamiliarity with Wikipedia's editorial standards, which obviously can't be extrapolated from the articles themselves)". Guoguo12 (Talk)  19:30, 27 September 2012 (UTC)

Discuss

  • So David, you're opposed to even a trial of it? Even with some shoddy pages and a bunch of watchers just to see what happens? Actually we should get some figures on who goes from mainpage to introduction page and thence elsewhere.....Casliber (talk · contribs) 07:35, 25 August 2012 (UTC)
    Yes, I oppose a trial. I disagree that sending newcomers directly to "shoddy" articles (from which a basic understanding of Wikipedia's editorial expectations can't even be extrapolated) is desirable. They won't know what's expected of them, so most of their contributions will be reverted, tagged or removed.
    Additionally, they'll become confused/annoyed upon encountering endless edit conflicts. That's why it's unhelpful for a large number of people — irrespective of knowledge/experience — to edit a particular article or handful of articles simultaneously. This situation, which is incredibly frustrating (even to longtime editors) arises naturally in articles about current/recent events. I see no reason to deliberately manufacture such a scenario in arbitrary articles, let alone bad articles edited by users who don't even know what an "edit conflict" is. —David Levy 14:22, 25 August 2012 (UTC)
    I think Caliber's choice of the word "shoddy" is a poor one. We would need to discuss what kinds of articles need this kind of support. Clearly we wouldn't want very obscure topics...and certainly not horribly controversial ones...but also not articles that are already very high quality. But there are plenty of articles out there that languish from lack of editors but aren't horrible.
    I propose that we have the corresponding Talk pages be pre-loaded with welcoming, experienced Wikipedians (I'm going to call them "Shepherds") - who (let us suppose) have been discussing the article there for a day or two before the article is promoted. That way, the newbies will arrive to a welcoming, non-controversial editing environment, with gentle expert editors to guide them rather than a shark-tank.
    The issue of having large numbers of people flood a single article can be controlled by removing each article from the front page once edits from...oh...20 new editors have been made? Cycling through a large number of articles in this way would help spread the load. We could also consider linking the "EDIT ME!" link on the front page to a sand-box - rather than to the actual, live article. The 'Shepherds' would be responsible for replacing the 'live' article with the sand-box changes whenever they feel it's better. So reversion won't have to be urgent and violent.
    Shepherds would be instructed to explain policy issues rather than using curt and cryptic "WP:RS" or "WP:NOR" links as a shorthand.
    I believe that a short trial would teach us a lot about how to make this work.
    SteveBaker (talk) 14:43, 25 August 2012 (UTC)
    I don't oppose the idea of expanding efforts to recruit new editors, including on the main page. I oppose the idea of sending newcomers directly to articles with the vague instruction to improve them.
    A hypothetical orange box should instead lead to an area in which potential editors are guided step by step (beginning with a basic explanation of Wikipedia's practices, with which they should be familiar before they're tasked with editing the carefully selected articles). And instead of listing articles to be edited, the box could contain a list of articles recently improved via the process. (This would provide helpful examples of what we hope to achieve and a reward/incentive.) —David Levy 15:42, 25 August 2012 (UTC)
  • Casliber et al, are you aware of Wikipedia:Today's article for improvement? (I noticed this advertised on a talk page.) It has a similar goal. Rambling from here out: (hopeful:) I'm all for trying something different. (skeptical:) Even though I agree with David Levy on the particular problems, (hopeful:) would an experiment be the end of the world? Past sub-pages that ask people to improve content have suffered from randomness and too many choices. (See the link to someone's redesign in the other discussion section: too many choices!) (skeptical:) The larger problem with any initiative of this type is that Wikipedia editing has frankly become a specialty. If you ask previously uninvolved visitors to improve screwdriver, they may offer many good-faith contributions, and they'll promptly be reverted by gatekeepers for being unreferenced, etc. I see a number of 'unproven' assumptions in this discussion, and one of my unproven assumptions is that the number of people who are willing and able to contribute substantively to Wikipedia in a way that follows all of its 2012 policies and norms is just vanishingly small. (On norms, compare the degree to which citation is "enforced" by the community now versus 2007, even though the policy still says "likely to be challenged".) (hopeful:) I'd still like to see something like this go up on the main page for a few days to prove that change control and the status quo on this project have not ground experimentation to an absolute halt. It has merits and demerits: try it. Clearly with a tight focus knowledgeable editors can be there to "steward" new editors. An edit notice could be placed on the chosen article outlining a few broad principles for editing in plain English, and explaining how the particular article could be improved in terms that non-insiders can relate to. I mean, I look at screwdriver and I wouldn't know where to start (except for the generic "improve references" trope, or the "copyediting and formatting" tropes, which are all things that insiders understand, but they're not teasers for new editors; "tell us what you know about" is the teaser, and yet (skeptical:) the norm in 2012 is "we could care less what you know!"). Riggr Mortis (talk) 07:09, 26 August 2012 (UTC)
    @Riggr - wow, I hadn't seen that! I intend to take a closer look....@David, I do concede alot of what you're saying about the potential for blind reverts and edit conflicts. The optimist was hoping that maybe added scrutiny by some more constructive editors at the time the article was linked might mean a scramble to look for sources of material that people add rather than just reversion. This is why I was thinking of broad articles. Anyway, if other ideas which are radically different to my intiial proposal come out of this, I don't mind in the slightest. I don't own this idea and I am happy to try some alternatives. I'll take a look at the community portal revamp when I can. Casliber (talk · contribs) 13:43, 26 August 2012 (UTC)
  • Right....we could also just run as a trial only, so clarify above. Casliber (talk · contribs) 01:46, 25 August 2012 (UTC)
  • I like the idea of providing more "Become an editor, here's how [easy it is]" links on the Main Page. But I think there may be better methods/designs to do so. Eg.
    1. See the "About Wikipedia" box at the bottom of WP:2012 main page redesign proposal/Pretzels for a particularly good idea, with 3 sections of helpful pointers (readers/new-editors/regular-editors) - [The links that are chosen would all need to be re-examined, as his draft was primarily focused on layout and overall-ideas; but the "3 sections" is a good direction to think in, that the Help Project is also considering using for redesigning the main Help:Contents page, in the near future). (also see WP:2012 main page redesign proposal for more design ideas, and much discussion on the talkpage).
    2. See User:Maryana (WMF)/opentask for a redesign that is (soon) to be placed in the top of the WP:Community portal, as part of the ongoing WP:Community portal/Redesign 2012. Using the Community Portal for specific article suggestions (as it has in the past) would be good, but getting new editors to glance at the WP:Introduction or WP:Cheatsheet (or similar) first is crucial. Less is more.
HTH. -- Quiddity (talk) 22:33, 25 August 2012 (UTC)
  • I haven't read the whole thing yet, but this would probably be the best way to interlap with PC. So if the wiki is worried about a bunch of bad edits, we could coach, but also, should a fixit box be displayed, then maybe pending changes could be a way to help out. I still have to read the rest though. Mysterytrey 21:38, 27 August 2012 (UTC)
  • I like the concept as a good contrast to the overly perfectionist tendencies found with FAs. But there are likely to be practical problems such as edit conflicts because the process will encourage many editors to rush at the article at once and so there will be too many cooks. Warden (talk) 21:38, 27 August 2012 (UTC)
  • Interesting concept, but I'll say this: based on my experiences dealing with newbies while doing RC patrol, WP:AFC, monitoring those articles on my watchlist, and other places, I would prefer to direct them to the help pages, tutorials, and policy pages first. If I wanted an article improved (especially a broad article on my watchlist), I would instead seek out established editors on the relevant Wikiproject, peer review, WP:GA, or WP:FAC (if applicable) – not have a bunch of newbies, unfamiliar with the GA and FA criteria, rush in at once. Zzyzx11 (talk) 04:48, 29 August 2012 (UTC)
    • Not to be rude... but that's an awful idea. Those policy and help pages are long, confusing and generally overwhelming. If this was a group of people we wanted to discourage based on policy, like someone trying to add links to Facebook everywhere, then sending them to those pages is the perfect way to do it. But this a group of people who we theoretically want to just try out editing, and then get them to then take on more serious, complex tasks that require deep knowledge of policy. The kind of people who will look at a list of articles needing simple improvement, and then decide to help are the kind we want to encourage the most. Steven Walling • talk 04:16, 3 September 2012 (UTC)
  • My vision is that we let editors loose on an article which has a basic structure but a lot of missing content (something like this, for instance?), and worry about Manual of Style issues etc one it is off the Main Page. Edit conflicts are a legitimate concern, but it's worth pointing out that we have no qualms about giving (often unprotected) news items prime placement. —WFC— 21:17, 1 September 2012 (UTC)
    My vision is that we let editors loose on an article which has a basic structure but a lot of missing content (something like this, for instance?), and worry about Manual of Style issues etc one it is off the Main Page.
    What about unsourced statements and original research? Should we refrain from removing/tagging them? (To be clear, this is a sincere question; I'm not being sarcastic.)
    My main concern isn't that the articles will temporarily receive a few blemishes. It's that new editors, few of whom are familiar with Wikipedia's practices, will become discouraged (and never edit again) when their contributions are reverted or otherwise deemed problematic (even if this occurs after the article's main page appearance). This already is a very real problem, and I see no reason to exacerbate it by encouraging newcomers to edit articles without first gaining a basic understanding of our expectations.
    Edit conflicts are a legitimate concern, but it's worth pointing out that we have no qualms about giving (often unprotected) news items prime placement.
    And the resultant edit conflicts can be downright nightmarish, despite the fact that we aren't instructing readers to edit those articles. —David Levy 17:58, 2 September 2012 (UTC)
    The only way to prevent IP editors' feelings from getting hurt through policy-based reverts would be to restrict editing to registered accounts only (on a sitewide basis). We could do that very easily, but it would become harder to claim that we are still the encyclopaedia anyone can edit.

    As for your comment on edit conflicts, I'm extremely confident that this section would receive significantly fewer edits than an ITN item. If it was proven at trial that this assumption is wrong then I would probably oppose the section becoming permanent. Besides, we're going for a different type of editor here. I hesitate to use the phrase "quality over quantity", because that would be unfair to the IPs who on balance contribute a lot to news related articles. But topical articles are edited by people who want to break news, and need little further encouragement to edit. This section would be aimed towards people who don't edit because they don't feel that there is much left to contribute, but who could be attracted to the site through the traditional charm of Wikipedia: seeing glaring omissions in content and deciding to help fill them. —WFC— 23:27, 2 September 2012 (UTC) (italic text added —WFC— 23:29, 2 September 2012 (UTC))

    The only way to prevent IP editors' feelings from getting hurt through policy-based reverts would be to restrict editing to registered accounts only (on a sitewide basis).
    And even then, the problem would persist among newcomers with registered accounts. As I noted above, it's an unavoidable consequence of operating a wiki.
    No matter what we do, some users will jump directly to editing (without first gaining a basic understanding of Wikipedia's practices). And of them, some will become frustrated and discouraged when their contributions are reverted or tagged. But we needn't encourage this approach.
    That's my point. The proposed setup literally would instruct readers arriving at the main page to begin editing articles without first visiting the various help pages available.
    Supporters are focusing on the importance of recruiting new editors, and I agree. I also agree that this should be done via the main page. But no one is explaining why it would be beneficial to send newcomers directly to articles to be edited instead of a tutorial or training ground. And no one has commented on the alternative format that I suggested.
    As for your comment on edit conflicts, I'm extremely confident that this section would receive significantly fewer edits than an ITN item.
    Are you referring to the articles themselves? If so, that seems like a very low conversion rate (not that a high conversion rate would produce better results).
    Honestly, I want us to attract lots of new editors via the main page. I just don't understand why they should be encouraged to edit immediately (without preparation of any kind). —David Levy 02:11, 3 September 2012 (UTC)
    What generally happens with ITN stories is that a development to the story breaks, there is a 15-30 minute flurry, and then the editing slows to a realtively steady stream or trickle (depending on how prominent the story is) until the next major update. With this proposal we wouldn't have those spikes, which would account for the lower edit rate (and fewer edit conflicts). The other thing to bear in mind about ITN is that IP editors generally click on the page with the intention of checking that the latest development is in there, and then decide to add it themselves if it isn't. In other words, it generally attracts those who are already hooked on the "anyone can edit" concept, but for whatever reason don't want to sign up. It can reasonably be assumed that 95% of IP edits to a page under this sort of system would not have otherwise happened: fewer edits than ITN would therefore not automatically be a failure. —WFC— 06:35, 3 September 2012 (UTC)
    With this proposal we wouldn't have those spikes, which would account for the lower edit rate (and fewer edit conflicts).
    But we don't instruct readers to edit the articles linked from ITN.
    In my experience, if a dozen people are trying to edit an article simultaneously, the resultant edit conflicts are incredibly frustrating (even for someone who understands why they're occurring, which newcomers probably won't).
    The main page averages roughly 5,000 views per minute, so if an orange box explicitly inviting readers to edit a handful of specific articles were to fail to accumulate a dozen simultaneous participants per article, that would constitute a failure in my book. (But again, success would be problematic too.) —David Levy 07:39, 3 September 2012 (UTC)
    In response to your question about why we don't send them to a tutorial, my view is that we want them to prominently see the help (via an editnotice and a banner/template at the top of the article). But ultimately I believe the balance should be "we are inviting you to edit this article. All the help, support and information you need can be found here." rather than "Help, support and editing advice can be found here. Once you have read that, we will disclose the location of an article where we can test what you know about Wikipedia." —WFC— 06:35, 3 September 2012 (UTC)
    I believe that we can find a happy medium. SteveBaker made some good suggestions. —David Levy 07:39, 3 September 2012 (UTC)
  • Comment: Hey. I just wanted to say that, with the amount of visits that our Main Page gets, you won't need three months to see if people will click on and actually do the tasks in a list. I'd suggest that you split up each month to test a different strategy to try and engage new contributors. Steven Walling • talk 04:11, 3 September 2012 (UTC)
  • I think we should make the box dynamic and geotarget visitors IP, like WP:GEONOTICE does. So an editor from Ireland would see the article on Ireland as neededing improvement, but somebody from Hawaii would see Hawaii, and so on. Could use GAs from corresponding WikiProjects for a wider selection. --Piotr Konieczny aka Prokonsul Piotrus| reply here 15:46, 11 September 2012 (UTC)
  • TL;DR. So after 3-month trial, is it set to default on or off? (Better clear up this concern or it'll go down the same path as Pending Changes) OhanaUnitedTalk page 01:29, 15 September 2012 (UTC)
  • Wouldn't doing something like this require randomisation in order to avoid a mass of folks on the same pages, and since actual randomisation requires turning off caching, at least on the page in question, wouldn't that be potentially kind of bad? -— Isarra ༆ 18:44, 23 September 2012 (UTC)

Summary

The general concept of a three-month trial of listing articles requiring work on the Mainpage has consensus. Further discussion is required to take into account how the trial should be run, what sorts of articles should be included (randomized, geonoticed, etc.), and how new users should be handled (via PCs, with help pages, by the status quo, etc.). I suggest Casliber start a new subpaged RFC where different implementations can be displayed and discussed. MBisanz talk 22:52, 4 October 2012 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.


Restyle talk header css class

The following is a screenshot of the section 0 of a talkpage:

Two things stand out:

  1. Holy crap, that is a lot of talkheader.
  2. That is not a good colour, especially when there is so much of it.

Somehow I kind of doubt there's an easy solution to #1, but for #2, how about a nice grey? Maybe like so:

Doesn't that look nicer? I think it looks much nicer. We should totally do that (or something more along those lines) instead. -— Isarra ༆ 07:52, 27 September 2012 (UTC)

I appreciate your point, but I think that's a little too much grey, especially with all the rest of the site furniture around it. Too much of any one color might cause people to stop bothering reading (especially new editors). Plus, some bits need to stand out - for example, {{not a forum}}. I think that a complimentary color* palette should be devised for all the classes of talk page header - WikiProjects, AfD/AfM/etc notices, article milestones, warnings. That way it would be very easy to pick out particular features you may be looking for on a talk page. -- Hex [t/c] 09:30, 27 September 2012 (UTC)
* And other features to assist recognition for those who are colorblind.
I am in support of increasing the range of colors for talk headers. Even if the color of templates cannot be changed holistically, perhaps colored tabs/markers, like the ones on cleanup templates could be added? Guoguo12 (Talk)  19:40, 27 September 2012 (UTC)
Colored tabs a la the cleanup templates is an excellent suggestion. Just enough color to be distinguishing, not enough to hurt the eyes, and consistent. -- Hex [t/c] 08:04, 29 September 2012 (UTC)
The reason why there is too much grey is because there is just too much stuff in general. Now perhaps we ought to consider fancier colours for the templates themselves, but that would probably best come after a detailed look into why we even need all that stuff in the first place. For now, however, could we not at least make the tmbox class that they all use not beige? Beige is gross. -— Isarra ༆ 20:31, 27 September 2012 (UTC)
Please don't turn this into a rainbow of colors for each kind of template. If there are lots of headers, we can solve the problem with a collapsable box of some sort, like {{ArticleHistory}} or something like that, which can help, but we shouldn't have a range of colors, which doesn't improve readability so much as it makes ones eyes bleed from the obnoxiousness. --Jayron32 20:44, 27 September 2012 (UTC)
Lyrithya, I agree with Hex that the layout here is already plain to begin with. However, the gray-and-blue based layout was probably chosen to be neutral in tone and we shouldn't crack wise with the layout if visitors will object. The current orange is already neutral enough to begin with and I actually think it is eyecatching, exactly what you would want if you are asking people to respect WP:FORUM. It's worth a try, though. 68.173.113.106 (talk) 23:23, 27 September 2012 (UTC)
New proposal: {{Talkheader}} should stay orange, but make {{ArticleHistory}} light gray or blue. 68.173.113.106 (talk) 23:27, 27 September 2012 (UTC)
This thing is positively flesh-coloured. I don't necessarily oppose differentiating between some of elements, but that colour really needs to die. -— Isarra ༆ 03:04, 29 September 2012 (UTC)
The various banners using the same colour scheme sounds like something we should continue. That said, I could see suggesting that none of the other talk page templates use that "talk page banner" scheme.
So for example, the archives box could be switched to the grey (presuming it's tested for visual WP:ACCESS). - jc37 23:36, 27 September 2012 (UTC)
Realistically speaking, the archives box should probably match the TOC and catlist since it's just a very basic interface thing. -— Isarra ༆ 03:04, 29 September 2012 (UTC)
  • Has it really been that long already? Amazing. Well, they were certainly great at the time, but look a little dated now, especially when there's a whole lot of them together. I think that a review could well be called for. I would suggest restyling along the lines of the {{Ambox}} system if we did have a review. — Hex (❝?!❞) 16:51, 2 October 2012 (UTC)
  • Tis as simple as changing all the uses of "#f8eaba" (and "#F8EABA") in MediaWiki:Common.css to whatever new color is decided upon. ambox uses the grey #fbfbfb. The site-background is #f6f6f6. I think #F0F0F0 (a touch darker) might stand out a little better - it's the shade used in the new "editsummary/save/preview-button" area. —Quiddity (talk) 23:34, 2 October 2012 (UTC)
  • I know, but that's just one color; the problem that I see here is that all the talk messages are the same color, which impedes readability when there are lots of them. As Guoguo12 did above, I'm suggesting having a color scheme set up in the same way that {{Ambox}} puts a colored tab on the left of different types of message. — Hex (❝?!❞) 10:52, 3 October 2012 (UTC)

Voting mechanism essay

I have an essay on voting at User:Homunq/WP_voting_systems. It acknowledges that WP:NOTVOTE is the main policy on this matter; but, for the rare cases where some explicit form of voting does seem indicated, proposes a mechanism that I believe will work well for Wikipedia.

This essay was inspired by the abortion title debate. That debate has recently moved from kvetching about the last, failed effort to a new RFC. The new RFC suggests using my essay as a guide for the voting process.

I'm posting here now for a couple of reasons:

  • I'd appreciate comments and feedback on my essay. I realize that much of it is TLDR; should I try to split it up into an executive summary and gory details, or what?
  • Given that it appears to be moving towards actual use, should I consider moving it out of my personal userspace to somewhere more official? How would that work? In doing so, would I have to remove first person pronouns?

Thanks,

Homunq (࿓) 17:19, 1 October 2012 (UTC)
No comments so far... am I in the wrong place here? Homunq (࿓) 22:03, 1 October 2012 (UTC)
You're in the right place. A lack of comments in the space of a couple of hours (the time between your two comments) means nothing. WhatamIdoing (talk) 19:28, 3 October 2012 (UTC)

This was an excellent read, and made a lot of sense. I think that this is one of the least gameable systems I have seen. If Wikipedia has to carry out a straight vote, your system makes a lot of sense. something to think about is whether or not there is an equation relating the % SO !votes to the supermajority % needed on an issue. For example, I want a higher percentage than 60% agreed to, say involuntarily remove a sitting member of ArbCom. Also, how votes not cast are assigned is confusing to me. I couldn't tell you if 1: SS 2: SS 3: no response 4: SO what the correct vote to plug in for 3 is. Tazerdadog (talk) 23:50, 3 October 2012 (UTC)

I can see that while my idea does have some support, it is a concept that will likely never be implemented. Thank you to all who participated in this discussion. AutomaticStrikeout 00:24, 5 October 2012 (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.

A proposal about de-sysopping

I am proposing the creation of a set-up called an RfD (Request for de-sysop) which would allow the community as a whole to determine if an admin should be temporarily or permanently deprived of the tools due to misconduct. As far as I know, nothing currently exists that would allow the community to do so. (I'm ignoring recall, as admins are apparently allowed to determine if they are open to recall). My proposal would allow any logged-in editor to create an RfD for any admin, and the process would be fairly similar to an RfA, except for having an opposite goal in mind. Editors could be allowed to ask questions of either the editor proposing the de-sysop or the admin facing the de-sysop. The RfD could be closed at the appropriate time by an uninvolved bureaucrat, although an uninvolved admin could be permitted to make a SNOW closure. In the event that the admin targeted for the de-sysop was allowed to keep the tools, he or she would not be permitted to ever take any sort of administrative action against the user who had started the RfD. So, that's my proposal. I'm sure there could be more to iron out, but I'm throwing out that basic idea. AutomaticStrikeout 19:14, 1 October 2012 (UTC)

  • A couple of points, first there would need to be a screening mechanism to avoid harassing requests that have no real chance of success. Second, a blanket ban on admin action against the nominator would allow nominators to target admins because they didn't want future administrative action. Third, what about those that support removal but aren't the initial nominator? Fourth, is it a vote or are the weight of the arguments considered? Fifth, how strong a consensus is required to desysop? Sixth, what protection is there against a vocal minority using the process and hoping not enough neutral editors shows up to overcome that? Seventh, what protection is there against the RfD turning into a popularity contest rather then focusing on actual administrative conduct? Monty845 19:32, 1 October 2012 (UTC)
To answer your first point, harassing requests could be closed quickly by an admin. As to point two, any nominator that started a frivolous RfD could be topic banned from starting any more RfD's. Those supporting removal would not be exempt from future administrative action as such a rule could severely hinder the admin in question from using the tools in the future. The weight of the arguments would be the main concern. Consensus would have to at least face the same standard as an RfA, if not higher. As for the vocal minority, any RfD should run a week barring SNOW closures and harassing RfD's. That should provide plenty of time for neutral editors to chime in. As for the popularity concern, the closing 'crat would be allowed to use discretion in disregarding !votes that do not pertain to the question of if so-and-so should be an admin. I hope this answers your questions. AutomaticStrikeout 19:45, 1 October 2012 (UTC)
  • Comment - Please see: Wikipedia:Requests for removal of adminship, which I think matches what you're proposing. I never got around to an RfC on it. - jc37 20:25, 1 October 2012 (UTC)
    Well, there is at least one difference. I would not require the nomination to be certified by any admins. AutomaticStrikeout 20:28, 1 October 2012 (UTC)
    Then I am dubious that it will gain consensus. Having a "gate" of sorts seems to be necessary to prevent problem noms. - jc37 20:32, 1 October 2012 (UTC)
    Maybe so, but there is also the concern that admins are known to have each other's back to a significant extent. I'd argue that a requirement of three admins certifying is a little excessive. AutomaticStrikeout 20:36, 1 October 2012 (UTC)
    Could you offer an example of people saying that? I'd like to know where you're coming from. — Hex (❝?!❞) 20:55, 1 October 2012 (UTC)
    Well, that's the impression that I have gained from different conversations I have observed. Of course, some of that is sour grapes coming from people who are unhappy about some sort of sanction. AutomaticStrikeout 22:01, 1 October 2012 (UTC)
    And I believe all 'crats are admins. So you'd need someone like Arbcom to provide the final judgement. In which case these desysop requests are just another WP:RFAR. Ho hum. The Rambling Man (talk) 20:49, 1 October 2012 (UTC)
    Unfortunately, yes. Sorry, AS. — Hex (❝?!❞) 20:55, 1 October 2012 (UTC)
    Having said that, of course accountability is a good thing. But one imagines that within around six months, we'd have no admins, and no candidates to become admins, because it simply isn't worth it. This is a volunteer project. If admins were paid per block or per protection or per deletion it would be a different matter. There are almost no RFAs per month right now. Maybe this proposal is great, as long as anyone supporting it accepts it will result in a drastic loss of admins. And that may be not such a bad thing, but I don't know. As a project, we seem to struggle to keep up with admin tasks right now, so reducing our admins by half or more (which this proposal would end up doing by eliminating those edgy admins and putting off other admin candidates) will have an negative impact on Wikipedia. Won't it? The Rambling Man (talk) 21:02, 1 October 2012 (UTC)
    Perhaps so. I'm not sure that the effects would be as drastic as you are saying, but I could be wrong. AutomaticStrikeout 22:01, 1 October 2012 (UTC)
    User:Rambling Man, Jimbo has stated his solution idea, in context of solving problem with troublesome admins, that it should be both easier to get, as to lose, the bit. (Are you in general agreement with him? I am.) Ihardlythinkso (talk) 07:56, 3 October 2012 (UTC)
  • Comments Automatic Strikeout, I'm supportive of having something, but if I list some concerns, it isn't that I am opposed to the general idea, it's that this has literally been discussed for years, and I don't see evidence that you've reviewed the prior proposals and addressed the shortcomings. For example, You suggest To answer your first point, harassing requests could be closed quickly by an admin.. Well, it isn't in the proposal so the proposal needs tweaking. The subject of the RfD is an admin, by definition, what if they decide to close it? I know, I know, it should be obvious that you meant it could be closed by an admin other than the subject one, but these things need to be spelled out.
You decided not to add in a "gate" noting that "admins are known to have each other's back to a significant extent". Why wouldn't one of those admins simply close it?
Or perhaps you meant that an admin could close it immediately only if there is harassment? If so, you need to define harassment.--SPhilbrick(Talk) 22:15, 1 October 2012 (UTC)
Well, for one thing, there is likely no perfect way to do this. I apologize for being unclear, I'll try to answer the questions you raised. As you guessed, an admin cannot close an RfD of which he or she is the subject. Ideally, an RfD will only be closed by a crat unless it is a harassing RfD. In determining what RfD's are harassing ones, one should determine if the RfD has been opened in good faith or as a retaliatory measure or some other form of non-constructiveness. Basically, an uninvolved admin can SNOW close an RfD if it is clear that consensus is in favor of the admin in question keeping the tools. Any closure of an RfD by an admin should be uncontroversial. AutomaticStrikeout 22:30, 1 October 2012 (UTC)
Thanks for the response. I realize I misread one clause; when you said RfD should run a week barring SNOW closures and harassing RfD's I thought you were suggesting that SNOW would not be allowed. My bad. However, I would like some comments on Consensus would have to at least face the same standard as an RfA as it isn't clear, at least to me. The bar for approval is about 70%, which mean 31% saying no is enough to prevent the candidate from becoming an admin. Does the same standard mean that 69% support for retaining admin means the bit is removed, or did you intended that the bar has to swing the same amount in the other direction, where 31% support and 69% opposed would mean the bit is retained? There are problems with both interpretations, but I've often seem a general support for the same standards, without a clear definition of what that means.--SPhilbrick(Talk) 22:48, 1 October 2012 (UTC)
I was stating that there would need to be the same level of consensus to de-sysop as there is to sysop in the first place. In other words, there would need to be 70% or higher (likely higher) support for de-sysopping in order to remove the admin tools. AutomaticStrikeout 01:18, 2 October 2012 (UTC)
You'll probably save yourself a lot of time and frustration if you read through all of the preceding proposals for such mechanisms and looked in particular at why they failed. Your proposal suggests a high-pressure, short-timeline, likely-to-require-canvassing, public lynching. It's even less deliberative and more vulnerable to failure than, for example, the soundly rejected WP:CDA. The discussion about the proposal (Wikipedia:Community de-adminship/RfC) is enlightening. There's no point in re-inventing (and reproposing) the square wheel. TenOfAllTrades(talk) 03:50, 2 October 2012 (UTC)
  • All suggestions for a better desyoping method are PEREN and will probably never succeed. Most of those on the lines proposed would simply open the flood gates to the lynchmobs of the anti-adminship cabal. We have a process already, albeit not a very good one because they sanction mildly uncivil admins and and award bulletproof vests to the brigade of 100,000+ editors. It's called Arbcom. Kudpung กุดผึ้ง (talk) 06:06, 2 October 2012 (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.

Proposal to create a Wikipedia blackout in the Philippines

Editors are discussing a Wikipedia blackout in the Philippines at Wikipedia talk:Tambayan Philippines#Proposed blackout. Frankly, I disagree with them that local consensus on that page can be used to make that decision, but I better let some people know. Ryan Vesey 05:15, 3 October 2012 (UTC)

English Wikipedia blacked out for SOPA; why not black out worldwide for this new law that is equally bad in a different country? John Vandenberg (chat) 07:33, 3 October 2012 (UTC)
Well, Wikipedia is an encyclopedia. I don't see how it benefits us to be getting involved in political issues and taking sides. Admittedly, I don't know much about the situation, but we aren't a political organization. AutomaticStrikeout 19:25, 3 October 2012 (UTC)
This is possible, but not as a result of a discussion on a talk page, I guess.--Ymblanter (talk) 07:35, 3 October 2012 (UTC)
If there will be a blackout, it will most likely be a localized one, not a global one like the SOPA/PIPA blackout. But if non-Filipinos would like to take up the cause of RA 10175, then they are free to do so. (And Yaroslav, that "talk page" is the Philippine notice board. I don't see why people think that proposals can't go through a country's regional notice board if the issue affects users in the country in question.) --Sky Harbor (talk) 07:50, 3 October 2012 (UTC)
I am sorry, I did not realize that this is a notice board. That removes my objections.--Ymblanter (talk) 08:08, 3 October 2012 (UTC)
John, the main difference is that the English Wikipedia has to comply with US law, so SOPA and PIPA could have had an outsized effect on us. The WMF isn't based in the Philippines. WhatamIdoing (talk) 19:36, 3 October 2012 (UTC)
As I recall, there's a few countries who have tried to say that we're not complying with their laws, and we've responded "we're an American site that hosts our content in different languages. Just because much of that content is maintained by people in your country does not change the fact that we only have to comply with US law." Ian.thomson (talk) 19:41, 3 October 2012 (UTC)
Based on what I've been hearing from the lawyers who are also riled up about this, the situation currently confounding Filipino Wikipedians is akin to the situation involving the Italian Wikipedia. The law punishes people for what they say on the Internet, regardless of where that data is stored. This is why people here are making such a big deal about how the law could potentially affect our right to freedom of expression: because of the way libel is defined in Philippine law, where it is the substance that is punished and not the intent, there is a very big risk for users to continue with our activities here if we know we're risking 12 years in jail, a one-million peso ($20,000) fine, or both! For example, a BLP violation or a politician wanting to get revenge for Wikipedia "slandering" him can easily sue and possibly win, or in the meantime get the Department of Justice to issue a takedown order to remove the "offending" material without the need for a warrant.
Just because the Wikimedia Foundation's servers are based in the United States does not change the fact that in many countries, Internet users (Wikipedians included) are governed by both U.S. and local law: U.S. law for content storage, and local law for things that netizens do online. It's the latter's prospects that have scared many Filipino netizens, Wikipedians included. --Sky Harbor (talk) 23:41, 3 October 2012 (UTC)
This is why Scott MacDonald's approach to WP:NPOV is correct. Nyttend (talk) 12:52, 6 October 2012 (UTC)

English variations

I'm just wondering, has anyone ever proposed some sort of addition to the edit window in articles tagged with english variation templates like {{Use British English}}? I can see that an old top-icon has been removed, but how would editors know about these templates placed at the top if they're editing only a section, for example? There seems to be no notification to the editor that the article uses a specific variation, as the template itself is invisble in read mode, is a hidden category, and only appears in the hidden categories on the edit page, which are now even more hidden by the new edit window design. So I suppose what I'm suggesting is that for articles tagged with these templates, some sort of edit notice should be in place in the edit window (kind of like the one for BLPs) Brambleclawx 14:44, 7 October 2012 (UTC)

Excellent idea, particularly if there's some way to automate it. Mogism (talk) 14:47, 7 October 2012 (UTC)
I think you want an WP:Edit notice. I don't think it can be automatically added by the template, but I believe that we could set up a bot to create one for every page that has the UBE template. You'd need to file a WP:BOTREQ. WhatamIdoing (talk) 23:52, 7 October 2012 (UTC)

Would it be beneficial to seek consensus somewhere other than here first then, before filing a bot request? Brambleclawx 02:18, 8 October 2012 (UTC)

It would be necessary to seek a strong consensus (i.e. much more than just 1 other person supporting), but whether that is done here or elsewhere probably doesn't matter much. Anomie⚔ 02:24, 8 October 2012 (UTC)

Templates for new city articles

Hi everyone! I'm active in New Page Patrol, and for a while now I've been seeing an increasing trend of new articles about cities and towns. While these are, obviously, a good thing, there's also a problem: these articles look horrendous. So, what I am proposing is a new sort of template - a template that would theoretically work like this:

  • the current "create a page" workflow adds a new button to the last page: "create an article about a city or town"
  • if clicked, the new article edit window is opened: preloaded with a subst:city (or whatever its name will be) template that includes fields for variables that would belong in an infobox, categories, as well as things like name, nearest town, a "fill in your own other stuff" box, etc -- all common in these new city articles.

When the user clicks Save page, the template is substituted, and voila! A new gorgeous city article. Thoughts? Theopolisme 12:11, 6 October 2012 (UTC)

Support Sounds like a good idea to me. AutomaticStrikeout 02:22, 7 October 2012 (UTC)

  • Support for towns/cities only. Per my comment earlier today here, I'd strongly object to broadening the automation to any topic other than those like cities, mountains, sports teams etc where an infobox is always appropriate - if a new editor follows all our instructions to the letter, and then the infobox is removed as inappropriate by someone, it's likely to confuse and annoy the newcomer. Mogism (talk) 14:59, 7 October 2012 (UTC)

Proposal for redesign of Help:Contents

A redesign of Wikipedia's main help page has been proposed. Comments are welcome on the talk page. the wub "?!" 11:41, 8 October 2012 (UTC)

a proposal

Dear Mr./Ms.,

I am one the milions users of your outstanding website. perfect job! However, take this as a suggestion. I'd like to know your opinion about what if most of the people in the world could have a page on your pedia page. Basically just those the most important and well known persons have wikipedia page as who they are and what they did. But may be it would be a good idea for less important people, I mean, compare to celebrities, athletes, scholars or the others can be a wikipedia; although, not necessarily that much complete. What I mean is that to design something somehow as a curriculum vitae of normal people. For example if someone wants to apply for a job or university easily their personal information accessible on your website. Is it possible?

I hope I could convey the message what had crossed my mind. I am sure you all are talent enough to elaborate all the ideas perfectly. Thanks in advance!

Sincerely, B.M.Azmoodeh — Preceding unsigned comment added by 193.205.230.58 (talk • contribs) 17:33, 8 October 2012‎

This idea, while interesting, cannot be implemented on Wikipedia. It may be appropriate for another website or wiki, but we strive to be a neutral, verifiable encyclopedia. As such, there are things that Wikipedia is not. In particular, Wikipedia is not a social network, a resource for conducting business, or a means of promotion. szyslak (t) 16:47, 8 October 2012 (UTC)
Aren't you proposing Facebook?--SPhilbrick(Talk) 17:14, 8 October 2012 (UTC)
Or more specifically, LinkedIn. Apteva (talk) 20:28, 8 October 2012 (UTC)

Bureaucrat rights' proposal

Closing per WP:SNOW - no consensus for implementation. Steven Zhang Help resolve disputes! 03:29, 10 October 2012 (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.

Presently, Bureaucrats do five basic tasks:

  1. Close RFAs;
  2. Flag and de-flag administrators;
  3. Close RFBs;
  4. Rename user accounts;
  5. Flag and de-flag bot account.

The RFA/RFB closing functions and the admin flagging and de-flagging function have become the smallest components of the crat toolkit by a very wide margin; There have been four RFBs, twenty RFAs in 2012, ~150 de-adminnings, and ~20 re-adminnings in 2012, compared to over 2,500 renames. I'm therefore proposing that the English Wikipedia delegate the task of RFA/RFB closures and admin flag granting/removing back to the Stewards on Meta (full disclosure, I am a crat and a steward). Given the extreme infrequency of RFAs in the modern era and the specialized high capacity of stewards to handle user-rights changes, this proposal would permit crats to better focus on the tasks that make up the bulk of their work and also assure the community that those seeking to be crats will not be able to wield a dangerous power for political/personal purposes. Comments, supports, or opposes are, as always, welcome. MBisanz talk 20:46, 30 September 2012 (UTC)

  • I'm fairly confident that 98% of RFAs could be done using a 70%/80% bot rule and the renaming 2% can be adequately solved by reading Wikipedia:RFA#About_RfA_and_its_process. Given we're averaging under fifty RFAs per year, this means there will maybe be one RFA per year that the steward actually has to read and think more than thirty seconds on how to close. I'm confident the stewards will think and read carefully in that one case. MBisanz talk 20:55, 30 September 2012 (UTC)
  • Oppose. If anything re-naming should be given to other people. Secretlondon (talk) 20:51, 30 September 2012 (UTC)
  • Comment I not sure of the logic here; if these tasks are now very little work, why do they need to be hived off? Johnbod (talk) 20:52, 30 September 2012 (UTC)
  • Oppose respectfully, per Jasper Deng. Noting the improper decratting of X! (talk · contribs) and where a steward jumped the gun at the initial implementation of the inactive admin policy. --Rschen7754 20:53, 30 September 2012 (UTC)
  • Oppose all the re-sysop's I've performed (albeit quickly) have been based on an knowledge of those editors here at en.wiki. Not sure how a steward would necessarily have that understanding, nor have the time or inclination to do the work to get there. If this is really a genuine proposal, then let's look at all the things 'crats do, and that amounts to... renames. So perhaps all 'crat duties should be centralised to stewards. After all, there's little left to allow 'crats the discretion afforded them by the community to actually do. The Rambling Man (talk) 20:54, 30 September 2012 (UTC)
  • This is a genuine proposal. My concern is that we don't have enough crats to do renames because the bar at RFB is set artificially high to protect against wrongly giving the ability to make people admins. This leads to a gross excess of crat resources to handle RFA and a dearth of resources to do renames. Removing the quality that people are so hesitent to grant should result in them being more willing to grant the quality that is in need and that is viewed as less politically/socially dangerous. MBisanz talk 20:58, 30 September 2012 (UTC)
  • To be honest then do less renames. It's generally cosmetic and is waste of staff time. Secretlondon (talk) 21:04, 30 September 2012 (UTC)
  • I would tend to agree with you, but for the fact that the stewards' capacity to do renames does not seem high enough to accomodate the 3,500+ yearly renames done on en.wiki by the crats. I would also agree that the crats operate with nearly no discretionary authority, making the usual concerns of crats running amok to be laughable from my position. MBisanz talk 21:05, 30 September 2012 (UTC)
  • Or we could make it a flag - it involves less clue than being an admin really. I accept I'm biased as I see doing them to be an utter waste of my time. When 'crats started we didn't do renames at all, renaming came later. After once spending a whole evening doing them (changing them from one pop culture ref to another one) I decided I could find endless more productive uses of my time. However I cannot see what the benefit to en would be of losing their admin promotion abilities to global stewards. Secretlondon (talk) 21:15, 30 September 2012 (UTC)
  • Yep, spend endless hours "bureaucratically" looking at mindless rename requests that anyone and his dog could do, or make the slightly more important decision as whether or not to allow an editor the tools to delete, block and protect pages. This proposal seems upside-down. The Rambling Man (talk) 21:18, 30 September 2012 (UTC)
  • Oppose I see no reason why a steward would be better at determining RFA consensus. If anything, debundle rename, and make it easier to get. Monty845 20:57, 30 September 2012 (UTC)
  • Oppose I fail to see the point of that. It seems to me that it is simply a case of because some tools are not used as much as others then crats shouldn't have them. I think it's much safer if the power is distributed evenly between the two rather than just vest it all in the stewards as it saves time. The C of E. God Save The Queen! (talk) 20:58, 30 September 2012 (UTC)
  • Since the issue here seems to be a lack of crats available to handle rename requests, how much opposition would there be to a proposal to, instead instead of lowering the crat bar, giving admins that right such that no 'higher' permissions are even required? -— Isarra ༆ 21:47, 30 September 2012 (UTC)
    That's what I'm wondering. Are there perhaps special privacy concerns? WhatamIdoing (talk) 20:21, 1 October 2012 (UTC)
  • Oppose Not really seeing a point in this either, other than to just shake things up. Yes, we don't promote very much anymore, but conceptually, I really dislike the idea of non-community members (stewards) handling community-driven processes (like RfA). Besides, if RfA is as dead as you make it out to be, how is it really pulling us away from renaming? EVula // talk // ☯ // 21:49, 30 September 2012 (UTC)
  • It's not pulling us away from renaming, it's preventing us from recruiting people who are qualified to do renames, but not qualified to close RFAs as crats. MBisanz talk 00:07, 1 October 2012 (UTC)
  • Ah, alright, that I understand, though I ultimately disagree with the proposal. I think NYB's comment about spinning off renaming would, ultimately, a bit more productive than spinning off flag modification. EVula // talk // ☯ // 02:22, 1 October 2012 (UTC)
  • Oppose. When I saw this proposal at first I was going to oppose on the simple ground that our locally elected bureaucrats are more familiar with En-WP norms than the globally elected stewards, and that absent evidence that the 'crats weren't closing RfAs and RfBs timely and correctly, this was a solution in search of a problem. Having read more closely, I gather the problem being addressed is that RfB candidates who would be perfectly capable of handling renaming and bot-flagging can't pass RfB because people don't trust them with RfA closing, which has become a less important part of the 'crat role than in years past. Now that I understand the rationale, though, I still oppose, for these reasons:
  1. Hopefully, the current lull in RfAs is temporary. Granted, we'll probably never have as many RfAs per month as we did in (say) 2007, but I sure hope we'll have a lot more in the the future than we've had lately.
  2. We haven't had any RfBs in awhile (that I recall) where the candidate made the points that MBisanz made above.
  3. More generally, we haven't had that many RfBs at all in awhile, and the percentage of those we've had that have succeeded hasn't been so bad. If there comes a time when a half dozen RfBs in a row don't pass because the community is in one of its throes of endlessly-discussing-and-giving-disproportionate-attention-to-the-wikiphilosophical-fine-points-of-how-to-handle-73.8%-support-RfAs-that-happen-maybe-once-a-year, then I would say we should reconsider this issue.
  4. If we absolutely need to create more renamers or bot-flaggers, then I'd say the better plan would be to split those functions off from 'crat, rather than to hand off sysopping. (In particular, although I understand why all admins shouldn't be able to do renames, I'm not sure why all admins can't be trusted to flag and deflag bots.) Newyorkbrad (talk) 00:18, 1 October 2012 (UTC)
There are over a thousand users in the Wikipedia:List of administrator hopefuls category, but not very many that have over 1 edit/day over the last month, maybe about 160, and only about 30 who have tried to become an admin. Maybe I will start randomly nominating some. By the way, something is broken there - the list stops listing properly at "Secret Saturdays Template:Toolbar" Apteva (talk) 02:14, 1 October 2012 (UTC)
The pagecode says:
Preprocessor visited node count: 276845/1000000
Preprocessor generated node count: 39134/1500000
Post-expand include size: 2048000/2048000 bytes
Template argument size: 981483/2048000 bytes
Highest expansion depth: 18/40
Expensive parser function count: 1/500
Which means the page is too long to be rendered by the software. MBisanz talk 02:36, 1 October 2012 (UTC)
I see some indef'ed users there - any objections if I replace their user pages with the standard indef templates? That might help with things. --Rschen7754 05:31, 1 October 2012 (UTC)
On second thought, I'm concerned about the bot reverting everything; going to hold off on this. --Rschen7754 05:56, 1 October 2012 (UTC)
  • Oppose. Honestly, I'm not seeing the logic: We have too few bureaucrats because RFB participants oppose people who are not qualified to close RfAs, so let's hand over all RfAs to people who are not qualified to close RfAs? Jafeluv (talk) 10:56, 1 October 2012 (UTC)
  • Oppose if the admin promotion right is putting people off becoming bureaucrats in order to do renaming or bot flagging then a better solution would be to alter the way these rights are granted - either make them into separate user rights (in the case of bots this would be easy as bots are approved by the bot approvals group anyway) or give them to admins. I have no particular reason to think that stewards will be any good at closing our RfAs. Hut 8.5 11:02, 1 October 2012 (UTC)
  • Oppose ... er ... what problem are we solving here exactly? Spartaz Humbug! 14:24, 1 October 2012 (UTC)
  • Oppose - Bureaucrats are not so overworked that they can not handle this task. There is an aspect of democratic control over elected Bureaucrats that does not exist with Stewards. Don't fix what ain't broken, as the yank saying goes... Carrite (talk) 15:15, 1 October 2012 (UTC)
  • I'm more than happy to withdraw this proposal as it won't pass, but I would kindly ask those who participated to remember it the next time a specialist shows up at RFB who is willing to help with renames, but has no obvious overt competence or desire to handle RFAs. MBisanz talk 15:23, 1 October 2012 (UTC)
    • I think that's a very reasonable point to make, but are there instances of failed RFBs where candidates have been rejected because they stated they'd be happy to rename but not to promote? The Rambling Man (talk) 16:23, 1 October 2012 (UTC)
  • Comment - I'd have supported the suggestion that stewards close RfBs if only due to: "Admins do not close RfAs, so why to bureaucrats close RfBs?" Anyway, as to the seeming intent of this proposal, perhaps the way to deal with this is to try to see if the community will reduce the seeming % requirement from being as high as it currently is. I dunno if this is possible, but I can't imagine it could hurt talking about. - jc37 18:41, 1 October 2012 (UTC)
    • Bureaucrat is the end of the line for specific wiki's, so that is why Bureaucrats close RfBs. Stewards do not make decisions (as stewards), they implement them ("technical implementation of community consensus"). Apteva (talk) 04:29, 2 October 2012 (UTC)
  • Oppose. I am unconvinced that the authority to close RfAs & RfBs is preventing the promotion of candidates who would otherwise be suitable to undertake re-naming. Axl ¤ [Talk] 20:08, 1 October 2012 (UTC)
  • Oppose. I agree with Axl and, looking at the rename pages, it doesn't look like there are problematic backlogs suggesting a desperate need for more crats anyway (though more hands always appreciated - definitely don't want to put anyone off!!). More worried about lack of RfA candidates than lack of RfB candidates to be honest... WJBscribe (talk) 22:48, 1 October 2012 (UTC)
  • Oppose. With all due respect for the proposer, I'm not as confident as MBisanz that 98% of RFAs could be done using a 70%/80% bot rule and the renaming 2% can be adequately solved by reading Wikipedia:RFA#About_RfA_and_its_process. I do have great confidence in our crats for making the right closures through human discretion which a bot can't do, and reaching the right decisions when a crat chat is required. I don't see a reason or need to shift this upwards to the stewards any more than the right to rename accounts. Renaming is probably a boring routine task, but so are many admin tasks. What we need are more admins, and probably in fact more crats, and any suggestions that might have been made here to disband the crat flag altogether are, IHMO, a solution looking for a problem. Lowering the parametric bar for cratship might make sense (where for RfA howerver,it's about right), but at the end of the day, just as at RfA, it's the voters themselves who set the real bar anew for each candidate depending on who comes along to vote with their own personal criteria (and/or agenda). Kudpung กุดผึ้ง (talk) 05:05, 2 October 2012 (UTC)
  • Oppose — Per some others, I don't trust outsiders (which stewards usually are) to make the right decisions. I don't think it should be down to a simple "<70% fails, >=70% succeeds" criterion. We've had RFAs in the past that were closed (correctly, in my view) in ways opposite than that rubric would suggest, such as Danny's RFA. --Cyde Weys 20:39, 9 October 2012 (UTC)
  • Oppose, but I would support a proposal to grant stewards the authority to do this in addition to bureaucrats. Blue Rasberry (talk) 21:56, 9 October 2012 (UTC)
  • Oppose and suggest closing per WP:SNOW. Nothing more to see here; let's move on. (No one other than the editor who made the proposal has supported it.) -- John Broughton (♫♫) 03:17, 10 October 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

Alternate proposal

Would it be better if admins were offered the chance to gain rename priveledges similarly to how an ordinary editor could gain rollbacker? Please, with a support or oppose add whether community consensus is needed, or just the crat's blessing. Tazerdadog (talk) 01:21, 3 October 2012 (UTC)

  • Very interesting idea, but despite the difference between the two tasks, I still feel as if I could easily support someone who can perform renames within policy to also be granted the additional responsibility of judging consensus at a contentious RfA. So I'm leaning towards opposing this proposal, not because it's a bad idea, but I just think that it's superfluous to have so many different roles designated to different members of the community. There's too much bureaucracy as it is. Kurtis (talk) 06:19, 7 October 2012 (UTC)

Editor review with RfA/RfB in mind

I'm proposing a new form of editor review that would be a precursor to an RfA or RfB. I know that many times that is effectively the case anyway, but this new type of review would dispense with any uncertainty as to the purpose of the review. The review would be conducted to allow a user to gauge whether or not he has enough support to conduct a full-fledged RfA/RfB. Other editors could comment by saying that they would likely support, oppose or be neutral in a future RfA/RfB. This review would give the user a better idea as to if a week-long RfA/RfB would be worthwhile or if it would just be a waste of time. Also, editors contributing to such a review could provide the editor being reviewed with suggestions on how to better refine their editing skills in preparation for an RfA/RfB. The review would be closed by the editor in question at a time determined by him or her. AutomaticStrikeout 00:55, 5 October 2012 (UTC)

I think it would be helpful for an editor who is really seeking a review with adminship in mind if they can officially get a review that pertains to adminship. Also, I think editors would be more willing to simply state if they would support a user than conduct a full-fledged review. AutomaticStrikeout 23:13, 5 October 2012 (UTC)
Ok. Maybe this time will be charm, so to speak. AutomaticStrikeout 23:21, 5 October 2012 (UTC)
It's not reinventing the wheel. The idea is that someone would basically say that he or she is about to undertake an RfA/RfB and wants to know if it would a good idea or not. AutomaticStrikeout 02:21, 7 October 2012 (UTC)
  • All they have to do is make that statement when requesting an editor review. I would suggest no new board. Perhaps this is a softer RFA, but typically there will not be a lot of response unless the candidate actually runs! Graeme Bartlett (talk) 11:13, 7 October 2012 (UTC)
  • Oppose if somebody wants to gauge whether he would or would not pass a RfA, he can go thru one and find out. We don't really need an additional process designed as a pre-RfA. And if one wants feedback on their work, strength and weaknesses than there's the already existing, tho weak, editor review process. This is a solution in lack of a problem, and it hardly solves anything. Creating a pre-RfA hardly solves either our problems of lack of active sysops or that some percieve RfA has a too high bar. It has been proved in the past over and over that there's no harm in running for an RfA, multiple admins have been elected after multiple failed runs, and as such there is no reason to create an additional process when two already processes cover it perfectly. Snowolf How can I help? 10:53, 10 October 2012 (UTC)
  • Comment We used to have Admin coaching, something I believe Esperanza introduced. I went through it. Here's my admin coaching page when I was preparing for RfA. Admin coaching has now fallen into disuse and is marked as "historical". If people want this, they could revive it. —Tom Morris (talk) 11:57, 12 October 2012 (UTC)

Prolific IP editors - encouraging them to register

Most IP editors only make a small number of edits to Wikipedia. However there are some that contribute much more to it. Whilst IP editing is generally OK (and note - I am NOT proposing that we prevent it), it can be problematic, particularly when another editor wants to discuss something with an IP user whose IP address changes (e.g. to point out a consistent error they're making or a policy they're not following properly). Yes, you can post on an IP Talk page, but next time the editor logs on they might have a different address and therefore not see the message. Also, where an IP user is enaged in a discussion, it can be difficult to keep track of what they're saying - each time they post to the thread, it may appear as though they're a different person. Where IPs edit once or twice and then disappear, this isn't a problem, but some IP users are quite prolific and should really be encouraged to register so that they can contribute more effectively to Wikipedia.
I therefore propose capping the number of edits that can be made by an IP address in a certain time period, say, a maximum of 20 edits per day. Those users that only do a little bit of editing won't be affected, but the more prolific ones will be more inclined to register. This approach may also help to reduce mass vandalism by some IPs. What do you think? Bazonka (talk) 20:27, 9 October 2012 (UTC)

So basically you're saying that IP editors can't make mistakes and fix them? ♫ Melodia Chaconne ♫ (talk) 22:20, 9 October 2012 (UTC)
Er, no. IP editors are likely to be less experienced and less knowledgable of Wikipedia policies than an active registered user. Everyone makes mistakes or does things wrong, especially new editors. If they amend their own errors then fine, but sometimes people need to be nudged in the right direction or shown what to do. It's all part of Wikipedia's collaborative processes. If it is difficult to communicate with a user, then this nudging won't be as effective. Bazonka (talk) 22:26, 9 October 2012 (UTC)
As one of the many very prolific IPUsers, I strongly object to any restrictions on using IP editing. What I normally did as a work around was to move discussion to the registered users talk page to consolidate it and so that I could find it again. I also move discussions that were started on one user talk page and answered on another (if I am one of the two parties), so that the discussion is in one place and easier to follow. This is an encyclopedia and by nature there are many edits that can most easily be made by someone who is an expert in that subject, and the annoyance of having to make up a username just to be able to make an edit is absurd. And if that person sees 50 or a 100 things to fix in one day so much for the better. While I frequently got encouragements to register, it was a little pointless two years after I already had... Apteva (talk) 23:11, 9 October 2012 (UTC)
@Apteva, since you already have two(!) registered accounts, I cannot understand why you'd ever want to edit as an IP. This is a form of sockpuppetry, and since you don't get the advantages of a registered user, e.g. a watchlist, then why would you want to do it? Making sure that your conversations are all readable is good, but will all IPs do this? Probably not. Also, if I wanted to start a conversation with you via an IP talk page then I have no way of knowing whether it will actually reach you, unlike if I were to use User Talk:Apteva. Bazonka (talk) 07:23, 10 October 2012 (UTC)
The answer to "why" is beyond the scope of this conversation. I was simply pointing out that there are many prolific IPUsers and I am one of them. I rarely if ever missed anything that was placed on an IP talk page, as the orange bar shows up just like for everyone else, but had I not moved it to the user talk page following the conversation the next day, from a different IP address would have been difficult. I can think of an Admin who never checked or responded to anything on their talk pages - though after that was pointed out they might have become a former Admin. As to a watchlist, it gets so full as to become useless, so I rarely use it (my recollection is that out of 4,000 edits I have edited about 1,000 different pages). So I have the village pump and maybe two or three other pages on it right now. Apteva (talk) 13:33, 10 October 2012 (UTC)
I note that you didn't respond to my comment about sockpuppetry. My suggestion about a daily cap of IP use would surely help to reduce this heinous crime. Regards, Bazonka (talk) 16:30, 10 October 2012 (UTC)
Distinguish "sock-puppetry" from "multiple accounts". Our primary goal in discouraging sock-puppetry is to encourage good behaviour and discourage bad behaviour. As long as Apteva's following our guidelines and policies and generally behaving well, there's no real issue with them having multiple accounts. IAR. {{Nihiltres|talk|edits|⚡}} 17:36, 10 October 2012 (UTC)
I'm not convinced such a restriction would have an impact on sockpuppetry and it may have unintended consequences. Here is an example of an editor who uses sockpuppetry extensively both via registered accounts and via IPs. The list of IPs used is incomplete because they sometimes use IPs that aren't reported because blocking them would cause collateral damage (e.g. to a university network). An edit restriction could also cause collateral damage. This SPI case archive is a good source of sock data. The indefinitely topic banned and subsequently blocked editor has used sockpuppetry pretty consistently over an extended period, they have confirmed that they will not stop socking, and so the dataset is quite a large and relatively continuous sample of the trail left by a sockpuppeteer. If you look at the contributions by the IPs, and there are 15+ examples, you can see that within any given 24 hour period they make relatively few edits (and in this editor's case they are sometimes made in parallel with registered sock accounts). Relatively few edits within any given 24 hour period by IP socks is fairly typical in my experience and socks can and often do use both registered accounts and IPs. Sean.hoyland - talk 17:53, 10 October 2012 (UTC)
That is a good point. Long before an IP sock hits 20 edits they will have most likely been blocked or moved on to pre-empt blocking. And if the counter made them move on that only makes it harder not easier to see their editing pattern. Apteva (talk) 18:14, 10 October 2012 (UTC)
While there are many legitimate reasons for IP editing (and even some for legitimate socking) the fact remains that IP edits are inevitably seen as being potentially problematic. The real question to ask is: Why can't we make it more obvious to good faith IP editors what the chief benefits of registration are? Especially for dynamic IP assignment, it is virtually impossible to sustain a constructive one to one dialog: the talkpages keep changing. LeadSongDog come howl! 18:45, 10 October 2012 (UTC)
Speaking only for myself, I think that if it was possible to upload images I would never have even thought of becoming an admin some day, and never would have registered. I have found little to no use for the perks of being able to customize thumbs, etc, etc, and if anything when I am editing I want to try to figure out how someone else is going to see the article. I found the AFC process quite sufficient for creating new articles, and so on. I have seen ornery confirmed IP users whom I would have liked to have seen editing as a registered user, but telling someone else what to do is like herding cats. Apteva (talk) 19:38, 10 October 2012 (UTC)
Precisely - telling people to register doesn't necessarily work, hence this suggestion which should encourage them to register. Bazonka (talk) 20:05, 10 October 2012 (UTC)
  • Oppose. We need to remember that IPs are not the same as IP editors. One IP address can represent a library a company or even an entire country, and there may be many individual people editing via that IP address. So this wouldn't just be 20 good edits only then you're locked, it would be if anyone else has done 20 IP edits via the same IP you then can't do any. We also need to remember that IP editing is not something to be discouraged, sometimes it should even be encouraged. For example I occasionally edit via IP addresses in insecure locations such as airport terminals, we should be discouraging people from logging in when they are on an unsecure free public WiFi, not pressurising them to login. ϢereSpielChequers 20:54, 10 October 2012 (UTC)
Former prolific IP editor here. I think this proposal would be unnecessary and countereffective. While it is true that communicating with dynamic IPs can pose challenges, they can easily be overcome if the IP editor chooses to do so. It's easier and quicker with an watchlist and a new messages bar, but an IP can check the page history of pages they recently edited and check if they were reverted or if their former talk page turned blue. And if they need to follow up from a different IP, they can resolve any confusion by saying exactly that. Furthermore, prolific IP editors have likely been welcomed several times. Thus their continuing editing as an IP means WP:REG was read and rejected and throttling their edits is more likely to drive them to leave than to register. Kilopi (talk) 04:29, 11 October 2012 (UTC)
  • WP:WHY already exists. If an IP user has been here a long time, and feels that they don't need to register an account, we don't need to even know why, much less try to actively coerce, nudge, cajole, or encourage them to do so. If they wanted to, they'd have done so already. If they don't want to, as long as they are productive and useful members of the Wikipedia community, who cares? --Jayron32 04:40, 11 October 2012 (UTC)
    I would say nudging or encouraging is fine as long as you are clear that it remains the IP editor's choice and you respect it if its clear they understand what accounts offer and have decided to edit as an IP. Monty845 06:33, 12 October 2012 (UTC)
  • Oppose Prolific IP editors find ways to deal with the issues mentioned, and some have relatively static IPs which makes it easier. Inviting them and encouraging by identifying the benefits to registering is fine, but ultimately it is the editors choice. Monty845 06:33, 12 October 2012 (UTC)
  • Comment So, why would people want to be IP editors? Oh, here's a reason. A few months ago, I was at the Apple Store waiting to talk to one of their many blue t-shirted hipster Geniuses. I had about ten or fifteen minutes to wait. I was using a public computer on a public wifi network in a shop where I could be interrupted at any minute and forget to log off. Why would I want to log in with my admin account? I hopped over to Commons and categorised a few images and generally improved the wiki, then carried on with my day. IP editors aren't all newbs, idiots and crazies: some of them are long-time users, admins and the like who, for some practical reason, don't want to log in. —Tom Morris (talk) 12:05, 12 October 2012 (UTC)

Email Notifications (No Re-Arm)

As is, articles can be monitored for changes by adding them to My Watchlist and setting up My Preferences\E-mail options to "E-mail me when a page or file on my watchlist is changed".

Unfortunately, after each notification a user has to log in and visit the watched page to "re-arm" the notification service.

It would be nice if notifications would continue without having to "log-in to re-arm". — Preceding unsigned comment added by 195.241.24.118 (talk) 00:13, 2 October 2012 (UTC)

On the other hand, consider what would happen when you watch very busy pages, like this one or like WP:ANI. You'd wake up in the morning and have an inbox full of hundreds of change notifications. And then you'd come home from work and have an inbox full of hundreds more change notifications. Take a holiday for a few days, and come back to thousands. I don't think that would work for very many people. Anomie⚔ 20:05, 2 October 2012 (UTC)
I find even the talk page email notification is filling my inbox with lot of mails. I check my Watchlist more frequently than my email inbox. May be we can have something like email notification for specific pages rather than all pages on watchlist. --Anbu121 (talk me) 20:35, 2 October 2012 (UTC)
More fine-grained control over watchlists has been requested for so long, it's not even funny. Multiple watchlists or watchlist grouping would naturally open the way to having some pages generate email notifications, some not. Rd232 talk 17:15, 3 October 2012 (UTC)
Who would watchlist a page that is constantly updated, generating "thousands" of e-mail notifications a day? What would be the point? Perhaps the concept of "watching" should be refined to give people the explicit choice to "favorite" and/or "subscribe". --rrzzrr (talk) 03:31, 8 October 2012 (UTC)
Not everyone uses the watchlist the way you do. 2307 have this page watchlisted, 2397 watch Wikipedia:Village pump (technical), 2571 watch Wikipedia:Village pump (policy), 2744 watch User talk:Jimbo Wales, 3559 watch Wikipedia:Administrators' noticeboard, 5614 watch Wikipedia:Administrators' noticeboard/Incidents, 3539 watch Wikipedia:Administrator intervention against vandalism. Especially now that we have the ability to show which revisions have changed since the last visit in the history for watched pages, watchlisting these pages can be very useful. Anomie⚔ 10:47, 8 October 2012 (UTC)
Obviously, there are people who use watchlisting for different purposes. I would like "streaming" notifications, you don't. Why not refine watchlisting and offer the choice? Perhaps by separating "favoriting" and "subscribing", or offering a choice between "streaming" and "single" notifications.--rrzzrr (talk) 21:52, 15 October 2012 (UTC)
Here's who: subjects of BLP articles. People keeping an eye on articles about companies. Quite frequently, people want to know immediately when someone changes an article if that change is likely to cause them real-world stress. Unlike the hardcore Wikipedians, admins (etc.), some expert editors are likely to have very short watchlists. If someone is an expert on, say, an obscure 18th century German philosopher, their watchlist might just consist of one or two articles. Email is actually perfect for that kind of use case, even if it would be overkill for those of us with thousands of things on their watchlist. —Tom Morris (talk) 11:52, 12 October 2012 (UTC)

An admin of the day

DECLINED BY COMMUNITY
Quick close - unfortunately, this is an idea for a different time. Although well-intentioned, at present it would act as another beacon for conflict in a time when even becoming an administrator seems to have temporarily become impossible. Also, with our extremely limited stock of admins, the idea would run out of candidates in no time at all. — Hex (❝?!❞) 07:49, 15 October 2012 (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.

I am proposing the initiation of a project that identifies one administrator each day to be the admin of the day. It would be very similar to the Wikipedian of the Day, but more focused and would be a reward given to an admin for a specific admin task he or she performed. The project would list openings ten days in advance, and users could nominate an admin for any of those days, although they would only be allowed to nominate an admin once per admin task being recognized (as in, you would only be allowed to nominate an admin one time in recognition of a specific action, but you could nominate him for all ten days for ten different reasons). Self-noms would be prohibited. The admin of the day would be the first admin to receive 5 supports (the admin could not support them-self) for that specific day. Likewise, 5 opposes would cause the nomination to be removed. AutomaticStrikeout 21:34, 12 October 2012 (UTC)

Yuk! Malleus Fatuorum 21:39, 12 October 2012 (UTC)
I didn't know there was a Wikipedian of the Day. Don't explain it to me, I'm not interested. Jc3s5h (talk) 21:41, 12 October 2012 (UTC)
Why would we do this? Every single admin is an evil, power-hungry, corrupt, arrogant asshole who deserves a slap, not recognition to boost their already over-inflated ego--Jac16888 Talk 21:43, 12 October 2012 (UTC)
I didn't start this thread with the intention of seeing it lead to a bunch of people spewing out hateful personal attacks. AutomaticStrikeout 21:44, 12 October 2012 (UTC)
As you can probably tell, I didn't realize you were an admin. My bad. AutomaticStrikeout 21:46, 12 October 2012 (UTC)
Sarcasm aside, I see no reason to single out administrators for special praise. (Note that I'm one too.) —David Levy 21:57, 12 October 2012 (UTC)
Well, it seems like admins have to deal with more mistreatment than any other group of editors. AutomaticStrikeout 22:01, 12 October 2012 (UTC)
Seems like that to whom? Certainly not to me it doesn't. Malleus Fatuorum 00:36, 13 October 2012 (UTC)
Agree with Malleus Fatuorum, if anything the shoe is on the other foot! ~ GabeMc (talk|contribs) 00:59, 13 October 2012 (UTC)
Watch the admins who handle Indian castes or AE for a while, that should give you a bit of perspective. The Blade of the Northern Lights (話して下さい) 02:55, 15 October 2012 (UTC)
Treating editors as members of separate "groups" is unhelpful. As you can see from some of the responses to this proposal, there already is a widespread perception that administrators are treated as an elite class (and unfortunately, it does occur). —David Levy 02:10, 13 October 2012 (UTC)
Sounds great! Now RFA is near-defunct, people have a lot of stored-up abuse & this would be a useful place to vent it. Mind you we could only run it for around 2 years before we ran out .... Johnbod (talk) 00:43, 13 October 2012 (UTC)
Yeah, there's only ~700 to 800 active admins, speaking practically. --Rschen7754 01:01, 13 October 2012 (UTC)
What a splendid idea! There could also be special prizes for major admin achievements, like who manages to block the most productive content editors. The winners could appear on the front page, replacing the featured article. Wikipedia is experiencing a truly amazing evolution under the guidance of our dear administrators. --Epipelagic (talk) 01:15, 13 October 2012 (UTC)
You realize that a non-administrator proposed this, right? —David Levy 02:10, 13 October 2012 (UTC)
I agree its a pretty good idea but we are so low on admins that they'll all have a turn before Christmas. Kumioko (talk) 01:20, 13 October 2012 (UTC)
We don't need the drama of anything in project space or with nomination discussions. You are free to make something like User:Bibliomaniac15/Today in userspace with posts to your selections. PrimeHunter (talk) 01:46, 13 October 2012 (UTC)
True. There's already been several completely uncalled for remarks. As PrimeHunter suggested, I might just start something in my own userspace if I can get some other editors interested in helping. If not, I may just start my own Wikipedian of the day with everyone eligible. AutomaticStrikeout 02:02, 13 October 2012 (UTC)
  • Nice idea but sadly oppose: This is undoubtedly a nice and positive idea to acknowledge contribution and may be encouraging for editors, But, giving the admin tools, that's also for 24 hours is not the best thing we can/should do. (BTW, what is Wikipedian of the day?, you can post in my talk page if you want to avoid drifts) --Tito Dutta (talk) 08:15, 14 October 2012 (UTC)
  • Oppose as a horrible idea. Any admin that needs their ego stroked by something such as this has no business being an administrator to begin with. And if we DO go ahead with it, let's revive WP:ADMINCOACH and make this a subpage, because the majority of the people voting for administrator of the day will be the type fawning over admins in the hope it pulls in a few extra votes when their RfAs come up. Trusilver 15:21, 14 October 2012 (UTC)
  • I'm sure this was proposed with the best of intentions, but I don't think it's a good idea. We should be trying to lower the status of admins to the "no big deal" idea, not looking for ways to boost egos -- Boing! said Zebedee (talk) 07:11, 15 October 2012 (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.

Main page redesign competition - straw poll

A straw poll recently opened as part of the 2012 main page redesign competition. The poll is not binding and will not be used to replace the current main page; its purpose is solely to narrow the number of proposals so that these can be discussed further and refined. All editors are invited to view the proposals, vote, and participate in the resulting discussion. - Evad37 (talk) 09:31, 13 October 2012 (UTC)

You guys are still operating this as a "competition"? —David Levy 15:41, 13 October 2012 (UTC)
Well, its not really a standard competition... the "winners" will have the "prize" of being further developed, discussed, tested, and put before a larger scale RFC as alternatives to the current main page. So in answer to your question, yes and no - Evad37 (talk) 16:54, 13 October 2012 (UTC)
I'm aware. But that seems like the same approach that failed in 2008 (when warnings that "competition" almost derailed the 2006 redesign were ignored).
As I recall, the current attempt began with a call for submissions from professional Web designers. That idea seems to have fallen through, so why was the "competition" format retained? —David Levy 17:38, 13 October 2012 (UTC)
Because no one is in charge. -- It's snafu, as we predicted and tried to warn against. -- There are some interesting content ideas, but the underlying code in most (all?) of them is napkin-sketch quality.
However, There is a good code-update-proposal (see the redlinks here, a few inches down), that replaces the htmltable-layout and embedded styling, with modern CSS layout and separated styling. I'd be exceptionally happy to see that revived-checked-and-implemented by any admin with web-design-understanding. It would be a very strong move in a positive direction. (Ideas from the 'competition' could then potentially be added in to that good code-base, if/when it arrives at a decision on what is wanted). —Quiddity (talk) 20:46, 13 October 2012 (UTC)
The proposals page states "It is expected that high profile web designers will team up with Wikipedians" - that didn't end up happening. Maybe it should have been an explicit requirement. Maybe the whole thing should have been a discussion on what to change, with subsequent entries required to comply with all (rough) consensus reached. But now that we have these proposals, we might as well go through with it - what is the other option, abandoning them and just giving up? - Evad37 (talk) 02:24, 14 October 2012 (UTC)
Well, that is what ended up happening last time. I'm not suggesting that it necessarily should occur in this instance, but it's worth considering whether it might be prudent to cut your losses instead of investing more time and effort in an endeavor that isn't panning out.
Because there was no "discussion on what to change" (and no specific goals were established), the submissions comprise a random mishmash of conflicting ideas. No offense intended, but there honestly isn't one that I regard as a better starting point than the main page's current design is. Sorry. ): —David Levy 19:34, 14 October 2012 (UTC)

Democratic wikipedia fork

I propose that Wikimedia will initiate a fork of Wikipedia where the rules of editor interaction are democratic. I set up a fork under the name of Creative Democracy to host this proposal until it is picked up. Its charter reads:

Creative Democracy is a democratic Wikipedia fork. Like Wikipedia it accepts anyone to its editor ranks, but, unlike Wikipedia it follows the principle of separation of powers as a federation of categories, guided by noting but Humanism at large.
  • Its editors form legislative, executive, creative and judiciary bodies, both at the category level and the federal level.
  • All editors belong to one, and no more than one, federal body, with the default being the creative body. All editors may choose to be members of one creative category body and one legislative category body, and may change these once in a calendar month, or subject to federal judge approval.
  • Only members of the executive body may hold software dependent rights that are not shared with all other editors. Moreover, only one such right is allowed per member.
  • Executive and judicial body members are appointed and recalled by their corresponding legislative bodies. All executive members are subject to term limits, set by their legislative category body, but which cannot exceed five years per category.
  • Each article has one primary category. Its primary category is sovereign in regard to running ads and soliciting contributions on that article, the proceeds of which are shared with the main foundation. It is also sovereign in making editing open to members of other categories, on a category by category basis.
  • The main foundation, and each of its categories are obliged to release at least 50 percent of income to editor compensation. Compensation is awarded to editors as a share of released income appropriate to their expertise and time investment.
  • All legislative bodies operate by the principle of majority rule. The members of the federal legislative body are selected by the categories legislative bodies, and their number of representatives is kept in proportion to weekly unique IP page-views. It is up to each category to maintain a ranked list of editors standing-by to transition from the federal creative to the federal legislative body, as new page-view information requires realignment.
  • Financial information, both in the category and federal level, are kept publicly available on a near real time basis.

All other issues are left to decision of the federal legislative body.

→Yaniv256 wind roads 19:13, 7 October 2012 (UTC)

OK, how about if we make it the go-to place for articles that are subject to edit warring? This way it can both releave some of the pressure in the Wikipedia page and allow disputes to be setteled with better due process. →Y256 wind roads 18:33, 18 October 2012 (UTC)

It's time to temper the rule against shared accounts.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus is strongly against this change. Sven Manguard Wha? 04:59, 19 October 2012 (UTC)

There are a large number of institutional stakeholders that would benefit from having what I would call an institutional account, from which editing could be done. Here's an example. I recently spoke with the public relations offices of the Indiana University Maurer School of Law and the Indiana University Robert H. McKinney School of Law, in order to clear up a few lingering disambiguation links from Indiana University School of Law. In the course of each conversation, I suggested to the outreach person to whom I spoke that their office would benefit by having someone with a presence at Wikipedia to insure the accuracy of information about alumni of these institutions. Indeed, I think every university should have a Wikipedian in residence in their outreach office, someone who can facilitate communications and access to university-held information. However, I don't think it makes sense to ask these institutions (or other institutions like libraries and museums) to rely on individuals who take the username with them when they leave the position.

I think that with proper guidelines to insure transparency, we could make very effective use of accounts attached to institutions, wherein the person holding the office of institutional Wikipedian may change from time to time while the role of the account itself remains the same. Obviously, such accounts would be ineligible for admin status (although I could see giving rollback rights to an institution that has demonstrated wisdom in selecting account holders), and users wishing to maintain a personal account while also having access to an institutional account would need to disclose their distinct roles. I believe that such an amendment to our policies would allow institutions with a useful body of knowledge to develop a greater sense of investment in Wikipedia's success. bd2412 T 04:44, 12 October 2012 (UTC)

  • Agree. OTRS exists to validate stuff like this. --Tagishsimon (talk) 04:47, 12 October 2012 (UTC)
  • Oppose In sui generis cases, it may be OK per WP:IAR, but I would be opposed to changing the existing policy in any way. It's a very short trip down a very slippery slope to get from having a role account used by University Wikipedians in Residence to other more dubious uses, such as having PR offices from companies using such accounts to enforce "official" versions of pages. I don't see having each person who hold such an office having to maintain their own account at Wikipedia to be a significant barrier to having them contribute. Seriously, if a new person takes the job, they can register their own account. It take 10 seconds. --Jayron32 04:51, 12 October 2012 (UTC)
  • Oppose: If there is change at the university in employee status, user pages can be updated. I've talked to people inside stakeholder organisations who have done or might be interested in contributing knowledge and donating materials. This issue has never come up as a need. --LauraHale (talk) 05:01, 12 October 2012 (UTC)
    • By "user pages can be updated" do you mean that the account can be updated to indicate that a different person is now the user, or that the account no longer edits on behalf of the institution, and another one does? bd2412 T 05:03, 12 October 2012 (UTC)
  • Oppose Too many problems come with shared accounts: Disputes over control, one controller getting a message and then another controller not knowing about it, issues with socking, etc. Also we would need to carefully consider the implications on our licensing scheme. Is a shared account compatible with our licensing structure? Monty845 05:11, 12 October 2012 (UTC)
  • Oppose - I believe that people should contribute Wikipedia on a personal and individual basis, for which shared accounts have no uses outside the scope of the current policy.--Jasper Deng (talk) 05:15, 12 October 2012 (UTC)
  • Oppose Personalities and memories are unique to an individual and so should the username that we are interacting with. Make up a username like IBM-23846328 if you wish, but make it only for one person. This is a situation, though that may lend itself to the necessity of using an alternative account for other edits, or changing usernames if the individual leaves. Apteva (talk) 05:57, 12 October 2012 (UTC)
  • Comment Kinda surprised no one seems to have mentioned it, but isn't "individuals who take the username with them when they leave the position." a necessary part of the licence you submit to when editing WP? Whoops, I guess someone did. ♫ Melodia Chaconne ♫ (talk) 06:25, 12 October 2012 (UTC)
  • Oppose I agree with the sentiments expressed by others - potential headaches, with not enough benefits. Like Apteva, I think the goal can be achieved better by other means. I think eight digits is overkill, a starting user name like Indiana SOL_a, followed by Indiana SOL_b, when a new person is appointed, then Indiana SOL_c etc., will keep the edits identifiable.--SPhilbrick(Talk) 14:19, 12 October 2012 (UTC)
  • I definitely like the idea of certain institutions having a larger presence (assuming that they behave themselves as per WP:COI), but I'd rather they have clearly-defined individual accounts, which would make it easier to remove them from a specific role once the individual is no longer employed by the institution. (and for the record, my "certain institutions" statement means that we'd happily welcome a group like a museum or a university, but be FAR more wary of a PR firm). EVula // talk // ☯ // 21:25, 12 October 2012 (UTC)
  • Oppose. It's a wiki: no position of authority over individual edits exists, so there's no such right to transfer to others. Individual accounts are so easily set up, with so little friction, with such naming flexibility, and with such low requirements for individual identification, that there's no need for account sharing or continuation in any way. Example: User:LiaisIJ (Ian), who is followed in the IUMSL liaison position by User:LegalStafferx04 (Jane), can both identify their affiliation (conflict of interest) on their User pages, per WP:COI, as usual. ---Lexein (talk) 17:55, 14 October 2012 (UTC)
  • Oppose - have you considered the copyright implications, for one thing? And the potential for delusions of a "right" to WP:OWN an article are pretty obvious. --Orange Mike | Talk 19:05, 18 October 2012 (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.

Page listing potential candidates for adminship

What with there having been a recent drought at requests for adminship I brainstormed for some ideas as to how to get more editors nominated and promoted. In my opinion the best solution I came up with is to create a listing page similar to Wikipedia:Inactive administrators that lists potential candidates for adminship to consider for nomination. The page would be updated by a bot and list users from Category:Wikipedia administrator hopefuls (thus being opt-in) who have, say, at least 7,500 edits and have made at least 60 edits in the previous 30 day period. These numbers are relatively arbitrary and could be adjusted. I checked with User:Madman (who runs the bot that updates the inactive administrators page) and it should be possible for a bot to do this should there be consensus to create this listing. What does the community think? Ks0stm (T•C•G•E) 01:02, 19 October 2012 (UTC)

Sure, but I'd also put a disclaimer stating that candidates should be vetted before nomination. --Rschen7754 01:05, 19 October 2012 (UTC)
See Wikipedia:List of administrator hopefuls. RickBot updates it twice a week. Legoktm (talk) 01:11, 19 October 2012 (UTC)
Huh, somehow I completely missed that page (which probably says something). Why not beef up that page a little instead, then. I still say showing users with at least 7500 edits and who have made at least 60 in 30 days would do well; at my RfA I had over 200 edits in the preceding two months and there were still a couple of complaints about lack of activity, so 30 in two months seems woefully short. I also had around 7000-7500 edits which from what I can tell is pretty low on the scale for successful RfAs, so filtering to editors with at least about that many edits also makes sense to me. I do like that it shows previous RfAs, though...that's a feature I hadn't thought of. Ks0stm (T•C•G•E) 01:30, 19 October 2012 (UTC)
I'm going through and removing the indefblocked users; the page is broken towards the end. --Rschen7754 01:38, 19 October 2012 (UTC)
The reason for the problem at the end is too much information to display. A section of editors with over 5,000 edits, and 100 edits in the last month and a link to others would help. The problem with too much to display would also be fixed by segmenting the list by first letter, or even just splitting it into two lists, A-M and N-Z. Apteva (talk) 02:25, 19 October 2012 (UTC)
It's updated by a bot so any solution must take that into account. I have replaced the many calls to the expensive {{user20}} with the inexpensive Wikipedia:List of administrator hopefuls/User, made for the purpose. The old version failed long before the end with "Post-expand include size: 2048000/2048000 bytes". The new version should have room for three times as many users since it says "Post-expand include size: 644966/2048000 bytes". It also previewed in 12s instead of giving up after 60s. I don't think we need a split or reduction. I will suggest the bot operator uses Wikipedia:List of administrator hopefuls/User in updates. This is a very simple change. PrimeHunter (talk) 03:16, 19 October 2012 (UTC)
Seems like a good idea, though we'll see how many people actually utilize it. elektrikSHOOS (talk) 04:12, 19 October 2012 (UTC)

Rare and Orphan Diseases App

Dear Wikipedia, I am the president of the not-profit BLACKSWAN foundation (www.blackswanfoundation.ch, we are supporting the research on rare and orphan disease and improve the knowledge of the general public about rare diseases). I am very often confronted to researchers, patients and families with a horrible rare and/or orphan disease. There are more than 7'000 rare diseases out there, so how you can imagine we cannot know all of them. In order to understand and discuss with those people most of the time I am using your excellent iPhone app. Now, the reason because I am contacting you: could be imaginable to develop a wiki app focused only on rare and orphan diseases? We already worked on that App with our webmaster, but off course we do not have a database describing all this diseases. And this db should alive, often updated...This, will improve the quality of life, the knowledge, the take care and many other aspects of the rare disease patients. Looking forward to reading a positive answer from you Best regards,

Dr Olivier Menzel, PhD— Preceding unsigned comment added by Mrgreenworld (talk • contribs) 18:54, 15 October 2012 (UTC)
Dear, Dr. Oliver Menzel, I doubt developers would make an app focused only on diseases. However, if you are capable of developing apps, I believe the mobile Wikipedia app is an open-source program so you are free to use that and focus it on medical searches. Although, I don't understand why you can't just use the Wikipedia search bar on our mobile app.—cyberpower ChatOnline 13:36, 16 October 2012 (UTC)
Dr. Menzel, if I'm reading you right, you'd like a wiki that focuses on rare diseases. It would be possible for you to set one up on Wikia, and copy relevant material to it from Wikipedia, providing you abide by the terms of our copyrights and license. Were you to license contributions to your site in the same way, they could be shared back to the main body of Wikipedia and everybody would benefit. Does that sound like what you want? — Hex (❝?!❞) 09:28, 18 October 2012 (UTC)
Yes, you would create a WP:FORK of just the articles that interested you. They ought to be listed at Category:Rare diseases.
You might like to talk to the people at WP:MED. They might have ideas on which things you would want to include. Unfortunately, I don't believe that anyone there would be able to create the app for you, though. WhatamIdoing (talk) 16:14, 19 October 2012 (UTC)

Display Article Rankings in Title

I'm not sure if this is the right place for this suggestion, but I think it would be a good idea to put the quality ratings of articles near the title of pages. This would be similar to the featured or good article symbols, except that it would apply to all ratings. I think that this would help readers know how reliable and useful the article is and would help editors know how much the article has to be improved. --qwekiop147 → talk 17:38, 21 October 2012 (UTC)

Isn't it already there? --  :- ) Don 17:45, 21 October 2012 (UTC)
I don't think so. For example Wiktionary is rated C-class, but you have to go to the talk page to find that out. The idea would be to put a symbol like at the top right of the page. --qwekiop147 → talk 18:00, 21 October 2012 (UTC)
There is a gadget. Chris857 (talk) 18:02, 21 October 2012 (UTC)
Thanks, I didn't know that. I enabled that gadget, but I still think it would be a good idea to put a symbol there. --qwekiop147 → talk 18:19, 21 October 2012 (UTC)

Articles for Improvement

APPROVED BY COMMUNITY
Process accepted.

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.

Main page: Wikipedia:Articles for Improvement

I am proposing the approval of this new process called Articles for Improvement. I have been working on this since June and think it is ready to be presented to all the community. This process is intended and designed to support the development and expansion of articles in the need of urgent care from editors. The process is also planned to avoid those articles to be mistakenly nominated for deletion for the mere purpose that it doesn't meet the guidelines but, with help from the community, will be eventually able to. The whole process is already designed, as can be seen in the link above, including how to nominate an article, how the nominations may evolve, among other information. — ΛΧΣ21™ 03:21, 12 October 2012 (UTC)


  • Strong support A great idea! Zac (talk) 03:22, 12 October 2012 (UTC)
  • Comment It's not clear to me how this improves on the current situation; we have articles nag-tagged, and users either do or do not improve them. Now we can list them on AFI and have a discussion. A discussion about what, exactly? You seem to be describing out many unloved and somewhat borked articles - articles on which several cleanup and maintenance tags has been placed and still, after a grace period of over one month, are still awaiting such improvement where there's little to be said beyond "please wikify / reference / adduce notability / etc". So. Not convinced. --Tagishsimon (talk) 03:45, 12 October 2012 (UTC)
  • This is an alternative to AFD. This is an alternative to tagging articles. Many articles end up in AFD because of their actual state. This process is intended for any article. Users can gather here and improve any article they wish, altough the process is originally designed to apporach articles in a poor state that can be substantially improved in a matter of days. How this improves the current situation? Tagging an article is not enough, if you never visit the article, you'll never know it needs improvement. AFI's goal is to provide a centered gate were many users can discover and work on articles that do need help and that otherwise they will never look at. — ΛΧΣ21™ 03:59, 12 October 2012 (UTC)
  • Well, good luck with that. The argument you level against tagging (and fail to level against the categories which tagged articles fall into, and the work groups which mine those categories) applies equally to the proposed page/method. Only time will tell if the community will adopt and use such a process. I tend to doubt it, mainly for the reason that I think we lack editors, not the organisation of the work of those editors. --04:21, 12 October 2012 (UTC)
  • Categories is not the same as this. This gives you the possibility to center discussion with all users interested in improving the article. Tags and categories doesn't do that and i've proven that by myself. If AFD works at improving articles, why not designing a process for articles that are not up for deletion but can be substantially improved? Our goal is to build an encyclopedia, and we lack a work center to join as a community and share ideas and teamwork. I know we have Wikiprojects, but they center on some specific groups of articles; this is a global process. I know we have categories, but this lets you comment and interact with other users on a single venue to reach a common goal: achievement. Tagging is not enough if we don't have an organized entity into which discuss how to make such tag dissapear and produce quality content. — ΛΧΣ21™ 04:29, 12 October 2012 (UTC)
  • I kinda like this idea. Social processes on Wikipedia should be used to help nudge articles to a better state. WikiProjects is part of that. Strangely, AfD does that too (albeit with the negative cost of holy shit they want to kill my baby!). WP:TAFI is doing that. Imagine, if every day you went on to Wikipedia, there were editors who were actively looking for people to help improve an article. Sort of a bit like WP:ANI but instead of drama, it'd be filled with good faith efforts to improve the 'pedia. I'm up for that. —Tom Morris (talk) 12:08, 12 October 2012 (UTC)
  • Support. Sounds very rationale and needed. We have a lot of articles in bad shape and this can help. Good idea! — Tomíca(T2ME) 18:03, 12 October 2012 (UTC)
  • Support seems like it would be a net positive--it can always be refined if there are bumps in the road. Mark Arsten (talk) 18:54, 12 October 2012 (UTC)
  • Strong support If the process fails, no harm is done. If the process succeeds there is a considerable amount of benefit. Fruitful discussions from the process could be passed on to WP:TAFI to get even wider improvement. Ryan Vesey 18:58, 12 October 2012 (UTC)
  • Oppose. This will need a lot more work before it is even near ready. Creating a workable process takes a lot more than copying AFD and replacing "deletion" with "improvement".

    Let's first consider the process this is modeled upon, AFD. Why does AFD get stuff done?

  • We have fairly well-defined inclusion and deletion criteria. After most of deletable articles are pruned by CSD or PROD, relatively few articles are left for AFD to discuss. That is, it generally will not be overwhelmed by excessive numbers of nominations. Even then, we sometimes have cases of mass AFD nominations that threaten to overwhelm the system.
  • AfD has a relatively firm deadline. Yes, you get relists; rare cases get multiple relists, but they are discouraged, and admins try to close an AFD older than seven days whenever possible.
  • Editors who want the article to be kept has a strong incentive to try to improve it before the deadline.
Now look at this proposed process. The nomination criteria are extremely broad and vague, which will lead to lots and lots of nomination since virtually every single article on this project can be improved. There is no deadline for discussions - they remain open indefinitely until participants somehow decide that the article is "ready" (for what?), and there's no incentive to actually improve the article - nothing will happen if the article stays the way it is. Even when the article is improved, the system will split discussion about an article between the AFI page and the article talk page, making it hard to figure out.
We have a process with this kind of characteristics, too. It's called editor review. Every editor can ask to be reviewed, just as pretty much every article can be improved. There's no incentive for reviews; and those review pages will stay around indefinitely until the subject decides to close it.
Look at the page now. Of the 24 open reviews, only a couple has substantial participation from a number of editors, and the majority haven't even been touched yet or only has a very short comment. We got several requests from more than half a year ago that's still open!
What this proposal, in its current form, will likely lead to, then, is AFI being overwhelmed with nominations that very few editors would notice or care much about and that languish indefinitely. In the end, it will just become yet another maintenance tag, though a fancy one with an associated project space subpage. I cannot support such a pointless exercise. T. Canens (talk) 02:59, 13 October 2012 (UTC)
What you say has no meaning in part. If a nomination lasts opened with no comments for more than 7 days, it will be closed. This process is similar to peer review but for articles that are not up for GAN, FAC, etc. We won't have a big backlog. I know that any article can be improved, but this is only designed for articles in urgent care. Also, the page says that each nomination may last from 7 to 14 days. The other point: it won't be a maintenance tag, as it will only be there for 7 to 14 days (as I already said). — ΛΧΣ21™ 03:54, 13 October 2012 (UTC)
  • Question - what exactly does this have to do with AfD? Any articles that qualify for deletion under policy cannot be improved and that is precisely why they qualify. If the participants in AfD discussions are not keeping to this, that's another issue entirely, but adding a side process isn't going to help that any, however useful it may or may not be in bringing folks together to collaborate on some of the more salvageable ones. -— Isarra ༆ 07:17, 13 October 2012 (UTC)
    The only conection this may have with AFD is that many articles that are kept on AFD are so because they can be improved but are mistakenly considered as unsalvageable. This project is aimed at improving articles mainly from the stub-start-C-class categories to B-or-high categories, to make an example. AFD is for the unsalvageable ones, AFI is for the one that can be easily improved with efforts from several users. — ΛΧΣ21™ 16:46, 13 October 2012 (UTC)
    Aiight, fair enough. As you previously said it was an alternative to AfD, I was a little confused. -— Isarra ༆ 03:09, 15 October 2012 (UTC)
  • Unenthusiastic support. My general experience of Wikipedia is that robotic mechanisms yield robotic results, and that the more noticeboards/XfX type processes we have, the less time people spend on individual ones. But this does attempt to address a big problem on Wikipedia: difficulty in getting second opinions on articles that aren't supported by an active Wikiproject. It's worth a shot. —WFC— FL wishlist 07:25, 13 October 2012 (UTC)
  • Support A good concept, hopefully it will gain traction quicker than WP:TAFI has. AutomaticStrikeout 17:32, 13 October 2012 (UTC)
  • Won't work. How is this different from Wikipedia:Article Rescue Squadron/Rescue list or any of the other dozen attempts to do this? What you need to fix articles is people. The reason people show up at AFD is because there are immediate consequences: find the sources, or we dump it. Without that enormously motivating stick, you've got no reason to get it done within a week. That, as a result, puts you back into the everyday activity of article improvement drives, collaborations of the week, and all the other maintenance and improvement WikiProjects, which are generally dormant because nobody cares enough to join them. WhatamIdoing (talk) 16:08, 19 October 2012 (UTC)
  • If there are enough volunteers, I suppose there could be some sort of way that automated lists of 5 or so B-class or below articles would be sent out to interested editors. If they agreed to do so, they could work on cleaning up those articles. List items could conceivably be drawn from specific areas that contributors are interested in working within. This isn't the proposal, to be sure, but could something like this be tied in with it? dci | TALK 16:36, 21 October 2012 (UTC)
  • Oh good proposal. Of course it can be tied to it. Create a sort of message like the Signpost and RFCs do. We can develop this later after the proposal is approved and tie something like this to it. — ΛΧΣ21™ 21:32, 21 October 2012 (UTC)
  • Support. I'm skeptical that it would actually work - anybody who wants to fix articles which have been tagged already has easy access to a gigantic backlog - but any initiative which focuses minds on improving bad articles is worth a try. Maybe throw in a few barnstars, GOCE-style. bobrayner (talk) 11:10, 22 October 2012 (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.

WP:COI+

Hi all!

I was wondering if you would take a look at WP:COI+.

I intend for COI+ to seek a middle ground between the current ambiguity of WP:COI and the severity of Bright Line prohibitions on any direct editing. This is particularly important because the community has identified that there is some problem with WP:COI but also found no consensus to outright ban paid editing.

  • The 2009 RfC to ban paid editing closed with no consensus.
  • The 2012 RfC on COI closed with no consensus as well.
  • For as many people who have supported a prohibition on direct editing there is another editor who calls COI a distraction and cites WP:NPOV as the only relevant policy.

For those reasons, I simply don't believe that Bright Line will ever gain consensus. I also happen to think it's not ideal, as it could drive paid advocates under ground, it has no requirement for disclosure, and it offers no reasonable assurance to paid advocates of a timely response to their suggested changes.

COI+ is designed to address each of those concerns:

  • COI+ would appeal to paid advocates by welcoming them to the community, educating them about our mission and policies, and guiding them towards constructive interaction;
  • COI+ would require disclosure--in triplicate--on user pages, relevant article talk pages, and with links to COI declarations in comment signatures
  • COI+ would set a 1 month time limit on edit requests: if no editor even responded to a paid advocate's suggestions or proposed changes within a month--after going through talk pages, help boards, noticeboards, and OTRS--then a paid advocate could make a change directly, if they left clear notice on the article talk page and at the COI noticeboard.

I am drafting a Signpost op-ed introducing COI+ to run in the next month or two, with an RfC to follow. At first COI+ would merely be an aspirational, voluntary agreement. It could, however, be a bridge forward towards a more comprehensive, instructive, and hopefully effective guideline for COI editors and particularly paid advocates. I'd love to hear any thoughts you have about it. Ocaasi t | c 14:15, 22 October 2012 (UTC)

User page edit notice proposal

Wikipedia:Village_pump_(policy)#User_page_global_edit_notice_proposal Please discuss on the other thread. Gigs (talk) 00:54, 23 October 2012 (UTC)

Proposal: remove/hide signature button when editing articles

APPROVED BY COMMUNITY
Tracked in Phabricator
Task T7645

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.

This proposal is short and sweet: I propose removing or hiding the signature button ( or ) from the editing toolbar when the page being edited is an article. Per WP:SIGNHERE, "Edits to articles must not be signed, as signatures on Wikipedia are not intended to indicate ownership or authorship of any article."

Adding a signature to an article is a common mistake among new users (my bot spends much of its time removing these from articles), and whenever something's not supposed to be done, it makes sense not to have a button to do it. (If there ever is a reason where an article should be signed, a user could still just type ~~~~ manually in the edit window to do it.) 28bytes (talk) 23:02, 30 September 2012 (UTC)

Sounds like a good idea, but having a magic word or other setting to enable the button on a per-page basis would be good (such as for project pages like this one).--Jasper Deng (talk) 23:05, 30 September 2012 (UTC)
It would just be removed for article space (namespace 0), not project space or other spaces. 28bytes (talk) 23:28, 30 September 2012 (UTC)
  • Support. There's no reason why an article should be signed. --Rschen7754 23:40, 30 September 2012 (UTC)
  • Support - though I don't know of its technical implementation.--Jasper Deng (talk) 23:59, 30 September 2012 (UTC)
  • Support provided technical implementation won't be complex or take excessive developer time relative to other priorities, and provided this won't create a server load issue (since a different page configuaration would need to come up for some pages tha others). Newyorkbrad (talk) 00:20, 1 October 2012 (UTC)
  • Support iff NYB's conditions are fulfilled. --Guerillero | My Talk 01:08, 1 October 2012 (UTC)
  • Okay It's alright, but what does it solve? The most it might help with is if new editor goes to sign their contributions. Other than that the only time four tildes have appeared in a row in an article is for vandalism. It might just be easier to put ~~~(~~) on a blacklist specifically for the article namespace. Regards, — Moe ε 02:37, 1 October 2012 (UTC)
    There's no reason to have it there at all in the article namespace - it just adds clutter to the toolbar. -— Isarra ༆ 02:45, 1 October 2012 (UTC)
    Not saying that it doesn't, but the difference between (around) 25 clickable things versus 24 isn't the argument, I think. If the goal is to have lower instances of signatures appearing in the article namespace, then a blacklist on a string of ~ appearing is a better solution. Manually, ~~~~ could still be typed out by editors, making the button not being there pointless. Regards, — Moe ε 05:08, 1 October 2012 (UTC)
    A button is still easier to click by accident than a pile of tildes are to type out, and just blocking the end result won't stop people from doing it in the first place and getting confused. If it is an issue, perhaps doing both would be in order? -— Isarra ༆ 05:22, 1 October 2012 (UTC)
    Possibly. I have no preference whether the button stays or goes personally, I was just addressing the problem it creates being there rather than its existence. Either a blacklist or a notification (similar to the "you are missing an edit summary" save notification) if ~~~[~~] are saved in the article namespace would probably fix it, along with removing the physical button. Regards, — Moe ε 06:11, 1 October 2012 (UTC)
    I believe there are a number of maintenance templates used in article-space which involve timestamps generated through a five-tilde signature, and various deletion-related templates (eg speedy, prod) are often signed by editors. I don't think technically prohibiting the string is the best solution. Andrew Gray (talk) 13:59, 1 October 2012 (UTC)
  • Support emphasizing that this only applies when editing an article. Pine✉ 06:05, 1 October 2012 (UTC)
  • Support, but button should be blanked out rather than completely removed, so that the other buttons are in same place, for the sake of editors who use them a lot and whose fingers know exactly where to find them. PamD 06:40, 1 October 2012 (UTC)
    If implemented in JS, this will also avoid the problem of a user trying to select a button before the JS fully loads, and then clicking the wrong button as everything "jumps" to the side. (I keep having this with the top-bar links, as "My sandbox" lags a second or so) Andrew Gray (talk) 14:25, 1 October 2012 (UTC)
  • Support, Makes sense. Kudpung กุดผึ้ง (talk) 07:42, 1 October 2012 (UTC)
  • Support, really good idea! mabdul 08:40, 1 October 2012 (UTC)
  • Support The button could be disabled or grayed out if removing is technically complex. --Anbu121 (talk me) 08:44, 1 October 2012 (UTC)
  • Support Computer software usually makes it impossible for users to do things that ought never to happen. On Wikipedia, we make it technically possible to do undesirable things, then when a confused newcomer does them, we revert them and give that user a telling off. This change would be a first step towards remedying that. MartinPoulter (talk) 12:45, 1 October 2012 (UTC)
  • This is in Bugzilla (remarkably enough, from 2006). Link added. Andrew Gray (talk) 14:08, 1 October 2012 (UTC)
  • Support, I too remove mistaken signatures in articles, from mis-clicks of buttons. This one is not needed for editing articles. Fylbecatulous talk 14:12, 1 October 2012 (UTC)
  • Support Makes sense, little to no chance of causing problems, and removes a common nuisance. --Jayron32 14:14, 1 October 2012 (UTC)
  • Support assuming it doesn't create technical problems. It's just good UI design.--Curtis Clark (talk) 14:55, 1 October 2012 (UTC)
  • Support Yay, you're halving the edits my bot has to do! Why did nobody think of this years ago? Rcsprinter (talk) @ 15:12, 1 October 2012 (UTC)
  • Support as this is a no-brainer. AutomaticStrikeout 18:39, 1 October 2012 (UTC)
  • Support. Sensible suggestion. Axl ¤ [Talk] 20:12, 1 October 2012 (UTC)
  • Support, although to my mind a greater problem than stopping new editors signing articles is the problem of getting them to sign talk page posts... Peridon (talk) 20:59, 1 October 2012 (UTC)
  • Support but I'd prefer to do the right thing—change the software so it automatically signs where needed. If it monumentally silly that we ask new users, faced with a mountian of non-obvious rules, to add one more that could be handled by the software. --SPhilbrick(Talk) 22:53, 1 October 2012 (UTC)
    • I don't think it would be that easy to automate signing. I mean, we could program so that everything one posts on a talkpage has four tildes added at the end ... but suppose I post something, and it's signed, and then I go back and fix a typo in it. Do I then wind up with a second signature in the middle of a sentence? (And then there are pages, such as RfAs, where most comments need to be signed but there are some mechanical things that don't, and so forth....) Newyorkbrad (talk) 02:02, 2 October 2012 (UTC)
      • I grant that it isn't trivial, but I've posted in a lot of forums, and I can't think of another one where I have to sign. Surely if everyone else has figured it out, we can too. To respond to the specific question about typos, in one other discussion site, every post is signed, but if I see I made a typo, I click on edit, as opposed to post, and it doesn't add a new sig. The problem here is that everything is an edit, we don't distinguish between new posts and edits, but one possibility is either that minor edits (which should apply if it is a typo) would not be signed, alternatively, there could be a box to check which indicates not to add a sig. As for RFAs it should be easy enough to identify pages which are not normally signed.--SPhilbrick(Talk) 17:07, 8 October 2012 (UTC)
        • Those forums store every post separately; that allows for the post to be linked to the author. MediaWiki does not have that. For all it knows, this discussion is simply a long unnumbered list. Building in something like you proposed is quite a lot of work, that will result in a likely buggy implementation with its own quirks that annoys a lot of people who are, for better or worse, used to the old system, all for relatively little benefit. T. Canens (talk) 16:03, 12 October 2012 (UTC)
  • Support as straightforward. Would .ns-0 .wikiEditor-ui a[rel="signature"] {display: none;} or similar suffice for the WikiEditor UI? That should probably work, but someone should check it over. {{Nihiltres|talk|edits|⚡}} 00:42, 3 October 2012 (UTC)
  • Support - definitely no reason for the sig button when editing articles, and it just leads to mistakes among newcomers. Eliminating it would help improve Wikipedia. --Jethro B 01:07, 3 October 2012 (UTC)
  • Support - A button should only esist if it can be used appropriately in some conceivable circumstance. I see no such circumstance for this button. — Preceding unsigned comment added by Tazerdadog (talk • contribs) 03:53 3 October 2012 (UTC)
  • Comment This can easily be done by looking at the ca-addsection element presence. Alternatively though, I have also been thinking if it would not be a good idea to move the sign button to the bottom right of the edit screen when you are at talk pages. At least out of the toolbar. I feel it's not fully in it's right location and the reason for that is probably mostly 'historical'. This point/issue might be something for the team of Oliver Keys. —TheDJ (talk • contribs) 07:42, 4 October 2012 (UTC)
  • Support — Makes sense to me. When will we ever have a need to sign our names in article space? Just imagine reading this in an article as someone who's never even set foot in Wikipedia's backroom discussions (i.e. this place):


No, doesn't make any sense. No scenario where it'd be useful. Yes, this is a discussion about an arbitrary technical update, but like I said, it makes sense to not have that button there. Kurtis (talk) 06:37, 7 October 2012 (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.

Should administrators have block rights removed?

DECLINED BY COMMUNITY
WP:SNOW. Absolutely no consensus for support.

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.

Admin can deal with issues without handing out blocks. Most of the time they don't answer to requests for blocks on AN/I which it is listed as "Blocking for reasons other than vandalism" well, they just don't block for almost any reason other than vandalism and somethimes when they just get pissed off at a user. Recently an admin showed me something that Andy the Grump had said and didn't recieve a block for and told me point blank he was sick of dealing with Andy. The event was too stale for any intervention, but a recent AN/I filing was just closed as admin is not the civility police. If they don't block for disruptive behavior then why do they even have the ability to block anyone. Vandalism is just incivil editing. We can lock the article. Why does admin have this right that others don't have. It really is a super power and it is NEVER utilised in a consistant manner. Some users are treated as even more special and while I hear a lot of barking I see no bite. Either we are all allowed to be Andy the Grump or we stick to the rules of professionalism and civility. This is getting stupid. ---Amadscientist 03:53, 18 October 2012

Support - Average admin do not need this tool. It is simply being used in an inconsistant manner and in many cases is not warrented. When it is, then it should be done by a handful of either those elected to hold this power or given out by Jimbo or ArbCom.--Amadscientist (talk) 10:45, 18 October 2012 (UTC)

Oppose. Did April 1st come early (or late)? Evanh2008 (talk|contribs) 11:07, 18 October 2012 (UTC)

Oppose. Block is the principal tool of sysops and should remain so. There are very good reasons why admins should have a right any other editor does not. A few controversial cases does not outweigh the utility for blocking disruptive editors, vandals, sockpuppets, etc. —  HELLKNOWZ  ▎TALK 11:12, 18 October 2012 (UTC)

Strongly Oppose - While some rogue administrators can and sometimes do abuse their authority in this manner, and far too often other administrators and bureaucrats turn a blind eye to abuse with this tool and let the abuse happen when it should be reverted or challenged, that isn't sufficient justification for why this authority needs to be removed from administrators. There are strict guidelines in place for when it is appropriate to use this tool, and it should be noted that admins do get their rights stripped when abuse happens. Still, most cases where it has been applied and I've reviewed logs on Wikipedia and other similar projects, the blocks are amply justified and fitting within the guidelines as well as common sense reaction to serious problems... problems which are the very reason why administrators are created for projects like this. Often locking an article is not sufficient to stop blatant vandalism, and instead you need to stop it at the root blocking not just the user but even the IP address.

I completely disagree that this tool is "NEVER utilised in a consistant manner". On the contrary, it is usually used in a manner to control genuine trolls that would disrupt and even destroy Wikipedia as a project. It can also be used as a legitimate tool to "cool down" discussions and encourage editors to take a slight breather, particularly in a fierce edit war or some other highly controversial topic. This is true even for otherwise fantastic contributors to Wikipedia that otherwise simply need to be reminded to be civil and to remember that writing a Wikipedia article isn't that big of a deal. --Robert Horning (talk) 11:43, 18 October 2012 (UTC)

Oppose Blocks for clear-cut reasons is a major role of admins. But we should recognize this for being the limited situation that it is. An admin can be just a kid who passed the popularity ( = have kept their head low) contest at RFA with the tool belt. No longer should it be considered a substitute for / prevent the creation of a higher credibility / greater depth review processes for situations that don't yet merit arbcom. North8000 (talk) 11:49, 18 October 2012 (UTC)

  • Oppose. You deal with abuse of the block tool by dealing with the admin abusing it. This is a solution in search of a problem. UltraExactZZ Said ~ Did 12:34, 18 October 2012 (UTC)
  • Oppose If your only exposure to what admins do is through ANI then you have a fantastically skewed view of it. Just as the vast majority of users have never even visited that page, and happily edit articles in bliss without partaking of the dramafest of ANI, the vast majority of blocks come about via WP:AIV, where nearly all of the reports are of garden variety vandalism (adding "Mike is teh gay LOL" to articles and stuff like that), and where blocks come pretty regularly. According to my admin stats, I've blocked in excess of 2000 users since becoming an admin. I would imagine that less than 100 blocks have come about because of a response to an ANI issue. And those 2000 blocks allowed good faith editors to continue to edit the vandalized articles, something that page protection would not have done. --Jayron32 12:53, 18 October 2012 (UTC)
Assuming bad faith on the part of the proposer is not the best route to take or assuming my only exposure is through AN/I. The very point is, that admin do not need the tool most of the time. And, like other editors, there are a handful of those that use it when needed and others that almost always defer its use to others. If vandalsim is the main issue then why do all admin need it?--Amadscientist (talk) 22:00, 18 October 2012 (UTC)
Could you point to the phrase I used which demonstrates that I assumed you had bad faith? I'm quite positive you nothing but good faith in your proposal. I disagree with it, but the fact that I disagree with you does not mean I think you are acting in bad faith. --Jayron32 02:39, 19 October 2012 (UTC)
That was really, very inappropriate.--Amadscientist (talk) 02:42, 19 October 2012 (UTC)
Inappropriate? Maybe. Inaccurate? Without the power to block, they are supposed to... YELL? --  :- ) Don 03:21, 19 October 2012 (UTC)
  • I don't think that this would work in the long run; we need admins to be able to efficiently protect areas of the encyclopedia endangered by editors who need to be blocked. dci | TALK 03:06, 19 October 2012 (UTC)
  • Oppose. Vandals vandalise, sometimes in sprees. The inability for any available admin to block quickly would multiply the damage done, and inspire more vandalism. bd2412 T 03:25, 19 October 2012 (UTC)
  • Oppose - blocking is not for vandals and spammers only. It's also for edit warriors and other forms of disruption such as POINT violations.--Jasper Deng (talk) 03:30, 19 October 2012 (UTC)
  • Strongest possible oppose. (edit conflict) Blocking is one of the primary responsibilities associated with the mop. It ensures stability site wide by offering the strongest protection available against individual vandals, edit warriors and tendentious editors. In addition, this proposal fails to properly introduce anything to replace it. At worst, it seems like the proposer is suggesting that only ArbCom or Jimbo should be able to block. This is an exceptionally bad idea that would kill this site. We would be completely overridden in less than a day by persistent vandals and edit warriors who can now work freely because there is a sorely inadequate number of people to respond to them. The biggest problem facing the site right now is that not enough people are given that bit, not too many. The recent, regular backlogs at WP:AIV and WP:UAA are testament to this. Is every block perfect? Of course not. Admins, like everyone else here, are human, and have made bad calls. But removing the right for the whole group based on the actions of a few of those in it is shortsighted and harmful. And in this case, it would only hurt Wikipedia. elektrikSHOOS (talk) 03:55, 19 October 2012 (UTC)
  • Oppose - The rationale for removal of block permissions is basically an all-or-nothing argument based on a single data point. Furthermore, there are lots and lots of other reasons why admins should retain block permissions, like how many editors are not here to build an encyclopedia and editors who suffer from IDIDNTHEARTHAT-itis who cannot usually be dealt with by conventional, conversational means. I, Jethrobot drop me a line (note: not a bot!) 03:57, 19 October 2012 (UTC)
  • Oppose. I'm sympathetic to the idea, and I agree with the nominator that blocking is done inconsistently, and too often whimsically and arbitrarily. But the solution is to have the ability to remove the block button from those administrators who are behaving whimsically and arbitrarily, without any undue fuss, rather than remove it from the default admin utility belt. Malleus Fatuorum 04:03, 19 October 2012 (UTC)
  • Oppose But I like Malleus' idea, I was actually going to mention it myself. Ryan Vesey 04:06, 19 October 2012 (UTC)

Let's talk civility for a minute, Amadscientist. I see in your proposal above that you repeatedly mention User:AndyTheGrump in a negative light, and yet when I look at his talk page history, I do not see any notification from you to him that you are doing so. Do you not think it would be courteous to let the person you are using as a negative example on a public noticeboard know that they're being discussed in such a way? 28bytes (talk) 04:17, 19 October 2012 (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.

Refining proposal

DECLINED BY COMMUNITY
This proposal lacks both consensus and a definable change from the current RFA process (therefore will lead to an unproductive and off-track discussion). - Furthermore it appears to discuss a surface problem instead of a root cause. As the problem identified appears to be with desysoping and abuse of administrator privileges. Therefore if the requester wishes to press forward with this issue in a manner that is not perceived as !vote manipulating, they are advised to open an WP:RFC on the issue of desysoping/misuse of admin tools.

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.

This is not to completley remove blocking. It is a proposal to limit block rights or to require some trigger that gives these rights only to a selected group, proven to understand how to use it properly. Just today there was a block then an immediate unblock partly because the blocking admin made a mistake. This is meant to limit the use of such tools as a punishment and to encourage its use for the right reasons.--Amadscientist (talk) 03:58, 19 October 2012 (UTC)

You'll never eliminate the use of blocking as a punishment; when used against established editors that's pretty much what it always is. The simple solution is to amend the software so that individual "rights" can be removed from administrators, just as they can from regular editors, but of course that will never happen. Malleus Fatuorum 04:06, 19 October 2012 (UTC)
The safeguards already exist for the abuse of the block. An administrator who abuses the power is better known as a user. --  :- ) Don 04:13, 19 October 2012 (UTC)
Agreed, but in practice that never happens. ~ GabeMc (talk|contribs) 04:15, 19 October 2012 (UTC)
And how easy is it, in your opinion, to "downgrade" and administrator to a "user"? On a scale of 1 to 10? Malleus Fatuorum 04:17, 19 October 2012 (UTC)
(edit conflict) Um, "gives these rights only to a selected group, proven to understand how to use it properly.", Isn't that the entire purpose of WP:RFA? Sure, it's an imperfect system, but the idea behind restricting adminship to only a select group of editors through RFA is to "give rights to only a selected group, proven to understand how to use it properly." Malleus's point that some administrators are known to slip through that system and probably shouldn't have access to the tools anymore is a valid one, but ultimately that's a failure of Wikipedia to establish a reasonable means to desysop admins, on those few occasions when it seems like the initial RFA was in error. But in theory (if not always in practice 100% of the time), you're not proposing anything we don't already do! So yes, you are correct that not everyone is responsible enough to use the block tool. Those people shouldn't be admins at all, and we have a system to prevent such people from getting the block tool. It's called WP:RFA. Does it work 100% of the time? No. Could it work better? Yes. So I'm not really sure what you are proposing here that we don't already do.--Jayron32 04:14, 19 October 2012 (UTC)
I should have thought that was obvious; removing individual tools from administrators in exactly the same they're removed from regular editors. Malleus Fatuorum 04:22, 19 October 2012 (UTC)
Yeah, but at any point where you'd want to remove the blocking tool from an Admin, you'd want to remove the entire tool set. I can't imagine an Admin who was so outrageous in their use of the blocking tool would somehow have enough support among the community to retain the other tools. It's just incongruous. I don't oppose having a well-working procedure to remove the tool set from a bad admin in any way. But it doesn't make sense to just pick off a tool at a time. If an admin is that bad, just get rid of the admin bit altogether. --Jayron32 04:36, 19 October 2012 (UTC)
I disagree. Perhaps the community may initially trust the user with all the tools, but soon finds out that he/she isn't compatible with one of the tools but is great with another. I detest the "trusted with one, trusted with all" argument, highly: by that argument, why don't we only have one advanced permissions group? Why do we have several (bureaucrat, admin, checkuser, oversighter (especially the former 2))?--Jasper Deng (talk) 04:39, 19 October 2012 (UTC)
(edit conflict) Well, let's make it concrete. Let's say that an admin, in a fit of spite, blocks a user they are in a content dispute with. How does removing the blocking tool prevent them from protecting the article against non admins? How does it prevent them from deleting the article out of spite just because they don't like where the article is going? I agree that not all tools have an equal level of trust, which is why we have checkuser and oversighter permissions restricted to a very limited number of users, but I do think that the three admin tools require approximately the same level of trust; they all relate to restricting the ability of other users to edit Wikipedia by deleting their work or stopping them from editing. If I don't trust an admin to know when it is or isn't appropriate to stop another user from editing Wikipedia with one of their tools, why would I trust them to know when it is or isn't appropriate with other tools? The admin toolset isn't just a random set of advanced tools, its a specific set tied to the ability to restrict the editing of others. Checkuser and oversight are tools which are trusted to a smaller set because those tools are used to deal with issues of privacy, which is of its nature a more sensitive issue than merely blocking or protecting or deleting. So, I fully understand why we have different levels of user rights: it's just that the block-protect-delete set is essentially "on the same level". --Jayron32 04:50, 19 October 2012 (UTC)
The community has no choice but to trust the candidate with all the tools initially, but no ability to remove those tools the candidate subsequently proves to be unable to wield correctly. What's better? Simply removing that tool or going through a long hard process of trying to get that admin desysoped? Malleus Fatuorum 04:46, 19 October 2012 (UTC)
I'd go even further in fact; why have ranks such as "administrator", "bureaucrat" and so on at all? Why not simply assign the relevant rights without such ranking? Malleus Fatuorum 04:51, 19 October 2012 (UTC)
(edit conflict) Why would removing one of the tools be any less "long and hard" than removing the whole set? --Jayron32 04:52, 19 October 2012 (UTC)
Consider the difference between the removal of rollback and a block. Anyway, this discussion will go nowhere, just as every other proposal for reform has gone nowhere, so who cares. Malleus Fatuorum 04:55, 19 October 2012 (UTC)
Well, insofar as I think that Wikipedia needs a good, solid desysop procedure which has teeth, but is also fair, I care. But I get your point that this specific proposal has no traction. Still, it is something sorely lacking at Wikipedia. I don't have the solution, but I recognize the need for someone to come up with one. --Jayron32 04:59, 19 October 2012 (UTC)
My point actually was that no proposal for reform will ever gain traction. And consider the example of rollback. It's easily taken away from regular editors who misuse it, but are you seriously suggesting it would be better for an admin who misused it to be desysoped rather than have that right removed? Malleus Fatuorum 05:03, 19 October 2012 (UTC)
Rollback is the stupidest thing at Wikipedia, and the games we play with it are just silly. It's just a one-click undo function. If you take it away, it takes two-clicks to accomplish the same thing. I've never understood why it isn't just something that every autoconfirmed user has access to all the time, if someone is edit warring with rollback, they'd be edit warring without it, so all the fuss we make over an inconsequential tool is just silly. So I don't think your example is a good analogy, if only because I think that rollback is just silly to begin with. So, no, I don't even think we should be taking away rollback, because it either should be available to everyone (and misusers should be sanctioned as anyone who edits disruptively is) or no one. An admin who repeatedly and eggregiously misused the block function shouldn't be an admin. --Jayron32 05:15, 19 October 2012 (UTC)
Yes, This has always made me a little curious about the entire rollback function and why I never even considered requesting it. I can still revert the random vandal and have a number of pages watchlisted for this very reason. A couple of clicks and I'm done.--Amadscientist (talk) 05:25, 19 October 2012 (UTC)
As a global rollbacker, I disagree. When you have to do many reverts in a short amount of time, a few clicks does make a difference.--Jasper Deng (talk) 05:30, 19 October 2012 (UTC)
So why not give it to everybody? It's not particularly more harmful for users to edit war using the undo link, or to do so by clicking an older, preferred diff and saving that over their opponents version. If someone has reached the point where they're edit warring, the specific number of clicks used to edit war aren't really the key issue. --Jayron32 13:07, 19 October 2012 (UTC)
The only issue is that when you revert using undo, it usually needs an edit summary.--Jasper Deng (talk) 22:44, 19 October 2012 (UTC)
I would agree with you about rollback, except for the fact that it's now also become a criterion for being allowed to monitor article feedback, on the basis that rollbackers can be trusted, whereas non-rollbackers can't. Ring any bells?. There's a disturbing trend. Malleus Fatuorum 05:22, 19 October 2012 (UTC)
Rollback is handed out automatically on Wikibooks along with pending changes related rights as part of a package when certain criteria are met (which broadly equate to editing relatively frequently for about a month). The theory is that obvious vandals have by this point been blocked and every other editor can be reasonably trusted to use something that is of little consequence. The pending changes rights are more significant than the rollback of course. QuiteUnusual TalkQu 18:51, 21 October 2012 (UTC)
  • Support. - Why can't the specific right to block be revoked from specific admins (read abusive or hostile admins)? Specific editors are routinely blocked/banned from editing specific articles, specific topics, and even the entire project. Double-standards are never a good thing. ~ GabeMc (talk|contribs) 04:15, 19 October 2012 (UTC)
    But double standards are the bedrock of Wikipedia governance. Malleus Fatuorum 04:19, 19 October 2012 (UTC)
  • Support - what you see at an RfA does not necessarily show whether that person will make punitive or preventative blocks (it isn't brought up that often, after all). As for the technical implementation of it, it's easy unless you are asking for temporary removals of the permission (current software can't do it for set periods of time).--Jasper Deng (talk) 04:20, 19 October 2012 (UTC)
    It's always seemed bizarre to me that very often candidates are criticised for not having enough experience in "admin-like" areas such as AfD, but the brutal truth is that nobody can have experience of blocking until they get that button; twittering at AN/I is just that, twittering. Malleus Fatuorum 04:27, 19 October 2012 (UTC)
  • Comment - Well this proposal is much better. We are not going to remove blocking, only limit it. How are you going to do that? Consensus? Then who is going to click the "Limit Block" button? --  :- ) Don 04:48, 19 October 2012 (UTC)
    • I think bureaucrats would be a good candidate for that, as they are generally trusted to evaluate the quality of a particular admin. I'm not sure how "limit blocking" will work, and it's not technically possible.--Jasper Deng (talk) 04:51, 19 October 2012 (UTC)
Exactly, and if you check their archives, you will find that is where administrators become users. We don't need a proposal or a refined proposal. The solution exists. --  :- ) Don 04:57, 19 October 2012 (UTC)
That is exactly what this is Malleus. You hit the nail directly on the head! First, I say we begin with separating block rights from the bundle of administrative tools when RFA is approved. Block right would not be in the tools given to new admin, but they could earn it with some trigger, such as demontsrating to a senior admin that they have a need for the tool. Not every admin needs blocking rights. Desyopsing is a different issue. That is when you feel the admin should no longer be allowed to use any admin tools. Requesting adminship is also a mess but again this is a different proposal in that we are not limiting or changing the RFA process here (though something needs to be done to clean up that process, but that is another discussion) What I am proposing is to simply not give out block rights immediatly with an approved adminship. Some may never even request or desire it. It is also not a proposal to take away the block rights already given, although some process to do this might be appropriate and should probably be discussed.--Amadscientist (talk) 05:20, 19 October 2012 (UTC)
As I said, I'm sympathetic to your position, but you'll find yourself faced with a wall of administrators and admin wannabes who'll do whatever it takes to down your proposal. I wish you luck nevertheless, because you're obviously on the right lines. Malleus Fatuorum 05:29, 19 October 2012 (UTC)
Some things just need to be proposed and discussed even in the face of certain opposition. This is one of those things. Admin are not the enemy. We are all here to improve the project, but we see things declining everyday and no real effort to imporve them. The importance to improve the project is the goal even if it may not be agreed upon by all. Admin, of all editors should be supportive of something that takes a little pressure off them and places it on the community as a whole and helps improve the project.--Amadscientist (talk) 06:10, 19 October 2012 (UTC)
But they aren't. You have to accept that and live with it. Malleus Fatuorum 06:16, 19 October 2012 (UTC)
  • Comment. - Reminds me of Nietzsche's aphorism (or was it Goethe?): "Distrust all those in whom the desire to punish is strong." Perhaps the amount of resistance with which Amadscientist's brilliant proposal will be met with will correspond directly to the degree to which admins view their blocking powers as an essential tool to their daily tasks. ~ GabeMc (talk|contribs) 06:42, 19 October 2012 (UTC)
  • Oppose. Removing admin rights bit-by-bit misses the point of the group. If an admin is consistently making bad blocks, they are probably performing poorly as a sysop in general. Therefore, the solution is instead to make it easier to demote them from the position altogether. elektrikSHOOS (talk) 14:58, 19 October 2012 (UTC)
  • Oppose - Is this lunacy still here? My official input on this refined proposal.
  1. What real power does an administrator wield other than the power to block. If their prose could convince anyone to do anything, then they would be a politician, then I would never trust them.
  2. I can't believe that anyone who has been approved as an administrator would go around blocking people with "NO" provokation.
  3. A method already exists to desysoping.
  4. The lady doth protest too much, methinks.
--  :- ) Don 15:31, 19 October 2012 (UTC)
Out, damn spot!--Amadscientist (talk) 22:52, 19 October 2012 (UTC)
Don: Admins have a lot of power to influence editing by others besides blocking. They can change page protection, add and revoke low-level user rights, delete and undelete pages, and do many other things which can be mis-used for political/ego purposes in violation of administrator's guidelines. The ability to protect a page is probably the biggest "politically abuse-able" tool besides blocking. It is to their credit that the vast majority of administrators do not abuse their tools. davidwr/(talk)/(contribs)/(e-mail) 16:29, 24 October 2012 (UTC)
  • Oppose If the admin can't be trusted when it comes to blocking a user, he probably can't be trusted when it comes to protecting the pages the user was working on, or deleting those pages, or .... you get the point. If the admin's abusing the tools, take them away, don't just take some of them away. --Philosopher Let us reason together. 21:14, 21 October 2012 (UTC)
  • Support un-bundling tools in general, at least in terms of splitting editor-related admin tools from content-related tools. I realize that un-bundling in general has very little support on the en-Wiki, but this proposal is somewhat better than the current status quo. davidwr/(talk)/(contribs)/(e-mail) 16:32, 24 October 2012 (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.
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_94&oldid=1091624717"