Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes should be filed at Bugzilla (configuration changes should have gained a consensus).
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 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

Restrict A class usage

Background As far as I can tell, only two WikiProjects make wide use of the "A" assessment; WikiProjects Military History and Hurricanes. These are two of the largest and best organized projects we have, and they have both the local expertise and the participation levels to sustain an in-project assessment system. WikiProject Film has an A class assessment, and a few A class articles, but they appear to be from 2009 and earlier. Outside of those projects, there is a smattering of other articles marked as A, and it is not always clear what criteria are being used and whether or not there was a formal review. Niemti has, on three occasions, started a talk page thread in articles that were already GA class, elicited support from two or three people for assessing the article as A class, and then changed the assessment. I'm not sure, but I think that these are the only three A class video game articles. Although the Video Game WikiProject is one of the few that could possibly sustain A class assessments, there doesn't appear to be a formal process. There is a smattering of Road and Television articles that also are marked as A class, but I can't even figure out how they got that way. There are also a handful of pages assessed as "A" that are a far cry from it, and were rated as A class by the author (apparently not aware that A class requires an assessment by another user.)

Proposals

• Proposal 1: "A" should only be given as the result of a formal assessment by a project that is conducting such assessments (i.e. not by talk page thread and not unilaterally). It is up to the projects themselves to determine what the specific requirements are, and how to run the assessments. Only projects that are large enough and organized enough to properly do assessments should do so; new projects have to prove that they are sustainable before they can do A class assessments.
• Proposal 2: Only the projects that have formal assessment schemes should have A class enabled as an option in their talk page templates, For projects that don't have the assessment, if "A" is stuck in the class= slot, it will appear as B class. This prevents people from unilaterally adding a rating that suggests an assessment was done because they didn't understand how the ratings work. Here is a good example of where someone has given A ranking to an article that has never been formally assessed and is generously C quality (diff shows me undoing it).
• Proposal 3: A class assessments should, in cases where a GAN has not been done, count as a GAN. WikiProjects Military History and Hurricanes are fully capable of determining what is and is not GA class. Therefore, if they do an assessment of an article that has never been to GAN, and declare it A class (which ranks higher in terms of quality than GA), it should be considered a GA by projects that do not have A class assessments, as if it went through GAN.
• Proposal 3A: In order to be ranked as A class, an article must have already been promoted to GA class through the standard GAN process.
• Proposal 3B: In order to be ranked as A class, an article must either have already been promoted to GA class, or must be checked against the GA criteria during the A class assessment (i.e. an article can be assessed against the GA and A class criteria at the same time, by the same person or people). A class assessments should always be done in a subpage (either of the article or the wikiproject) and transcluded to the article's talk page. If the article was not already a GA, the A class assessment should contain a formal GAN-style review, in addition to the A class review.

Please let me know your thoughts on these ideas. 3A and 3B are mutually exclusive, but 1, 2, and either of the 3s are not mutually exclusive with each other. They should all be able to stand on their own, if necessary. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 21:03, 13 February 2014 (UTC)

Comments

• Support all three Support 1, 2, either 3A or 3B as nominator. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 21:03, 13 February 2014 (UTC)
• Have you actually read Wikipedia:Version 1.0 Editorial Team/Assessment/A-Class criteria?
  I strongly object to A-class assessment "counting" as GAN. GAN happens against the WP:Good article criteria, not according to whatever someone believes is pretty good. While an A-class article should meet those, there's no guarantee that the WikiProject reviewers will actually check those specific items. WhatamIdoing (talk) 03:53, 14 February 2014 (UTC)

  Yes, WhatamIdoing, I have. It says "Only minor style issues and other details need to be addressed before submission as a featured article candidate.", which to me at least is a very high standard. I understand your reluctance, and will edit point 3 in a moment. Do you have any comment on the other two points? Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 05:28, 14 February 2014 (UTC)

• Comment: WikiProject Highways inherited its ACR process from two of its subprojects (the U.S. Roads and Canada Roads wikiprojects), and it requires any nominees be listed as a GA before nomination. The process is also used by other subprojects for Australia, Hong Kong and the UK. Imzadi 1979 → 03:58, 14 February 2014 (UTC)
• Support proposals 1, 2, and 3A, with the understanding that under these proposals WP:HWY would still be able to use our A-Class review system. Not sure how you missed it in your original proposal, but our ACR system has been around for longer than I've had an account on this site, and it's a historically successful system; four out of five articles that pass HWY/ACR pass their first FAC. TCN7JM 06:09, 14 February 2014 (UTC)
• To some extent, this is simple - I believe most (but not all) Wikiproject templates are based on, and substitute a standardized template. We could easily add a switch | aclassenabled= where A-class is only available if that is set to "yes". I believe some are non-standard, however.

  One issue: What if an article is rated A-class by, say, WP:MILHIST, but is also in, say, a politics Wikiproject? Should it be allowed to be A-class in that case? Adam Cuerden ^(talk) 06:01, 14 February 2014 (UTC)

  My stance is that no, it should be listed as a GA for classes that don't do A class assessments. Unlike other ratings, which are communal, only a small number of projects both care enough to do A class assessments and are equip to do so. Allowing A class in other project's templates has and will continue to cause confusion and mislabelings. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 06:28, 14 February 2014 (UTC)

  Why? What benefit is there to this? WhatamIdoing (talk) 18:33, 14 February 2014 (UTC)

  WhatamIdoing, Izno: The idea behind proposal 1 is to prevent people, predominantly inexperienced users, from unilaterally marking an article as A class, which gives the impression that the article went through an audited, peer review process. Ultimately that is what GAN, A class reviews, and FAC are. They are our peer review systems, and for them to matter, we have to make sure that things tagged at those levels meet a high standard. The idea behind proposal 2 is to remove the responsibility for enforcement from WikiProjects that are not organized enough to do so. Larger projects are able to keep track of their recognized content better than smaller projects ever will be. While we have bots that keep track of FA and GA class additions, there is no bot in place that checks to make sure that an article with an A class assessment actually went through that assessment. By making A class only an option in projects that actually do A class reviews, we remove the need for smaller projects to check their content for mistaggings. The idea behind 3A and 3B is to set a common minimum standard from which A class can build off of. Having a rating that is in between GA and FA is useless if the pages that have that rating don't meet the standards of the level below it. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 01:45, 15 February 2014 (UTC)

  Because if MILHIST says it's B-class, it's safe for me to copy that to another project, but if MILHIST says it's A-class, then MILHIST probably screwed up somehow and I shouldn't agree with them? The problem with mis-assessments is when someone invents a rating that nobody agrees with, not when someone copies over a rating that another group of editors has determined is well-deserved. (Also, people don't mess with the class rating nearly as often as they declare a subject to be Top-priority for all WikiProjects.) WhatamIdoing (talk) 02:01, 15 February 2014 (UTC)

  If your only case in support of proposal 1 is that inexperienced users are a problem, this seems like a rather draconian method to deal with what again is a social issue.

  "things tagged at those levels meet a high standard" – That's true, but irrelevant. It doesn't make the case for changing how it works.

  "remove the responsibility for enforcement from WikiProjects that are not organized enough to do so" – Irrelevant. If they don't want to use ratings, that's their prerogative, not yours or the community at large's, and forcing the WikiProjects to do anything has never been an enjoyable endeavor (not to bring up WP:BIRDS and WP:Article names, but... birds). Also, agree with WhatamIdoing on this point.

  As for 3A and 3B, that's sophistry. A is not GA and has no relation to it beyond that some projects place A articles as higher than GAs and some lower; the more meaningful relation is that A-class articles are above B-class articles.

  @Sven Manguard: Please readd the status quo as an option. You have created a false quad-chotomy by forgetting to include "no change" as an option. Thanks. Additionally, you do not own the discussion and it's "rude" to assume that you do. --Izno (talk) 03:37, 15 February 2014 (UTC)

  Izno - I disagree. I made it rather clear that people were free to support or oppose any and all of the proposals. You personally are free to support or oppose anything you wish, but you should do so in a comment that is followed by your signature. You are not free, per community norms, to edit someone else's prose, which is what you did when you inserted your Proposal 0 in between the prose that I wrote and my signature. When I said "That's not an actual proposal, and while it's an option, it's still rude to do it like that", the "like that" was in regards to you putting your text into my paragraph. This isn't an article, where who authors what is irrelevant; this is a discussion thread, where - at least until Flow is launched - it is difficult enough keeping track of who said what, when, even without people sticking their comments in the middle of other people's comments. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 04:50, 15 February 2014 (UTC)

  I see nothing in any of the text that you wrote as claiming that any and all may be rejected. You never made such a positive claim about your proposals, so I do not know how you can say that you "made it rather clear".

  "You are not free, per community norms..." It is normal, per community norms, not to sign your proposals (that's a rather large indicator that the initial discussion may be biased, wouldn't you agree?), and the fact that you're wiggling around that by claiming that I edited your comments is simply obnoxious. If you would like to move or amend my added text, you are free to do so, but I ask again – @Sven Manguard: Please add an option which makes it clear that there is a no change option. Thanks. --Izno (talk) 14:51, 15 February 2014 (UTC)

  Izno, sometimes we do have signed proposals, especially when (as in this case) the proposal comes from a single person. You could re-add your "Proposal 0" after his signature, if you thought it important, or you could !vote Oppose all. WhatamIdoing (talk) 17:01, 15 February 2014 (UTC)

  Sometimes we do. I do think it is important to present all options to the discussion participants. Does he? That aside, I have also !voted in that regard, below. (On a side note, I was the "someone" who left a note at the council page.) --Izno (talk) 02:43, 16 February 2014 (UTC)

• Reject options 3A and 3B per WhatamIdoing. Reject 1 as it does seem to take autonomy away from WikiProjects, which should always have autonomy to act as necessary (within the bounds of WP:LOCALCONSENSUS). Reject 2 as that seems to be a technical solution where a social solution makes more sense (education!). In fact, point 2 seems almost directed at fixing non-obvious vandalism, of which I'm not sure the occurrence is high enough to remove a WikiProject's autonomy. It would also defeat the various bots that (used to?) run to synch the settings. In other words, prefer option 0, status quo. In fact, the above proposals seem not to have any pros. It's not broken, so why fix it? --Izno (talk) 14:17, 14 February 2014 (UTC)

  I'm not quite sure how "per WhatamIdoing" is a rationale to oppose proposals 3A and 3B; he only said proposal 3 was bad. Please explain. TCN7JM 14:56, 14 February 2014 (UTC)

  Never mind. I think my arguments elsewhere in this section are sufficient on why 3a/b are poor. --Izno (talk) 03:37, 15 February 2014 (UTC)

• Support 1, 2 and 3A, as this is the standard we use over at WP:HWY/ACR, which has a 90% success rate in promoting A-Class articles at their first FAC since 2010. - Floydian ^τ _¢ 22:34, 14 February 2014 (UTC)

  "1" and "3A" are mutually exclusive options. "1" says that each project gets to set its own standards, and "3A" tells them what their "own" standards must include. WhatamIdoing (talk) 23:07, 14 February 2014 (UTC)

  3A just says the article has to be a GA. Going by WikiWork measurements, which is what a lot of projects use these days to gauge where their project or task forces of their project are at as a whole, A is higher than GA anyway. Although, I see where your concern is, and I'd advise @Sven Manguard: to change Proposal 1 to read that an article must be a Good Article before it can be assessed as A-Class...unless, of course, he was trying to do exactly the opposite. TCN7JM 23:46, 14 February 2014 (UTC)

  WhatamIdoing: They are not mutually exclusive options. Keep in mind that "A" class is considered above GA class. They're not equal, parallel ratings. The point of proposal 1 is to prevent people from just deciding that something is A class and tagging it as such, without the article going through an actual assessment. The point of proposals 3A and 3B are to establish a minimum baseline. Think of it this way: each specialty in medicine is free to determine what requirements it takes to be an accredited member of that specialty, but all of them have in common that their members had to go through medical school first. 3A and 3B are designed to make sure that, while each Wikiproject is free to choose which specific points they want to highlight in their A class reviews, in the end A class denotes something above and beyond GA class. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 01:36, 15 February 2014 (UTC)

  A-class is only considered "above" GA and "below" FA by the makers of WikiWork, which almost nobody actually cares about. At least once upon a time, we had A, B, Start, and Stub, and GA and FA were unrelated, separate settings. In fact, A-class used to be considered higher than FA by some people. WhatamIdoing (talk) 02:01, 15 February 2014 (UTC)

  Sounds like nobody is really sure exactly what the agreed upon hierarchy is. I was under the impression that A was below GA, apparently I was mistaken, but it made reading this proposal especially confusing. --NickPenguin_(contribs) 02:07, 15 February 2014 (UTC)

  We aren't in those times anymore. It doesn't really matter what the assessments used to be considered. A-Class is nowadays clearly not higher than the sitewide FAC process, and this proposal is for the future, not the past. Also, regarding WikiWork, speak for yourself. TCN7JM 02:41, 15 February 2014 (UTC)

  GA/FA have always, repeat always, stood separately from the A–start scheme. It's a WikiProject rating, not a wiki-wide rating. Period. Asserting that this is "for the future" is simply sophistry. That tools are configured to treat ratings in a certain fashion is irrelevant to the social aspects of WikiProjects. --Izno (talk) 03:37, 15 February 2014 (UTC)

  Okay, so that first part may have been wrong. But first, this proposal is to change the guidelines/policy/etc. for the future – asserting it as such is not "sophistry", and second, GA→A→FA is my own personal opinion, thus my support of these proposals. TCN7JM 04:22, 15 February 2014 (UTC)

  Except it is sophistry, because you're using it as the conclusion of your argument without showing why it is the conclusion. As for your personal opinion, I'm glad that that's clear. --Izno (talk) 14:51, 15 February 2014 (UTC)

• This is a proposal to change Wikipedia:Version 1.0 Editorial Team/Assessment. I've left notes for the Wikipedia talk:Version 1.0 Editorial Team about this discussion. Someone else left a note for WT:COUNCIL, which is a central point for people interested in WikiProjects (although it formally has no role in article assessment as such). WhatamIdoing (talk) 19:04, 15 February 2014 (UTC)
• Oppose all. A class is a project-level ranking, no different than B, C, Start or Stub. Consequently, I reject proposal 1 as the few projects that bother with A class should be permitted to set their own requirements on determining if an article is A class. And by the same token, if an article is in multiple projects and one uses an A class, that should not cascade as a rating for the other projects if they don't use it. I reject proposal 2 for the same reason. I reject both 3A and 3B because I do not hold that A class is superior to GA. At its absolute best, it could be considered parallel, but in truth, it is actually redundant. And that, I think, is why almost no projects bother with it. Resolute 02:06, 16 February 2014 (UTC)
• Support 1, 2, and 3A WPMILHIST has it right. 3A serves as a check on any individual WikiProject that the article has undergone the process from WPGA. No WikiProject should be able to overrule GA on adherence to GA rating. I'm curious about who will evaluate number 2 and how that will be done. I'm part of the semi-moribund WikiProject History (parent of all history-related wikiprojects) and we don't have a separate A-Class process. What's to stop me and three other editors from nominating and evaluating A-class for History? I'd like to see some external consensus for a WikiProject's viability for A-class. Chris Troutman (talk) 21:05, 16 February 2014 (UTC)
• Question What is the benefit to be gained by the additional bureaucracy? What is the harm caused by the WikiProjects with less formal assessment schemes? I see that the proposals may lead to a handful fewer articles in Version 1.0 as it drops their score down a lot, though I don't see that as a major benefit or loss, as there are very few informal A articles --Hroðulf (or Hrothulf) (Talk) 14:02, 17 February 2014 (UTC)

• Oppose per DGG below, additional bureaucracy is harmful --Hroðulf (or Hrothulf) (Talk) 21:07, 21 February 2014 (UTC)

• Oppose all, for the same reasoning as Resolute. In particular, I do not see what problem this is intended to solve. There is no evidence that there is any confusion, or that anyone is being misled, or that the rating is used inappropriately. To establish guidelines to deal with non-existing problems is the very essence of bureaucracy , and a direct contradiction of the basic principle of NOT BURO. If projects are doing nothing harmful to the encyclopedia, and not disrupting other standards, or outraging the general standards of the community, let them use ratings as they see fit. It's not as if our use of ratings is that exact, or free from disputes in specific cases , and this was introducing inconsistency into the system. The milhis project is the most consistent of all projects here, and why anyone should want to interfere with it escapes me. We should encourage other projects to emulate it, and if they want to use ratings like milhis does, all the better. If they want to use them slightly differently in away which is not contradict the general system, I see nothing wrong with that either. When we actually have a problem, then we can deal with it. DGG ( talk ) 16:21, 17 February 2014 (UTC)
• Comment: Do we even need an A-class? GA means that there's the possibility of FA, an extra step in between that's rarely used just seems like it's unneeded. What if we eliminate the A status altogether, grandfathering in the current ones? Supernerd11 :D Firemind ^_^ Pokedex 17:19, 17 February 2014 (UTC)
• Support proposals 1, 2, 3A and 3B, agree with rationale by nominator, above. Cheers, — Cirt (talk) 02:57, 18 February 2014 (UTC)
• Oppose All - I favor the elimination of A-class altogether... STUB-START-C-B for self-assessments; GA and FA through a process, assuming people want to go through the process. Carrite (talk) 03:50, 18 February 2014 (UTC)
• Tentative support for 1, 2 - Although I don't like to see restrictions imposed on how WikiProjects assess, I can see there is a good case for tightening up how A-Class is assigned. It undermines the value of A-Class if someone can unilaterally inflate the assessment of an article that's outside one a the big projects, even if it's done in good faith. I don't think project size is critical - if you have three active people in a WikiProject that may well be enough to get a decent review, as long as the it's done through a formal process. However, it's clear that the "basic method" described here is not widely used. Walkerma (talk) 19:58, 20 February 2014 (UTC)
• Oppose 1, and all of the 3's, Tentative support 2. We shouldn't be telling projects what they can and cannot have for grading scales, and if they want to put the effort into creating or adopting a set of requirements for an A class article, that is entirely up to them. It also shouldn't hinge on the level of participation, as long as there is a set guideline as to what does or does not qualify, the rest is entirely irrelevant. — {{U|Technical 13}} ^{(t • e • c)} 18:12, 21 February 2014 (UTC)
• Oppose; The proposal attempts to mix together two divergent rating/grading systems, each concerned with differing parameters of the article(s) in question, and would therefore be an additional muddying of the waters surrounding the article class system currently used by wiki-projects. To begin with, the use of the "A" class rating by some projects and not others is a moot point. Even if, for instance, a project wants to come up with a class system that carries the "grading" system in the other direction (I'm all for adding "D," "E," "F", etc. classes as necessary), who are we to worry about it or try to control it? As long as the project members understand and accept the specified parameters involved, the class system is simply their tool for finding articles which need specific improvements and it should be left alone. FA and GA have nothing to do with the project classification ratings within the projects themselves. The proposal is really not necessary, and at best another example of bureaucracy creep. GenQuest ^{"Talk to Me"} 21:56, 21 February 2014 (UTC)
• Oppose all. GA and FA are project wide, and hence suitable for larger governance. There is no rational reason why any other classifications should be under the purview of anyone except the given wikiproject. If you want to create a new article class for articles that have passed some sort of site-wide review not covered by GA or FA standards, please feel free. But restricting wikiprojects from using classes is just pointless bureaucracy. VanIsaac_{WS Vex}^contribs 22:24, 21 February 2014 (UTC)
• Strong Oppose All First off, I don't think there's a reason to make a general rule when there isn't an identifiable problem - there are a "handful" of pages that are inappropriately labeled as A? Doesn't sound like a problem that needs an added layer of formal process to solve. Second, it really strikes me as a problem to be making general rules for how WikiProjects can rate the articles in their scope. If I start WikiProject Alternative Methodology tomorrow and start rating articles on a Check, Check Plus, Check Minus system, are you going to require that I have a formal process to rate something Check Plus now? What if I start WikiProject Contrarianism, where ratings are inverted, and only FA-class articles are rated as Stubs? Would my whole scheme be disallowed? In my view, article rating on a project-by-project basis is little more than internal bookkeeping, and it seems like it's no one's business but the Project's how they want to rate articles. 0x0077BE [^talk/_contrib] 08:02, 22 February 2014 (UTC)
• Oppose all - as mentioned, this is a solution in search of a problem; if articles are being improperly assessed, the solution is to correctly assess them, not to suggest that an entire assessment level be tossed out or restricted. I've seen lately some articles that are not stubs having assessments changed from "start" to "stub" based on misunderstandings of what a stub is, but I don't think anyone would seriously suggest restricting or doing away with the Stub assessement because of it. - The Bushranger _{One ping only} 08:25, 22 February 2014 (UTC)
• Support 2; oppose others: 2 is the only option that seems to actually empower the individual projects by giving them the option to opt in or out of having "A" class as they see fit, via a modification of the master talk page template (much like how projects currently can opt in or out of "bottom" class assessments). That said, I do a lot of assessment for two projects and have seen little evidence that this is a problem worth imposing top-down Wiki-wide strictures: assessment of stub-A is for the projects benefit only, and has really no bearing outside of it. The only harm mentioned is some asserted "assessment inflation" (which I haven't seen in the projects I tend), and can be easily remedied by doing occasional checks on those that are rated "A"-class.Morgan Riley (talk) 17:46, 27 February 2014 (UTC)
• Oppose all per DGG. I have always wondered just where A-class stood. I feel like it's just that the popularity of GA/FA wound up causing it to get swept under the rug. I think we should do something with A-level classification... I think it'd be a shame to just throw it away considering we have the logic of A, B, C ranking. I feel like A could either be thought of as subdivided into FA and GA (convenient that these both end in A and follow each other in the alphabet). That or I could see A class being turned into a sort of "super-FA", requiring a project-level FAC-like process that can happen once the article is FA. Of course, I'm sure "eliminate A-class" and "create a super-FA class" are practically perennial proposals with good reasons why they haven't happened. —/Mendaliv/^2¢/_Δ's/ 07:20, 2 March 2014 (UTC)
• Oppose all. Judgment to classify articles as A-class needn't be formal and simply follow common sense, and to formalize A-class assessments would simply be another headache. A-class is a class like any other, I'd argue, like B and C; I don't see the necessity of an additional formal assessment for article quality in addition to GA and FA. Within WPTC, the formal A-class assessment process crashed and burned long ago, and it's mostly done with common sense and off-wiki communication these days. Cloudchased (talk) 03:03, 6 March 2014 (UTC)
• Support proposal 2 as making the most sense to me. Or how about Proposal 4: Deprecate A-class altogether and promote (demote?) existing A-classes to GAs unless they undergo a proper WP:FAC. -- œ^™ 05:42, 6 March 2014 (UTC)
• Support all per nom but just looking at the existing comments I don't see this gaining consensus. davidwr/(talk)/(contribs) 05:08, 10 March 2014 (UTC)
• Comment - a bit late to this party, but wanted to point out an error in the initial statement: the video games project has 42 A-class articles, not 3, and has a process for assessing new ones. --PresN 07:38, 10 March 2014 (UTC)
• Comment If it's not allready A class should be a protected class. A specific set criteria should be made. A uniform means should be made to check it, similar to GA or FA. Groups can use that standard or higher. The set standard should be higher than GA. Either that or A class should be moved lower on the precedence scale than GA and projects can figure it out for themselves.Serialjoepsycho (talk) 00:59, 11 March 2014 (UTC)
• Support anything that improves the assessment method. There is a certain logic to the requirements for each of the three processes, e.g. GA involves one reviewer, A-class needs two reviewers to concur and FA needs mutiple opinions. The criteria for each one have been written with very similar wording so it isn't as though they are speaking different languages. Let's formalise the current A-class method by having a central forum like GAN and FAC, with the review carried out on a sub-page by appropriate WikiProject teams. GA requires that nominators put the nominee in an appropriate category so there is no reason the same couldn't be done with an A-class forum. Since many articles are covered by two or more WikiProjects, it would be good to see more collaboration between reviewers. I'm certain that projects like WP:MILHIST have a lot that could be shared. Green Giant supports NonFreeWiki (talk) 20:51, 11 March 2014 (UTC)

Asking for closers

In some cases where a discussion is likely to be complex and contentious, someone (usually me) has asked ahead of time for closers at WP:AN, so that they can hit the ground running when the discussion closes (usually at the 30-day mark). This looks like one of those cases, and I'll go make the notification. - Dank (push to talk) 17:57, 21 February 2014 (UTC)

We had no takers at WP:AN, so I'll be closing this, along with whoever else shows up. This isn't a criticism, because you guys might have been waiting to see whether this proposal picked up steam before you made your notifications, which is fine. The recent vote is leaning negative, but if the votes turn around, if it looks like we might be making changes to a community process that probably has more than 100,000 man-hours invested in it, then more notifications will need to be made than have been made so far. - Dank (push to talk) 17:56, 25 February 2014 (UTC)

This discussion began on Feb 13, so I'm planning to close on March 15 (and no surprise, I don't see much consensus here). If anyone else wants to help close, or if anyone wants the 30 days extended, please say so. - Dank (push to talk) 12:20, 11 March 2014 (UTC)

Proposal to have a bot delete stale warnings from after certain period of time

As you know, Wikipedia is a non-profit organization. Therefore, it relies on the donations from the public. There are a lot of IP addresses that have been used for vandalism and they get warned. Once certain period of time passes by, the warnings become stale and unfortunately, stale warnings take up a lot of space. It costs money to obtain and manage additional storage space. When I am patrolling Recent Changes, I notice that some IP talk pages have lots of stale warnings, some from as early as 2006. Likewise, there are times where I deleted stale warnings in a single talk page and deleted more than 50,000 bytes of stale warnings.

What I am suggesting is that Wikipedia should have a bot that detects old warnings from, maybe, like at least 1-2 months old, and delete them. If the {{OW}} tag isn't tagged, then this bot should tag it as well. This way, the space saved by deleting stale warnings can be used to generate useful articles.

Human editors may not have a lot of time manually deleting stale warnings from old IP talk pages, even if they do try. Just like how vandalism is very common and ClueBot is here to revert vandalism and warn the users, which would reduce the amount of human editors needed to fight vandalism.

If you have any questions about my thoughts about this bot, please feel free to contact me. NHRHS2010 RIP M.H. (1994-2014) 16:34, 1 March 2014 (UTC)

It may be a good idea to have a bot remove stale warnings but your point about storage space is actually working against your argument. As Wikipedia keeps a copy of every version of every page, making a change to a page would actually take up more space as both versions would be stored. Also, the WMF has never indicated storage space is an issue. --NeilN ^{talk to me} 16:46, 1 March 2014 (UTC)

That's great that Wikipedia never had an issue with storage space as I never heard of such issue. However, either way I still think that IP talk pages should be cleaned from time to time. Maybe human editors who patrol Recent Changes and warn vandals, should be encouraged to remove stale warnings. This practice can also allow vandals to see new warnings more clearly. NHRHS2010 RIP M.H. (1994-2014) 16:55, 1 March 2014 (UTC)

Another note is that back when I first joined Wikipedia in 2007, I remember indef blocked accounts got tagged with {{indefblockeduser}} a lot more commonly than these days. After a certain period of time, administrators would delete these old indef blocked users' pages (such as ST47 deleting a userpage with the summary "Temporary page, too old"). NHRHS2010 RIP M.H. (1994-2014) 16:59, 1 March 2014 (UTC)

How do you define stale? As far as I am concerned every warning is a further clue to the prior performance of an account or IP and should be retained indef. Leaky Caldron 17:02, 1 March 2014 (UTC)

They are retained indef in the talk page history. I don't see the point of displaying warnings from 2010 if the IP hasn't edited during the interval. --NeilN ^{talk to me} 17:09, 1 March 2014 (UTC)

• (edit conflict) NHRHS2010, the best person to answer your concern about storage space is likely Reedy, and I'll leave that at that (he only seems to be checking that account once a week, so his reply may be slow). As for your other suggestion that those talk pages should be cleared from time to time, I agree on a case to case basis. What I mean by that, is there are some IP talk pages with no comments on them for multiple years, and the warnings on them may be harsh and likely no longer apply to whomever may next use that page. I have no problem with such pages being deleted per consensus at a MfD discussion, nor do I have any objection to those talk pages simply being blanked by a bot after a year of inactivity on the talk page if the IP hasn't been defined as any of a set of special cases (School IP, IP of a known sock, otherwise tagged by CU, etc) because this leaves the content available in the page history for anyone who really wants to know. Such blanked pages should also be placed in a maint cat so that people will know that is why it is blank and think to check the history. — {{U|Technical 13}} ^{(t • e • c)} 17:19, 1 March 2014 (UTC)

Note: Wikipedia:Don't worry about performance may be applicable to this proposal as well... — {{U|Technical 13}} ^{(t • e • c)} 17:30, 1 March 2014 (UTC)

No I'm not concerned about storage space. I am just trying to give suggestions that would be supportive to Wikipedia, the free encyclopedia that anyone can edit. Of course, we will continue to expect people to vandalize due to our freedom to edit. Though I have noticed some preventative measures (such as disallowing curse words, the word "poop"...). I have even witnessed my one best friend vandalize (and at least once I have personally reverted his edits without his knowledge). Wikipedia is not my own website, and we are just contributors. Also, like I mentioned before, I would tag {{OW}} on IP talk pages where the stale warnings were removed, regardless of whether it is personal or shared IP. The OW tag actually reads "Older warnings and/or other comments on this page have been removed, but are still viewable in the page history." whereas the word "page history" is linked to the page history of the IP talk page. Alternatively {{old IP warnings top}} have been placed on top of stale warnings while {{old IP warnings bottom}} have been placed under the last old/stale warning in order to hide the stale warnings (where people can click on the Show button to see the hidden warnings). NHRHS2010 RIP M.H. (1994-2014) 18:17, 1 March 2014 (UTC)

There may be some legitimate reasons to remove warnings from talk pages of dynamic IPs, but disc space or other WP:PERFormance issues should not among those reasons. Besides, editing a page to remove stale warnings doesn't decrease the size of the database, but increases it instead when the revision is saved. If you simply want to remove the clutter on a talk page, archiving would be a better option. 24.149.117.220 (talk) 21:40, 1 March 2014 (UTC)

Though rather than traditional archiving, for cleaning up the warnings on a dynamic IP's talk page, it's more appropriate to collapse the warnings with the {{Old IP warnings top/bottom}} templates. Which, as NHRHS2010 sorta suggested, could maybe be done by a bot. Certainly, there could be benefits both to IP users and patrollers to cleaning up very old warnings, particularly for dynamic IP addresses and school IP addresses where the current user of the IP is unlikely to be the person the warnings were for. Novusuna ^talk 22:01, 1 March 2014 (UTC)

I think that it is preferable to delete stale warnings altogether, and replace them with the {{OW}} tag. This reduces unnecessary link load in the "What links here" space. For example, if you look at a randomly picked article like Banana, you will see that there are literally dozens, if not hundreds, of IP addresses from which it is linked. Many of them are nothing more than this eight-year-old warning, basically saying "your edit to Banana was reverted". Putting the warnings in a collapsed template conceals them on the IP page, but retains this clutter on the "what links here" page for any article mentioned, as well as to the various policy pages that are routinely linked in such warnings. bd2412 T 17:38, 6 March 2014 (UTC)

RfC: Largest cities of...

Background

On 27 February 2014, it was requested that {{Largest cities of India}} be added to India of which I declined due to a concerns that the navigational template has a citation.

I started a discussion about my specific concerns on Wikipedia:Templates for discussion/Log/2014 February 27#Template:Largest cities of India where I stated my concern and asked some questions:

This template includes a citation, and as such is required to go above any or {{Reflist}} section. This template is also what is considered a navigational box which is required to sit at the very bottom of articles below any or {{Reflist}} section. As such, this is a contradiction in of itself and any placement of this template will require consensus.

• Is there consensus to allow this NAVBOX to go into the context of the article?
• Should (can) the included citation be removed or otherwise presented so that this NAVBOX does not need to go into the context of the article?
• Should all of the navigational properties of the template be removed so that it is no longer a NAVBOX?
• Should this NAVBOX simply be deleted?

During the discussion on that page, it was brought to my attention that {{Largest cities in Turkey}} has this same problem, and potentially all of the templates in Category:City population templates could have this problem, so I asked the contributors there if this was worth taking to a larger venue for more in depth discussion and figuring out what the appropriate course of action for these templates should be. The response was that TfD is an inadequate venue.

TL;DR version: Are {{Largest cities}} templates actually NAVBOXes, and if they are, should they be required to use raw citations (so that or {{Reflist}} isn't required below them)? — {{U|Technical 13}} ^{(t • e • c)} 15:31, 6 March 2014 (UTC)

• In fact, you have at least 51 Asian, 50 African, 26 North American, 52 European and 14 South American templates with the same "problem" as you see it. The Banner talk 16:10, 6 March 2014 (UTC)
• The answer is in the link you have already provided, WP:CLN: "Finally, external links should not be included in navigation templates. Sources may be included in the template documentation (a <noinclude> section that is visible only after viewing the template itself, but not upon its transclusion)." --Mirokado (talk) 21:08, 6 March 2014 (UTC)
• Templates should never have references called with a reflist tag, as that is just a recipe to screw up page layouts. bd2412 T 02:43, 7 March 2014 (UTC)
• 'Agreed. If there are such templates out there, they need to be modified/fixed pronto. This would be a clear breaking of WMoS by an over-zealous template editor. GenQuest ^{"Talk to Me"} 03:16, 7 March 2014 (UTC)
• Separate the tables from the templates. We seem to have mixed up information tables with navigation boxes. I don't think such templates are particularly useful, especially since most of them are used on one or two articles each. The tables and citations should be hardcoded into the articles and the templates rewoorked to contain only navigational links. Green Giant supports NonFreeWiki (talk) 23:23, 11 March 2014 (UTC)

Wikipedia:WikiProject Articles for creation/RfC for AfC reviewer permission implementation

This proposal has been around quite a bit longer than 30 days. Is this where I should report it for possible closure? —Anne Delong (talk) 19:47, 6 March 2014 (UTC)

I think the right place to request closure is here, but that page has such a monstrous backlog at the moment that this notice on the village pump might work faster. Novusuna ^talk 20:42, 6 March 2014 (UTC)

Should we raise the requirements for autoconfirmed status?

I think that the current requirements for an account to become autoconfirmed (10 edits and/or 4 days) are way too lenient and allow way too much unconstructive editing through. In particular, the concept of "sleeper socks" where you create the account, wait 4 days, and then edit through semi-protection, is too easy under the current system. Therefore, I propose that we raise the threshold to 100 edits and/or 30 days, which, while higher, is still easily attainable for anyone who wants to contribute constructively. Jinkinson talk to me 00:14, 7 March 2014 (UTC)

I know it'd be harder to track, but what about 4 active days? That is, they have to log in on four separate days, rather than just wait. Ian.thomson (talk) 00:20, 7 March 2014 (UTC)

• While I agree that 10-4 is just to low and easy, I think 100/30 is too high... There has to be a balance and good middle ground. Perhaps 20-7? — {{U|Technical 13}} ^{(t • e • c)} 00:35, 7 March 2014 (UTC)

I'm not convinced that the autoconfirmed threshold needs to be raised, but if we do, 100 edits and 30 days is way too high. For reference, 100 edits and 90 days is the standard for accounts with a Tor IPBE. 20 edits and 7 days would be more reasonable, if it must be raised, but again I am not convinced that we need to. Novusuna ^talk 01:10, 7 March 2014 (UTC)

Sheesh, this feels like an auction. I guess 100-30 probably is too high, but maybe something like 40 edits would be better. Also, I don't think just creating an account and waiting, no matter how long you do it for, should get you autoconfirmed. You should have to demonstrate that you are a competent and/or constructive editor by--oh, I don't know--actually editing. Jinkinson talk to me 01:16, 7 March 2014 (UTC)

• As much as I dislike them, that discriminates against SPAs and if someone only wants to work on one article, and that happens to be semi protected, then they should be allowed to do that. I think that if they put in a handful of edit requests on the talk page and maybe ask for the protection level removed or changed to PC1, then it shouldn't be hard for someone like that to get 20 edits fairly reasonably. Then, waiting out a week, seems reasonable. — {{U|Technical 13}} ^{(t • e • c)} 11:52, 7 March 2014 (UTC)

• I don't have a strong opinion (yet, at least), but I at least want to provide some info from another wiki. es.wiki (Spanish) has I believe a 50 edit minimum (don't remember the day count). I only have 35 edits, there so I'm not autoconfirmed, but I ended up wanting to move a page, and had to request it. Like I said, no opinion yet, just a different perspective to think about. Chris857 (talk) 02:14, 7 March 2014 (UTC)
• Expanding a bit on User:Ian.thomson, I think we should make it 4 active days AND ten (unreverted) edits. It shouldn't really be all that hard to become autoconfirmed, otherwise we scare everyone away; but with my proposal, sleeper socks wouldn't be such a big worry, it would prove the constructiveness of the new editor, and still retains all the filters (for lack of a better word) that new accounts have. Supernerd11 :D Firemind ^_^ Pokedex 02:27, 7 March 2014 (UTC)

I don't think that it's possible to distinguish unreverted edits from reverted edits. --Redrose64 (talk) 09:56, 7 March 2014 (UTC)

I actually did some testing in regards to this a month ago or so. Edits which are undone, rollbacked (note that twinkle rollback and undo is just a page edit and not actual rollback or undo, and therefor those don't get hidden), or deleted as part of an article deletion, do not show up in Special:Contribs and therefor I would assume are not counted towards the ten. — {{U|Technical 13}} ^{(t • e • c)} 11:52, 7 March 2014 (UTC)

Technical, I believe you incorrect. If you look at the recent history of my talk page you will see several edits reverted using rollback. Then if you look at the editor's contributions all the reverted edits show up. If the edits are made to a deleted page, they no longer show up in the Special Contributions but they still count towards the 10 edits required for autoconfirming. GB fan 12:20, 7 March 2014 (UTC)

Here is an edit count of the above user. I count 12 edits on their contributions page, the tool says they have 13. The difference is one deleted edit. The editor will be autoconfirmed in less than 12 hours. GB fan 13:01, 7 March 2014 (UTC)

(edit conflict) You state "Edits which are undone, rollbacked ... do not show up in Special:Contribs" - how many edits do you see for 86.164.116.164? I see nine, of which the four edits made by that user today have all been reverted using various means. One was a true WP:ROLLBACK, one was reverted using WP:STIKI, and two were undone using the normal "undo" link. That true WP:ROLLBACK didn't delete the edit but left it in the page history (in fact it added one edit to the history and in so doing increased my own edit count by 1); and since that edit is still in the history, it (and all the others made by the user) all count towards the user's edit count. Once this tool is working again, it should count nine edits. --Redrose64 (talk) 12:34, 7 March 2014 (UTC)

• Special:Contributions/Aei4eia says no edits, User talk:Aei4eia#Speedy deletion nomination of User:Aei4eia is a speedy deletion warning for a page they created and edited, ?title=Special:Log/block&page=User:Aei4eia says they are blocked... So, I conclude that deleted edits do not show up in special contributions. Whether or not they count towards autoconfirmed, I do not know. — {{U|Technical 13}} ^{(t • e • c)} 12:59, 7 March 2014 (UTC)

They have an edit count of 3 edits according to Wikichecker. They are all deleted edits. GB fan 13:16, 7 March 2014 (UTC)

• At present the edit count (10 edits, as noted above) relates to edits in any namespace, and there are a number of autoconfirmed editors who have never edited outside userspace. Perhaps the edit count should only take into account edits in article space? --Redrose64 (talk) 09:56, 7 March 2014 (UTC)

• Not sure I like this either because it discriminates against those who are here to contribute constructively in more technical means/capacities like Templates, modules, or even those who want to focus on clearing out the backlogs of copyright violating images and upload new ones or whatnot. — {{U|Technical 13}} ^{(t • e • c)} 11:52, 7 March 2014 (UTC)

• As far as "real" edge cases go, there "is" still confirmed which someone could get by convincing an administrator that they are worthy and are just having a hard time getting to the 20 edits or something. — {{U|Technical 13}} ^{(t • e • c)} 11:52, 7 March 2014 (UTC)
• It appears from mw:Manual:Autoconfirmed users that it can only depend on account age and total edits (it includes deleted edits) with the current software. wgAutoConfirmCount and wgAutoConfirmAge are set in http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php. The default in Wikimedia sites is 0 edits and 4 days. Some wikis change 0 edits to 10 to 50 (mostly 10). A few wikis change 4 days to 0 or 7. PrimeHunter (talk) 12:40, 7 March 2014 (UTC)

• That may be, but there is also mw:Manual:$wgAutopromote which could probably be used to refine the criteria a hair more (like requiring an email address, if we wanted to do such a thing). Also, if we had some other "specific" criteria we wanted to enforce, it wouldn't be too hard to get a developer to write a patch to allow most things as a restriction or filter. — {{U|Technical 13}} ^{(t • e • c)} 12:59, 7 March 2014 (UTC)

• Correction: WP:Autoconfirmed status requires both four days and ten edits (for most users) here at the English Wikipedia. There is no "just creating an account and waiting" here. For comparison, Spanish requires four days plus 50 edits. French and German appear to require four days and zero edits. In the German case, this might be because everything is under mw:FlaggedRevisions, and so all mainspace edits are double-checked anyway. WhatamIdoing (talk) 17:45, 7 March 2014 (UTC)
• My $0.02: Maybe change autoconfirmed to require 10 non-deleted edits to pages other than the user's own userspace and the sandbox, and have the 4-day timer start with the first of those edits rather than the account's creation time. Jackmcbarn (talk) 19:56, 7 March 2014 (UTC)
• I'd be ok with increasing the edits a bit, but less happy about the days. Maybe just edits to 40 or 50? Johnbod (talk) 20:00, 7 March 2014 (UTC)
• Does anyone have any evidence that "sleeper socks" are a big problem, or that there is some other specific problem with the leniency problem? Most of the discussion I'm seeing is about how easy or hard it is to get autoconfirmed, but if you're going to make some changes, it should always start with the identification of the specific problems, and an estimate of how the changes would solve things.

In this instance, I think adding more edits to the requirements would be counter-productive. Auto-confirm is about impulse control and as far as I can tell it's doing its job to control that very well. Having a low barrier to auto-confirmation makes it so that most people who make an account and do a little editing are auto-confirmed before they even notice that they would want such a thing, and if they abuse that privilege, it's taken away very quickly, and the vast majority of people don't create multiple sleeper accounts to circumvent this minor protection. If you are the sort of person who creates a sleeper sock account, you're not likely to care much if you have to create them a week or a month in advance. If you're the kind of person who will make beneficial edits to semi-protected articles, on the other hand, you're not likely to shoot for a certain number of edits just to be able to help out. To the extent that this isn't a solution looking for a problem, I think it's the wrong solution for the only identified problem. 0x0077BE [^talk/_contrib] 21:35, 7 March 2014 (UTC)

I would also like to note that regarding the proposals about only counting edits in a certain namespace - beyond the above concerns about barriers to entry, you risk inducing people to go on a spree of low-quality edits in the main namespace rather than in some less detrimental place. Probably not a huge problem, but always keep your incentives in mind. 0x0077BE [^talk/_contrib] 21:39, 7 March 2014 (UTC)

Regarding "sleeper socks": most of these users were sleeper socks until discovered. Those whose user names are the word "User" and a number sprang into life a few days ago; User 47 (talk · contribs · deleted contribs · nuke contribs · logs · filter log · block user · block log) is a typical example that I discovered myself. --Redrose64 (talk) 21:54, 7 March 2014 (UTC)

I don't dispute that sleeper socks exist, you'd expect that, but the optimal number of bad thins happening is almost never zero. I'm not really seeing much in the way of evidence that this is such a difficult problem to solve that we can't keep up. If we were seeing a huge flood of vandalism on semi-protected pages by sockpuppets, that would be a different story, but I don't see any evidence that this is the case. 0x0077BE [^talk/_contrib] 21:29, 8 March 2014 (UTC)

Conclusions

• Disagree with proposal. Per discussion above, I just don't think a change is necessary or appropriate to autoconfirmed. GenQuest ^{"Talk to Me"} 00:09, 8 March 2014 (UTC)
• Support  20 edits and 7 days is fine.  Unscintillating (talk) 11:20, 8 March 2014 (UTC)
• Support 20 edits and 7 days. — {{U|Technical 13}} ^{(t • e • c)} 13:24, 8 March 2014 (UTC)
• Oppose No need to change this. The "sleeper socks" will just make 20 minor or userspace edits instead of 10, and if necessary sleep a little longer. So let's not make things harder for legitimate newbies. Anomie⚔ 14:09, 8 March 2014 (UTC)
• Oppose Per my comments above - not an obvious rampant problem, and to the extent that it is a problem, this would hurt more than it helps. 0x0077BE [^talk/_contrib] 16:44, 8 March 2014 (UTC)
• Oppose Still don't see the need to make things harder for new users. People who are so dedicated to disruption that they're willing to make sleeper socks will also be willing to make as many edits and wait as many days as necessary. Novusuna ^talk 20:31, 8 March 2014 (UTC)
• No conclusion. I don't see that a strong case has been made that there is a definite problem with either "sleeper socks" or impairment of newbies, and therefore a conclusion either way would be poorly founded. ~ J. Johnson (JJ) (talk) 22:28, 10 March 2014 (UTC)
• Support a change to 25 edits (unreverted and in non-userspace) and 10 days (from the first non-userspace edit) as a reasonable compromise between 10-4 (far too low) and 100-30 (maybe too high). Having a higher requirement would be inconvenient to newbies but it might make malevolent sleepers just a tad more difficult to create. Green Giant supports NonFreeWiki (talk) 23:52, 11 March 2014 (UTC)

Main Page redesign

Screw process, I'm going all-in. I spent over a year working on it, and now I feel it is finished and ready to deploy.

Visually more of a restyle then a redesign, most of the changes are under the skin: the entire page is competely fluid, so it adapts to any screenwidth. There is not a single table in the code, all divs. There are some modern features, but none are detrimental to old browsers.

I'm looking for people who want to participate with ideas for functionality and design, bugs, and coding. Test it out on everything you have, resize you browsers, abuse it. Then say Yes or No. Simple as that. Then answer: do you want to build further on this design? Questions and constructive feedback always welcome. — Edokter (talk) — 15:20, 8 March 2014 (UTC)

Main Page

Discussion/Comments

Moved from "No", due to the question's modification. —David Levy 13:41, 9 March 2014 (UTC)

• I'm impressed, but I disagree that this is "ready to deploy" and dislike this proposal's binary format. In my opinion, this design is off to a very promising start, but it could use some collaborative tweaking. —David Levy 15:42, 8 March 2014 (UTC)

  Tried that. I can't seem to get people interested in collaborating. — Edokter (talk) — 16:13, 8 March 2014 (UTC)

  Let's try again. —David Levy 16:17, 8 March 2014 (UTC)

  Isn't that what the comments/discussion section above is for? You say that you are impressed, and that it is just not ready (which implies with a few tweeks you would say yes). I feel the same which is why I'm reserving judgment pending discussion and collaborating above. ;) — {{U|Technical 13}} ^{(t • e • c)} 16:22, 8 March 2014 (UTC)

  I feel that more than a few tweaks are needed. As the choices are "yes" (the design "is finished and ready to deploy") and "no" (it isn't), the latter is the appropriate response. —David Levy 16:35, 8 March 2014 (UTC)

  I see, Discussion/Comments is just above Yes. The choices I see are: Discussion/Comments (not ready, please fix "X", "Y", and "Z"); Yes (it's ready, deploy it now); No (there's nothing you can do to fix it, I don't ever want to see it deployed). /me wanders away mumbling to hisself. — {{U|Technical 13}} ^{(t • e • c)} 16:56, 8 March 2014 (UTC)

  Given the context, I disagree that "no" means "there's nothing you can do to fix it". The question is simply whether the design is ready for immediate deployment (and my response is "no, it isn't").

  I also believe that more work is needed than can be carried out in the "Discussion/Comments" section. (I don't regard this as a "fix X, Y and Z and it'll be good to go" situation.) I see this as a solid proof of concept with technical merit, but I'm not sure about the specific implementation (layout, coloration, etc.). —David Levy 17:31, 8 March 2014 (UTC)

  Please tell me your concerns. The main problem is lack of feedback. Fixed one bug already, so yes, I may have been a bit brisk. I crave input; it is the only way to move formward. — Edokter (talk) — 17:11, 8 March 2014 (UTC)

  My main concern is that more discussion and experimentation are needed. It isn't a matter of elements being objectively broken, but one of room for aesthetic improvement. I don't think that it would be helpful for me to list my personal opinions regarding the colors, gradients and such (with which others are bound to disagree). I think that we need to sandbox some variants (including alternative layouts) and see what clicks. —David Levy 17:31, 8 March 2014 (UTC)

  But it is exactly that reason why this keeps failing; not giving your opinion. I Have no problem with multiple implementations, but no one else is stepping up producing them, and there is only so much I can do. — Edokter (talk) — 17:43, 8 March 2014 (UTC)

  I realize that. To be clear, I overlooked your previous attempts to solicit feedback, so I'm seeing this for the first time today. I would like to experiment with some variations (and I hope that others can be persuaded to participate in the process). —David Levy 18:01, 8 March 2014 (UTC)

• I don't want to say yes or no. I like the modernization, but there are a couple things that set me off about it.
  1. "Today's featured picture" image is way too large on my screen
     • It is more than three times the length of the accompanying blurb at 1320×825×24 (1.089 MegaPixels)
     • At 640×480 the blurb is 30% longer than the image
     • At 480×300 (mobile in desktop mode) the blurb is more than twice as long as the image, which doesn't fit on one screen.
  2. The "Wikipedia's sister projects" section is half the page because instead of filling in the entire box using multiple columns, it is a single column.^(screenshot)

• It shold have fallen back to floating divs. Removed columns for now. — Edokter (talk) — 16:08, 8 March 2014 (UTC)

• I'm using Firefox 27 in case it turns out to be a browser specific issue. — {{U|Technical 13}} ^{(t • e • c)} 16:19, 8 March 2014 (UTC)

• Weird. I could have sworn it worked on my Firefox 27. Columns are gone now. — Edokter (talk) — 17:54, 8 March 2014 (UTC)

It also throws me as odd that "Today's feature picture is looking left from the left side of the screen away from her blurb like she is saying get me the heck out of here. — {{U|Technical 13}} ^{(t • e • c)} 15:41, 8 March 2014 (UTC)

POTD shows no different then on the current main page; I have no control over that. — Edokter (talk) — 16:05, 8 March 2014 (UTC)

• I like the overall look of it but I feel there is a bit too much whitespace if two of the 'boxes' don't have the same height. For example, there is quite a bit of space below the Did you know box, because the Be an editor box is a bit higher. Also, I think the vertical spaces between adjacent boxes should be reduced (for example between the In the news and On this day boxes), as I find the vertical space more distracting than the horizontal space. Apart from that I feel the overall increased space between the boxes helps uncluttering the page a bit, which is good. -- Toshio Yamaguchi 15:43, 8 March 2014 (UTC)
  • Boxes should be equal height, but your browser may not support flexboxes. What is your browser? — Edokter (talk) — 16:10, 8 March 2014 (UTC)
    • @Edokter: I am using Safari for Windows. -- Toshio Yamaguchi 20:47, 9 March 2014 (UTC)
      • That's basically Webkit. If you have a recent version, you should see equal-height boxes. — Edokter (talk) — 20:51, 9 March 2014 (UTC)

• Works fairly nicely in Mercury on iPhone 4. Easier to read and use than current page. Not keen on the extended blurb in the box at the top of the page. Also, in my experience the only way I've personally seen effective changes to something like the Main Page was a small discussion with someone who actually coded stuff together, followed by boldly implementing it after the small group egged an admin into doing it, followed by tweaking based on the ensuing discussion that only happened after the change. Collaborative, yes, but it isn't reasonable to go for full community involvement, especially since most editors won't care enough to engage properly with the process. 86.161.109.226 (talk) 19:34, 8 March 2014 (UTC)

  The most recent successful main page redesign (in 2006) involved collaboration among a small number of editors, followed by a poll with nearly 1,000 participants. —David Levy 20:13, 8 March 2014 (UTC)

  And I would seriously love that to happen again. Really. But people can't just wait around for a mandate before doing this stuff: it has to look like it's actually happening. This is no longer the community where, for example, a load of editors would just share out archiving large talk pages regularly, even ip editors, and manually create archive pages because they needed doing. This is a community where most editors now expect grunt work and administrative tasks to be done by bots and some nebulous 'others': I just don't see people jumping in to these tasks in the way they used to. I suspect a large portion of the community is under the impression that the Main Page is some foundation responsibility, and outside their purvue: but this is just my impression. I would love to be proved wrong by an enthusiastic and productive response. 86.161.109.226 (talk) 21:49, 8 March 2014 (UTC)

  Several redesign attempts have been made since then, attracting significant interest but ultimately fizzling. These failures are attributable to various factors, but I believe that the single greatest problem has been a lack of focus. Everyone involved wanted to improve the main page, but there was no agreement on how to go about it. So instead of actually collaborating, individual participants arbitrarily cobbled together "drafts" reflecting their personal preferences (not actual goals identified by the community), most of which were vastly inferior to the current main page.
  Things were simpler in 2006, when it took very little to spice up the page's incredibly plain design. And while its successor seems technically outdated, a worthwhile update requires a level of coding expertise that most of us lack. I regard Edokter as one of the few Wikipedians up to the task. But collaboration (ideally with Edokter's work as a reference design and his direct involvement throughout the process) remains essential. —David Levy 22:31, 8 March 2014 (UTC)

  I would be surprised if you could actually get a meaningful set of "actual goals identified by the community". The community here is very diverse and does not agree on whats ideal for that page. For example, we know from prior discussions that some people want to showcase only the best work, and others insist that it must include pages that a good-faith newbie could likely improve. You can't have it both ways. I've no objection to you trying to lead such a discussion, of course, but I think it is doomed to producing "no consensus" on anything that is concrete, measurable, and realistic. (Consensus can be had on glittering generalities, but that's not pointful.) WhatamIdoing (talk) 21:33, 9 March 2014 (UTC)

  Any attempt to rework the main page's encyclopedic content en masse is doomed to failure. For the most part, we can only hope to improve its technical performance and aesthetics. Edokter evidently realizes this. —David Levy 22:09, 9 March 2014 (UTC)

• I really like the changes to the content ("Become and editor" box and the little blurb in the "Welcome to Wikipedia" box; everything in boxes), but honestly, I like the original color scheme better. Is it possible to have a way to change back to the old one while still keeping the new content and layout? Supernerd11 :D Firemind ^_^ Pokedex 21:44, 8 March 2014 (UTC)

• I like that Edokter (talk) has gotten the ball rolling. This is, at least, something we can start with as a basis to build some community support / consensus from; and a very good start. GenQuest ^{"Talk to Me"} 22:57, 8 March 2014 (UTC)

• (edit conflict) I've taken a look on the latest versions of Firefox and Chrome for Windows, and Dolphin browser for Android, and it looks pretty good (to me) in all of them. The "Welcome to Wikipedia" box could stand to be a little smaller, I think, it tends to draw my eye more than the Featured Article box, which doesn't seem desirable. I noticed that the boxes don't all have the same vertical height on Dolphin, so mobile browsers may be less likely to support the flexboxes, but I'm not sure whether or not that's a big issue since there's a separate main page for the mobile site anyway. Novusuna ^talk 23:00, 8 March 2014 (UTC)

  We could probably use some input from editors familiar with accessibility and usability, as well. Novusuna ^talk 06:32, 9 March 2014 (UTC)

• Comments:
  1. Under many display settings, today's tall TFA image protrudes from the box (due to its reduced height), breaking the formatting of the two boxes below. (I believe that This, that and the other refers to this issue below. Note that it wasn't present with yesterday's image.)
  2. It seems that this poll is unclear. What, exactly, is the question being asked? I interpreted it as "Is this design 'finished and ready to deploy'?". If the intended question actually is "Do you like this design and wish to pursue its continued development?", I'll change my answer. —David Levy 05:18, 9 March 2014 (UTC)

  That was unexpected (I have a small screen). I've added overflow:hiden; to the boxes which should prevent such breakouts. — Edokter (talk) — 12:06, 9 March 2014 (UTC)

  Yes, that appears to have fixed it. —David Levy 13:41, 9 March 2014 (UTC)

• Looks good on a Samsung Chromebook, I like the fact that it doesn't use tables, and the symmetry is achieved with mirrors sets of different sized boxes. Overall, a vast improvement. --NickPenguin_(contribs) 06:10, 9 March 2014 (UTC)
• I agree with David Levy. This thread is asking for a simple approve or disapprove. Right now I can't approve of this as it changes things too much from the current consensus for sectioning. Changing the main page is hard....VERY hard and I think it is meant to be. Maybe harder than any other page on Wikipedia. Taken some time to accept this fact but yeah.....this seems to be attempting an end run around a lot of discussion.--Mark Miller (talk) 06:25, 9 March 2014 (UTC)

  I have adapted the question at the top. — Edokter (talk) — 12:06, 9 March 2014 (UTC)

  I've changed my response accordingly. —David Levy 13:41, 9 March 2014 (UTC)

My main concern is the orange and the black-on-color contrast, now that the main issues with the MP design have been resolved. The text is less readable than on the current main page, and I'm still somewhat concerned about the readability of text on the MP and clarity of which section is which (I thought ITN was DYK for a few moments before my eyes actually picked up the header.) In other words, I'd just like it to be highly readable, and, er, not use orange (or at least, use a soft shade of red or yellow if emphasizing featured content?). It rather clashes with the cool colors. Also, there isn't much emphasis on portals; slightly tweak it to do so, perhaps, in addition to these previous concerns? If these issues are resolved than I'll gladly support. Cloudchased (talk) 22:45, 9 March 2014 (UTC)

These are all details that need to be worked out, so don't get hung up on how it looks now. If this goes forward, each and every aspect of layout and styling will be adressed. — Edokter (talk) — 23:50, 9 March 2014 (UTC)

• Totally broken in NCSA Mosaic, but that's no surprise: the rest of Wikipedia is also totally broken. --Carnildo (talk) 08:55, 10 March 2014 (UTC)
  • You really should upgrade to IE6. — Edokter (talk) — 12:14, 10 March 2014 (UTC)

• One concern I have is over the "Today's featured picture" div. It has a red background whereas the current main page's section has a very light grayish/light purple background. When I compare the current main page to your main page, today's image dramatically changes in color perception (an overall reddish cast). The current main page seems to be rather good at not altering my color perception of photos. I think the red background itself is somewhat to blame as is the lighter heading. The current main page has a darker heading. Overall though, I think your design is nice. Whether it's better, I'd need to think about. Jason Quinn (talk) 03:56, 12 March 2014 (UTC)

Comment on the process

Why are we having the discussion here, the village pump? We already have the redesign page so either we use it or merge it with 2013. I don't have a particular preference for the discussion, but trying to implement in a covert way is not democratical. Imagine someone commenting at the main "main page redesign" page without knowing there is some parallel discussion going. This is very problematic. (Personally I don't like the current main page design and so I don't like this one either.) -- Taku (talk) 13:43, 10 March 2014 (UTC)

It is here beause the 2014 redisign page is solely preoccupied with process, and nothing to do with the actual redisign, and therefor bound for failure. It also was not advertised in any way. The Village pump is hardly covert; it is the principle page to post proposals. I am trying to get a fluid process going that has collaboration at its core, using the outcome of the 2013 RFC as its guide, and my framework as a foundation. If you read the comments (also on the Main Page talk page), you will see that many people have identified "process-overload" as the main factor in these failures.

The 2014 is definitely not the main discussion regarding this proposal. That is why I removed it (twice). In due time, when this proposal has gained enough support, we will set up a new work area where those interested will collaborate to build a new page. So please do not link to that page again. — Edokter (talk) — 14:02, 10 March 2014 (UTC)

Yes

1. It apparently needs some tweaking for the all-browsers/all-screens issues, but I like it somewhat better than what we've got. Edokter certainly needs feedback and testing over multiple days and bug reports, but design-by-committee and WP:BIKEshedding is not going to help. WhatamIdoing (talk) 18:07, 8 March 2014 (UTC)

   A great deal of middle ground exists between design by committee and the complete absence of collaboration. Likewise, a great deal of middle ground exists between focusing endlessly on trivial details and not discussing details at all. —David Levy 18:24, 8 March 2014 (UTC)

   In design work, it's my experience that the you get better results if you tell a designer what you like and dislike, and let him (or her) deal with your feedback, rather than trying to have multiple people own a design. WhatamIdoing (talk) 21:36, 9 March 2014 (UTC)

   Hence my comment about the importance of relying on someone with coding expertise. All that's missing is the feedback (though not because Edokter hasn't sought it). —David Levy 22:09, 9 March 2014 (UTC)

2. There's room for improvement ("Be an editor" should be visible without scrolling; in "Sister projects" the columns are a bit awkward), but it definitely beats the existing main page. -- Ypnypn (talk) 01:56, 9 March 2014 (UTC)
3. I'm not particularly taken with the colours... there is tan, blue, and purple, but no green-type shades. I'm also not too keen on having the FA stretch across the entire page: the long lines are not conducive to rapid reading. Also, with very large browser window sizes (or when zoomed out), the FA image can get in the way of the "In the news" section. But: nice use of media queries (the layout adjusts flexibly for narrow screens), and overall it looks really clean and reasonably modern. Nice work, Edokter! — This, that and the other (talk) 04:38, 9 March 2014 (UTC)

   I had briefly wondered if green had been avoided because of the problems it creates for people with red–green colorblindness. It can be a difficult color to maintain legibility with. WhatamIdoing (talk) 21:36, 9 March 2014 (UTC)

   I ditched the green because the amber/blue/violet seems easier on the eyes. I am trying to be somewhat innovative, but I lack the inspiration with regards to colors and box design. So this is definitely not a final design with regards to styling. But since the CSS for styling is not inline, we could have many different styles without actually having to edit the main page. It could potentially end up withno styling at all. — Edokter (talk) — 22:26, 9 March 2014 (UTC)

4. Given the question's modification, I've switched from "No" to "Yes". I do want to build further on this design. —David Levy 13:41, 9 March 2014 (UTC)
5. An overall improvement. Rehman 15:52, 9 March 2014 (UTC)
6. To answer the re-formed question, Yes, let's build further on the design as now presented. GenQuest ^{"Talk to Me"} 16:10, 9 March 2014 (UTC)
7. Definitely the right direction. Jackmcbarn (talk) 16:34, 9 March 2014 (UTC)
8. A big improvement on what we currently have, and probably the best thought out of all the redesign proposals I've seen. the wub "?!" 17:18, 9 March 2014 (UTC)
9. I'll admit I don't love the proposed design, but against the current Main Page, it'd win my vote 90–to–1. The div/id-based structure is also great, and allows restyling of the Main Page a lot more easily than now. Cloudchased (talk) 02:05, 10 March 2014 (UTC)
10. Colour me impressed. I like the layout. Styling could stand to be a bit more bold, but that should be easy to hash out. Edokter has done well and, I'm sure, will continue to improve. — Huntster (t @ c) 20:40, 10 March 2014 (UTC)
11. I rather like it. : ) Is there a mobile version? Philippe Beaudette, Wikimedia Foundation (talk) 08:56, 12 March 2014 (UTC)

No

Not ready. See this screenshot, using Chromium 33.0.1750.146 on Arch Linux. The "Be an editor" box is also a little small; there's a gap between it and the DYK box. Cloudchased (talk) 15:30, 8 March 2014 (UTC)

Re screenshot: can be fixed. Do you have a screenshot of the 'gap'? — Edokter (talk) — 15:35, 8 March 2014 (UTC)

Both fixed now. Sister project icons no longer use columns, and the gap should be gone. — Edokter (talk) — 17:27, 8 March 2014 (UTC)

1. No, I simply don't like this style. The background colors, boxes and drop shadows are a relic of early-2000s-style graphic design and should be shunned. Good design allows the text fields to define the layout with the minimal possible decoration. —Designate (talk) 04:44, 9 March 2014 (UTC)

   You must really hate the current main page then... I'm open to ideas. Go ahead and make your own mockup; you'll see it is really hard to come up with a good design. — Edokter (talk) — 12:25, 9 March 2014 (UTC)

   I sure do. That's why good design is something you get paid for. —Designate (talk) 12:31, 9 March 2014 (UTC)

   I'm not getting paid, and I also don't have any money to pay. Would you none the less be interested in helping out? — Edokter (talk) — 13:27, 9 March 2014 (UTC)

2. No. Sorry but this is not how we make changes to the main page. But you have David Levy impressed and that is a great start. I am willing to collaborate on another attempt at the main page but very much agree with David that this isn't time to be asking for deployment.--Mark Miller (talk) 06:31, 9 March 2014 (UTC)

   How do we make changes then? All help is welcome. I changed the question and am calling for participants. — Edokter (talk) — 12:25, 9 March 2014 (UTC)

3. I'm glad something is happening and I commend Edokter for achieving that, but this isn't a significant enough improvement on what we already have. It still has a meaningless pastel colour scheme that clashes with the Vector skin 99% of users use, the proportions and spacing are inconsistent, and it's still a wall of text. — Pretzels 18:51, 11 March 2014 (UTC)

   This is certainly not the end result; most changes are 'under the skin', making the page fluid and allowing us to apply whatever style we want. It is more of an intermediate version between the HTML1 we have now and the CSS3 flexbox model that offers near-unimited flexibility in page layout. — Edokter (talk) — 20:33, 11 March 2014 (UTC)

4. I think this is visually a slight improvement on the existing page, but there really isn't enough difference. If we're going to change the Main Page (which is definitely overdue), let's do something a bit more exciting. 86.160.86.139 (talk) 03:12, 12 March 2014 (UTC)

Wikipedia:Featured topic candidates

Should the above page be moved to Wikipedia:Featured and good topic candidates? Same goes to Wikipedia:Featured topic criteria, Wikipedia:Featured topic removal candidates and some others. Huang (talk ^{in public} _{in private} | contribs) 18:16, 8 March 2014 (UTC)

Mandatory, agreed-upon reasons for Undo

I’d like to discuss whether it would be helpful to add specific reasons for undoing changes in articles.

Description of current problem

Many users have indicated that deletions, or reversions of their contributions, are one of the most annoying and misused aspects of Wikipedia, leading to edit wars. Some state that deletions of contributions particularly affects women contributors, and has been given as one of the reasons why female participation in Wikipedia is low (of course the issue affects all contributors, not just women). As a result there have been proposals to limit the Undo function

The ability to undo changes in Wikipedia is essential to prevent vandalism and delete material that is irrelevant, just plain wrong, offensive, constitutes spam, etc. However, the fact that many people seem to be dissatisfied with the way the current undo process works, suggests that it could be improved.

Currently editors have a lot of leeway to remove contributions. Editors, at their own option, can write a reason for the undo, but the default text is very general (i.e. “Undid revision…”). Even when editors choose to specify a reason, it can sometimes be vague, or in fact deletions may be made for inappropriate reasons. This, in turn, can leave the person whose edit has been deleted, confused, upset, etc.

Description of proposed solution

The proposed change is quite simple - i.e. it is suggested that a defined list of reasons for undoing be added (e.g. Vandalism, Spam, Offensive, Not relevant, etc) Thus, when an editor is performing an undo, she/he must select the appropriate reason (e.g. via drop down list or radio buttons), before the undo can be carried out. If a reason has not been selected an error message would appear

This list would include a short description of each reason, so that everyone understands what are the appropriate, agreed upon reasons for deleting edits. The list can also include an “Other” reason, plus, as now, a textarea where the editor can add additional helpful explanations. Once the delete is confirmed, the selected reason, along with the additional written explanation, will appear on the View history page in the edit summary text.

Of course, a definitive list of valid reasons for performing undos, would first need to be defined and agreed upon

Benefits

The benefits of this simple change would be twofold:

1. To editors who are performing undos, it would provide a reminder on what are valid, agreed upon reasons for deleting contributions, and thus make the process less arbitrary. By requiring specific reasons for deletions, the incidence of inappropriate deletions, as well as possibly the intensity of some edit wars, could be reduced
2. To editors whose contributions are being deleted, the reasons would provide a better, agreed upon explanation of why their contribution was deleted. Thus, the process would appear less arbitrary to them, and potentially less unsettling. This in turn could reduce the likelihood of editors being discouraged from participating, as observers state is the case now

Level of effort

Implementing the proposed change would be fairly simple, requiring relatively little effort - Ivansfca (talk) 22:25, 9 March 2014 (UTC)

Comments

Devil's advocate question: what if I write gibberish for an "Other" reason? Chris857 (talk) 00:39, 10 March 2014 (UTC)

It depends. If it's possible to come up with a definitive, all-inclusive list of valid reasons for Undo, then Other wouldn't be needed. So that would have to be first determined and agreed upon - Ivansfca (talk) 03:50, 10 March 2014 (UTC)

A definitive, all-inclusive list would be a couple of pages long, at best. That's if the undo reason doesn't actually comment on article content (e.g. "the article already says that he was Bavarian, not American") or contributor behavior (e.g. "reverting edit by admitted publicist for the article subject").

• More than "a couple of" pages. Also, in many cases the summary will need specific, article-driven responses. You can't "boiler-plate" that. This proposal as stated is untenable. GenQuest ^{"Talk to Me"} 23:53, 10 March 2014 (UTC)

Trying to cover such reasons for reverts with a prewritten message will make the problem worse: it becomes less personal. I get the impression that the main reason people are frustrated is that they don't understand why their edit was reverted. Default messages other than "undid revision" would help, but cannot be all-encompassing.

That said, a better argument against gibberish "other" messages would be that those who are lazy enough to just hit the undo button and not explain why are also too lazy to go hunting for the "other" option and type in gibberish. Maybe make the default option "I'm too lazy to properly explain why I undid this and may be edit warring," in addition to the other option. Ian.thomson (talk) 04:01, 10 March 2014 (UTC)

I agree with Ian. Another option to consider would be that Undo revisions that are unclear in nature can be reverted as if they are vandalism. That would have to be clearly defined however.Serialjoepsycho (talk) 18:36, 10 March 2014 (UTC)

• That can, does, and is allowed to happen now. GenQuest ^{"Talk to Me"} 23:53, 10 March 2014 (UTC)

I agree that defining more clearly valid reasons for undo will help, regardless of how its implemented. As Ian notes, people get upset when they don't understand undos. When rules are clearer, people are more likely to go along with them

Problem is we’re flawed human beings and don’t always do what we should (like properly explain an undo). The proposed approach would at very least require specification of reasons for undos, which people should be doing in any case. Users will still be able to elaborate on this reason with additional written explanations as they do now. In fact written explanations may also improve, since they will be tied to explicit agreed upon undo reasons. Currently written explanations can be vague, don’t always provide helpful information. As to number of valid undo reasons, it may prove that some smaller number, e.g. less than 10, account for 80-90% of undos

One way to determine best approach, and also address Trovatore's point, below, would be to carry out a user survey, to get their broader feedback on what might be the best solutions here, in terms of improving what now seems to be a frustrating experience Ivansfca (talk) 19:46, 10 March 2014 (UTC)

This proposal is no doubt well-intentioned, but I can't support it even slightly. In most cases, the burden of proof should be on a new change to prove that it's an actual improvement over the old text. (Note that this is a distinct issue from the burden of proof for assertions, which is on the side doing the asserting — in that case, the person removing the assertion meets his/her burden, not by proving the assertion is false, but just by pointing out that it's an assertion and is not supported.)

Changes that are not clear improvements should be undone and the status quo ante restored. This has two major advantages: First, it promotes a stable experience for readers, except when it the experience can actually be improved. Second, it discourages editors from making frivolous (even if otherwise harmless) changes just because they can. --Trovatore (talk) 18:44, 10 March 2014 (UTC)

This is a very dangerous argument, that any proposed edit needs to pass through a dozen committees before being allowed to remain on-wiki. (I know that's not exactly what you said, but it's the logical extension thereof.) -- Ypnypn (talk) 01:56, 11 March 2014 (UTC)

Not at all. My point is that there is, and should be, a bias in favor of stability. If a change is per-se harmless, but also useless, it needs to be reverted. That way articles don't change for no good reason, and it's easier to track the changes that do occur and make sure they're sound. --Trovatore (talk) 05:15, 11 March 2014 (UTC)

• Oppose Although I understand the reason behind such a proposal, I have to disagree with a need for it. The proposal as stated would result in the creation of an unwieldy and absolutely huge dBase needed just to hold possible outcomes. I understand your frustration, but you can't control editors, and make them all fill out the summary. However, currently, if an edit takes place without a summary filled in, it is another possible reason for the next guy to come along and just hit the "Undo" button. If an edit is as necessary and as important as an editor thinks it to be in the first place, it needs a summary. Those editors who make these mysterious, non-summarized edits run the risk of being reverted at best, or starting an edit war at worst. (Both of which is OK—at least it gets the editors talking/communicating after a point). Remember, if you make what you feel is an important edit, even a good, well-intentioned; value-adding edit may be reverted if there is no summary and the reason for the addition is unclear to the next person passing by. As hard as it is on some articles to get a change to stick, you'd think people wouldn't open the door wider to let in just another reason to be reverted. GenQuest ^{"Talk to Me"} 23:53, 10 March 2014 (UTC)

Quick question. How would this create a much larger dbase? Currently users have option to type really long text string in Edit summary to describe reason for Undo (don't know if entire typed string is stored) In fact they can type completely different, long reason text strings for each and every Undo. I assume that has to be stored somewhere. If all users type in different reasons, as many different long text strings have be stored as there are Undos. To add a mandatory, predefined reason, as suggested, all that is needed is one extra index field, and a look up table. For good design you'd probably want at most some 10 different reasons (to include perhaps an "Other"), since in most cases 80:20 rules apply -- i.e. a relatively small number of reasons account for majority of Undo use cases

Users would still have option, same as now, to type in additional explanation. To give a purely hypothetical example, one reason, among 10 or so, might be "Not relevant", where user can type in additional explanation "This information would be more relevant in article x, since focus of this article is y". Other users can type in their own, different detailed explanations, so it also gives flexibility. Main advantage is that, at the very least, one reason would have to be selected, e.g. via simple drop down list. That compares to example Ian gave above, where no reason is now given, because users "are too lazy", leaving people frustrated

I brought this up becaus people have written articles in New York Times and elsewhere, identifying frustrations with Wikipedia Undo process as a key obstacle to greater editorial participation. If goal is to bring in new editors, then I think best way to determine best Undo approach is to survey a broad array of Wikipedia users, so they can speak for themselves. Separate from that, I do recognize potential technical difficulties, including potential database size impact you mention, so I would like to understand that better - Ivansfca (talk) 02:50, 11 March 2014 (UTC)

At present, the "undo" reason is stored as part of the edit summary for the edit, nowhere else; and every edit, no matter how large or small, has 255 bytes allocated to the edit summary. Once the edit is saved, there is no technical difference between the edit summaries of this edit and this one - both contain 255 bytes of information (which might include wikilinks) most of which is blank space. Thus, using your suggestion of "one extra index field, and a look up table" would create a larger database (n.b. not dBase) because even though the edit summary would have a higher proportion of blank space, it would still be 255 bytes long; space would be needed for index field (which would be needed for every edit, not just the "undo" ones) and also for the lookup table. At present there are something like 599,000,000 edits stored in the database. Even if the index field were one byte, that represents an increase in database size of more than half a gigabyte. Adding this field would require every record to be modified, which takes up processing power and thus real time. Finally, the software would need to be modified to perform the lookup and display it. --Redrose64 (talk) 08:25, 11 March 2014 (UTC)

Thanks for response, understand. Just as a matter of interest, would same apply if the Reason were stored, not in a separate index field, but in exact same place as where Edit summary text is now stored. In effect once a reason is selected it just becomes a textstring in existing Edit summary. So in above hypothetical example, where user selects (e.g. from drop-down list) "Not relevant" as reason, and then types as explanation "This would be more relevant in article x", the saved Edit summary text would read "Not relevant: This would be more relevant in article x". Thus everything is stored only in Edit summary, while to end-user it would appear practically same. Would this be different in terms of impact on db size, other impacts? Ivansfca (talk) 19:44, 11 March 2014 (UTC)

Essentially, that's what "Add two new dropdown boxes below the edit summary box with some useful default summaries" does (it's at Preferences → Gadgets, first entry in the "Editing" section). Whatever you select from those two dropdowns gets appended to the existing "Undid revision ..." text. The limit is still 255 bytes. --Redrose64 (talk) 23:17, 11 March 2014 (UTC)

So from purely technical end, this isn’t a big deal – most functionality already exists in gadget, and there are no db impacts, as long as Edit summary is kept to 255 bytes

To Blackbombchu’s point, below, complaints I’ve seen on current Undo process, are not just about bad edits being undone. There are at least 2 articles in NYTimes, which point to this problem, authored by 2 professors, so their professionalism and writing is no doubt top notch. Yet, they specifically identify frustration with current undo/deletion as a key reason that hinders broader editor participation.

Solution you propose, limiting people who do bad undos, is interesting. Others have also proposed limits on undos. To automate this, additional code would be required to collect data on # of bad undos per person, then implement appropriate algorithms/code to limit person’s undo ability. If they are indeed performing bad undo’s, they would still be able to undo, and annoy people, until they reached undo limit. Of course, no solution is bulletproof, but one advantage of approach I mention is that it’s simple. Often even small, simple changes can nudge people in positive directions. My favorite example is where on issue like organ donation, participation rates skyrocket from something like 20% to 80%, depending merely on whether default selection is No vs Yes. Current default for Undo in Wikipedia is that one need not specify a reason, perhaps making it too easy not to provide one, frustrating, and potentially turning away some editors

Given that Economist recently noted that number of editors on WP-EN has fallen by one-third, this should be concern. Of course, best way to understand true reasons for undo frustrations and possible solutions, is via a broader user survey Ivansfca (talk) 01:47, 12 March 2014 (UTC)

• Amend If a specific Wikipedian is discovered to have most of their undoes be undoes that weren't worth undoing, then they should be warned and if they persist having most of their undoes be undoes of good edits, then they should be made unable to do the default undo eature and if they start manually undoing other people edits in response to that block, they should be blocked from editing entirely. In the case of new inexperienced users who leave Wikipedia from being tired of all their edits being undone, if they really were bad edits, then the people who reverted them didn't do anything wrong because the purpose of edits is to make Wikipedia better, not to make somebody personally feel better about their own edit. One of the project pages should teach newcomers a guideline of what edits tend to be bad edits. They should also be taught by a project page that as they become more experienced, they might start making a higher fraction of good edits and can view article history to see which edits were good ones that weren't undone do become a better editor. Since people get notified when ever their own edit gets reverted, that should further increase their ability to learn from their mistakes which types of edits are bad edits. Maybe some people's real reason for leaving Wikipedia after their edits continuously get undone is not because they're tired of making so much effort for nothing but rather because they're afraid that they're damaging Wikipedia by making edits that are worthy of undoing and don't want to damage it more. I, on the other hand used to only create new sections on talk pages and answer other people on talk pages and never edit an article because I was afraid of taking the slightest chance of making a bad edit and now I'm really glad that my bad edits get undone because it makes me less afraid of making edits. In fact, I would keep on making edits that I wasn't sure whether were good or bad edits even if I new ahead that 2/3 of my edits would be bad edits for ever becuase I can't tell ahead which ones are good and which ones are bad and I know that since my bad edits will get undone, I would still on average be improving Wikipedia instead of worsening it. Blackbombchu (talk) 02:45, 11 March 2014 (UTC)

Have the back button sometimes take you back more than one page

My internet explorer 9 browser doesn't have an arrow for going forward or back more than one page in one step and it's happened to me before that I was watching a YouTube video and 4 times in a row, I clicked a suggestion to start watching it as soon as I was done the watching the previous video then clicking the back button once took me back 4 pages, so I know it's technically possible. I think that when ever somebody clicks the back button right after editing an article, it should automatically take them to the last page they were on that wasn't gotton to by clicking 'Save page', 'Show preview' or 'Edit', and if they made 2 edits since they went to that article without leaving that article, clicking the back button should take them back 5 pages + the number of times they clicked 'Show preview'. Blackbombchu (talk) 00:52, 11 March 2014 (UTC)

If you click-and-hold on your back button, does it not come up with a list of recent pages in reverse order for you to select from? Accessibility rules usually discourage breaking how the back button works. 86.157.148.65 (talk) 20:45, 11 March 2014 (UTC)

Actually it does work. I never thought to try it. Blackbombchu (talk) 00:20, 12 March 2014 (UTC)

Have an advanced search feature on Wikipedia

There are so many articles that need attention from an expert such as Nucleate boiling. Wouldn't it be nice if people no longer had to do all that work of hunting for experts. An easy way around that problem would be to enable anybody to do an advanced search where they search only for articles that have the expert template because way more experts would come to those articles on their own instead of being sought after in a wild goose chase. It should in fact be possible to do any template search where your search results are restricted to articles contntaining a specific type of template like for example, a stub, orphan, technical, expert, unreferenced, cleaning up, or proposed deletion search. It should also be possible for anyone to view the list of all articles that link to a specific article in such a way that they're able to see only those articles containing a specific type of template that link to it in the same way as they can choose to only see redirects and it should also be possible to set up their own account, or possibly computer, in such a way that links to another article that contain a specific type of template are a different color than the rest of the links in case they want to be a good Wikipedian finding all those articles that need a lot of attention to get improved and have the skill to make the appropriate changes to those articles. It should also be possible for anyone to restrict their search results to only those articles that both are part of a specific WikiProject and contain a specific type of template. The page Help:Template should also contain a list of all templates that are not an expanded version of another template, so it should include {{stub}} but not {{Internet-stub}}. Clicking {{stub}} in that help page should get you to Wikipedia:WikiProject Stub sorting/Stub types. Blackbombchu (talk) 20:14, 11 March 2014 (UTC)

I'm confused about the "all articles that link to another article" statement, but is this sort of thing what you mean? https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Expert-subject&hidelinks=1&hideredirs=1 - Purplewowies (talk) 04:07, 12 March 2014 (UTC)

Handing out barnstars

I would like hand out barnstars to all editors who made more than 250 edits to medical articles in 2013. We have the list. There are 114 in English and a 160 in other languages. One time task. Thoughts? Doc James (talk · contribs · email) (if I write on your page reply on mine) 21:22, 11 March 2014 (UTC)

Is it the same message to each person? If so, then WP:MassMessage from Meta will do what you want, and Jake can send it for you. You'll need to send it in "subst'd" form, since the templates don't exist everywhere, but that's easy enough to arrange. WhatamIdoing (talk) 21:56, 11 March 2014 (UTC)

Isn't a barnstar something you should personally award to somebody for his/her excellent work? While I like your idea to say thanks to people who contributed notable work, I'm afraid that by "flooding" userpages with automatically created barnstars you'll lessen the value of barnstars alltogether and especially the value of the barnstars you're handing out. My suggestion would be to stick with some "Thank you"-note in the form of a greeting card instead. --Patrick87 (talk) 22:06, 11 March 2014 (UTC)

I doubt that delivering a single barnstar to fewer than one in a thousand active editors here, and an average of less than one person per non-English Wikipedia, will "flood" anything. WhatamIdoing (talk) 23:55, 11 March 2014 (UTC)

Excellent thanks WAID. And we will get your barnstar out to you soon :-) This is a thank you to those who have worked a great deal on medicine. We are a small number of editors. And many may not realize that anyone has noticed the work they are doing. Doc James (talk · contribs · email) (if I write on your page reply on mine) 02:30, 12 March 2014 (UTC)