Jump to content

Wikipedia:Village pump (proposals)/Archive 110

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

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

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

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)

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)

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").
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)
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)

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)

I have no issue with this, but I would only say that the traditional way that mass barn stars are given is to place the barn star in a centralized discussion and state that you award them to all that have (fill in the blank).--Mark Miller (talk) 00:00, 13 March 2014 (UTC)

Restrict A class usage

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Disclaimer: I've been very active in A-class reviews for the Military History Project, so this closing statement concerns only the other A-class processes. I don't see any consensus in favor of a specific change ... I don't see it among the voters, and I haven't seen it in the past among the thousands of people who have been involved with A-class in one way or another (including at FAC, since most A-class articles move on to FAC these days, and the A-class reviews are usually relevant). As I mentioned below, I don't have any objection to the way this was handled ... if you guys wanted to test the waters first, and decided that this wasn't going anywhere so notifications weren't necessary, that's fine. But if this comes up again, some effort will be needed, per WP:CONSENSUS, to bring in the people who have been involved with the process you're discussing here . - Dank (push to talk) 02:00, 15 March 2014 (UTC)

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 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. VanIsaacWS Vexcontribs 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)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Tweak to tooltip text to add "tagged since "... more opinions wanted

Over at Wikipedia:WikiProject Inline Templates, I started a discussion to add the text "tagged since " to the date in the tooltip of inline tags. I started the conversation four and a half months ago but only received one recent "yes" reply. I am inclined to start making this change but I would be interested in more input before doing so. The ubiquitousness of these tags necessitates some caution I think over a "be bold" approach. (Actually, I'd also like to encourage some users to "join" WikiProject Inline Templates, an important project which seems to have too few participants presently. You can reply at the project's thread. Jason Quinn (talk) 01:02, 14 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://wiki.riteme.site/w/index.php?title=Special:WhatLinksHere/Template:Expert-subject&hidelinks=1&hideredirs=1 - Purplewowies (talk) 04:07, 12 March 2014 (UTC)
I think people should be able to search for articles with a specific template type in the same way as researchers can preform a deleted article search. The other method of showing what links to a template doesn't make it very easy to seek out an article with a title very similar to what you search for containing that template. Additionally, maybe there should be a project page educating experts about the method of finding articles that have the Expert-subject template. Since it's possible to do a search of videos in a specific YouTube channel, it should also be possible when you're on a "what links here" page to do a search of articles on that page. I believe there is a way for Wikipedia to enable restricting one's own search results to those that both have a specific template type and are part of a specific WikiProject despite the fact that it's actually the talk page that links to the WikiProject. By "all articles that link to another article," I meant it should be possible for anyone to have only links to articles containing a specific template type appear an unusual color because they might be good at improving articles with that template type and that way, they can easily find a link to an article containing that template type to improve it without going on a wild goose chase clicking a significant number of links in the article they're on then clicking the back button. Blackbombchu (talk) 16:24, 12 March 2014 (UTC)
You already can search for any article that contains a particular template using Special:WhatLinksHere. For example, Special:WhatLinksHere/Template:expert-subject will give you a list of pages that have the {{expert-subject}} template on it. --Dan Garry, Wikimedia Foundation (talk) 22:41, 12 March 2014 (UTC)
Also, if you're using the new search engine we've implemented a "hastemplate:" operator that can refine searches as well. ^demon[omg plz] 01:15, 16 March 2014 (UTC)

[Once more] Merge Merging process With AFD

It has been discussed several time. Most probably I started a thread too. Please merge "merge process" with AFD. AFD may be renamed to "Article for discussion" and merge discussions may take place there. Tito☸Dutta 00:06, 13 March 2014 (UTC)

What? No. I do not support that.--Mark Miller (talk) 00:50, 13 March 2014 (UTC)
"Merge" already is a possible determination at AfD. But AfD isn't an appropriate venue in which to propose mergers, which require the attention of an article's editors to carry out (because administrators lack a "merge" button). Merging is a normal type of editing, best discussed on articles' talk pages. —David Levy 00:57, 13 March 2014 (UTC)
We have, in fact, previously reached a consensus to restructure proposed merges to be more like Wikipedia:Requested moves; it's just that no one has gotten around to implementing that consensus. We even have the page for it, Wikipedia:Proposed mergers. bd2412 T 01:16, 13 March 2014 (UTC)
As I said in that discussion, and @Flatscan: noted too, there have been several (at least two - 1, 2) attempts to create a separate, discussion based forum for merging. They have failed due to low participation. @GenQuest: does a really good job at WP:PM; being the senior editor administering that part of the project (and the one whom gave it's current structure), I think their opinion would be important here. --NickPenguin(contribs) 02:05, 13 March 2014 (UTC)
A simple implementation of a requested moves-type process probably would not help at Proposed mergers. The merge backlog isn't going to be resolved on talk pages. I've been doing an analysis of the history, but get so far before diverting to other things. Significant fixes will be a longer term project. For a peek at what I've got so far, look here. I think we need better triage to isolate the minority of proposed mergers that would benefit from an RM-type discussion. For example, we have obvious duplicates like Matthew J. Zapruder and Matthew Zapruder. For that, we don't need a discussion; all we need is a guideline for determining which article to merge to. As to stuff like Wikipedia:Articles for deletion/Constitution Party of Alabama, give me a break. These are the kind of proposals that bog down this project. These are not duplicate articles; is the consensus really for combining the full content of some thirty articles into a single article, or is this all about WP:Deletion by redirection? Yes, please, the editors who formed the consensus in that discussion should just merge themselves as they agreed, rather than pass it off to this project. Wbm1058 (talk) 03:59, 13 March 2014 (UTC)
  • Agree whole-heartedly. If this is an outcome at AfD, then the responsibility should become that of the AfD closers/participants, especially when I run across an article to be merged with absolutely no references. When merged, guess what happens? The next editor comes along and deletes the non-referenced addition to the article (I can give examples if necessary.) This is blatant "Deletion by Redirection" in my mind, when it should have just gone away by a simple "Redirect" to begin with, something anyone at AfD should have been able to handle in the first place. GenQuest "Talk to Me" 23:38, 13 March 2014 (UTC)
As a parallel, there have been various AfDs that have been closed as merged, and I'm like, merge what? Sometimes just pull the trigger and just delete it if there is no valuable content. --NickPenguin(contribs) 01:00, 14 March 2014 (UTC)
Yup. See Wikipedia:Merge what?. Wbm1058 (talk) 17:57, 15 March 2014 (UTC)
  • Actually, as it now stands, anyone can boldly do a merge at any time.
Of course, if someone objects and reverses a bold merge, usually all confusion breaks loose, as most are not reversed properly, and old merge tags pop back into the merge-category backlogs which @Wbm1058:, @NickPenguin:, and a few others of us work so consistently in clearing. Note also: we can't take away BOLD merging, because if we discussed each merge that actually does take place as is implied above, the backlog would be even more untenable than it now stands.
The lack of consensus is not (and should not be viewed as a) justification for a "merge declined" decision. The lack of consensus (actually "no consensus") is more of a lack of meaningful participation in most of the discussions. Often, when this is the case, the nominator or one of us "mergists" will simply just proceed with the merge, if it makes sense to do so. It's when the reason for the merge request is less obvious—or potentially controversial—that additional input must be asked of the Wiki-Projects that should be interested. This is where much of the process breaks down, as more often than not, the call goes unanswered.
Another part of the dearth of merge proposal participants I attribute to the lack of knowledge by the average editor of the merge proposal discussion. As it is now, these take place in isolation—on the talk page of the article into which the merged contents are requested to be placed. If any change were to be made to the current "Merge Request" process (and as has been discussed in the past), I would recommend that a central clearing process be implemented. I would hope more similar to the DYK nomination board than the AfD board (the joining with the AfD process idea having been shot down repeatedly in the past). Then, the discussion has a central area to draw additional participants, yet the discussion is transcluded to the talk page of affected article(s), keeping article and discussion followers informed as well. That could prove helpful in widening exposure to the ongoing merge discussion, and actually generating a consensus. GenQuest "Talk to Me" 23:38, 13 March 2014 (UTC)
      • I'd strongly support this - and have a half-written proposal somewhere - it involves converting AfD into Articles for Discussion - the main 3 reasons being (1) avoiding duplication of work (2) reducing the polarising atmosphere of keep/delete at AfD and (3) addressing the fact that lots of merges and AfDs attract very little interest as there are just too many boards to follow and we need to merge some discussions. Cas Liber (talk · contribs) 19:19, 13 March 2014 (UTC)
see Wikipedia:Articles_for_discussion/Proposal_1 and Wikipedia:Articles_for_discussion/Proposal_2 Cas Liber (talk · contribs) 19:21, 13 March 2014 (UTC)
  • It's hard to get an exact number, but I would say somewhere from half to a third of the articles tagged in a given month are resolved within 60 days, many within the first 30. I would say the reason is more than half of all merge proposals are bad proposals. There are lots of very good cases identified with the merge tags (consider the currently oldest merge request Bomb the Bass and Tim Simenon), but articles often get tagged when they are in a similar realm, but sufficiently different to warrant separate articles. --NickPenguin(contribs) 02:20, 14 March 2014 (UTC)

I do support some automated merge nomination process. Being heavily involved in cleaning up the backlog, I have noticed that many merge requests are incomplete. For instance, often the merge notice is missing on the target page, and by far the majority has no discussion started on the talk page. This could be one reason why merges attract little attention. Doing it right with an automated process that adds all the right tags and starts a partially auto-populated merge discussion may improve the merge process and its visibility. But I have some reservations of dealing with merges through the AfD process. First, the AfD process goes to too fast. Nominations are only up for 1 week. Second, even if an AfD results in a merge, it still leaves the actual tedious task of merging. And finally, not all merges would require a discussion, such as obvious duplication and bold merges. I completely agree with GenQuest on this. -- P 1 9 9  ✉ 21:45, 14 March 2014 (UTC)

  • I like the automation aspect of P199's comments. I ask some of the tech-savvy editors, is such an automation possible? and if so, could the process be tied into the central clearing-house idea mentioned above? If so, I would be happy to draft a proposal of such. GenQuest "Talk to Me" 04:38, 15 March 2014 (UTC)
    Have you tried using WP:Twinkle for proposing a merge? It's under "Tag", almost at the bottom of the list. It will tag both pages and includes a space for an "optional but strongly recommended" rationale. WhatamIdoing (talk) 05:50, 15 March 2014 (UTC)
  • It has been a while since I participated in any merge discussions. Generally I see a tag and if the article needs a merge and there has been no discussion I see it as a weak silent consensus and will merge if it looks like it fits all the reasons to do the merge. However some merge proposals are just stale and need to just have the tag removed. There are a good deal of discussion on the merge process on the talk page of Wikipedia:WikiProject Merge and the project has taken time to go through all of the guidelines for merging. Haven't looked at it recently to see if anything needs updating but a quick look on the talk page suggests that someone has been trying to update it as needed.--Mark Miller (talk) 22:01, 14 March 2014 (UTC)

Handling merge proposals without rationale/discussion

As User:NickPenguin has said above, a large number of merge requests are just bad proposals, can we a) encourage users to start discussions while proposing merge (similar to Twinkle's Clean up reason option? b) or if we want to be more strict, we/a bot may undo merge proposal if there is no rationale/discussion Tito☸Dutta 05:09, 15 March 2014 (UTC)

No, not really, per WP:PPP. We don't want to destroy a good proposal just because someone didn't know to jump through the right hoops.
However, any single editor can look at any merge that's been proposed for more than a few weeks, and if there's no visible discussion and the merge seems like
(a) an obviously good idea, or
(b) an obviously bad idea,
then that editor may either (a) merge the pages or (b) remove the merge proposal tags, as appropriate.
If that sounds to you like "any human may undo a merge proposal if there is both no discussion and, after considering all the facts and circumstances, he opposes this specific merge proposal", then I won't quibble. But the "and he opposes this specific merge proposal" is a key point. You can't do this to any merge proposal you happen to stumble across, regardless of merit. WhatamIdoing (talk) 05:46, 15 March 2014 (UTC)
  • WP:PPP is an essay, anyway, it'll actually help to make the process more productive and systematic. then that editor may either (a) merge the pages or (b) remove the merge proposal tags, as appropriate. — No. Such merge/no merge should not take place based on one editor's opinion. Tito☸Dutta 05:55, 15 March 2014 (UTC)
If a merger is regarded as potentially controversial, it's best to seek input. But unlike deletion, merging is normal editing (the reorganization of content). If someone disagrees with a bold merger, he/she can revert and discuss it.
When participation in a merger discussion is low/nonexistent, the only solution is for editors to use their best judgement. Shifting the proposals to AfD wouldn't help, as that's an already-overburdened process in which even outright deletion listings often fail to attract wide attention. So instead of the articles' editors determining what to do, we'd have small groups of uninterested parties making binding decisions (to either deny or affirm requests) in a week or two. In the case of a "merge" decision, tagging would occur anyway (because, as noted above, administrators have no "merge" button to press). And discussion regarding how to carry out the mergers would be less likely to occur (because users would see that the decision was made and assume that further consideration was unneeded). —David Levy 14:03, 15 March 2014 (UTC)
  • Tito, you should read WP:PGE.
  • The fact that a merge/no merge decision could be made by one editor has been in WP:MERGE from the beginning. See statements in it like these:
    "If enough time (normally one week or more) has elapsed and there has been no discussion or is unanimous consent to merge, any user may close the discussion and move forward with the merger. If you propose a merger, and nobody objects within 30 days, then you or any other interested editor may boldly perform the merger at any time. If you see a merger proposal that is older than 30 days, and nobody has objected, and you personally believe the merger is appropriate, then you may boldly perform the merger whenever you want. There is no required 30-day discussion period. If a consensus in favor of the merger is formed in less than 30 days, then anyone may perform the merger whenever they want. If the proposal is obvious (e.g., the mistaken creation of a second page for the same subject under a slightly different name), then a discussion need not even be held.... Any editor, including you is permitted to perform mergers in accordance with consensus. Merging pages does not require intervention from an administrator."
    Merges, like other copyedits and reorganizations, can be easily reversed by any editor. WhatamIdoing (talk) 16:19, 15 March 2014 (UTC)
Every time I see a discussion like this, it always seems to come back to the idea that the merge backlog isn't a process problem so much as it is a productivity problem; we need more people to evaluate merge discussions, and if there is no consensus to merge, the just remove the tag. A merge is a subjective request about content, and we can't be afraid about removing tags. Editors are so reluctant to remove maintenance tags for fear of getting bitten. In my experience I have only had a handful of tag removals or merges reverted, and those were cases where I was simply wrong. --NickPenguin(contribs) 16:42, 15 March 2014 (UTC)
I have seen some very poorly done merges. I am not going to support one editor's sudden merge. Merging process should be systematic. --Tito☸Dutta 23:17, 15 March 2014 (UTC)
I have seen some very poorly done edits. I am not going to support one editor's sudden edit. Editing process should be systematic.
Do you see the problem? —David Levy 23:49, 15 March 2014 (UTC)
edits? Tito☸Dutta 23:55, 15 March 2014 (UTC)
Yes, such as those resulting in two articles being merged. —David Levy 00:09, 16 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)
Yes, some web browsers have unintuitive interfaces. --NaBUru38 (talk) 16:26, 17 March 2014 (UTC)

Should Wikipedia have a constitution?

Given that rules about Wikipedia are scattered all over the site, I think creating a constitution so that all these rules could be conveniently accessed in one place would be helpful. After doing so (possibly with the title WP:Constitution), we would fully protect the page because of its importance, and then propose "amendments" to it in much the same way as they are in the United States' government. Jinkinson talk to me 23:52, 12 March 2014 (UTC)

Our five pillars are our constitution, but I do support revisiting them for an update. Would you agree with such a discussion Jinkinson?--Mark Miller (talk) 23:57, 12 March 2014 (UTC)
Yes, Mark Miller, I definitely would. Personally, I've always thought that the 5th pillar is ridiculous and, at least in practice, serves only to allow biased and POV-pushing editors to get what they want. I would also argue that since WP:IAR would never work in real life, it shouldn't work on Wikipedia either. On a related note, I also think that Wikipedia should drop the "we're not a bureaucracy" act, clearly define the levels of authority in the Wikipedia bureaucracy, and actually start enforcing its rules. Jinkinson talk to me 00:05, 13 March 2014 (UTC)
Not that I think it's going to happen, but I strongly disagree with revisiting the five pillars. As much as I'd love to take the "respect and civility" rule out of there (pretty sure no one has ever been calmed down by "keep it civil", and it's just used as a way to change the conversation to be about a person's conduct), it's a really bad idea to start messing with the fundamental principles of an extremely successful endeavor for no reason. Things are going just fine, there's no clear identifiable reason for this and it's just an invitation for a big, pointless discussion where people speculate on possible problems and propose untested solutions to them. Likely nothing would come of it anyway, but if something did, I'd give it better than even odds that it'd be detrimental rather than helpful. 0x0077BE [talk/contrib] 04:35, 13 March 2014 (UTC)
It is never a bad idea to discuss editing a page or policy, even our core principles every so often to see if they are able to keep pace with the ever changing world around us. Things are going fine? No, not everywhere and perhaps you are just not aware of the issues that have become...deserving of further attention. If you feel discussion is pointless on Wikipedia you are in the wrong place.--Mark Miller (talk) 04:42, 13 March 2014 (UTC)
(edit conflict)The thing is, Wikipedia's policies shouldn't be rooted in real life because Wikipedia's not real life. WP:IAR is easily abused, yes, but that doesn't mean we need to throw it out. There's the navboxes that let you hop around easily enough between essays and guidelines and everything else, what are you proposing we do differently? But yea, everyone can see the pyramid of authority and all the back-and-forth, Wikipedia's definitely a bureaucracy, and like all bureaucracies, it's fairly bloated when it comes to diplomacy (for lack of a better word). Supernerd11 :D Firemind ^_^ Pokedex 04:54, 13 March 2014 (UTC)
You must be referring to the OP. I don't know if what you say about real life and Wikipedia is true or not, but when I say the world around us, I mean the Wikipedia world and the real world or have you just not noticed that cell phones are a major way Wikipedia is now accessed. That is the real world and if we ignore such, we are truly doomed, and perhaps...rightly so.--Mark Miller (talk) 07:14, 13 March 2014 (UTC)
The constitution of a country (the U.S. included) is not so much a collection of rules as a framework around which the rules are built - it holds the rules together. There are very few actual rules in the U.S. constitution - it says that there shall be certain bodies and indicates how people should be appointed to those bodies, and describes the powers of those bodies; but in terms of actual rules there are few: the President is the only person who can declare war on another country, for example - but nowhere does it say "thou shalt not kill/steal/bear false witness/etc." There was one which amounted to "thou shalt not touch alcoholic liquor" but look what happened to that one. Perhaps what we could do is formalise the relationship between the Executive (Jimbo Wales), the Judiciary (ArbCom) and the Legislature (everybody else). --Redrose64 (talk) 07:41, 13 March 2014 (UTC)
Going to back to your OP, do you mean a mission statement similar to WP:5P, or do you mean a convenient list of the important stuff such as Template:Wikipedia policies and guidelines? VQuakr (talk) 08:21, 13 March 2014 (UTC)

How about an organized and categorized page with all of the policies on them if there isn't already?Serialjoepsycho (talk) 11:57, 13 March 2014 (UTC)

And for every POVpusher you have claiming IAR there's a wikilawyer breaking the spirit of the rules.Serialjoepsycho (talk) 12:00, 13 March 2014 (UTC)
We do have such a page: WP:POLICYLIST. Yunshui 雲‍水 12:03, 13 March 2014 (UTC)
I would agree with creating a constitution. At the very least, it is a central document. Is there such a central place now? --LT910001 (talk) 08:36, 14 March 2014 (UTC)

Actually, User:Epipelagic, my starting this proposal had nothing to do with the discussion on WT:EW (which only uses the word "constitution" twice anyway). My idea for proposing this actually came to me when I was looking through some old ArbCom rulings, and realized that many such rulings contain important decisions that apply to pretty much anyone regardless of what type of articles they are editing. This is much like how Supreme Court rulings apply to everyone in the country, not just people in the state in which the dispute originally arose. Therefore, I think that after the original Wikipedia Constitution was drawn up, perhaps using material from the five pillars, we add a list of amendments to it based on these arbitration cases. The idea behind this latter proposal is to parallel the amendments to the actual US constitution. I'm open to suggestions, though, which is why I am posting here at all. Jinkinson talk to me 15:18, 17 March 2014 (UTC)

Have one sandbox for each ordered pair of an account and article

Any 2 accounts that click the Sandbox link on the same article should go to a different sandbox as is already done, but also which sandbox a specific account goes to by clicking the Sandbox link should be affected by which article the account user is on. That makes it so much faster for reviewers currently to review sandbox improvements only for the article they're on and look for sources for somebody else's original research changing its status away from original research. The reason there shouldn't instead only be one sandbox per article is because different people might have radically different suggested improvements to an article. People should still be able to freely edit somebody else's sandbox. My purpose in people being able to do that is to make an improvement to somebody else's sandbox page, not to totally overwrite it as though they were creating their own sandbox for the article they're on. If Wikipedia worked that way, with there existing a page User:Blackbombchu/Speed of sound/sandbox instead of User:Blackbombchu/sandbox, then I could add original research into User:Blackbombchu/Speed of sound/sandbox that would probably get reviewed extremely quickly such as "The speed of sound in a gas is defined to be the speed of a sound wave that is approached as the sound wave's wavelength approaches ∞ with constant amplitude and that speed is not affected by which amplitude is used. According to a quantum mechinical theory that neglects gravity, the cosmological constant, relativity, quantum decay, nonzero size of electrons and nuclei, and electron mass, for any diatomic gas, for any two temperatures above absolute zero, the ratio between speeds of sounds approaches a constant as the gas density approaches 0, those two temperatures approach absolute zero with a constant ratio in temperature, that constant approaches exacltly √7/5 × that ratio. Those 2 temperatures can be approached in that way because all substances above absolute zero are most stable as a gas if the pressure is sufficiently low and so the number that constant approaches exists. The reason why it approaches that number instead of being exactly that number at all temperatures below the plasma temperature is due to various effects such as photon emission and absorption and rare collisions to form unstable coumpounds in the same way as the self ionization of water. The exact speed of a gas exists in that theory because the absense of gravity allows for arbitrily large samples of a gas to be taken without being compressed by its own gravity and thus no upper bound on the wavelength of sound to be created. Also according to that theory, the planck constant is 0; electrons move infinitely fast; and nuclei behave completely like particles." Blackbombchu (talk) 16:44, 19 March 2014 (UTC)

That isn't an accurate description of how Wikipedia currently works so the suggested improvement doesn't make much sense. Rmhermen (talk) 17:46, 19 March 2014 (UTC)

Proposal to require non-autoconfirmed editors to submit a draft when they want to create an article

As the header implies, I am proposing not that we stop non-autoconfirmed users from creating articles (I know we already tried that), but rather that we require them to submit it for review before it will be visible by everyone. Not like AFC or anything, just so that there will be a newly created page that, in the same way that unaccepted non-autoconfirmed edits on PC1-protected pages are not visible to anyone except reviewers (and admins of course), would not be visible to anyone except, well, reviewers. That is, such articles would, after being created, have to be "accepted" by someone with the reviewer right before anyone without it could see them at all. If the article meets any of our criteria for speedy deletion, the reviewer would tag it accordingly and an admin would eventually come along and delete it. The benefits would be greatly decreasing the amount of vandalism, spam, and test pages that are created and have to linger and accumulate web traffic before they are deleted. And before you start saying, "The existing system of people patrolling Special:NewPagesFeed and then tagging things for speedy deletion works well enough," allow me to explain why I think it doesn't. Lots and lots of pages get viewed during the time they are created and are speedy deleted, even if they aren't viewed very many times. Under the change I am proposing, only reviewers would get to see such pages, rather than Wikipedia's intended audience (who presumably never actually edit it, just read it). This would provide not only an additional "layer of protection" standing between new accounts and creating pages, but would also help weed out the new accounts who are only here to vandalize or promote themselves or do some other non-encyclopedic thing. Also, I pretty much always get negative responses whenever I propose anything here, so that's what I'm expecting this time as well (though if someone wanted to surprise me that would be perfectly OK). ;) Jinkinson talk to me 02:07, 18 March 2014 (UTC)

  • Why would it be "What page?" All registered editors would be able to see it (and it would be yet another benefit to encourage registration). Not saying I support the idea, but I can see the technical feasibility of it. — {{U|Technical 13}} (t • e • c) 13:57, 18 March 2014 (UTC)
  • Why would we bother with this? Last time I checked the Page Curation backlog was hovering around 20 days, and that's up from 3 months a couple of months ago. We're doing really well on article review. Sure, we'd cut out the (gasp) horrifying possibility that people might see content that is not, in fact, perfect, on a collaboratively edited and fully-disclaimered encyclopedia, but by that standard we should everything, frankly. Ironholds (talk) 16:26, 18 March 2014 (UTC)
  • Fearing the bureaucracy that would be in effect at AfC or anywhere else, I'll have to say no, because the last thing new users need is to be shepherded into an unintuitive and separate process from what everyone else is doing. KonveyorBelt 16:30, 18 March 2014 (UTC)
  • Comment I'm confused, how is this different than current pracitce? Those non-*confirmed users that want to submit an article can do so through the AfC process (or submit in the Draft or User sandbox namespaces). There's several editors out there that monitor these types of submissions and move them into the unified Drafts space where the newbie can get assistance and support with their work in progress. At the end a user in good standing takes a look at the submission and if it's ready for articlespace can move it over. If it's not ready it gets declined and the advocate gets to improve upon it. Frankly, we already have enough "Newbie help" processes in the system that I don't think we need another. Hasteur (talk) 17:15, 18 March 2014 (UTC)
@Hasteur: The way it would be different from current practice would be that:
  • Now, non-autoconfirmed accounts can create articles that go live instantly, the same as any other user with an account.
  • Under my proposal, such accounts would be able to type everything in and hit save, but after they did so, the article would only be visible to people with the reviewer right, who would then either accept them or tag them for speedy deletion. The idea here is that there are a lot of non-autoconfirmed users which only have one purpose on Wikipedia, and whose purpose is not compatible with our policies. These users often create lots of stuff that is blatantly non-encyclopedic, so I think this measure would be very beneficial as far as preventing these types of pages from being created is concerned. And of course, as often comes to my mind when editing this site, an ounce of prevention (stopping the article from going live) is, as they say, worth a pound of cure (deleting the article after it's been created). Jinkinson talk to me 19:51, 19 March 2014 (UTC)
Now that you've explained it OPPOSE. This (or very similar) was proposed in Wikipedia:Autoconfirmed article creation trial. So many things that are wrong with this proposal (in addition to the Reviewer user right not being for that purpose in addition to having been given out like candy before). Hasteur (talk) 23:02, 19 March 2014 (UTC)
Hi Jinkinson, what do you actually think of the new "Draft:" namespace? See Wikipedia:Drafts#Incubation and Wikipedia_talk:Drafts#Moving a mainspace article to Draft. It's obviously still under development, but it looks very interesting. The whole draft namespace is "notindexed".
And what is your take on recent research, meta:Research:Wikipedia article creation? From its summary: "We were surprised to find that articles created by anonymous editors (where such creations are possible) are more likely to survive than articles created by newcomers who recently registered an account. This result suggests that it's time to review English Wikipedia's policy against anonymous article creation. We also found that, in general, the rate of survival for newcomer articles has been decreasing over time with two notable exceptions. In the English Wikipedia, the survival of newcomer articles decreased steadily until the introduction of Articles for creation, a space for creating article drafts and receiving review before publishing. In German Wikipedia, the survival of newcomer articles has been rising steadily since 2008, but we see no evidence of a comparable switch toward a draft & review process in that wiki. Finally, we found correlation based evidence that directing new article creators to AfC has resulted in a dramatic decline in the creation of good new articles by newcomers."
You have obviously given a lot of thought to the article creation problem, so what is your interpretation of the research results? --Atlasowa (talk) 20:21, 21 March 2014 (UTC)
First, thanks for asking my opinion. When I saw the above quote from the research on Meta, my immediate reaction was probably best summed up in this video. The reason I think allowing IPs to create articles would be such a bad idea is because that's exactly what led to the Seigenthaler incident--when any random person can write anything they want, bad things happen, which is why (at least some) restrictions on article creation are necessary. Of course, this applies not only to creating articles but also editing them, but that's another story. But I think the quote above, particularly its conclusion that IPs' articles are better than those of newly registered users, touches on an interesting point. I imagine what's going through the heads of many people who just created an account is "Mwa-ha-ha-ha! Now I can create as many nonsense articles, hoaxes, spam, and/or attack pages as I want!" So since having an account is a learning experience they'll of course either learn not to do that or keep doing it until theyre blocked. By contrast, IP editors are more a mix of the committed and experienced editors and the malicious vandals, since many of them have been editing for a long time anonymously. So I guess that may explain it. Also, the message at the top of the research page exhorting us to feel bad for the poor, downtrodden new accounts for whom it is so difficult to create pages is pure bullshit. Their articles getting tagged and speedy deleted is a good thing (unless it wasn't actually eligible for speedy deletion). We need to realize that Wikipedia can't allow itself to be taken over by the masses, and that bureaucracy is not only already in place but necessary for Wikipedia to achieve its goals. Jinkinson talk to me 20:42, 21 March 2014 (UTC)

Stub categories should be hidden

I have proposed that stub categories be changed to hidden categories, in line with other non-topic-specific/project categories. Please contribute to the discussion at Category talk:Stubs. Thanks. SFB 21:30, 23 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)
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)
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)
  • A new user would not create a new account and start meddling in Template-code, unless they've been active at other wikis using mediawiki. Still, the user namespace should be excluded from the 10 edits. KonveyorBelt 15:59, 20 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)
  • Oppose To actually effect Socks you'd have to change it to make posts count 4 digits with year or more as the time length. I see no problem with 20 edits and 7 days but the only target really being hit is Newbies.Serialjoepsycho (talk) 06:50, 13 March 2014 (UTC)
  • Oppose: Making it harder just bites the newcomers, and any less will just help vandals get in easier. Sleeper socks are generally going to get autoconfirmed, no matter how many more edits or days are needed. Supernerd11 :D Firemind ^_^ Pokedex 02:27, 15 March 2014 (UTC)
    @Anomie: So you're saying that while sockpuppets of vandals or otherwise unhelpful editors will be willing to make more edits if they have to to become autoconfirmed, but helpful contributors who recently created their accounts won't? How does that make sense? I never heard anything about how malicious POV-pushing trolls were more dedicated to editing than "legitimate newbies". Jinkinson talk to me 02:21, 18 March 2014 (UTC)
    Probably you haven't been involved in that area very much. Anomie and I could probably name half a dozen dedicated sockmasters offhand (except that it's really important to WP:DENY recognition to some of the fame-seeking ones). Also, "malicious", "POV-pushing", and "trolls" are three separate categories, and not the only ones that matter. WhatamIdoing (talk) 15:45, 18 March 2014 (UTC)
  • Oppose: I suggest lengthening the days perhaps to a week, but not the number of edits. Not being a terribly prolific editor, I would be so discouraged to have to reach even 50 edits to get off probation, I probably would not even bother. Of course, any crafty and savvy person could easily rack up a post count with nearly needless minor changes. Fylbecatulous talk 23:24, 23 March 2014 (UTC)
  • Oppose: I support the lengthening of time, but not the number of edits. When I first joined Wikipedia, the four days wasn't even a problem - just live your normal life until the timer ends. You can still edit most articles during that time, and edit requests aren't a problem either. 10 edits is a pretty difficult accomplishment for a good number of people, so lengthening that just drives away newbies. K6ka (talk | contribs) 18:38, 24 March 2014 (UTC)

Proposal to automatically ProD redirects to other language versions of wikipedia, instead of turhing them into soft redirects

At the moment, User:AnomieBOT III changes redirects to other wiki-language versions, something like this, into soft redirects, like this. This is an approved task, so this is not a complaint about the bot or the operator (and was discussed there first, [1]).

However, this task goes against the guideline Wikipedia:Soft redirect, which states "Soft redirects to non-English language editions of Wikipedia should be avoided because they will generally be unhelpful to English-language readers."

I propose that the bot would change its action, and instead of changing the redirects into soft redirects, it would turn them into ProDs for being invalid as they stand. If they get turned into articles in the week between tagging and deletion, good; if not, nothing is lost but an unwanted (soft or hard) redirect anyway. Thoughts? Fram (talk) 07:40, 19 March 2014 (UTC)

Agree for article namespace.
Obviously, if there is a suitable target within English language Wikipedia, it could be manually redirect ther instead.11:44, 19 March 2014 (UTC)-- 签名 sig at
What? Why would La Liga redirect to es:Primera División de España?
Note how e.g. Damaso Pio De Bono has now been twice speedy deleted already. There seems to be a consensus that we don't want or need such redirects, so having the bot propose them for deletion seems a better method that a bot turning them into unwanted soft redirects. This would only apply to the mainspace, and for redirects to other wikipedia languages, not soft redirects to wiktionary and the like. Fram (talk) 10:02, 20 March 2014 (UTC)
I have undeleted the redirect, because this was an abuse of process. No criterion currently permits the deletion of these pages: R2 is for redirects to talk pages and to miscellaneous namespaces; and G6 is for maintenance such as trashing empty maintenance categories and extraneous disambiguation pages, resolving accidental page creations, and facilitating pagemoves and histmerges. It's most definitely not meant as a "delete anything else that we normally don't keep" criterion. Nyttend (talk) 12:32, 23 March 2014 (UTC)
Note that it's not likely to be possible for the bot to determine whether there is a suitable target within the English Wikipedia, as that would require significant AI. It might be worth checking whether the foreign-language wiki has an interlanguage link back to some other enwiki article, but that's about the only case the bot could actually handle. Anomie⚔ 11:50, 20 March 2014 (UTC)
I found out yesterday that there is a bot that is tasked with deleting broken redirects under WP:CSD#G8 - it is AnomieBOT III (talk · contribs), and here's the log. Would it be worth asking Anomie (talk · contribs) if the same bot can be assigned this task? --Redrose64 (talk) 10:58, 20 March 2014 (UTC)
At User talk:Anomie/Archives/2014#Anomiebot III I suggested it be raised here to check consensus. ;) BTW, if anyone knows of any appropriate policy/guideline or WikiProject talk page on which this discussion should be advertised, please do so. Anomie⚔ 11:50, 20 March 2014 (UTC)
I went and advertised it at Template talk:Proposed deletion, WT:Proposed deletion, WT:Deletion policy, WP:AN, and WT:Soft redirect. Anomie⚔ 13:14, 22 March 2014 (UTC)
I've also advertised it at Wikipedia talk:Redirects for discussion. — Mr. Stradivarius ♪ talk ♪ 14:51, 22 March 2014 (UTC)
  • Any bot that did this would need to be sure the article page didn't have significant history. –xenotalk 13:04, 20 March 2014 (UTC)
    • Excellent suggestion. I lean towards defining "significant history" as "has any revision that's not an interwiki redirect", although I wouldn't object if people want less restrictive criteria. Anomie⚔ 13:14, 22 March 2014 (UTC)
  • Comment *Wikipedia:Proposed deletion currently says "it cannot be used with redirects, userspace pages, templates, categories, or pages in any other namespace." (my bolding) GB fan 14:12, 22 March 2014 (UTC)
    If PROD cannot be applied under the current rules, I suppose the alternative would be nominating such redirects at WP:RFD. Would the RFD system be able to cope with the influx of nominations, and would this be technically feasible? Alternatively, I would be ok with updating the PROD policy to specifically allow interwiki redirects. — Mr. Stradivarius ♪ talk ♪ 14:51, 22 March 2014 (UTC)
    OTOH, above Nyttend says that WP:CSD#R2 doesn't apply because these aren't redirects. Clearly this is a very grey area. Anomie⚔ 10:35, 24 March 2014 (UTC)
    Not quite: I was saying that R2 doesn't apply because the target isn't another namespace; the point of R2 is to get rid of redirects to things that are far from being articles (e.g. talk pages, Book:, User:), not redirects to other projects. Nyttend (talk) 12:27, 24 March 2014 (UTC)
    Perhaps R2 could be expanded to include such? –xenotalk 13:18, 24 March 2014 (UTC)
    I would support that. Nyttend is correct. But when faced with a technicality that would prevent us from fixing undesirable redirects, the best solution is to remove the technicality. Resolute 13:44, 24 March 2014 (UTC)
    Good idea. I proposed "prod" because these soft redirects go against a guideline, but hadn't noticed that applying prod to redirects goes against a guideline or policy as well :( I preferred prod because of the delay in it, which is less bitey and increases the chance of turning these soft redirects into articles. Fram (talk) 08:31, 25 March 2014 (UTC)
  • Completely against the idea of a Wiki. Folks are free to create a proper article replacing the soft redirect. If {{sofixit}} isn't what they want a sound soft redirect is better than unsourced red links. A bot cannot judge this, and the Prod-procedure explicitly excludes redirects. Example from de:w: to en:w::
    There never will be a proper de:HMS Proserpine (1777), it's not notable for w:de:. But en:HMS Proserpine (1777) exists and has a nice picture for visitors not understanding English. Nevertheless the soft redirect was killed by the de-version of a speedy, and readers of the two de-articles linking to the deleted soft redirect can now ask googlebot if a ship with this name really existed. –Be..anyone (talk) 22:28, 25 March 2014 (UTC)
    People are free to create a proper article replacing the redlink, in fact that is what redlinks are supposed to indicate and encourage. Soft redirects hide the redlink but don't help most users. And in general, enwiki notability rules are amongst the most relaxed of all wikipedia versions, so the de-to-en scenario you describe will rarely if ever happen in the other direction, which is the only direction that is relevant here. Fram (talk) 08:11, 26 March 2014 (UTC)
    Further, you can always use a cross-wiki link inside an article, e.g. instead of Abraham Lincoln you use Abraham Lincoln directly inside the article, if this is really necessary, instead of going through a soft redirect. While I in general oppose this as well, it is not covered by the current proposal at all, so your concern can be avoided this way. Fram (talk) 08:15, 26 March 2014 (UTC)
    The direct links on de:Neuwerk (Insel) and another page to the forsaken HMS Proserpine (1777) were immediately reverted, that's why I thought that they prefer soft redirects. Good to know that the rules here are still remotely rational. –Be..anyone (talk) 14:05, 26 March 2014 (UTC)
  • I agree that interwiki redirects should be deleted, or redirected to a related English article if desirable. A foreign article is of little use if you don't know the target language (which is likely). Why we are prioritising a non-English solution? I would actually prefer a WP:Red link, which would better highlight the need for an article to be written about the topic in English. SFB 21:07, 26 March 2014 (UTC)

Detect broken formatting?

I noticed the thread complaining about those bots which constantly remind you, after the fact, mind you, that you broke formatting, have a loose bracket, linked to a disambiguation page, etc. It got me thinking; why can't we integrate such syntax checks into the actual editing interface somehow? ViperSnake151  Talk  06:45, 23 March 2014 (UTC)

Sounds like a good idea if the wiki-mechanics and tech-guys can handle it, and save/lag-times wouldn't markedly rise. If I am understanding you correctly, I'm thinking your proposal would be some kind of a syntax-check which operated similarly to grammar-check or spell-check (as found in MS Word, for instance); thereby cutting out the need for a middle-man (or bot) so to speak? GenQuest "Talk to Me" 23:25, 25 March 2014 (UTC)

Change the source code for subheadings

I think that a phrase should use 1 = sign on each side for subheadings of level 2, 2 for level 3, 3 for level 4 and 4 for level 5. The reason why is because when creating an article, people don't actually create the title by typing a phrase with an = sign on either side at the top and instead do it deciding ahead what title they want the article to have. I once wrote =Marine D<sup>3</sup>= in the edit page of Marine D3 because I thought doing so would move it to Marine D3 but instead it made a second title appear lower down in the article. This change would make it no longer possible to create a heading of level 1 anywhere other than at the top of an article. Blackbombchu (talk) 12:01, 25 March 2014 (UTC)

I'm afraid you're about ten years too late to suggest something like that. — Scott • talk 12:37, 25 March 2014 (UTC)
Yes, the MediaWiki software is used by thousands of wikis today and many of them probably do use level 1 headings. Wikipedia sometimes does it outside article space, for example dates at Wikipedia:Reference desk and Wikipedia:Help desk. That means the discussion threads can be level 2 as usual. PrimeHunter (talk) 12:54, 25 March 2014 (UTC)

Enable formatting in file descriptions.

File:TetrationConvergence2D.png, which was uploaded directly to Wikipedia doesn't have the formatting in it's description that it was meant to have. Blackbombchu (talk) 13:37, 25 March 2014 (UTC)

I think that this is a WP:VPT matter, not VPR. Anyway, first question: what is your setting at Preferences → Appearance → Math? --Redrose64 (talk) 16:02, 25 March 2014 (UTC)
Do you see a field called "description"? I see a "Summary" heading at File:TetrationConvergence2D.png#Summary, and a "Comment" column at File:TetrationConvergence2D.png#filehistory. The summary is wikitext in the page source and formats fine for me. The comment is an edit summary from the upload and is cut off after the first 255 characters. It is not supposed to be formatted. PrimeHunter (talk) 16:35, 25 March 2014 (UTC)

Have unreferenced articles get as quick a response as ones nominated for deletion

WP:SNOW, WP:PEREN (non-admin closure) Jackmcbarn (talk) 22:02, 27 March 2014 (UTC)

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

No one has added any references to Double circulatory system up to 5 years after it was marked as unreferenced. Maybe, articles should should automatically get deleted by a bot 2 weeks after they get lableled as unreferenced if no one finds any reliable sources within those 2 weeks with only administrators able to remove the unreferenced template. Non administrators really should be unable to remove it, not just forbidden to. Even if most unrefenced articles would be better off staying unreferenced for 5 years than deleted, I think it's still worth them getting deleted after 2 weeks for the following reason: when an article is about to be deleted from being unreferenced, a lot of people will try frantically hard to find sources and then in almost all cases, somebody will find a realiable source for the unreferenced article if one exists with the end result that the number of articles that get deleted from being unreferenced for which a source exists will be a much smaller number than the number of articles that get a reference within 2 weeks as a result of the unreferenced template that otherwise would have gone on 5 years without getting a reference. Bereore you automaticaaly reject this from being to similar to a perennial proposal, make sure that you realize that the debate is not whether it's better for an article to get deleted than to stay unrefenced for 5 years but whether it's better for 1 unreferenced article to get deleted by mistake than for 10 articles to stay unreferenced for 5 years. If an article was marked as unreferenced before this change gets made, then it's automatic deletion should happen 2 weeks after Wikipedia makes that change instead. Furthermore, when ever an article is marked as unreferenced, there should be a page for its deletion discussion so there should be a page Wikipedia:Articles for deletion/Double circulatory system with the {{unreferenced}} template being a second kind of template that gives rise to that kind of page, where people might discuss how to hunt for references. Blackbombchu (talk) 12:13, 24 March 2014 (UTC)

Two weeks! No, we who edit Wikipedia are all volunteers and there is no reason to create a lot of stress. Oppose! Lova Falk talk 20:21, 24 March 2014 (UTC)
Oppose. I second Lova Falk's reasoning. Unreferenced articles are bad for the project, I cannot deny that. But setting artificial deadlines isn't going to help, particularly one that would require more work for admins and users, work that could just be put into finding references. If you want to deal with the problem of unreferenced articles, why not instead create a WikiProject dedicated to finding references for unreferenced articles? Novusuna talk 20:52, 24 March 2014 (UTC)
I feel that I should expand on my opinion a little bit. Unreferenced articles can, of course, be submitted to WP:AFD for discussion and possibly deletion, or even PRODed if the deletion is likely to be uncontroversial. What I object to is the automation of this process, which would mean that unreferenced articles no longer get any review to determine if they can be salvaged before they are deleted. We don't want to throw the baby out with the bath water. Novusuna talk 08:41, 25 March 2014 (UTC)
Oppose for reasons stated. GenQuest "Talk to Me" 05:02, 25 March 2014 (UTC)
Oppose - Unreferenced articles should be fixed, not deleted. --NaBUru38 (talk) 13:03, 25 March 2014 (UTC)
Oppose. will be creating alot of workload as many deleted articles will be recreated....current method involving AfDs not good but has a natural flow.Cas Liber (talk · contribs) 12:52, 27 March 2014 (UTC)
Comment: Can someone close this, per wp:Snow? GenQuest "Talk to Me" 21:12, 27 March 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia should have an extra tool that you can click to see a list of all web pages outside of the domain name wiki.riteme.site that link to the page you're on, just like TORI does. Blackbombchu (talk) 13:57, 25 March 2014 (UTC)

I cannot find the feature you mention for TORI. Where is it? Do you want links from other Wikimedia wikis or from the whole Internet? I don't think the Wikimedia Foundation has interest or resources to make a tool for the latter. PrimeHunter (talk) 16:51, 25 March 2014 (UTC)
It's the website itself that has that feature, not the article about it. Blackbombchu (talk) 18:52, 25 March 2014 (UTC)
I looked at the website before asking. Please provide an actual link. PrimeHunter (talk) 21:30, 25 March 2014 (UTC)
I never clicked 'Permanent link' before I worte this proposal and assumed permanent link meant what links to the page. Blackbombchu (talk) 03:20, 26 March 2014 (UTC)
I appreciate your enthusiasm, Blackbombchu, but you really should do a little more research before bringing some of your proposals to this section of the village pump. Maybe consider posting your ideas to the idea lab to see if they're feasible before trying to seek consensus. Novusuna talk 03:35, 26 March 2014 (UTC)
  • Yeah, that's just not going to happen. There is no way to compose that data in a reasonable manner, and the count would always be outdated as spiders crawled the web looking for links... Even Google doesn't really do that. — {{U|Technical 13}} (t • e • c) 22:05, 25 March 2014 (UTC)
Actually google does really do that. Well, once. --Atlasowa (talk) 14:24, 27 March 2014 (UTC)

Remove the sentence at the top of a non-article edit page

Every edit page says at the top that '[e]ncyclopedic content must be verifiable.' but I know that original research is allowed in a talk page. The sentence Encyclopedic content must be verifiable. should not appear in the edit pages of non-article pages. Blackbombchu (talk) 19:32, 25 March 2014 (UTC)

If you're editing a Talk page then you're not working with encyclopedic content... Just sayin'. DonIago (talk) 19:40, 25 March 2014 (UTC)
You can work on drafts and make suggestions on talk pages, and the other parts of MediaWiki:Editpage-head-copy-warn apply everywhere. It would be odd to omit the middle part on some pages. PrimeHunter (talk) 20:23, 25 March 2014 (UTC)
What PrimeHunter said. Some content outside of mainspace is still encyclopedic in nature. It's up to individual editors to tell whether that part of the notice applies to what they're doing or not. Novusuna talk 21:21, 25 March 2014 (UTC)
Why can't it be replaced with something pointing at the talk page guidelines? ViperSnake151  Talk  23:56, 26 March 2014 (UTC)
If you haven't changed language away from the default English at Special:Preferences then talk page edits already display MediaWiki:Talkpagetext which links to the talk page guidelines. PrimeHunter (talk) 12:45, 27 March 2014 (UTC)

Protecting featured articles--yes or no?

(Caution: long rant ahead.) I've had this idea for a few weeks now, and noticed it listed on perennial proposals. As those who have been watching this page recently will know, I propose a fairly large amount of stuff here, most of which involves adding additional restrictions to Wikipedia. To these people it should therefore be no surprise that I want to protect featured articles, since, after all, they are the best Wikipedia has to offer. I am also unconvinced that simply because they will need to be updated, or because the criteria will change, means we should let them sit around in the open like any other article. Why? Because if we need to update it, or change it to meet new criteria, we can do exactly what the PP page describes: have a main version that is identical to the one identified as a FA, and another "draft" where editors could work on updating the page while diverting vandalism from the version everyone sees. I think it is indefensible that we spend hours upon hours researching information so we can create long and well-written articles, then let them get a gold star in the corner, only to abandon it a few months later just because we've managed to delude ourselves that it will actually "improve over time, rather than deteriorate." Or because "they don't deteriorate that often". Or because "they have so many watchers, the watchers will make sure it stays up to par. Okay, well at least they'll revert all the vandalism." In my opinion, it's high time Wikipedia started acting like a real encyclopedia since it wants to be treated like one (as do I). Obviously there are still other details in the above proposal that haven't been defined yet, but I still think it would be far more of a benefit to us than a disadvantage. Jinkinson talk to me 03:31, 27 March 2014 (UTC)

Isn't Wikipedia extremely successful simply because it didn't start like a "real encyclopedia"? As you yourself have pointed out that this is a perennial proposal, it would be helpful if you could provide stats on how often featured articles get vandalized, and how many FA's deteriorate after a few months. etc. The way you've presented your proposal (which isn't really a proposal, it's a rant) right now, it seems like a solution searching for a problem. Clearly identifying the problem you are trying to solve would help your idea out a lot. In the meantime, this would probably fare better on WP:IDEA. Legoktm (talk) 12:45, 27 March 2014 (UTC)
I really really hate the idea of two current versions floating about. Ideally I think I lean in favour of semiprotecting all FAs or otherwise considering a low threshold to introduce semiprotection. Cas Liber (talk · contribs) 12:50, 27 March 2014 (UTC)
There are lots of watchers on FAs, so we shouldn't worry too much about someone slipping in problem text unnoticed. Semi is a bit excessive though. A default application of the 1RR should go along way without silencing all ipedits.LeadSongDog come howl! 13:21, 27 March 2014 (UTC)
  • Are you really proposing indefinite full protection for all FAs?
  • Is your evidence that there is a practical problem that needs to be solved really as flimsy as a personal preference/gut feeling? WhatamIdoing (talk) 15:47, 27 March 2014 (UTC)

Wikipedia is a work in progress.. Just because the article is featured doesn't mean it's done. It will never be "done". Especially with events and people that are recent, and with events and people of history, new information will be discovered. KonveyorBelt 16:30, 27 March 2014 (UTC)

You say Wikipedia should start acting like a "real" encyclopedia, but what do you mean by real? If you mean a traditional paper encyclopedia, we're pretty clearly not like those by design. Even the featured articles are works in progress, and always will be. That's the nature of what we're doing here. This is a somewhat long winded way of saying no, I oppose protecting featured articles just because they're featured. That's treating them like a finished product, which they aren't. Novusuna talk 16:52, 27 March 2014 (UTC)

This topic was already discussed in Wikipedia:Perennial proposals. I think a better level of protection would be a pending changes protection. Blackbombchu (talk) 13:16, 28 March 2014 (UTC)
No. As Konveyor Belt wrote, "featured" does not mean "done." Wikipedia has been successful because we don't act like a traditional encyclopedia. Traditional encyclopedias and wikis that try to act like traditional encyclopedias are failing. So that's not a model we want to emulate. We are the encyclopedia anyone can edit, not the encyclopedia anyone can edit as long as you only want to edit things that we don't care about. Mr.Z-man 16:48, 28 March 2014 (UTC)

Watchlist stars in search results

Would it be possible to make the watchlist stars show up while you're searching for an article? I edit a handful of articles with scientific names, and it can be difficult to find the right one when you edit, say, two out of eighteen in the same genus. I'd imagine that this would also come in handy for medical articles, acronyms, and maybe a few others. Supernerd11 :D Firemind ^_^ Pokedex 12:28, 27 March 2014 (UTC)

It that were a gadget, I would totally use it. — Scott • talk 12:52, 27 March 2014 (UTC)
@Supernerd11: @Scott: How about User:Writ Keeper/Scripts/searchWatcher.js? Might be a bit slow, but it should do the trick. Writ Keeper ⚇♔ 17:55, 27 March 2014 (UTC)
@Writ Keeper: Forgive me if I'm missing something really obvious, but where should I put it? Putting it on the common.js and vector.js subpages doesn't seem to change anything (I tried common.js first, FWIW). Supernerd11 :D Firemind ^_^ Pokedex 14:21, 28 March 2014 (UTC)
It's not a good idea to put it in both User:Supernerd11/common.js and User:Supernerd11/vector.js. --Redrose64 (talk) 15:40, 28 March 2014 (UTC)
Alright. Where do I put it? Supernerd11 :D Firemind ^_^ Pokedex 02:37, 29 March 2014 (UTC)

Template:Non-free review take two

I am reopening this proposal. Note: This is not intended to be canvassing. I just think this would be a useful change. -- Toshio Yamaguchi 21:59, 30 March 2014 (UTC)

I don't like ugly hat notes. How about adding the article temporarily to a hidden category "articles with potentially non-free media" or similar. A bot could automatically remove the tag after some weeks. –Be..anyone (talk) 13:24, 31 March 2014 (UTC)
I personally don't care whether an article is tagged with this template or not (for me the tagging is just one more edit). However, not all editors watching a particular article necessarily have the file pages of the media in the article on their watchlist, so they might not notice that there is a discussion happening on another board that might affect the article. I am not sure people would notice the article being added to a hidden category. But a big, ugly template they most likely do notice. -- Toshio Yamaguchi 09:32, 1 April 2014 (UTC)

A more lightweight approach to mentorship

Hi folks, I just wanted to inform you that there is an Individual Engagement Grant proposal related to creating a new approach mentorship. We intend to review current programs and create a pilot to test a more lightweight approach to mentorship. Feedback is helpful for the grant committee in guiding their decisions, and so if you are interested, we look forward to hearing your feedback on our proposal. Thanks, I, JethroBT drop me a line 21:22, 31 March 2014 (UTC)

Sorry, I've fixed the link. I, JethroBT drop me a line 15:45, 1 April 2014 (UTC)

Removing tags from good merge proposals

A few weeks ago, there was a proposal regarding merges that was ultimately unsuccessful, but did shed some light on the merge process and it's backlog. In that discussion, I commented that there are many 'bad merge proposals', stuff that can be quickly evaluated and closed as 'no consensus'.

As a general note, several editors are actively participating in the merge process, eliminating the backlog at Category:Articles to be merged at roughly twice the rate new mergers are being tagged. However I am growing concerned about good merge requests being closed as no consensus because they are old proposals, but they have had no discussion. This is a behavioural proposal, but I would simply encourage any editor that is contributing in this area to make an objective evaluation of any merge proposal, especially in the absence of any discussion. --NickPenguin(contribs) 21:27, 31 March 2014 (UTC)

Let me preface this by saying that I wish I had the knowledge to program a bot myself to deal with this, but I don't.

Far, far too often I click a link to an old, important discussion that is merely an anchor that was active at that time, but since archived. While I realize that cleaning existing examples of these cases may be difficult to automate, surely it's possible to have a bot work in tandem with the archival bots to update the "What links here" links to point to the archived discussions, no? This is a simple request (again, in my unknowledgeable eyes), but I wasn't quite sure whether to ask here or at the less populated bot request page. - Floydian τ ¢ 05:55, 1 April 2014 (UTC)

Cluebot III already does this I believe, of course it has to be the one actually archiving that particular archive for that to be the case. -DJSasso (talk) 14:58, 1 April 2014 (UTC)

Propose installing extension:variables to allow variables local to a specific page

Tracked in Phabricator
Task T9865
Tracked in Phabricator
Task T65324

Fairly often pages will require repeating certain text, which can be quite long. Repeating such text can be error prone, and can make a page much more difficult to maintain. The extension:variables allows defining local variables, for use later in the same page.

In my use case, the variable would be used in a template to contain the title of the main page it is associated with. This same template is used by several different pages. It uses this text in over 100 sub-templates, for linking to various sections and anchors in the main page.
Note that this template has over 400 edits a month.
Currently editors should type a long title to create valid links, but in fact most editors do not, so that the majority of links in the page are broken.
The extension:Variables would allow typing a much shorter reference to the title, as little as 6 characters if a 2-character variable name is chosen. This would facilitate valid links being created by the many less experienced editors of this page. This would also make the sub-templates much more readable, and thus much easier to maintain.

It would be possible to create a template with the title text, but that comes with disadvantages :
1) If the page referred to is renamed, it will be easier/more evident how to correct the page reference if the name is defined at the top of the template instead of hidden in another template.
2) A local variable name could be made shorter than a template name, which must be made more distinctive in order to minimize name conflicts, which can't occur with a local variable.
3) It would probably be less efficient to search for such a sub-template, than to define a variable in the page where it is used.

So in all, in this case the extension:Variables is the best solution to the problem, which is becoming worse over time.

Note that there are numerous posts on WP of problems which would be solved by such an extension. Lua/Scribunto has been a big plus. Adding the extension:Variables would complement and greatly improve the editing environment of complex pages.

Note also that from a programmer point of view, using a variable local to a page for something that is only used on that page is much cleaner than creating a special template in a remote location to do the same thing. André437 (talk) 07:38, 1 April 2014 (UTC)

See T9865 and T65324. I suspect the latter is you? Anomie⚔ 13:04, 1 April 2014 (UTC)
You're right. I was planning to contact you and other commenters on 7865 and the archives, hoping that your support would help.
A 7-year-old objection that doesn't seem to have been re-examined when both WP and extension:Variables have undergone considerable evolution should be reconsidered.
Note that version 2.0.0 (the current being 2.0.1) was a major re-write. From the changelog, it was altered to make each variable defined independent of others, to solve incompatibility problems with some other extensions. I suspect that this would have solved cache problems that a commenter has mentioned, before the re-write.
In any case, I have a page which would be excellent for testing. It has 100 calls to a module which invokes various templates. It would use only one variable defined by this extension. (Note that an advanced editor recently wrote the module to replace a template, considerably reducing the memory usage after transclusions. This module is used by hundreds of different pages.)
I would be interested in testing extension:Variables on my user page, to compare performance. I expect that the memory usage would be the same. Editing would certainly be much easier. It is not just the replaced text. There are many other elements frequently changed, and with the much more compact text, the page code will be considerably more readable, and thus more maintainable.
BTW, the argument that introducing programming in wiki pages is not desirable isn't coherent. Even the use of transclusions is a (simple) form of programming. This is a minor enhancement, which can greatly simplify certain complex pages. André437 (talk) 18:05, 1 April 2014 (UTC)

A more modest proposal

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

It is time to get rid of the horrendous, gauche, in-your-face, and down-right ugly tags in Wikipedia articles. I propose that all such tags which have been placed and not acted upon within a timely manner (two years is what I propose, but this is open for discussion) be replaced with the following template:

I think such a move will ensure that only the most sincere of editors are placing such tags, and that these would be the core group to actually do something about them (if even at a later date). I further suggest that such a development may finally keep the original taggers in such a state of embarrassment as to force a change in their future tagging behavior. How say you? GenQuest "Talk to Me" 17:36, 1 April 2014 (UTC)

Comment on tags prop 101

  • How will this proposal interact with {{multiple issues}}? Do you think people would delete several of the tags as "duplicates", even though there are (allegedly) multiple problems on the page?
We would replace the {{multiple issues}} with the {{perpetual issues}} tag (still in development) to keep the whiners at bay. Of course, one draw-back is the new issues template currently un-hides all the hidden categories (that problem is being worked on by others). GenQuest "Talk to Me" 22:55, 1 April 2014 (UTC)
  • How would you do this? Bot-changing the wikitext on each page (that's going to flood watchlists) or using code in the templates to display different text based on the date? WhatamIdoing (talk) 22:26, 1 April 2014 (UTC)
Option two would be my favorite, although I'm open. As long as all 2+years old tags are deprecated by this time next year. GenQuest "Talk to Me" 22:55, 1 April 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Page showing user warnings

Hello fellow Wikipedians, I have been with Wikipedia for one month or so and I see a new tool for use by Wikipedians. What if, just like Recent changes, there was a page that would display User warnings on User talk pages. That would allow for people to look at what accounts are prone to misbehavior and make note of that, allowing for more easy detection of vandals. Finally, It would act as a deterrent to vandals as they would know that, if they get a warning, they are being noted of. With the best of hopes, Happy_Attack_Dog "The Wikipedians best friend" (talk) 20:02, 19 March 2014 (UTC)

No All this does is to empower WikiCops in their never ending hunt for "People Doing Bad Things" thereby destroying the assumption of good faith of others and the great pillar Civility. Hasteur (talk) 15:31, 24 March 2014 (UTC)

Or maybe an option to show if a user has gotten warnings so that you could see in the blink of an eye who has had a history of bad editing, Although this could not help AGF... ...I feel it would be a good tool to use, and a hard tool to abuse. Happy Attack Dog (you rang?) 16:14, 25 March 2014 (UTC)

As if New Accounts and IPs and Redlink Userpage Accounts aren't already subjected to "special scrutiny." AGF is for interpersonal editing relationships. Problematic accounts are already flagged, this seems a sensible additional class of "specially watched" accounts. Carrite (talk) 01:00, 4 April 2014 (UTC)

Main Page

Even though a lot of people seem to talk about it everywhere, The Main Page for Wikipedia has not been created. Why not? Simply south...... discombobulating confusing ideas for just 8 years 12:53, 1 April 2014 (UTC)

IDK, what's it about? K6ka (talk | contribs) 15:47, 1 April 2014 (UTC)
I have no sense of humour at all and will point out the The Main Page has been created and deleted three times. The main page on the other hand does exist but I can't seem to get at it. CambridgeBayWeather (talk) 05:24, 2 April 2014 (UTC)
It's a redirect, accessible here. You just need to add "?redirect=no" (or "&redirect=no") to the end of the URL to stop it from redirecting you. K6ka (talk | contribs) 11:40, 3 April 2014 (UTC)
To clarify the last sentence: use a query only if there isn't already a query in the URL; otherwise use an ampersand. --Redrose64 (talk) 11:56, 3 April 2014 (UTC)

There has been a major change in Commons policy regarding a particular type of copyright on files (mostly images). Due to URAA restoration, many non-US images which were in copyright in their source countries (but not in the US) in 1996 were automatically given US copyright. Even after these images have fallen out of copyright in their source countries they remain in copyright in the US and will stay so for very many years. Commons and Wikipedia have not been allowing such images to be hosted. However, with the acceptance of the Wikimedia Foundation (even with its encouragement?[2]), this policy has been largely reversed. See the WMF statement here and especially a recent deliberate change and also the Commons discussion at Commons:Massive_restoration_of_deleted_images_by_the_URAA.

Following this new policy, Commons will no longer delete images solely on the grounds that their copyright was restored by URAA – see Commons:Template:Not-PD-US-URAA. Because Commons requires images to be out of copyright both in the source country and in the US, whereas ENWP only observes US copyright, it will probably be appropriate for us to follow the Commons in allowing these images. If we do not, images not allowed here could be legitimately and successfully moved to Commons.

However, because of legal complexity, Commons are not intending to mass undelete images but will allow individual undeletion discussions. This is a also a matter of policy, not one of law or WMF policy. WMF will continue to delete following appropriate DMCA takedown requests. Thincat (talk) 18:05, 2 April 2014 (UTC)

Discussion (URAA)

  • I suggest we should adopt the same policies of (1) no longer deleting files solely on grounds of URAA copyright restoration in the US and (2) allowing files previously deleted to be made available again following a successful request for undeletion. Thincat (talk) 18:05, 2 April 2014 (UTC)
  • Seems reasonable - if commons is taking that practice, there's no reason we should not either, and assuming (as I read that discussion) this is a blessed action by the WMF, we should be good. --MASEM (t) 18:08, 2 April 2014 (UTC)
    • Very pleased about the Commons decision. First I knew of it was when a self-deletion request I made for this image File:Sir (Leslie) Patrick Abercrombie - NPG x82059.jpg I uploaded without at first realising it was ineligible for URAA reasons in fact got kept (a pleasant surprise indeed). But I need some guidance on what is envisaged here. Does it mean for example that all the fair-use images of Charlotte Salomon's works (who work came into PD in the EU beginning of the year) can now be transferred to Commons (and in high resolution versions, of which I have several). What I thought was so extraordinary about that affair is that in Wikipedia projects which presumably haven't formulated non-free content exemption doctrine policies (I'm thinking in particular of Germany, France and the Netherlands, the countries most closely associated with Charlotte), her work still couldn't be illustrated even though it was PD in their countries, a strange lacuna I raised with Masem at the time. I shall happily transfer the files if I can get the go ahead. Coat of Many Colours (talk) 20:06, 2 April 2014 (UTC)
      • Well, Commons will continue to refuse non-free (fair use) images. However, an image that is PD in the EU but URAA-restored in the US could only be hosted here under a non-free use claim. Now it should normally be possible to host it on Commons (and hopefully here) with no claim. Hence the WP:NFCC criteria will be irrelevant for this sort of image. I say "normally" because I think Commons will still delete when there is a strong case that an image is definitely under US copyright under URAA restoration (apparently this is rarely clear cut). Also WMF will delete if a reasonable takedown request is made on URAA grounds. Thincat (talk) 20:17, 2 April 2014 (UTC)
  • We should be consistent with commons on this issue. So therefore allow WP:Refund requests to be honoured for such images (although probably move to commons if they have educational value). Also update the deletion rules. Graeme Bartlett (talk) 21:26, 2 April 2014 (UTC)
  • 'Bout freakin' time! - Wholly support, though I may be one of the catalysts behind that drive on Commons. - Floydian τ ¢ 21:46, 2 April 2014 (UTC)
  • Obvious support, but undeletion discussions/requests should should each be considered individually and not blindly reinstated simply because they fall into this category. There very well may have been other reasons to delete the image. TLSuda (talk) 14:10, 3 April 2014 (UTC)
  • Support, and I am pleasantly surprised to see the foundation standing against copyright paranoia. Resolute 14:15, 3 April 2014 (UTC)
  • Comment. We should be careful to avoid any statement that we or the WMF intend to ignore or defy copyright law. There are good organizations that do so, and merit our individual approval, but the purpose of Wikipedia is to collect what we can safely and stably. As I understand, the issue is not that we intend to defy the URAA but only that some evidence might be needed to know that something is subject to it. Therefore, we should not perform automatic deletions of such content. We also should not delete or discourage Fair Use rationales from the files; we can mark them as superseded, but it is best to keep our fall-back options open. Nobody can predict a copyright court. Wnt (talk) 17:21, 3 April 2014 (UTC)
  • Support consistency with Commons, and no objection to mass undeletions, if that's technically feasible. BMK (talk) 01:04, 4 April 2014 (UTC)
    You realise that this would result in the mass deletion of US only images?16:56, 4 April 2014 (UTC)

Guidelines on music artists' infoboxes?

I'm not sure if this is the right place to ask this, but if it's not, could someone direct me to the proper page to ask this: Are there any guidelines as to what a music artists' infobox should include? Specifically, do these guidelines discuss how specific (or general) the genres in that infobox should be? I'm asking because I have seen examples of both general and specific genres and it seems there is some contradictions as to how specific they should get. Thanks!Twyfan714 (talk) 14:12, 4 April 2014 (UTC)

Music genres are one of the most annoying things at Wikipedia. No matter what someone puts in the infobox, 50 other people will have 100 other ideas about what to put, and they're all different. People who work in the area try to keep it under control, but it's really hard given the passion with which people hold their positions on what they believe the genre of a music artist to be. If you are interested in working in the field, perhaps Wikipedia:WikiProject Music/Music genres task force would be a good place to work. --Jayron32 14:36, 4 April 2014 (UTC)
Quite agree. Another problem is that (with some editors) a "reliable" (i.e. non-blog) source, even in a non-English language publication, will trump what apopears to be a perfectly reasonable genre that is pervasive in the informal music world. Then there is the problem of overlap of "genre" vs "style" - apparently iTunes can't be used as WP:RS. You'd find Pink Floyd under "rock" in a music store, but it would seem to be overly restrictive to limit that band to this one single "top level" genre. Then there's the problem of the monopoly that AllMusic seems to have here... etc. etc. Martinevans123 (talk) 14:50, 4 April 2014 (UTC)
I agree that these genre wars are annoying and its something that needs to be addressed. I have brought this up with Wikipedia:WikiProject Music/Music genres task force. You can weigh in here. Twyfan714 (talk) 18:05, 4 April 2014 (UTC)
As info boxes are supposed to summarize what is in the article, it shouldn't be such a problem. If the genre(s) mentioned in the article has/have been RS'd, then it can be included in the music infobox. If not, it is subject to removal. Same with all the other infobox entries. This holds for any infobox, by the way, not just music. GenQuest "Talk to Me" 18:41, 4 April 2014 (UTC)
Oh jeez, genres in infoboxes. This is has been discussed at Wikiproject Music a couple times. Wikipedia talk:WikiProject Music#Genre in the infobox recently, and then back to Wikipedia talk:WikiProject Music/Archive 9 in 2008. My take on all that is most people oppose having genre in the infobox (although its not an overwhelming majority) but for various reasons nobody has put together the right combination of moves to pull the trigger on that. A properly worded and structured RfC, bringing in the voices of those other discussions, might do the trick.
People who oppose infoxes have two main reasons: 1) leads to sterile conflict over whether a band should be characterized as "Post-neopunk Trashcore" or "Speed Metalcore/Deathpunk" and so forth, and/or 2) inherently oversimplifies. In addition it's surprisingly hard to get good refs in a clear preponderance because people who write about music aren't necessarily going to clearly assign an artist to a particular genre.
People who support infoboxes have some variety of reasons. Some of those support a limited-list type paradigm (e.g., only X approved genres -- "jazz", "folk", "rock", etc. to be allowed) and since this is probably inherently unpassable and unworkable (see for instance the above links plus Template talk:Infobox musical artist/Archive 12#Proposal to revamp the genre field) some could be brought over to the no-inbox side, maybe. Herostratus (talk) 21:07, 4 April 2014 (UTC)
Oh, God, tell me about it. I have tried doing this on several famous rock bands' talk pages, and the results have been mixed. In particular I got into a LONG and ultimately futile debate with one user over whether to simplify Pink Floyd's genre to Rock in the infobox. In the end, it did nothing but waste valuable time for both of us. Ideally, I would LOVE to have these things removed as, while they may be beneficial to the reader, they are nothing but a massive headache for editors. Twyfan714 (talk) 22:12, 4 April 2014 (UTC)

Make "Citation Needed" tags less prominent

NOT DONE
This suggestion is problematic, for a number of reasons that are outlined in the comments below. — Scott • talk 16:55, 5 April 2014 (UTC)

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

It may just be me, but I find the [Citation Needed] tags rather obtrusive. I think it would better if just the initials were used, as in [C.N.]. Zacwill16 (talk) 16:10, 28 March 2014 (UTC)

Oppose - I would actually prefer them to be far more in-your-face to the point of being blatantly offensive to the eye, just short of inducing migraine ;) - then maybe they won't be ignored so much. Roger (Dodger67) (talk) 16:16, 28 March 2014 (UTC)
Oppose - I might be open to a retuning of them, but abbreviating them will only lead to some readers being confused as to their meaning. Granted some readers are already confused, but let's not compound the issue. DonIago (talk) 16:26, 28 March 2014 (UTC)
The purpose of the {{citation needed}} tags is to point out that there's potentially wrong material that needs backing up. With just a [C.N.], a lot of readers won't know what they mean. I don't know if an in-your-face tag would be good (although if we could somehow do it without disrupting the reading too much, then it might be fine), but our spelled-out superscript is the best I can think of. Supernerd11 :D Firemind ^_^ Pokedex 16:27, 28 March 2014 (UTC)
When one hovers over the tag, a box of text appears explaining the purpose of it. This could be modified slightly to also clarify that "C.N." is short for "citation needed". Zacwill16 (talk) 16:34, 28 March 2014 (UTC)
We want to make sure that they can see right off the bat whether what they're reading is truly factual or not. Making it be a mouseover doesn't do that very good. Supernerd11 :D Firemind ^_^ Pokedex 16:57, 28 March 2014 (UTC)
Agree with Supernerd11. Also, if the [citation needed] tag blends into the text, the uncited statement may go undetected for years. At least if it stays as is, then the statement has a higher chance of being sourced. So, I oppose this. Epicgenius (talk) 12:50, 4 April 2014 (UTC)
Oppose Non-cited statements often hang around for years before someone either 1.) supports the statement by rustling up a ref, or 2.) removes the statement/content all together. An argument for larger, not smaller, it seems.
And, since they are currently ignored en masse, I think asking one to be hovered over before any action is taken is asking too much for the average editor. I think they are just fine as they currently are. GenQuest "Talk to Me" 16:40, 28 March 2014 (UTC)
Oppose the fact that an article contains info that is not verified needs to be obtrusive.--Cube lurker (talk) 16:45, 28 March 2014 (UTC)
Oppose This is a perennial proposal, and was last discussed on the template's talk page at Template talk:Citation needed/Archive 11#Abbreviating the template. --Redrose64 (talk) 17:58, 28 March 2014 (UTC)
If this is as you claim a "perennial proposal" perhaps it should be added to Wikipedia:Perennial Proposals which I made sure to double check before posting here. Zacwill16 (talk) 18:08, 28 March 2014 (UTC)
Oppose [C.N.] could be mistaken for an actual citation, which is the opposite of what the tag should convey. — HHHIPPO 22:01, 28 March 2014 (UTC)
Support – compared with the similar and shorter "who?", "which?", etc. "citation needed" is really too long and no question, but "C.N." is only shorter, not better. Suggest a question, please, e.g., "source?". –Be..anyone (talk) 13:13, 31 March 2014 (UTC)
{{who}} and {{which}} are mostly about being specific rather than citing. Paradoctor (talk) 17:33, 4 April 2014 (UTC)
Support - No need for the interruption of the reader's flow, any more than with any of the equivalent tags. "Please cite", "Cite?", or whatever would work as well. BMK (talk) 01:07, 4 April 2014 (UTC)
I kind of like these alternatives from BMK. WhatamIdoing (talk) 17:11, 4 April 2014 (UTC)
 Comment: Isn't the point of the {{citation needed}} tags so that the page gets the attention that it needs? The tag is supposed to be like that so you can actually fix it, not so you could leave it there indefinitely. (Not sure if I can vote here as an IP user, though...) 50.14.142.33 (talk) 03:52, 4 April 2014 (UTC)
Anyone with a good idea is welcome in these discussions. WhatamIdoing (talk) 17:11, 4 April 2014 (UTC)
leaning Oppose - could be "cite needed" I suppose, but anything shorter might lead to it being misinterpreted. And we need to prioritise fixing them. And if casual readers discover they can fix them all the better. Cas Liber (talk · contribs) 04:31, 4 April 2014 (UTC)
Oppose Readers need to know that the information is un-cited, so they know that the info is unreliable. Acalycine(talk/contribs) 06:40, 4 April 2014 (UTC)
I believe that our readers are smart enough to determine that no citation is present without a little sign next to it saying "Look! There's no citation here!". Additionally, "uncited" and "unreliable" are almost unrelated concepts. At any given point in time, Wikipedia contains seriously inaccurate information that is cited, and never-cited information that is wholly reliable. WhatamIdoing (talk) 17:11, 4 April 2014 (UTC)
A {{cn}} informs the reader that the tagged text has been challenged, which is different from merely uncited. "Reliable" requires some means of verification, otherwise we're talking about claims instead of information.
Oppose The tag is hardly obtrusive, and the proposed initialism would be jargon cruft. Paradoctor (talk) 17:33, 4 April 2014 (UTC)
Oppose The tags are meant to be somewhat distracting. This is so that people are more motivated to fix them. If they are abbreviated, people will be less likely to edit them. Twyfan714 (talk) 18:01, 4 April 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There should be a "Good List" article class

Wikipedia has many high quality list articles that are useful and informative that do not get the attention they deserve because our quality classification scheme lacks an equivalent to the Good Article for lists. To remedy this I propose the creation of a Good List article class. The current criteria for the Featured Article class excludes important and beneficial content because some subjects, by their nature, do not lend well to these standards. Featured articles are required to be comprehensive, yet many useful lists may never satisfy this criterion. Some could satisfy it, but are difficult to evaluate because of the lack of a canonical list to compare the article to or the subject's obscurity. Further, many quality lists are excluded due to informal Featured Article criteria like the requirement that the majority of linked entries have an article, even though the list itself is useful in a stand-alone way. As such, I propose that a list which can meet the following criteria deserves to be considered a "Good List":

Proposed Good List criteria Current Featured List criteria Justification for differences

Well-written

Verifiable with no original research

Prose. It features professional standards of writing.

I propose that Good Lists be held to the same standard of prose and verifiability that Good Articles are, but less than Featured Lists are. The criteria proposed in the first column for Good Lists is taken word-for-word from our Good Article criteria. The designation of Good Content demands quality writing, but not necessarily the unimpeachable professional standards of Featured Content.

Lead. It has an engaging lead that introduces the subject and defines the scope and inclusion criteria.

Lead. It has an engaging lead that introduces the subject and defines the scope and inclusion criteria.

Here I propose identical standards betwen Good Lists and Featured Lists. For a list to be effective enough to warrant the designation of Good Content, it must have a quality lead that introduces the subject, scope, and inclusion criteria.

No conspicuous omissions.

  • (a) The list lacks conspicuous omissions but may not be completely comprehensive.
  • (b) In length and/or topic, it meets all of the requirements for stand-alone lists; does not violate the content-forking guideline, does not largely duplicate material from another article, and could not reasonably be included as part of a related article.
    		•  Comprehensiveness.
    • (a) It comprehensively covers the defined scope, providing at least all of the major items and, where practical, a complete set of items; where appropriate, it has annotations that provide useful and appropriate information about the items.
    • (b) In length and/or topic, it meets all of the requirements for stand-alone lists; does not violate the content-forking guideline, does not largely duplicate material from another article, and could not reasonably be included as part of a related article.

    A list can still be useful and informative even if it hasn't been verified as 100% complete. The current FA criteria exclude many such lists because the obscurity of the subject matters makes their comprehensiveness difficult to verify or because the dynamic nature of the list makes true completeness impossible. My proposed Good List criteria allows these under-appreciated articles to get the recognition they deserve by allowing more leeway regarding the comprehensiveness of the list while still demanding the quality expected of quality content on Wikipedia.

    Structure. It is easy to navigate and includes, where helpful, section headings and table sort facilities.

    Structure. It is easy to navigate and includes, where helpful, section headings and table sort facilities.

    My proposed structural criteria for a Good List is identical to that of a Featured List because effective organization and navigation are bare minimums for a quality list.

  • Style. It complies with the Manual of Style and its supplementary pages.
    		•
  • Style. It complies with the Manual of Style and its supplementary pages.
    		•

    I expect a Good List to meet the same standards of stylistic quality as a Featured List because of how essential this is for the presentation of a quality article.

    Stability. It is not the subject of ongoing edit wars and its content does not change significantly from day to day, except in response to the featured list process.

    Stability. It is not the subject of ongoing edit wars and its content does not change significantly from day to day, except in response to the featured list process.

    The proposed criterion for Good List stability is identical to that of Featured Lists. Articles undergoing major revisions or subject to edit wars do not deserve to be considered Good Content.

    Linked entries: A list which satisfies all other criteria may be considered Good even if most or all of its linked entries do not lead to articles so long as the list is useful in a stand-alone way.

    Linked entries (unofficial): A Featured List must have most of its linked entries lead to pre-existing articles.

    There is an informal, unwritten rule that for a list to be Featured, a substantial majority of its linked entries must be to pre-existing articles. I recognize the value in this criterion for highlighting the very best lists Wikipedia has to offer, but many lists on Wikipedia are of high enough quality to deserve recognition because the list itself is useful whether or not the entries composing it have separate articles. Therefore, I propose that Good List nominations be considered solely on their own merits without concern for the existence of separate articles on individual entries therein.

    Abyssal (talk) 22:37, 28 March 2014 (UTC)

    Discussion

    • Have added a subheading so we don't have to wade through the text.
    • Support I have always found it strange that we go straight to the centralised FL process. This could be integrated as a category under GA. --LT910001 (talk) 03:23, 30 March 2014 (UTC)
    • Support Lists are the underdog class of articles, and they don't get the attention of recognition they deserve. This additional classification would help a great deal in distinguishing between something like List of hospitals in Quebec City, and something like List of mathematical symbols. Certainly one list is of higher quality than the other, and we should be able to classify them as such. --NickPenguin(contribs) 15:17, 30 March 2014 (UTC)
    • Support—the proposed criteria make sense. Imzadi 1979 → 02:47, 31 March 2014 (UTC)
    • Strong support, very well thought out. bd2412 T 13:58, 31 March 2014 (UTC)
    • Support the idea and the proposed criteria. De728631 (talk) 14:03, 31 March 2014 (UTC)
    • Oppose. Certainly a well thought out proposal, however I find the idea of separate good and featured lists to be rather redundant. In truth, most featured lists are really short GAs with a table. There isn't enough of a distinction between the two concepts to warrant another review process. In fact, this proposal essentially admits to this by using identical criteria in five of seven categories. The focuse seems to be on the need for dynamic lists to be eligible for something, and I think it might be better to look at how such lists could fit into the existing FL criteria where appropriate. Likewise for lists with many redlinked entries, I think that is better handled by looking at existing FL criteria. If several entries are non-notable, then the links should be removed (as done in this FL), or if we reasonably believe that articles can be created, I would support allowing the list to stand as is. After all, it is not a deficiency of the list if articles on notable topics do not yet exist. Resolute 14:13, 31 March 2014 (UTC)
      • The need that this addresses is something to distinguish the large number of really poor-quality lists from those that are actually pretty good, but fall short of the very high bar for featured lists. bd2412 T 14:42, 31 March 2014 (UTC)
        • That would argue for more project-level categorization then. Perhaps start-class lists and B-class lists. My concern is primarily with redundancy in reviewed processes. Resolute 15:00, 31 March 2014 (UTC)
          • Could the current GA process integrate a GL evaluation into their operation? --NickPenguin(contribs) 17:40, 31 March 2014 (UTC)
            • I like Nick's solution. Why couldn't we just use the current Good Article machinery already in place? Really I don't understand why our list and regular article rankings are even different. Resolute raises a good point by asking why there aren't "stub" or "B" class articles. If I had my way, there would be a full parallel scale from stub to FL for lists, but I was only thinking about the quality content when I wrote the proposal. Abyssal (talk) 14:34, 1 April 2014 (UTC)
    • I kind of like the idea. It could be like WP:Featured lists, ones that don't quite meet "featured" standards. (Of course, we can also have "good" media, "good" topics, etc.) 50.14.142.33 (talk) 03:54, 4 April 2014 (UTC)
    • Strongly Oppose As Wikipedia slowly turns into the on-line equivalent to The Book of Lists, I oppose anything that may encourage more list generation. GenQuest "Talk to Me" 18:51, 4 April 2014 (UTC)
    • Oppose in favor of NickPenguin's solution. Sven Manguard Wha? 22:42, 4 April 2014 (UTC)
    I don't understand how Nick Penguin's solution constitutes an "oppose". Abyssal (talk) 02:23, 5 April 2014 (UTC)

    A modest proposal

    Hi, Rich Farmbrough here. Since my return I have noticed that Wikipedia has got bigger and bigger, and more and more confusing. There are some simple things we can do to fix this, and numbers are the key.

    Firstly we can save space by using numbers for common words, this will take some getting used to so we should start immediately, letting 1=the, 2=be, 3=to, 4=of, 5=and until we get used 3 1 new system. Clearly we will have 3 spell out one, two, three, but that's a small cost.

    Secondly we can replace ideas with numbers which are more precise. So using 1 ISBN number 4 a book, 4 1 IP address 4 a web site. Wait I hear you cry! Wikipedia has 1 same IP address as other projects 4 1 WMF. So we can clarify with 1 Alexa rank 5 1 ISO639 code converted numerically for the language. Thus (5)-0514-91.198.174.192. Other ideas will 0ccur 3 readers 15 time goes 0225.

    Eventually 1 (5)-0514-91.198.174.192. will ∀ purpose 2 << size 5 >> clarity(1) <- (sense disambig from Wiktionary) We can even use (5)-0514-91.198.174.192 revision ids for any 601561709. 4 598676834 601789833 15 602277090#10

    1037 2014-04-01:15:32Z0

    Double Plus Un-Good Attempt to good-rectify wikilang ref minitrue should crimestop most badthink. Hasteur (talk) 15:49, 1 April 2014 (UTC)
    Swift thinking. We could round off pi as well. --  Gadget850 talk 16:56, 1 April 2014 (UTC)
    Right. Would "3" be close enough ? :) André437 (talk) 17:37, 5 April 2014 (UTC)
    'The Egyptians used 3 in ancient times, and did things we still can't duplicate.
    Rags (talk) 23:05, 6 April 2014 (UTC)

    Serif in headings???

    According to my knowledge of typography, serifs are better suited to prose as they lead the eye. On the other hand, sans-serif fonts are preffered, where increased reading attention and precision is desirable. Taking that into account, I would expect Wikipedia to display all in serif or all in sans-serif. A combination of prose in serif and headings in sans-serif also makes sense. The recent change making it the other way around looks quite odd to me. Has there been any discussion on this? — Petr Matas 10:28, 4 April 2014 (UTC)

    See WP:VPT#Font size and style. Johnuniq (talk) 10:43, 4 April 2014 (UTC)
    And mw:Typography refresh. --  Gadget850 talk 10:45, 4 April 2014 (UTC)
    It's atypical to combine sans serif text with serif headings in printed materials, but there's considerable precedent for it on the web, where typographical details are obscured by the low resolution. If it bothers you, try using Monobook. (I do, although not for that reason.) Rivertorch (talk) 14:28, 4 April 2014 (UTC)
    • And I will add that if the new "look" bugs you, switch your skin to Cologne Blue, which looks far better than either the old or new "default" page look... Carrite (talk) 16:39, 6 April 2014 (UTC)

    WP mobile

    Not sure f this is the right place, but the mobile site doesn't offer the best convenience. For example its hard to read the backpages of WP via simple clikc-throughs like the regular site. Lihaas (talk) 22:34, 6 April 2014 (UTC)

    This is gradually improving. The mobile development team is gradually exposing the functionality to make sure that the website works as optimally as possible. Some of the functionality may currently be unreachable, because it has not yet been optimized for mobile yet. This is a multiyear process. —TheDJ (talk • contribs) 22:39, 6 April 2014 (UTC)

    Bot blank and template really, really, really old IP talk pages.

    I have been doing this manually for several years now, but it is a big and tiresome task. Basically, I propose that we hire a bot to replace all content on IP talk pages with an {{OW}} tag if:

    1. No edits have been made by the IP within the last seven years; and
    2. The IP is not been blocked within the last five years.

    In other words, any IP talk page for which the IP has made no edits since early 2007, despite being able to edit for most of that time, should have no content but the {{OW}} tag. Examples of typical pages that would be blanked/tagged under this proposal are:

    Note that even the shortest of these pages links to the article for the message was generated, three different Wikipedia policy pages, and both the user page and talk page of the editor who left the note, all to no end. bd2412 T 16:08, 27 March 2014 (UTC)

    Naive as I may be, my I ask why? If the IP isn't editing then nobody's going to come along and complain about the length because they'd have no reason to be there anyway. KonveyorBelt 16:25, 27 March 2014 (UTC)
    I started doing this because I do a lot of disambiguation fixing, and would like to be able to see the contents of the "What links here" page without scrolling through several screens worth of ancient IP talk page warnings to do so (note that limiting the namespace is not helpful for this purpose, as disambig links can be problematic in article, portal, template, category, file, book, and now draft spaces). In other words, these links are not helping anything, and can get in the way. bd2412 T 16:34, 27 March 2014 (UTC)
    Let's see: an existing process is providing no benefit (because the IPs haven't been used for editing in forever), and it's causing problems for someone trying to solve a real problem (dealing with disambiguation problems). I support making work less pointlessly complicated for our dabsolvers. In fact, I think this proposal is quite restrained: no edits or blocks within the last three or four years would be plenty good enough as far as I'm concerned. WhatamIdoing (talk) 16:56, 27 March 2014 (UTC)
    This is definitely a good idea. Trivial historic clutter impedes the utility of our link indexes. I agree with you that the proposed cut-offs are very conservative, as well. — Scott • talk 18:41, 27 March 2014 (UTC)
    I see no reason not to support this. It doesn't do any harm, and would make work easier for DAB fixers. Novusuna talk 17:13, 27 March 2014 (UTC)
    Support proposal as long over-due. Five year limits would be even better. GenQuest "Talk to Me" 21:08, 27 March 2014 (UTC)
    +1 – seven years is actually rather long. Before I accidentally used my commons account here I edited with o2-DE IPs in 2013, and months would be good enough for that. Both IP ranges of this mobile wannabe-broadband ISP were blocked for some weeks before christmas, and some issues reported on "my" (IP) talk pages were years old—maybe even back to times when another ISP held these IP ranges. –Be..anyone (talk) 06:09, 28 March 2014 (UTC)
    Correction, looking at 194.202.213.254 after vandalism on SVG months are clearly not good enough, this IP edited Kantar Group for four years. –Be..anyone (talk) 06:22, 28 March 2014 (UTC)
    Although 7 years is a fairly long time, it is a better cutoff than none at all. If we start off with this and find that a tighter cutoff is needed, we can always reign it in at some point in the future. bd2412 T 16:48, 28 March 2014 (UTC)
    BTW, IPv6 would be a different (technically+legally) issue, I assume that this proposal is limited to IPv4. –Be..anyone (talk) 18:02, 31 March 2014 (UTC)
    At the moment, IPv4 are the only kinds of IP talk pages that would fall into the date range, but why would IPv6 raise any other issues? An IP talk page is an IP talk page, as far as I can see. bd2412 T 14:44, 1 April 2014 (UTC)
    • Support. I'd also change it to only five years of not editing, and three years of not being blocked. (IP addresses do change often, you know... so we don't want someone to find that they've been warned of something they didn't do.) Epicgenius (talk) 12:57, 4 April 2014 (UTC)
    • 👍 Like Five years of not editing, and three years of not being blocked would also be fine. Herostratus (talk) 19:29, 4 April 2014 (UTC)
    • Support Worth doing on a user perspective alone, as EpicGenius describes. Good idea to formalise this as a regular bot task. SFB 19:05, 8 April 2014 (UTC)
    • As this is about filtering your search results, wouldn't this suffice?
        var thelist = document.getElementById("mw-whatlinkshere-list").getElementsByTagName("li");
    if (thelist.length<1) return
    var IPpageCounter = 0;
    for (var i=0;i<thelist.length;i++)
        if (thelist[i].firstChild.href.match(/\/wiki\/User_talk:\d+\.\d+\.\d+\.\d+/)) {
            thelist[i].style += "; display:none";
            IPpageCounter++
        }
    var message = document.createElement("p")
    message.setAttribute("id","mwhacked-whatlinkshere-hiddenlinks-IPuser_talk")
    message.setAttribute("style","color:red; font-weight:bold")
    message.setAttribute("onclick",'thelist = document.getElementById("mw-whatlinkshere-list").getElementsByTagName("li"); for (var i=0;i<thelist.length;i++) thelist[i].style += "; display:list-item"; document.getElementById("mwhacked-whatlinkshere-hiddenlinks-IPuser_talk").style+=";display:none"')
    message.appendChild(document.createTextNode(IPpageCounter+" IP user talk pages hidden (click this to show)"))
    thelist[0].parentNode.insertBefore(message.cloneNode(true),thelist[0])
    Works with Greasemonkey, didn't work as Wikipedia user script, will look into it if "forced". Paradoctor (talk) 16:38, 5 April 2014 (UTC)

    Promotional articles

    The sole fact that an article seems promotional shouldn't be enough reason for it to be speedy-deleted. According to Wikipedia:Criteria for speedy deletion, an article can be speedy deleted if there's almost no chance that it would survive a deletion discussion. There's no need for there to be such a rush to delete a promotional article that it should stay deleted for ever even if it would have been possible to find a way to turn it into an eneyclopedic article. I know people are sometimes allowed to recreate a deleted article if it's created in a totally different way but it's not like anyone is going to find every deleted article to recreate it totally differently when there is a way to do it that doesn't violate Wikipedia's policies. Blackbombchu (talk) 20:25, 29 March 2014 (UTC)

    I couldn't find any project page that explains why promotional articles need to be speedy deleted. I could only find ones that state that that's how Wikipedia works. Sometimes people create promotional articles by accident. Blackbombchu (talk) 20:59, 29 March 2014 (UTC)
    Unambiguously promotional articles are speedily deleted because Wikipedia is not a platform for ads. Promotional articles violate the core content policy of keeping a neutral point of view. They very often fail the other two core policies as well, no original research and verifiability. Novusuna talk 21:06, 29 March 2014 (UTC)
    I understand your confusion. It arises largely because what constitutes "unambiguously promotional" has drifted significantly over the years. So consider an article that says something like, "Web Company has the lowest prices and the best customer support for all your computer needs. Web Company was rated #1 in three polls conducted by the company. Phone Saul Salesman at <redacted> and mention code LUVWIKISPAM to get what you need today!"
    Horrid, right? That is definitely not going to survive AFD. There isn't even a single half-sentence that could be retained. That deserves speedy deletion, and that's what the criteria was aimed at.
    But the problem is that people are now deleting things because they provide accurate information about a company that happens to be doing well. We're now deleting pages that say things like Rural Hospital is the largest and oldest healthcare facility within 100 miles of its home in Lake Woebegone, which is located in central Minnesota. In 2010, it won a statewide award for patient satisfaction. The full-service hospital's motto is "Where the Emergency Room Doors Swing Wide Open to Greet You".
    That sort of article is not what the speedy criteria is meant to deal with. The problem is that some people tag that kind of article, because they wrongly believe that "neutral" articles always say exactly the same amount of good and bad things about an article. Also, when they see things being deleted that don't quite meet this criteria, or were deleted sloppily/in violation of the policy, or when they wouldn't have been deleted as promotional, but needed to be speedy-deleted for another reason, then the taggers (rather reasonably) start assuming that the notion of "exclusively promotional" actually means "mostly promotional" or "sorta kinda promotional". When that process has repeated through enough successive "generations" of users, then what's in the policy and supported by the community and what's actually being done by the handful of editors and admins who deal with this can be quite divergent.
    What you can do to help with this is not to change the policy, but to review articles more accurately yourself (try Special:NewPagesFeed and to review tagged articles so that you can remove tags from pages that don't qualify for speedy deletion. WhatamIdoing (talk) 22:01, 29 March 2014 (UTC)
    I can't do that with one I created myself. Blackbombchu (talk) 00:43, 30 March 2014 (UTC)
    Well I restored one of your pages. the one on Service Inspired Restaurants should probably be rewritten with a claim of importance, it certainly was not promotional, but it did fail the A7 criterion. Graeme Bartlett (talk) 11:43, 2 April 2014 (UTC)
    And I deleted it again. Not promotional? The only sources are two "sponsored messages" (i.e. thinly disguised adverts), and the text makes claims like "It's not even necessary for one to diet or exercise to lose weight if one eats Marine D3." (only the exclamation mark is missing to make it completely in your face advertising). We really don't want or need this kind of articles on Wikipedia. Fram (talk) 11:48, 8 April 2014 (UTC)

    Wikidata-centric citations

    I apologise in advance for the length of this.

    As I'm sure many of you know, providing exhaustive citations (via the {{cite *}} templates) thoroughly throughout entire articles (of moderate to large sizes) is not only incredibly time consuming, it also bloats article byte-counts considerably (authors can't scour every line of sizeable articles for citation redundancy, simple things like different page numbers require filling articles with many versions of citations that differ only by one or two characters) and it quickly turns the bibliographies of large articles into horrid messes most readers probably don't bother to grapple with. Roman Empire is a great example of this.

    That's why I like {{sfn}}. Provided with the bare minimum identifiers and page number(s) for references, it automatically generates a readable list of short footnotes which are also automatically condensed condensed upon multiple usage and—most importantly—it only requires the full information of any given publication to be entered once (within properly formatted citation templates which the short footnotes then link to). But, {{sfn}} is still problematic for large articles. Migrating content to subarticles requires finding every reference it contains, copying their full citations to the said subarticle, and then making sure every one of those full citations are still being used by the original article.

    I've been thinking about this issue for a while and I wondered what if a template similar to {{sfn}} were implemented, but:

    • Instead of requiring the author name(s) and publication year, simply took the Wikidata ID for the relevant publication's page at Wikidata
    • Populated the name and publication year portions of the {{reflist}} short footnotes with data pulled from the item's author and publication year properties
    • And, were accompanied by another template which collects the IDs of all the Wikidata based citations used and automatically generates full citations populated with the information from their respective Wikidata pages

    This should be possible with syntax like {{#property:P50|id=Q3107329}} (i.e. {{wikidata value|The Hitchhiker's Guide to the Galaxy|50|Q3107329}}, which in this case returns the author value 'Douglas Adams'). Currently, however, there seems to be a bug that prevents Wikipedia articles from accessing the properties of items which which aren't their sister items at Wikidata. Is there any interest in pushing to fix this bug and develop citations templates something like what I outlined? —Sowlos  06:24, 6 April 2014 (UTC)

    Unless I'm reading this wrong, this would only work with publications that have Wikipedia articles with associated Wikidata entries providing the information to scrape. If I'm correct about that, what percentage of citations do you think this would cover, such that it would be useful to implement? Sure, we have a Wikidata item on Hitchhiker's Guide, but I don't think we do on the vast majority of books (and other items) people cite. For example, look at today's featured article, Battle of Greece. I don't think we have an article on a single one of the numerous books it cites, so if implemented, this would have no utility for it. I think this is true of a rather high percentage of citations.--Fuhghettaboutit (talk) 13:17, 6 April 2014 (UTC)
    Wikidata is not limited to that which has an article in Wikipedia. You can add whatever you want, as long as it is an entity and can be described. The wikidata community might have some limits, but as long as it has an ISBN, it's probably OK. Individual website pages are a different story I'd suspect. —TheDJ (talk • contribs) 22:44, 6 April 2014 (UTC)
    Yes. Wikidata entries are not limited only to items which have Wikipedia articles. (However, their current primary use is providing language independent data for Wikipedia articles which are associated with them.) While Wikidata currently lacks items for most publications cited in the Wikipedias, editors are already required to enter the information for those publications in Wikipedia articles. Centralising where that information is put would eliminate the redundancy of entering the same information in multiple articles (even in multiple locations of single articles), would make it easier for editors to provided exhaustive information for each citation, and would build up Wikidata's catalogue of publications very quickly. Citing the existence of a published book or article is a simple matter. While just proving a book exists may not be enough to write an article about it, that would be enough to justify a Wikidata entry if it supports a Wikipedia article. —Sowlos  05:12, 7 April 2014 (UTC)
    I like the idea of having a centralized database for commonly used citations. It would be handy to take a popular review article, describe it at WikiData, and then have the corrected citation appear at all Wikipedia articles that happen to cite it. But having a dozen, or a hundred, variants of "{{#property:P50|id=Q3107329}}" scattered all over articles is not human-friendly in the least. How would you keep straight which citation supports which thing? We need something human-readable, like {{#property:P50|id=Q3107329|The Hitchhikers' Guide to the Galaxy}}
    You may also want to send e-mail to User:Jdforrester (WMF), who has probably thought about this in some detail, and also the people involved in WP:MED's translation work (which does a lot of cross-wiki porting of citations). Doc James is the obvious first contact for that group. Good luck, WhatamIdoing (talk) 15:53, 7 April 2014 (UTC)
    @Sowlos: Yes, this is something a number of people have expressed interest in us doing, and it's definitely worth talking about. Jdforrester (WMF) (talk) 16:34, 7 April 2014 (UTC)
    Sounds like a great idea. Clearly there needs to be some discussion around what citations we should do this for – this would be a really useful function, but having potentially hundreds of thousands of citation wikidata would skew the database content in a very new direction. SFB 16:42, 7 April 2014 (UTC)
    @WhatamIdoing: Well, the Wikidata inclusion syntax would still need to be wrapped within a template, so the non-human-friendly syntax could be abstracted from in exactly the way you're thinking. If we're using {{Sfn}} as a model of what we want, then we would have something like {{wd cite|Q3107329|The Hitchhikers' Guide to the Galaxy|p=1}} which would internally use inclusion syntax (such as {{#property:P50|id=Q3107329}}) to create the short footnote "Adams 1979, p. 1." for {{reflist}}. As with the already existing {{sfn}}, {{reflist}} would be able to condense any citations which use both the same work and page selection. However, since publication information would be centralized at Wikidata (as opposed to being manually included at the bottom of the article), another template (lets call it {{wd bibliography}}) would use the information already included in the article to identify and pull the data for each publication cited and populate {{cite}} templates accordingly. To simplify things for editors, maybe the bibliography template would transclude {{reflist}} itself, since it always directly precedes the bibliography section in practice, allowing editors to mind only two templates rather than three.
    @Jdforrester (WMF): Thank you for taking the time to read this over. I'm glad I'm not the only one who's thought of this sort of thing (that would be a little shocking actually :p ). I'm making this proposal in the hopes of generating some concrete progress on this front. For me, the current method of providing citations can unfortunately be a dissuading factor in editing articles under certain circumstances. I'm sure a number of other editors have experienced the same. I think anything we can do to make it easy for editors to properly cite articles is a great investment for Wikipedia.
    @Sillyfolkboy: indeed but since Wikidata is intended to support the WikiMedia projects by "[centralizing] access to and management of structured data, such as interwiki references and statistical information," I think this would fall within its mandate. —Sowlos  11:15, 8 April 2014 (UTC)
    @Sowlos: I definitely agree it's a good idea. There is no reason why this should be an "en.Wikipedia" only discussion as in theory we could allow usage across languages. This might be a conversation to start directly at the WikiData project or on this Meta page. Also to note: the project seems a little behind on their delivery timelines as it is so there should be plenty of time to discuss this fully and reach a solid consensus. (I'm quite excited about the potential of moving lists to WikiData as that will significantly change the way I work, but that is still in development!). SFB 18:42, 8 April 2014 (UTC)
    Some years back (actually, 6 years ago -- has it been that long?) at the suggestion of LA2, I tried to create a system to achieve what the OP has proposed. Have a look at {{Ref Ethiopia}}. -- llywrch (talk) 19:50, 10 April 2014 (UTC)

    Capitalisation of bird names

    Can as many folks as possible read the issue at Wikipedia_talk:Manual_of_Style#Bird_common_name_capitalisation. In essence, bird articles are currently capitalised, yet this is not in accordance with wikipedia guidelines so there is a discussion to try and settle this debate that has been ongoing for several years. See options there. Cheers, Cas Liber (talk · contribs) 02:45, 10 April 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)

    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 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)
    • 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)
    • (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)
    • 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)
    • If my window (or at least content-pane) gets narrower than the "Today's featured picture" picture-set itself, the box does not get side-scrolling--annoying, but grudgingly acceptable that a single item too wide to display is not easily remedied. But the text in that box still lays out to the full width of the box, which is still that "wider than my window" width of the image-set, so the text is cropped on the right too--that's a real problem. I'm using firefox-8.0.1, the highest one that appears to support x11 (and therefore remote-display use) on OS X. DMacks (talk) 03:43, 22 March 2014 (UTC)
    The current mainpage (whole page) becomes side-scrolly in this situation, as for other WP articles with content that have some hardcoded minimum-width or long-lines. DMacks (talk) 03:47, 22 March 2014 (UTC)
    I have no control over the content that is transcluded to the main page, so some glitches will always remain (until POTD fixes it). Always check if the same problem occurs on the current main page as well. If so, nothing I can do. — Edokter (talk) — 12:53, 22 March 2014 (UTC)
    Please read what I wrote carefully. I said the main page *does* work correctly, or at least is "as best compensated as possible" for wide content, as compared to actual breakage (the result of the template is mis-handled and made worse) in yours. Your div or whatever box magic needs to enable side-scrolling or grow itself wider if overflowed width for the size of the screen. DMacks (talk) 18:04, 22 March 2014 (UTC)
    I think I fixed that now. — Edokter (talk) — 19:13, 22 March 2014 (UTC)
    Looks fine even on my crappy browser. Thanks. DMacks (talk) 21:56, 22 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)
      My own relatively minor design contributions to WP improved light years by asking for feedback, so this is certainly the right approach, for an important page. André437 (talk) 19:46, 5 April 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)
      I've tried making it as mobile-friendly as possible. If you narrow the screen, all sections should be stacked automatically. (Though I have some trouble making Android behave here; it seems to ignore the @viewport directive.) — Edokter (talk) — 12:33, 12 March 2014 (UTC)
      I think i fixed it using the proper media queries. — Edokter (talk) — 20:59, 12 March 2014 (UTC)
      I don't see why this should be much of a consideration, seeing as there is a mobile-specific Main Page. — Pretzels 13:03, 13 March 2014 (UTC)
    12. Well done! Still a bit bland, but knowing that style and layout are purely subjective matters, it will be nearly impossible to get a consensus on a radial different design. More incremental changes can be built on this design. -- P 1 9 9  ✉ 22:05, 14 March 2014 (UTC)
    13. I love it. Love it, love it, love it. (Did i mention I love it?). Finally a Wikipedia home page that is worthy of the 2010s. Beautifully crafted @Edokter:. Major kudos.--Coin945 (talk) 07:37, 16 March 2014 (UTC)
    14. I'm a fan--it's sleeker, less clunky, and more modern. I especially appreciate the "Be an editor!" area, which will hopefully attract new editors to our project. Well done. –Prototime (talk · contribs) 21:41, 25 March 2014 (UTC)
    15. An overall improvement accessibility-wise and good framework to build on, though from my current view I would give just a little extra space from OTD to the ITN text. Maybe that's personal. SFB 18:13, 1 April 2014 (UTC)
    16. A considerable improvement, especially in adapting to any page width. But like some other comments, I think that 2 sections wide (not counting the left margin) on normal width pages would be better for readability. (I just realized that my usual browser window was a bit too narrow to see any side-by-side sections. Maybe minwidth/maxwidth needs to be reduced a bit on some sections ?)
      The expanded "WIKIPEDIA" and renamed "Be an editor" sections are nice as well. Welcome improvements. André437 (talk) 19:46, 5 April 2014 (UTC)
    17. I like this one would like to see it as the main page. To be an editor feature is a fine inclusion to encourage IPs and stop vandalism to much higher extent. The Herald 14:01, 7 April 2014 (UTC)
    18. A massive improvement on the current layout. Dynamic, interesting, with better use of colour and typefaces. It also includes similar wide/narrow variations to the proposal on Talk:Main page, which could in theory be done first but it makes more sense to do them all at once and resolve bugs and issues in one go, rather than deal with two rounds of testing and discussion.--JohnBlackburnewordsdeeds 01:19, 8 April 2014 (UTC)
    19. This has the potential to be a vast improvement, especially with the new "Be an editor" section and other nice improvements to flexibility. I strongly support a motion to move forward and start working on this further. --Nicereddy (talk) 07:01, 13 April 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)
      [No longer a vote] Only because I don't like the pastel shades. The layout is good, and I like the slightly raised look of the panels. — Scott • talk 14:00, 12 March 2014 (UTC)
      I'm confused as to why you regard this as a reason to cease further development, particularly given Edokter's explanation that style elements (including the colors used) are subject to change in accordance with consensus. —David Levy 15:55, 12 March 2014 (UTC)
      Huh. The question this section is asking has changed since I initially saw it. Should there be further work on this? Sure. I've unnumbered my vote, then. — Scott • talk 16:03, 12 March 2014 (UTC)
      A "no" purely on the grounds of not liking the pastel shades is simply WP:BIKESHEDding. Is there an addressable problem with these shades, such as WP:CONTRAST? --Redrose64 (talk) 15:59, 12 March 2014 (UTC)
      One man's "bike shed" (nice essay - I didn't read it) is another man's "that looks like an old lady's kitchen wallpaper", which I was too polite to say the first time around. HTH! — Scott • talk 16:03, 12 March 2014 (UTC)
      Any color this shade is "pastel". To be honest, I'm stuck here because I'm not one to come up with good colors. I picked them from Help talk:Using colours. Though I'd like to have some color, peprhaps there is an alternative to using background coloring. — Edokter (talk) — 21:06, 12 March 2014 (UTC)
      I've been thinking that we could try coloring the headings instead. But that's a discussion for later. —David Levy 22:17, 12 March 2014 (UTC)
    5. I think it looks nice, and is an improvement visually over what we have now. But I find the proposed design, as well as the current one, too busy or crowded for lack of a better term. I'd prefer something more radically differet, with a somewhat minimalist design. Hot Stop talk-contribs 02:46, 13 March 2014 (UTC)
    6. Oppose - I'm going to start off by saying that I have a tremendous amount of respect for your desire to push through big changes and deliver a new main page. Unfortunately, while I agree that the current main page could use updating, there are a number of problems in this proposal that need fixing, as well as some design choices you made that I can't get behind.

      Visual issues - From a visual standpoint, I have several issues. First, I feel that the top bar (the one with the portals in it) looks visually cluttered. I personally don't feel that the mission statement adds any value (and I dislike the wording). If we're going to put text there though, I would have it start at the height of the "ikipedi", as opposed to the height of the larger W and A. Otherwise it looks stuffed in the top corner. I also don't think that the portals belong in the top section. They look out of place in the current build, and they look out place in this build. I love portals, and I would love to keep links to them, but there's too much going on in that top section, and of the four elements (globe background, wordmark, intro text, and portals), I feel portals are the weakest link. Second, I dislike the shading in the header of each section. The-white-fading-into-box-color thing just looks off to me, as the colors never really match up and my attention is drawn to the line where the colors meet/clash. Third, I feel that we need to lock the bottom matter (in the case of TFA, this is the "Archive – By email – More featured articles..." part) to the bottom of the box, rather than to the end of the text. The way it is now, each section has the bottom matter floating a different amount above the bottom edge of the box. On my screen, there's almost no gap between the bottom of the box and the bottom matter in the "From today's featured article" and "In the news" sections, noticeable gaps in all of the other sections, and a very large gap in the "Today's featured picture" section. Finally, I would find a new place, or evaluate the need for having, the current date and purge button. It's in the bottom of the "On this day" section, a vestige of the current design, and disrupts the visual cohesion without really adding anything. I would advocate that we pull a page from Bulbapedia's main page and put the clock up top (their clock is also a purge button).

      Layout issues - I dislike that the featured pictures section is at the bottom. I realize that everyone has different priorities in terms of what they want placed 'above the fold' (above having to scroll down, in this case), but that's my preference. I feel that kicking it to the bottom is a mistake in the current design, and would love to see the new main page have it above the fold, at least partially, so that people know it's there.

      Process issues - I feel that you took the wrong message (or an incomplete message) from my analysis of the redesign process. You latched onto the 'give the community a binary choice' part, but missed the 'there is a disconnect between what the designers are making and what the community wants' part. The 2012 redesign process, from which this emerged, didn't make an effort to reach out to the community and get an idea as to what we would like to see in a new page. It appears that a dozen designers each, in relative isolation, took the existing pieces and re-skinned them in a visual style they found appealing. Plenty of people want the main page to look "nicer", but there's no real understanding of what the community would view as "nicer", nor is there an understanding of what elements the community wants on the main page. An effort was made in 2011 to collect this information, but it suffered very low turnout, wasn't very focused, and ended up with more "no consensus" results than anything else.

      Accounting for the future - While I feel that the main page redesign needs to be community driven, I think it's also important to speak with Jorm (WMF) and the the other members of the WMF design team so that we can get a feel for what the default interface is going to look like in the future. This design seems catered towards the visual style of Vector, but Winter appears to be the future (and perhaps Athena further into the future), and it's going to change the shape and color scheme of the interface.

      Sorry for the long read, but if we're going to do this, I want to make sure that it's done right, and sometimes that calls for large blocks of text. Sven Manguard Wha? 08:44, 16 March 2014 (UTC)

      I think you completely misunderstood the question as it stands; it says "do you want to build further on this proposal with my framework as a reference design?" You "no" implies you do not want any change at all. Everything you mention are mere details, which are exactly the issues I want to work on in the next step. Again, the design you see is merely an example that is build on the reference design. The underlaying framework allows any layout and styling, but styling is the last thing we should be focussing on.
      I understood your message perfectly, and I am trying to avoid its pifalls. I am also trying to break through the barrier that seems to lock the current main page in a consensus-demanding stasis. I think a small group of people should ultimately be 'in charge' of the main page, just like the various main page projects are in charge of its content. We should not be afraid to make changes and be more dynamic; the is Wikipedia after all. Winter is going to be a few years I guess, so there's no telling how it will integrate now. But this new framework will allow the mian page to adapt to any new default skin that may come. Again, we need to let go of this fear of change, or we will still see this page in 2020. — Edokter (talk) — 12:48, 16 March 2014 (UTC)
      Winter is going to be like, next month, as a beta feature.--Jorm (WMF) (talk) 17:26, 16 March 2014 (UTC)

    Main Page taskforce

    I certainly don't see any objection to move forward, so let's do just that. Let's set up a place were everyone interested can throw around ideas and brainstorm (and not be burdened with RFCs and such). I'd also like to have some delegates from the various main page projects involved, so we can coordinate and improve on interoperability with the main page. Please state your interest below. — Edokter (talk) — 01:32, 16 March 2014 (UTC)

    • I would be interested. My primary desire would be the inclusion of the "Become an editor" type content, and how we could best use this space. --NickPenguin(contribs) 05:43, 16 March 2014 (UTC)
    • For the record, I will join the taskforce, as I'm interested. However, I just want to say: no, there isn't much objection, but I also don't see much support, either. We all agree that we want to see the main page be updated, but there is still not much more than that (that's probably the efforts keep failing); we even have disagreement on the process. (cf. Wikipedia:2014 main page redesign proposal.) In a situation like this, I think it's better to seek a small cosmetic change, and we already have many good design ideas (e.g., Chinese Wikipedia one, which was actually originally from English Wikipedia.) I think it's better to just open a poll on designs, including ones from the past efforts and including your new design proposal. If there is no clear winner, we will run a run-off and so forth. In short, I would like to pass the brainstorm stage. (of course, maybe it's just me.) -- Taku (talk) 17:55, 17 March 2014 (UTC)
      • Competition (with users voting on various proposals to select a winner) is the one main page redesign method that's failed consistently (including in 2006, when it nearly derailed the entire endeavor). Collaboration is the only way forward.
        You keep mentioning the Chinese Wikipedia's main page, which I haven't seen anyone else cite as a desirable model. Perhaps you can explain why you believe that it "has the best chance of the community support". —David Levy 21:10, 17 March 2014 (UTC)
      • The last thing I want is process, polls, competitions, and most of all, deadlines! There is no policy that dictates how the main page should be maintained. My feeling is we should treat it like any ohter page; as a collaborative effort. Look at how MediaWiki is doing it. Community size should not matter. We lay down the basis and adjust anything that comes up. That should result in a page that conatains the best from all other designs combined. I will be setting up a workspace soon, and then we can get to work. — Edokter (talk) — 21:37, 17 March 2014 (UTC)
        • if that last bit is the case, then as I've said before, you should implement the current main page exactly as it is using your new, easier to modify framework. Once that has acceptance, and it is easier to modify the layout and such, then we can begin to propose incremental changes. In my mind, there is no other way forward, you will continuously cone up against a yes/no ultimatum and the answer will always come up no. --NickPenguin(contribs) 23:02, 17 March 2014 (UTC)
          • Exactly. I can't see any reasonable opposition to just making the background coding more sensible, in a way that people who don't understand code won't even notice. You just need to get an appropriately empowered admin to do it, frankly. Anything beyond that, you maybe need a small group of people who care enough, and a friendly admin, while being open to input from passers by and people on the Main Page talk page. Collaborative editing doesn't mean discussing and voting on everything before doing anything: it can mean just changing something and seeing how people react. 86.157.148.65 (talk) 19:52, 18 March 2014 (UTC)

    Proposal to implement the current Main Page using Edokter's framework

    What we have here is two conflicting desires: the desire to update the 'look and feel' and the desire to update the underlying framework; I think we need to focus on the latter before the former. As I have observed over the last two years, proposals to add or remove content have generally failed because of structural issues, especially achieving visual balance. Tables are very rigid and unfriendly to modifications. Conversely, @Edokter: has a solid design which can be easily modified to achieve balance, and it opens up a huge range of styling possibilities.

    If it is the case that this design is more capable of modification, then it would seem the best way to move forward is to reimplement the page exactly as it appears now (or as close as possible), using his new framework. Then, other visual improvements can be discussed and made through consensus with a smaller, more focused group. --NickPenguin(contribs) 01:54, 20 March 2014 (UTC)

    Indeed, I would like to see the main page's current layout (or an approximation thereof) with Edokter's framework.
    Next to the ill-conceived competitions, the greatest obstacle to successfully redesigning the main page probably has been the implementation of too many ideas at the same time. At the moment, this comes across as a package deal, which tends to evoke opposition from users who dislike some of the changes and oppose the entire proposal (including changes that they like). I agree that an under-the-hood overhaul would demonstrate that this isn't an all-or-nothing proposition, allowing us to discuss additional improvements more easily. —David Levy 21:38, 21 March 2014 (UTC)
    I don't know if I can present the main page exactly as it is now (nor if I want to). Also, having two divs stacked is something I have not considered yet, but I'm sure willing to try (unless you want to have two section share a div, as they share a table now). — Edokter (talk) — 22:02, 21 March 2014 (UTC)
    @Edokter: Yeah, I wouldn't expect such an implementation to look exactly like the current main page. I don't know what coding approach would be best, so I'll gladly defer to you on that point. The goal, I think, is to approximate the current design in whatever manner best preserves the technical advantages that you've mentioned. It should be relatively easy to achieve clear consensus for that type of improvement, at which point we could discuss other changes without placing it in jeopardy. —David Levy 00:26, 22 March 2014 (UTC)
    I can try to lend a hand at approximating the current Main Page design. If that becomes the current plan. --NickPenguin(contribs) 03:27, 22 March 2014 (UTC)
    I think I have the structure laid out, see here. I have not got around to styling yet, so whatever you do, don't click here. :) — Edokter (talk) — 13:54, 22 March 2014 (UTC)
    Do you object if I poke around in your workspace and try to make them look closer to the current Main Page? --NickPenguin(contribs) 14:48, 22 March 2014 (UTC)
    Not at all. I'm done playing for the moment. — Edokter (talk) — 16:04, 22 March 2014 (UTC)
    I tweaked it, and everything looks the same except for two things: the headings on the sections on the new version are just slightly bigger, and the spaces between the sections are bigger too. Not sure how to fix those two things... Other than that it looks the same on my screen. --NickPenguin(contribs) 05:51, 23 March 2014 (UTC)
    I fixed most of it. Just for fun, I'd like to see if anyone can spot the difference, but, IF this is going to be on the main page, I will have to insist that the top banner and sister links are also made fluid. Otherwise, having only the main sections have adaptive behaviour is not much use at all. ~~
    It renders extremely similar on my laptop, not identical, but very close. However on my phone, it appears different; TFA and ITN are stacked instead of side by side, same with DYK and OTD. Also, the extra space on the right hand of each section is filled with empty coloured space. --NickPenguin(contribs) 19:03, 24 March 2014 (UTC)
    Actually, the reason its doing that it because the text in TFP it to the right of the image instead of below, and the pictures and lower script in the other boxes are all justify right. Could this be fixed by making the text in TFP fluid? --NickPenguin(contribs) 03:55, 25 March 2014 (UTC)
    The stacking is intended. As I said before; I have no control over the content being transcluded. POTD is encapsulated in a table and its layout is dependent on the image size and orientation. — Edokter (talk) — 13:13, 25 March 2014 (UTC)
    Fair enough, that could be one thing that mentioned when the final version goes before a community wide vote, probably on Talk:Main Page and advertised on WP:CENT. Is there any more work to do? It looks pretty identical to me at this point, aside from some functional differenced that would need to be addressed with transcluded templates. Maybe @David Levy: could chime in here? --NickPenguin(contribs) 15:18, 25 March 2014 (UTC)
    I'm seeing a slightly narrower left-hand column and slightly wider right-hand column, along with a bit of extra space below TFA and ITN. Otherwise, the differences seem negligible (apart from the equal division of a column's extra space between its two sections, which is an improvement). Excellent work. —David Levy 19:18, 25 March 2014 (UTC)
    It looks the same, but uses my framework. The banner is still not fluid though. Perhaps that should be the first item to improve? — Edokter (talk) — 23:05, 25 March 2014 (UTC)
    Well if it is the case that this version is virtually indistinguishable from the current appearance of the main page, then I think we should start a new discussion on the main page and propose the code be changed to this, and then afterwards propose some incremental/functional changes. --NickPenguin(contribs) 12:28, 27 March 2014 (UTC)
    Just want to note my strong support for this direction (change structure first, content later). Thank you so much folks. I look forward to supporting this proposal wherever needed. –Quiddity (talk) 18:16, 28 March 2014 (UTC)

    I liked Edokter's redesign, but I also agree that it makes sense to update the framework first. Bravo to Edokter and NickPenguin for their work to recreate the main page. Novusuna talk 19:58, 28 March 2014 (UTC)

    If any kudos are directed at me, then it is surely because I am riding on the coattails of Edokter; he has done all the significant development here. --NickPenguin(contribs) 03:13, 29 March 2014 (UTC)
    You did tweak the CSS a bit, but that's a fair point. Three cheers to Edokter for making the framework, and I hope consensus can be reached to implement it soon. Novusuna talk 21:10, 29 March 2014 (UTC)

    Proposal has been posted

    On Talk:Main Page#Proposal to implement new framework for main page. — Edokter (talk) — 00:21, 2 April 2014 (UTC)

    Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_110&oldid=1123322167"