Home  

Random  

Nearby  



Log in  



Settings  



Donate  



About Wikipedia  

Disclaimers  



Wikipedia





Wikipedia:Village pump (proposals)/Archive 110





Project page  

Talk  



Language  

Watch  

Edit  


< Wikipedia:Village pump (proposals)
 


  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous
  • 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

    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
    On27 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}} (tec) 15:31, 6 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)

    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)

    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

    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

    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://en.wikipedia.org/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. TitoDutta 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)
    see Wikipedia:Articles_for_discussion/Proposal_1 and Wikipedia:Articles_for_discussion/Proposal_2 Cas Liber (talk · contribs) 19:21, 13 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)

    Handling merge proposals without rationale/discussion

    AsUser: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 TitoDutta 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. TitoDutta 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. --TitoDutta 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?TitoDutta 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}} (tec) 13:57, 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)
    HiJinkinson, 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}} (tec) 11:52, 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}} (tec) 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)
    • 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}} (tec) 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}} (tec) 12:59, 7 March 2014 (UTC)
    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

    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)-- 签名 sigat
    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)
    AtUser 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)
    • 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

    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 en.wikipedia.org 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)
    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)

    (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)

    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

    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

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

    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

    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

    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)

    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 (talkcontribs) 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)
        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:

    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 (talkcontribs) 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)

    Main Page

    Discussion/Comments

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

    It also throws me as odd that "Today's feature picture is looking left from the left side of the screen away from her blurb like she is saying get me the heck out of here. — {{U|Technical 13}} (tec) 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)
    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)
    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)

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

    Main Page (old style)

    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

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


    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_110&oldid=1123322167"
     



    Last edited on 23 November 2022, at 03:47  


    Languages

     



    This page is not available in other languages.
     

    Wikipedia


    This page was last edited on 23 November 2022, at 03:47 (UTC).

    Content is available under CC BY-SA 4.0 unless otherwise noted.



    Privacy policy

    About Wikipedia

    Disclaimers

    Contact Wikipedia

    Code of Conduct

    Developers

    Statistics

    Cookie statement

    Terms of Use

    Desktop