Jump to content

Wikipedia:Village pump (proposals)/Archive 133

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

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

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

Medical articles

Since many Wikipedia medical aticles may hhavve bbeeeen editeteddpeo by non-professssionals, shoulld there be a tag heading these articles clarifying this??#02:30, 3 July 2016 (UTC)Vorbee (talk)

This is covered by the medical disclaimer, but that's not to say that it wouldn't be useful having it additionally clarified in articles. That said, I don't think it's necessary, and would add unnecessary clutter to many pages. —  crh 23  (Talk) 09:21, 3 July 2016 (UTC)
I think we should have such a disclaimer, given the potential for real-world damage from someone being unaware of this disclaimer hidden at the bottom of the page. However, we should probably have a site-wide RFC to establish it. עוד מישהו Od Mishehu 09:20, 4 July 2016 (UTC)
We don't put disclaimers in articles. We shouldn't be cluttering up our articles because someone decides to get medical advice from a crowd-sourced Wikipedia article instead of actually talking to a real doctor. --Majora (talk) 18:33, 4 July 2016 (UTC)
No. All our articles are edited by non-professionals, including legal ones, etc.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:16, 6 July 2016 (UTC)

Religion in infoboxes

I noticed that celebrities who are members of the Scientology religion are identified as "religion: Scientology", yet celebrities who are followers of the Jewish, Muslim, Christian and other religions have nothing in their bios about their religious beliefs.

I propose that all celebrities' religions be identified. — Preceding unsigned comment added by SmudgeTheDragon (talk • contribs) 17:25, 4 July 2016

See Wikipedia:Village pump (policy)/Archive 126#RfC: Religion in biographical infoboxes, a discussion on this a couple of months ago. —  crh 23  (Talk) 17:45, 4 July 2016 (UTC)
Yeah, we're not going to "identify" people by religion, unless it's intrinsic to why they're notable (e.g. because they're religious leaders). The Scientologists being IDed this way need to have the parameter removed (unless they're CoS leaders).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:21, 6 July 2016 (UTC)
There are a few things that need to be addressed here. First: there is no consensus to implement this, especially when weighed against the wide-ranging implications of the implementation of the proposal. That being said, several people (on both sides) mentioned an opt-in option, and based on this discussion I'd encourage any interested editors to pursue this. If I may offer my two cents I believe that many opposes (and, perhaps, supports) come from people who may be confused as to the exact specifics of this proposal. This confusion is not unfounded as the proposal has some ambiguity of the implementation, and if/when a usable proof of concept has been made into a script and/or a gadget it may be easier to have a discussion about the concept, but I digress. The argument essentially boils down to fixing the disambiguation system vs usability (for new and old editors alike), and in the end the support simply doesn't exist for a proposal.
--Kharkiv07 (T) 01:57, 7 July 2016 (UTC) (non-administrator closure)

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.

Note: Following broad support so far, I am adding this discussion to the centralized discussion list in hopes of getting a large enough community response to justify action in a reasonable timeframe from the technical side. —swpbT 13:38, 18 May 2016 (UTC)

As INTDAB indicates, links in mainspace to disambiguation pages are usually (but not always) wrong. DPL bot does a great job of catching these links when they are added, and letting the editor know on their talk page, but, as Wikipedia:Disambiguation pages with links makes clear, there is significant non-response to these bot messages. It seems to me that we would have greater compliance if we could intercede before changes are saved.

I propose a high-attention message and two buttons that appear when "Save" is clicked (with the exception of disambiguation pages, which often intentionally link to other disambiguation pages), modeled on DPL bot, e.g.: "You have added [a link|links] pointing to the disambiguation page[s] [X, Y, and Z]. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles." Buttons: [Return to edit][Save anyway]. So:

  1. Is there support for the idea?
  2. What are the technical limitations?

—swpbT 19:59, 11 May 2016 (UTC)

Hi. Your idea is lovely. Is it actionable?
Best regards,
Codename Lisa (talk) 14:39, 13 May 2016 (UTC)
My "plan of action" is 1) Get consensus; 2) Open Phabricator ticket 3) Profit! —swpbT 17:15, 13 May 2016 (UTC)
  • Support - very strongly. Quite often, the person best able to correct the disambiguation link is the person linking the term in the first place. We obviously have the technical ability to intercept certain edits, for example edits introducing blacklisted external links. If we can intercept the introduction of a disambiguation link before it is saved and prompt the editor to fix it then, it will prevent a lot of errors. bd2412 T 17:53, 13 May 2016 (UTC)
  • Support assuming it's technically possible. Perhaps that code could also offer the user a selection of disambiguated targets? Ivanvector 🍁 (talk) 18:17, 13 May 2016 (UTC)
  • Support as this way editors will definitely be more likely to correct their dablinks. Two things to ponder: 1) should there be a way similar to a tool like popups, that would make it easier to disambiguate the links?; and 2) how high-attention should the new message be? It should be visible enough so that editors spot it, but if it goes over the top, it might scare newbies or add a layer of hassle that might actually place an incentive for people to add fewer wikilinks in their future edits and that is something we don't want to happen. Uanfala (talk) 23:11, 13 May 2016 (UTC)
  • Is this really a literal problem - can you show some actual use cases. I'm thinking people aren't so much as linking to disambig pages, as they are linking to redirects that then link to disambig pages? In order to develop a technical solution we need to have a clear understanding of the exact thing we want to avoid. Perhaps some recent Diffs for clarity? — xaosflux Talk 01:59, 14 May 2016 (UTC)
  •  Remark: Creator of WP:Dab solver here, I've actually looked into doing this in the past. What I'd actually build would be similar to Wikia's link suggestion, a search auto-complete drops down as soon as [[ is typed. I'd add extra features for disambiguation. This had been identified as something to port over from Wikia by the Usability team.
    However, the issue is political. The foundation demands a Microsoft Word functionality from the editor—to be programmed in house (WTF, I hear half the people at WMF can't/unwilling use MediaWiki). Anything that touches the editor is basically a minefield. So to program this, I would need buy-in from several admins for default JavaScript. — Dispenser 13:07, 14 May 2016 (UTC)
    • There are multiple possibilities in the proposal. The easiest part, I think, is just to give editors a prompt before they save an edit introducing a disambiguation link. Whether we also give them a resource to fix that link is a separate question. bd2412 T 16:38, 14 May 2016 (UTC)
      • Agreed. A suggestion/auto-complete function would be wonderful, but the complexities/politics of creating it should not be allowed to impede the introduction of a simple prompt in the mean time. To editor Dispenser: Supposing we set our sights on just a prompt for now, do you know of anyone in particular we should try to get buy-in from? It's also my impression that getting tech changes through requires support from the right people, I just don't know who they are. —swpbT 23:37, 15 May 2016 (UTC)
  • Support – Much more sensible than the current bot-sent talk page messages. RGloucester — ☎ 16:52, 14 May 2016 (UTC)
I second RGloucester's argument. — JFG talk 08:21, 10 June 2016 (UTC)
  • Oppose: This would make things seem utterly confusing for new users, and consequentially flood helpers at Help desk, Teahouse etc. with questions that would be adequately answered by a friendly message on users' talk pages (current practice). If there is already non-compliance with those talk page messages, it's likely because newcomers fail to understand the policy (the term "disambiguation" is used here in a highly technical sense) or lack the technical ability to write advanced wikicode (like piped links). The proposed solution solves none of that and only accentuates aversion to learning how to edit, causes lots of missed page saves, and tons of exchange over confusion. I see no reason to elevate disamb links among dozens and dozens of other absolutely non-urgent guideline do's and dont's to be the only one that prevents immediate saving (genuine technical restrictions such as edit conflicts and trying to move over an existing page are a different story). – Finnusertop (talk ⋅ contribs) 02:10, 16 May 2016 (UTC)
    • Do you really think it's that difficult to make one extra click on a "Save anyway" button? We can even make it a big old button that's selected by default, so that simply pressing "Enter" will choose it. Clicking "OK" to messages you don't fully understand is a nearly subconscious action for most people who ever use a computer; I don't think it's plausible that this would cause a significant of new editor discouragement. —swpbT 14:27, 16 May 2016 (UTC)
      • Yes. Newcomers already fail to save a page all the time (I, II, II, IV, V, VI). Sometimes it's them confusing the save and the preview button – ie. subconsciously clicking on something in the hopes that their intention gets across. I know we can't change human nature, but we shouldn't introduce a culture of 'just ignore any warnings' on Wikipedia, where we are dealing with serious issues like copyright infringements, attack pages, spam links, etc. on a daily basis. – Finnusertop (talk ⋅ contribs) 20:48, 16 May 2016 (UTC)
  • Comment. Sorry, don't want to read the whole section, but about newbies... We then could activate this for only some user groups, for example only that newly created 30/500 group? They should know, what a piped link is, what is a disambig etc. - less questions :) --Edgars2007 (talk/contribs) 05:33, 16 May 2016 (UTC)
Yes, this sounds like a sensible way to deal with the issue raised by Finnusertop. I'm wondering if the threshold should be that high though: I'd imagine after a 100 or so edits most people should have a good idea of how these things work. Uanfala (talk) 10:19, 16 May 2016 (UTC)
  • We don't need to come up with a one-size-fits-all solution right off the bat. We can start with a prompt for specific usergroups, and then adjust as our needs demand. Perhaps we could also adjust for other factors, such as edits adding a large number of disambiguation links at once (which is often a sign that there are going to be other problems with the edit, such as overlinking and even grammar issues), or edits adding commonly linked disambiguation pages like Heavy metal, English, and Model. bd2412 T 22:26, 16 May 2016 (UTC)
Could we implement this as an opt-in preference at the start? Experienced editors could test it and debug it for a while, then decide whether to roll it out to a broader group. I don't know if that is technically possible, but I would opt in. – Jonesey95 (talk) 14:07, 18 May 2016 (UTC)
I would support starting as an opt-in, though ultimately (i.e., once fully bug-tested) I would like this to be a fairly automatic function. bd2412 T 16:31, 18 May 2016 (UTC)
  • Support as the original editor is most likely to know what the intended target is as they are making the edit. Also in favour of a slow roll-out and restricting it to experienced editors until a better interface can be developped for choosing a target. Happy Squirrel (talk) 15:09, 18 May 2016 (UTC)
  • Oppose, editing by newbies should be made easier, not go through extra confirmation screens. Linking to disambiguation pages is a harmless non-issue compared to copyright and BLP issues that newbies really need to learn about. I could imagine a visual editor thingy that pops up the disambiguation page while adding the link, though. —Kusma (t·c) 16:38, 18 May 2016 (UTC)
Would you support with a threshold preventing the message from appearing to new editors? —swpbT 18:17, 18 May 2016 (UTC)
  • Comment : this might be able to be done with by the abuse filter, but need to be very clear about the criteria, if I'm reading the above correct support seems to be for:
    1. User is not a newbie (thresholds to be defined still)
    2. Page edited is an article
    3. Wikilink added that is to a page that is in category: Category:All_article_disambiguation_pages
    Anything missing there? How would you want to detect links that are redirects to disambig pages such as 10k? (These pages may not have a category to drive this). — xaosflux Talk 17:47, 18 May 2016 (UTC)
I think that's an accurate summary. To your last point, the current cleanup page uses this tool to generate a list that includes links to redirects to dab pages, so I don't expect any technical issue there. —swpbT 18:15, 18 May 2016 (UTC)
I'm pretty sure that tool is running database queries - which is good for its purpose, but doesn't lend to real-time analysis. I supposed we could place disambig redirects in to their own category Category:Redirects to disambiguation pages or the like? — xaosflux Talk 18:27, 18 May 2016 (UTC)
Yes - but we need to parse that category some. WP:INTDABLINK redirects (like John Smith (disambiguation) redirecting to John Smith) are not a problem, because they signify that the link is intentional. However, sortname redirects like Smith, John, or WP:INCOMPDAB redirects like John Smith (poet) would need fixing. These definitely would benefit from a categorization scheme that points them out as redirects to a disambiguation page. bd2412 T 18:47, 18 May 2016 (UTC)
Scratch all of this, the AbuseFilter won't be able to look forward to categories on the other page. — xaosflux Talk 01:22, 19 May 2016 (UTC)
  • Oppose a frustrating, time-consuming and distracting measure. We do not routinely display 'confirmation' messages for edits that require attention and I personally would find this makes writing wikipedia entries and editing more difficult. In addition, if we follow this logic here why not confirmation for other types of problems? edits without sources? spelling mistakes picked up by bot? etc? I do not think establishing further barriers between editing and saving content is the solution here. --Tom (LT) (talk) 23:58, 18 May 2016 (UTC)
  • Oppose When I press the save button I want the page to save. Hawkeye7 (talk) 00:26, 19 May 2016 (UTC)
  • oppose. I think the justification for this, that DAB links are “usually wrong“, is itself wrong. Yes, DAB links may need repairing, but they are often useful, good edits, part of adding a properly wikified block of text, even a whole article to the encyclopaedia. Far better than a contribution that has no links, perhaps as the editor is scared to add them after they were warned when trying to save that some of their links were bad. Someone will be along to fix them eventually. There is no deadline.--JohnBlackburnewordsdeeds 00:33, 19 May 2016 (UTC)
  • No to the second confirmation button, yes to the alert I think that the principle of an immediate alert to a user that they have added a disambig link is very useful, however, I don't see the need for a separate prompt to achieve this. Assuming we're all picturing the VisualEditor popup box, why not just let the alert appear in an assertive font/format below the edit summary text box? Tpdwkouaa (talk) 01:05, 19 May 2016 (UTC)
  • Conditional support and strong opposition without that condition being met: A prompt with relatively detailed suggestions for what might have been meant, with an easy click to select that makes the change for the editor would be great (and possible). The cheaper alternative alert complaining that the editor has added a link to a disambig page, will IMO be either routinely ignored or considered scary. If an interface isn't assistive, it's disruptive. Fred Gandt · talk · contribs 02:48, 19 May 2016 (UTC)
  • Oppose per Tom - frustrating, time-consuming, etc. If it's an opt-in gadget, then sure, go for it. But there are bots that can tell me if I've added a disambig link and others who can fix them. Lugnuts Dick Laurent is dead 06:52, 19 May 2016 (UTC)
    • There are no bots fixing disambiguation links, or able to fix disambiguation links, at this time. Every fix is time taken from a disambiguator, who could be doing something more productive. bd2412 T 17:03, 20 May 2016 (UTC)
  • Oppose frustrating, confusing to new editors, time-consuming. --Dirk Beetstra T C 08:39, 19 May 2016 (UTC)
  • Oppose has some people said it's time consuming and frustrating and would discourage editing of these pages and unnecessary because people can complain or edit it out Hanz24 (talk) 13:41, 19 May 2016 (UTC)hanz24
  • Oppose extra button I don't think we should require an extra click-through to save edits with links to disambig pages. I imagine that this will result in the loss of a good number of good edits that should be made, but which may be lost if an editor doesn't understand how to fix the disambig issue, doesn't care to fix the issue, doesn't realize his/her edit is not being saved without an additional click-through, etc. Maybe a compromise could be a pop-up after save, along the lines of Fred Gandt, suggesting an additional edit that the user could make. Calliopejen1 (talk) 17:19, 19 May 2016 (UTC)
  • Oppose - Newbies don't create many or time-consumingly difficult disambiguation links. Those generally arise from page moves and topic restructuring. William Avery (talk) 19:59, 20 May 2016 (UTC)
  • Oppose - This place is confusing enough - Newbies need more shit like this to contend with. –Davey2010Talk 21:19, 20 May 2016 (UTC)
  • Oppose per Finnusertop; this isn't a huge problem (and it's one that can normally be fixed without difficulty by someone else), and it would potentially make things much more difficult for many new users. Nyttend (talk) 13:51, 22 May 2016 (UTC)
  • Moral Support I like the idea, and think it would be good for experienced users as, say, a gadget, but not a general addition. I often add dab links without meaning to and being notified of that quickly would be useful. But the opposes above, talking about how confusing it would be for new users and IPs make me hesitant to support this overall. Wugapodes [thɔk] [kantʃɻɪbz] 04:03, 24 May 2016 (UTC)
  • Oppose - even if we exclude newcomers from this, we still need to deal with 2 situations where such links are frequently intended - hatnotes on articles, and links from disambiguation pages to other disambiguation pages, such as WP:DDAB. עוד מישהו Od Mishehu 17:53, 24 May 2016 (UTC)
    • @Od Mishehu: Those links are covered under WP:INTDABLINK, which provides instructions as to their proper formatting to avoid showing up as errors needing to be fixed. bd2412 T 15:03, 26 May 2016 (UTC)
      • Yes, but unless the software explicitly knows to recognize this marker, it's a problem for the software to start to make saving the page take an extra confirmation click. An external bot can probably be programmed to do this much more easily than software designed to run on wikis of multiple languages, each with its own set of rules. עוד מישהו Od Mishehu 15:24, 26 May 2016 (UTC)
  • Support Good idea. I've spent many hours fixing dab links and many times find an editor has linked to a dab when there is no corresponding article at all. It seems it is common to just add in a link and if it turns blue, then it's good to go. If a new editor knows how to add links, they should quickly learn to verify that the link goes to the intended place. It's bad practice in my opinion to assume a link is correct without checking it. Perhaps instead of implementing this as a Warning on Save, there should be a new button Show Links (next to Show Preview) that would flag links to dab pages and also identify the target of every link. There are times when a link goes to the one article on "Fred" but the editor doesn't realize he means a different "Fred" - and there is no disambiguation involved. MB (talk) 19:57, 25 May 2016 (UTC)
I second MB's argument. — JFG talk 08:21, 10 June 2016 (UTC)
  • No to the second confirmation button, yes to the alert, as per Tpdwkouaa. That seems like a good middle-of-the-road solution, esp. if the "alert" can be made very specific so that no0bs know exactly what's wrong and how to fix it. Dunno if that's technically feasible, but if it is, it should be done... --IJBall (contribs • talk) 02:20, 27 May 2016 (UTC)
  • Oppose implementation for all users, Support on an opt-in basis (and then reassess switching to opt-out down the road if it works really well) — Rhododendrites talk \\ 13:15, 28 May 2016 (UTC)
  • Oppose: I like this option just above: we do not need implementation for all users, but something opt-in for those who care seems good. Links to dab pages is a real yawner compared to all our possibilities for mistaken edits. I for one, like my visits from faithful DPL bot, always greet it on my talk page and then go repair my link. Those who understand or care already address this. Those that don't will not be swayed by an extra save warning. Fylbecatulous talk 12:32, 30 May 2016 (UTC)
  • Support: but preferably get the software to ignore links in hatnotes, as these are usually intentional links to dab pages and alerting editors to them would just be pointlessly irritating. As for new users: just make sure that the message displayed to them is really clear, and a well-intentioned new editor will be happy to learn that they've been alerted to a potential mistake and will appreciate the help. The editor linking to a dab page is the one who knows which of the possible usages of the term is the one they mean: they are the best person to fix the link. A really useful idea, thanks for proposing it. PamD 22:22, 31 May 2016 (UTC)
  • Support but with an option to opt-out. Also, the notice of a disambiguation link should be generated when the editor tries to save, "show preview," or "show changes" the page (but before the next page actually loads). Kylo, Rey, & Finn Consortium (talk) 12:47, 2 June 2016 (UTC)
  • Oppose with an opt in. I better requirement would be no bar urls but doubt there would be support for that either. Doc James (talk · contribs · email) 15:14, 3 June 2016 (UTC)
  • Strongly oppose as proposed, because it places a barrier in the way of saving edits, which increases the chance that an edit will not be saved -- all to prevent a relatively minor problem.
Many editors edit on an incremental basis, fixing one or more issues each time, and editing the same section repeatedly until they are happy with the result. Pressing for perfection in an edit impedes that legitimate and productive style of editing, and places a barrier in the way of many of our most productive editors.
Personally, I sometimes find it easiest to save my edits and then check the links afterwards, using WP:POPUPS to disambiguate as needed. It would be useful to have some form of warning of links to dab pages, whether through syntax highlighting or or a notice after saving, but in many cases I would still prefer to save with the undabbed links so that I can use popups to fix it.
I call this a minor problem, because if we were the consider the sort of problems we would like editors to avoid, this comes waaay down the list. It's not bot-fixable, but it is bot-detectable, and there are very good tools to allow editors to fix links to dab pages, whether created by them or by others. I'd place this one well below the following problems, listed in no particular order:
  • spelling errors
  • grammatical or syntactical errors
  • POV-pushing
  • original research
  • synthesis
  • unreferenced assertions
  • bare URLs
  • missing, inadequate or misleading edit summaries
  • BLP violations
Most of the significant issues there are not easily detectable in software. Placing a software barrier in the path of a relatively trivial error distracts attention from the more serious problems. --BrownHairedGirl (talk) • (contribs) 00:18, 4 June 2016 (UTC)
  • Support I've done this inadvertently a few times and this would be preferable to the present talk-page message solution. Pincrete (talk) 20:38, 6 June 2016 (UTC)
  • Strong support with a "Did you mean?" prompt listing the top 5 disambig options by popularity, and "Other…" if there are more. Would make life easier for newbies and experts alike. Let people save without choosing too. — JFG talk 08:14, 10 June 2016 (UTC)
  • Strong oppose. The problem is not harmful enough to justify making editing more difficult and frustrating for newbies. Wikipedia already gets criticised for how technically difficult editing is (example academic paper), and yet another means by which good-faith edits can be rejected – even temporarily – will be damaging in the long term. Support creation of an opt-in gadget with this functionality. Adrian J. Hunter(talk•contribs) 10:02, 19 June 2016 (UTC)
  • Oppose per comments above. A much better solution (if/when it is technically possible) would be for "Show preview" to indicate (unintentional) links to dab pages (e.g. by showing them in orange font) - i.e. similar to how redlinks work at present. DexDor (talk) 06:15, 20 June 2016 (UTC)
  • Support It will prevent a lot of unwitting mistakes from people who think they're going to the intended article. Jjjjjjdddddd (talk) 05:16, 25 June 2016 (UTC)
  • Strongly support for logged-in users, but neutral regarding anons, per some above concerns which I neither pooh-pooh nor take all that seriously. It's a general fact that new features tend to be tested as optional Preferences-section "gadgets" anyway, so this would be standard operating procedure. Also, request additional feature: It should have three options: 1) fix it by picking a more specific target, 2) proceed anyway because I'm not sure, 3) this is an intentional link to a redirect page and should be marked as such. In the case of the third option it would do whatever is necessary to adjust the markup such that bots will not react to it, and maybe even include an HTML comment that it's an intentional DAB link so later editors don't flip out. While the third case does not come up every day, it does come up, especially when linking to a specific DAB page section of a bunch of related items.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  13:05, 26 June 2016 (UTC)
  • DoubtThe way "Articles With Multiple Dablinks" works for me (and I do everything manual with WPCleaner) is that the page also works as a vandalism/spam-catcher. Would be sad to loose that. The Banner talk 15:13, 30 June 2016 (UTC)
  • Strong support – but please add a choice where the editor can leave an edit note telling us what their intended target is if they end up not dablinking properly or end up redlinking it. e.g.- "she's a red headed heavy metal drummer". Many times when I try to fix dablinks I just need a clue to help me pick the right dablink. Even the drop-down menu on the Visual Editor can be confusing at times because there is not enough clue given to figure out the exact target of the link. Cheers! {{u|Checkingfax}} {Talk} 11:39, 3 July 2016 (UTC)

Discussion

  • See also Special:Permalink/715705562#Reproposing DisambiguationLinks. This is a simple way to make disambiguation links more prominent, but probably best as an opt-in gadget. The key thing here though is that links to disambiguation pages are given the CSS class mw-disambig. So for our purposes we could implement some JavaScript that checks the post-save markup. Obviously less ideal, but we could show a popup that they've entered a link to disambiguation page, and even highlight it, after they saved. Doing it beforehand is still doable but tricky. I can also be a smart ass and say if you just use VisualEditor you get the autocompletion and a little preview of what you're trying to link to! :) Overall this proposal is sensible, but I worry about it's effect on new users. I suspect many are going to think to themselves, "WTF is a disambiguation page?", and abort the edit altogether — MusikAnimal talk 00:12, 19 May 2016 (UTC)
  • Is this going to popup every time you make a minor edit to a page that has an existing link to a disambiguation page? Because that would be really annoying, yet it seems like avoiding that would be a much bigger technical hurdle than the popup box itself... Monty845 22:21, 12 June 2016 (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.

Moderator proposal

A Request for Comment on a proposal to create a new user group with an abbreviated set of administrator user-rights, as an option for editors to request instead of requesting the entire sysop user-right package. I welcome everyone's thoughts on this. - jc37 21:12, 8 July 2016 (UTC)

Revive an old proposal

I think that Wikipedia:Protected Page Editor needs to be revived, it's a few years old I don't think anybody participated in the voting. Thanks! DatNuttyWikipedian (talk) 15:23, 10 July 2016 (UTC)

Previous proposal is at Wikipedia:Village pump (proposals)/Archive 95#New user right proposal. and Wikipedia:Protected Page Editor. --Guy Macon (talk) 10:14, 11 July 2016 (UTC)

Template:Welcome-anon-constructive

{{Template:Welcome-anon-constructive}} that's used to welcome constructive IP edits was originally for the purpose of IP edits that fight vandalism, and thus it contained a broom icon. But it's not just for anti-vandalism efforts anymore. I've used it today, and I was baffled as to why it uses a broom that makes it look like the edit made was swept, or needed cleanup, etc, until I looked at the template's history, in which the template originally said "I greatly appreciate your efforts to fight vandalism and make [sic] constructive edits on Wikipedia ." So I suggest using instead, or any other suitable image that conveys thanks and appreciation. —Hexafluoride (talk) 11:23, 7 July 2016 (UTC)

Agree -- remove the broom. Maybe add a wikipedia logo to make them feel like a wikipedian? --A D Monroe III (talk) 14:48, 7 July 2016 (UTC)
This has been changed to the WP logo with this edit. —  crh 23  (Talk) 11:32, 11 July 2016 (UTC)

Change needed in book citation template

Not sure where to post this but I just realized that the drop-down book template citation maker makes no provision for citing an article in an anthology or edited collection. I just added a new ref to the wikiarticle Joske's to replace a bad ref, and found there is no way to show both the article title and author and the book title and editor. Guess I've never cited a ref like this one before in my ten years on Wikipedia, but some of the wikiwizards ought to make it possible. As it stands, the new ref I added (#5) has the article author's name paired with the book title, which is just not right. Other than typing it all in the long way between <ref> marks, anyone have a better idea? Textorus (talk) 15:52, 10 July 2016 (UTC)

Use last1, first1 etc for the authors of the section, editor1-last etc for the bok editors, title for the book title and chapter for the article title. EdChem (talk) 15:55, 10 July 2016 (UTC)
And use Show/Hide extra fields in the wizard to access those extra fields. --Tagishsimon (talk) 15:58, 10 July 2016 (UTC)

I did use the Show/Hide button, but the extra fields just don't work the way you guys suggest. Go try it yourselves and see. Textorus (talk) 18:31, 10 July 2016 (UTC)

I've done a couple of tests; the first tbh had a wrinkle that the editor names were wikilinked. The output of the second attempt is (with ref tags removed):
  • author last, author first (2009). "chapter". In editor last, editor first (ed.). title. publisher. {{cite book}}: |last1= has generic name (help)
which I think is what we're after. Author name and chapter name (aka name of the article in the book), editor name and book name, date, etc. I think on the whole I'll be sticking to writing cite book by hand rather than via the edit UI doodab. --Tagishsimon (talk) 22:26, 10 July 2016 (UTC)

How did you force it to accept all that? Or are you saying you just typed it in the old-fashioned way? Some IT person really needs to be alerted to fix the template so it will accept this kind of thing. Textorus (talk) 20:54, 11 July 2016 (UTC)

Use the "contribution " field:
{{cite book |last=Amaldi |first=Edoardo |authorlink=Edoardo Amaldi |contribution=Commemoration of the Academy Fellow Enrico Fermi |pages=23–35 |editor-last=Bernardini |editor-first=C. |editor2-first=Luisa |editor2-last=Bonolis |year=2001 |title=Enrico Fermi: His Work and Legacy |location=Bologna |publisher=Società Italiana di Fisica: Springer |isbn=88-7438-015-1 |oclc=56686431 }} produces
Amaldi, Edoardo (2001). "Commemoration of the Academy Fellow Enrico Fermi". In Bernardini, C.; Bonolis, Luisa (eds.). Enrico Fermi: His Work and Legacy. Bologna: Società Italiana di Fisica: Springer. pp. 23–35. ISBN 88-7438-015-1. OCLC 56686431.
Hawkeye7 (talk) 21:04, 11 July 2016 (UTC)

I just looked through all 4 citation templates, using the show/hide button, and nowhere in any of them do I see a "contribution" field. Where are you seeing it, exactly? Textorus (talk) 20:54, 12 July 2016 (UTC)

I used the drop-down book template citation maker. It's a demonstration that it works. --Tagishsimon (talk) 21:59, 12 July 2016 (UTC)
Well this is not helping me at all. I guess you are using something that exists in your universe, but it sure does not exist in mine. I give up. Textorus (talk) 18:18, 13 July 2016 (UTC)

5th RfA reform

It's ridiculous that most experienced editors avoid requesting adminship because they don't want to go through the RfA process. After 5 reforms, no major changes have been made. I think with a final RfA reform, the process should be completely recreated. Something i'm proposing is the creation of "RfA guidelines", where certain topics cannot be discussed in the RfA (edit count, incidents that occurred 8 years ago, etc.) I think with a new RfA reform, the number of sysops will increase significantly. Additionally, i'm proposing that WP:RECALL be promoted to policy and be required for all sysops, making it easier for administrators to be desysopped. — Music1201 talk 22:40, 16 June 2016 (UTC)

  • Hmmm... a RfC should have some question or proposal, no? Tagging as RfC just to call folks for a nice conversation is not needed, or is it? Anyway, you do have a point. I think reforming RfA is probably too hard, and a revolution in the hope that something better comes up is small tiny liiiiittle bit too bold, I suppose. The idea about the recall, on the other hand, may have something interesting. I believe the problem is not that it is too hard to become an admin, but that it may viewed as too hard to stop being one. I do not think that the current process (mostly needing a ArbCom case) is as bad as its bad fame, still, there may be some progress there. Actually since I noticed that many admins have some recall condition I thought to get some of mine, but I keep forgetting to. So, good luck in trying, but I'd ask you to remove the RfC tag as this is not one (and hey! why not you run for admin? you already have a few "extras" so...) - Nabla (talk) 23:05, 16 June 2016 (UTC)
  • Music1201, I agree that RFA is a terrible mess that seems to have been completely overrun by people who have imposed standards that are in many cases completely unrelated to adminship, and more importantly have not been shown by any evidence-based process to make any difference in the quality of the candidate. I'd suggest that Rule #1 is that nobody can vote in more than 3 RFAs a year, which will significantly limit the number of oppose votes for completely irrelevant reasons. I'll take exception to your propsal that there's a problem with getting bad admins desysopped, though; as a former arb, there were many occasions when Arbcom would broadly and publicly hint to the community that serious consideration be made to bring a case about an admin...it was the community that couldn't be bothered, and Arbcom can't start cases on its own except in very restricted circumstances (e.g., admin socking, unblocking him/herself, wheel-warring). Arbcom has historically never really had much problem desysopping bad operators who are brought before them. Risker (talk) 00:01, 17 June 2016 (UTC)
  • If you want radical change, you could give bureaucrats the authority to grant provisional adminship. Such adminships would be reversible by other bureaucrats in a similar manner as admin-grantable permissions and the community could trigger a review at RfA on reasonable request or a provisional administrator can seek to have their status made permanent via RfA. –xenotalk 02:11, 17 June 2016 (UTC) [Disclosure: Current bureaucrat. I can think of at least one user who I'd flip the bit for immediately. Also: I'm not sure if this would fly with WMF legal's stance on viewing deleted revisions.]
    As long as the number of admins doesn't substantially pass previous high water marks, I don't think the deleted revisions question is a problem. My impression is the specific process for selecting admins isn't a part of the legal issue, and that it is the reason its granted, and number of people with it that matter. Administration of the site is an acceptable reason, but research, and some of the other proposed reasons are not, both based on the justification, and the potential for creep in terms of the numbers with the right. Obvious if this started to look like it could achieve consensus, it would be necessary to inquire with legal. Monty845 03:06, 17 June 2016 (UTC)
    This is not my area of expertise, but I believe that you are correct that "the specific process for selecting admins" isn't required. (After all, some WMF wikis take different somewhat approaches.) But I believe that it needs to show community support, which might require more than a single bureaucrat acting independently. The community telling a group of bureaucrats to get us some more admins would probably work, but maybe not a single bureaucrat on his/her own. (Since Risker is nearly omniscient  ;-) she might know more than I do on this subject.) WhatamIdoing (talk) 18:47, 17 June 2016 (UTC)
  • with Xeno's idea, a bureaucrat could grant adminship, to a suitable candidate, and then the community could debate whether to remove or keep the permission. Though I think that the access should only be given if the recipient agrees. Graeme Bartlett (talk) 12:42, 18 June 2016 (UTC)
  • The community has repeatedly rejected universal recall, unfortunately. I made my own attempt at laying out a reform procedure in that area a while back based on a similar successful process on another language Wikipedia (German, if I recall correctly), but it was strongly rejected. The reality is that the number of people who want RfA reform are relatively small because the number of people who work in maintenance areas is relatively small compared to all editors. And even among ourselves, we can't agree on what that reform should be. Any attempt to lay out standards will suffer from the same problems an RfA does; everyone has different standards, and everyone will be pushing their own POV on what an admin should have as experience. The best chances for reform is for individual editors to loosen their own standards and practice some AGF at RfAs for editors likely to be a net positive to the encyclopedia. ~ RobTalk 12:50, 18 June 2016 (UTC)
  • Comment: see Meta:Requests_for_adminship#Requests_for_temporary_adminship - for an option another project has used for people that only need adminship for some sort of purpose and then will go on - I don't think this will cover all of our use cases but the nut shell is if someone only needs adminship for a limited period, and states a limited set of tasks to restrict themselves to - these usually quickly get passed with a series of up/down votes on meta. Perhaps our 'reforms' could have multiple avenues to grant access to people who want to do the work, and something like that could be supplemental? — xaosflux Talk 14:39, 18 June 2016 (UTC)
  • I would support almost any proposal to reform RFA at this point. The goal of RFA is to find people who are competent and unlikely to abuse tools. I think almost everyone with rollback permissions fits that description (otherwise they wouldn't have been given rollback permissions). We currently have a huge number of opposes for irrelevant reasons. Anarchyte's recent RFA had people opposing because they thought that only a year or so of experience itself disqualifies a person from being a good candidate. The idea of RFA not being a vote is ridiculous and not even true according to policy; RFAs must pass when a certain fraction of people support, and they must fail when a certain fraction of people oppose. To encourage more people to run for adminship, we need to discourage or prevent people from voting like that, reform RFA in a different way, or unbundle the admin tools. Two ideas I've suggested in the past are unbundling only deletion tools to avoid legal problems and let us reform RFA however we want and renaming adminship to make it seem like less of a "big deal", as it was originally supposed to be. KSFTC 15:46, 20 June 2016 (UTC)

Basic facts

  1. The community has repeatedly agreed that there are significant problems with the current RfA system.
  2. The community has repeatedly rejected every single proposal to fix these problems.
  3. At this point, there appear to be no proposed solutions left that have not been rejected by the community multiple times.
--Guy Macon (talk) 14:38, 18 June 2016 (UTC)
Your basic facts miss one important thing, however. The subset of the community noted in #1 is almost entirely exclusive of the subset of the community noted in #2.--Jayron32 20:21, 20 June 2016 (UTC)
I don't believe that to be the case, as many of those who have raised issues with the request for adminship process have also expressed concerns about proposals to change the process. The key problem is there is no common understanding of what root causes need to be addressed. isaacl (talk) 01:21, 23 June 2016 (UTC)
It took a long time to achieve consensus that we had a problem - I started User:WereSpielChequers/RFA by month to collect evidence that there really was a drought rather than some random statistical fluctuation. The community has rejected most proposals, several proposals that have passed then either had no effect, were minor mitigations such as the unbundling of template editor or as with lowering the pass threshold and publicising RFAs on watchlists it is too early to see if they've improved RFA. There are some solutions that have only been rejected once or less, but they aren't obvious. One of these days I might go through User:WereSpielChequers/RFA_reform and add counters and last proposed dates. ϢereSpielChequers 18:01, 14 July 2016 (UTC)
  1. Also adding that at the current rate, we are set to have only about 12 new admins this year, compared to 408 in 2007.[1] — Music1201 talk 04:37, 21 June 2016 (UTC)

References

  1. ^ User:WereSpielChequers/RFA by month

Create junior-admins?

I suspect this has been suggested before, but I haven't found it. My idea is to create a new class of users below that of admins, giving them admin rights only in one specific area, such as AfD, without the right to execute admin actions with WP-wide effects, such as block/ban. Candidates for this would not go through RfA, but some new system we design to be streamlined. This also allows us to target specific areas with a high backlog that are specifically in need of admins. This should even help RfA, as established junior-admins that then go through RfA would likely be judged on their history of admin tasks, rather than non-admin things like having 10k edits, five FAs, etc. --A D Monroe III (talk) 20:15, 19 June 2016 (UTC)

Dozens of times. Wikipedia:Perennial proposals#Hierarchical structures and links therein, to start. Prompted by some RfA-related comments, I recently looked in at WP:PERM - which I normally ignore entirely - and found what looked like inflating standards over there too. I think the existence of some kind of mini-admin position would actually have the effect of even further inflating the standards for "full" adminship. Opabinia regalis (talk) 20:46, 19 June 2016 (UTC)
From the "page mover" RFC's that took a while it seem that to get a lot of the community behind a new group you will need to (1) Identify something that has significant backlogs; (2) workshop what permissions are needed. This is not unprecedented wmf wide (e.g. fawiki has eliminator group that gets: 'delete' , 'deleterevision' , 'mergehistory' , 'protect' , 'suppressredirect' , 'deletedtext'). To be useful for just closing xfd's they would probably only require "delete" -- however that would mean that 'undoing' would require a full admin. As Opabinia regalis said above, this has been proposed and rejected numerous times. I'm not as worried about inflation - but what you would almost certainly see would be RfA's saying "go try being an eliminator for a while, then reapply" to a large number of candidates. One thing that may make it easier is if the group came with a built in recall feature -- that may get more people to support it from the offset. — xaosflux Talk 20:57, 19 June 2016 (UTC)
Make the 'junior' level recallable and the 'senior' level not, and the rate of new admins will slow to cratlike levels. Opabinia regalis (talk) 05:32, 20 June 2016 (UTC)
I see the word "junior" as something which perhaps could be mistaken for an age related term by some. Elaborating on this I think "junior adminship" could be profitable to us younger editors. Many of us are seen as incapable of using sysop tools adequately and I would say the opposite is true in actuality. In short this could change attitudes to adminship exponentially. --PatientZero talk 18:21, 22 June 2016 (UTC)
I completely lack the competence of many others to predict whether this could work or not. But I do know that there would be little to lose and a lot to gain by trying something on a limited basis. Wikipedia would not fail, and we would gain actual real-life empirical evidence. ―Mandruss ☎ 02:32, 23 June 2016 (UTC)
  • Perhaps more importantly than this, we need a workable way of ensuring that both the letter and the spirit of WP:INVOLVED are respected.

    I can think of several historical AfDs involving football players where consensus appeared to be leaning in one direction, and the closing admin (one of several prominent members of WP:FOOTY with rigid and outspoken views on the notability line) would make the call based on that line. If the keepers were supporting on WP:GNG and deleters on WP:NFOOTBALL, they'd delete. If in a discussion where the balance of arguments was identical, keepers were supporting on NFOOTBALL and deleters on GNG, they'd close as no consensus. Such decisions would not be overturned because the close was within the realms of discretion, but the point that the discretion was being so blatantly used as a supervote fell on deaf ears. I'm in no doubt whatsoever that people in other topic areas would have had similar experiences of admins with outspoken opinions on the way in which certain policies and guidelines should be applied.

    As a result, I was always quite conservative in supporting RfAs, and am sure I was far from alone. If it were possible to overturn such discussions with no prejudice (i.e. go back to the status quo, without any cloud over the closing admin) and wait for a completely uninvolved admin, there'd be far fewer people with a big problem in giving trustworthy editors the tools in the first place. StillWaitingForConnection (talk) 07:32, 25 June 2016 (UTC)

Bureaucrats Appointed Admins

Since Xeno's radical idea didn't actually get any opposition, I thought it may be worth brainstorming how such a proposal might look. My rough sketch:

  • 1 year trial program, after 1 year, a follow up RFC will be held to decide if the program should continue. Consensus in favor will be required for the program to continue. (Instead of requiring consensus to stop it)
  • RFA remains an option for those who want it. Candidates at RFA should not be declined and referred to the Crat system.
  • Each Crat can appoint up to 5 admins. (22 Crats x 5 = 110 max) Any Crat appointed admins who go on to pass RFA no longer count against the 5 admin per crat limit.
  • The appointing Crat is primarily responsible for deciding on removal, though in a particularly serious case, any Crat my remove the admin bit from a crat appointed admin. (No specific criteria, just trust in crat judgement)
  • Other than being subject to Crat recall, Crat appointed Admins will be equal to RFA appointed Admins.
  • If the followup RFC terminates the program, admins appointed under it will retain the bit, subject to Crat recall. (It wouldn't be fair to them to yank the rug out from under them, just because we decided not to continue with Crat Appointment) Though they should perhaps be encouraged to convert to regular Admins through RFA just to wrap it up.

This would allow us to give an alternative to RFA a shot, while making sure it doesn't scale out of hand before we have a chance to evaluate its success or failure. If we decide we like the results, we would either remove the limit per crat, or maybe change it to be 5, per year, per crat. Obviously, for this to be implemented, it would require a full scale RFC, so lets just discuss some ideas here and not !Vote, though in feeling the water, it would still be helpful to know how many people are going to strongly oppose it in any form. Monty845 23:20, 20 June 2016 (UTC)

I think this is a great idea, and I would strongly support it, but I think there are legal reasons that the WMF won't let us choose admins without them going through an RFA-like process. As far as I know, though, that's only because they can view deleted pages, so maybe we should combine this with my idea to unbundle only deletion and remove the ability of new admins to delete pages and view deleted pages. I'm not sure exactly how this would work. Maybe bureaucrat-appointed admins would get those rights once they pass an RFA, or maybe deletion rights would become a completely separate process. KSFTC 00:16, 21 June 2016 (UTC)
My impression is that the view deleted issue wont be a problem as long as they are full admins, and the process remains fairly selective. Obviously we will need to check to see if legal would object if it moves forward. As for unbundling, I think that has too much baggage attached, and could make the proposal less likely to receive approval. Our best bet would be a narrowly focused approach that just considers a new way to get full admins. At least if legal doesn't object. Monty845 00:46, 21 June 2016 (UTC)
Even though I strongly support this idea, I'm worried about the possibility of editors complaining that their voices won't be heard in the selection process. Maybe we could include some sort of requirement that crats post a notice that they're considering a given editor for appointment on a process page a few days in advance, leaving room for comments by interested editors? (Of course, the crats would still have discretion over whether to appoint the editor.) Enterprisey (talk!) (formerly APerson) 01:10, 21 June 2016 (UTC)
I think this would be much better than my unbundling idea, for several reasons: It would give all interested editors some say in new admins, making the new process something like RFA (with a 0%-100% discretionary range, which I think is a good thing) but without the current problems, which are caused by everyone having power over whether someone becomes an admin, even people who really shouldn't have that power; it would make the discussion seem less serious and formal--that is, less of a "big deal". It would also finally end RFA being a vote, which is currently true even according to policy, not just de facto. It would probably be much friendlier, because none of the involved people, other than the bureaucrat, would actually have significant power over other involved people. I would even support completely replacing RFA with this process. I think we should try to find some people who would be opposed to this as-is so that we can fix any problems with it before starting an RFC. KSFTC 02:39, 21 June 2016 (UTC)
Or perhaps we have "RfA voters", where those users only would participate in the RfAs. I think we all know what an RfA is but the WMF hasn't defined RfA. — Music1201 talk 04:31, 21 June 2016 (UTC)
A committee to choose new admins would be interesting. How would they be chosen? KSFTC 05:12, 21 June 2016 (UTC)
Oh, the usual way. We'd start an informal discussion about how to conduct the election; after a week elevate it to WP:RFC; then a month or two later we'd need to ask WP:AN/RFC to sieve through the conflicting views. Then we'd hold the election, which only those who participated here would bother with.
Then those elected would argue for a bit about who to nominate as admin; and after that's over, and a crat has flipped the switch, somebody will scream "not fair" either because they didn't know about this VPR discussion, or because the nominee didn't go through full RfA. --Redrose64 (talk) 08:45, 21 June 2016 (UTC)
So you mean it would be like a current RFA but even worse. That isn't necessarily bad if we only have to do it rarely. KSFTC 12:47, 21 June 2016 (UTC)
As far as a committee is concerned, this was proposed a couple years ago. See Wikipedia:Administrative Standards Commission. It used an arbcom style election and initially would have run parallel with RFA. Rejected by the community. Oiyarbepsy (talk) 13:13, 22 June 2016 (UTC)
I've just been reading that RFC, and I think this proposal (the one at the bottom of this section, not the above proposal about RFA voters) fixes the same problems that that proposal was meant to and addresses a lot of the opposes: It doesn't create more bureaucracy; the relevantly-named bureaucrats already exist. It doesn't prevent anyone from having a say; depending on how we do it, there would still be a community discussion, just without the vote that RFA currently has. There shouldn't be too much concern about trust in the people making the decisions; bureaucrats have, in effect, gone through two RFAs, and, as far as I can tell, they are very widely trusted. KSFTC 13:56, 22 June 2016 (UTC)
  • This would give the crats a meaningful purpose again. As they are now, they go through heavy scrutiny to become one and they just sit around for the most part. Though, IIRC, the WMF has objections. Their rationale is, anyone that should be trusted enough to be able to view deleted edits must go through a scrutinizing process like RfA. IIRC of course.—cyberpowerChat:Limited Access 11:04, 21 June 2016 (UTC)
I like xeno's idea. To go through an RfA-like process, we could have a crat vote, if 80% (or possibly higher) of crats agree, then they could be appointed an admin? It would give crat's something to do, at least. If this is made policy, we should keep RfA, though. ThePlatypusofDoom (Talk) 15:05, 21 June 2016 (UTC)
I'm not sure about having bureaucrats vote on new admins. I think we should have bureaucrats nominate people, and then give everyone an opportunity to comment but leave the ultimate decision up to the bureaucrat. I don't think most people would like the idea of no one except bureaucrats having a say in new admins, and I also don't think we need every bureaucrat involved in every nomination. KSFTC 19:31, 21 June 2016 (UTC)
This could cause a problem, because we would be allowing bureaucrats to make anyone they wanted an admin (after a certain time period for comments). Ignoring the possible legal problems for now, maybe we could do a test to see who would be made admins with this system, without actually making them admins, then do an RFC to see if people are generally satisfied with the results. KSFTC 19:40, 21 June 2016 (UTC)
@KSFT: @Xeno: Good idea. How do we start the test? ThePlatypusofDoom (Talk) 19:57, 21 June 2016 (UTC)
I think we should get more people involved in this discussion first to find and fix flaws before we do a large-scale RFC or test. We should also find out what WMF Legal will let us do. KSFTC 20:05, 21 June 2016 (UTC)
Okay, pinging WMF Legal: @JGerlach (WMF):. If this doesn't work, can someone email? ThePlatypusofDoom (Talk) 21:38, 21 June 2016 (UTC)
Emailed. ThePlatypusofDoom (Talk) 22:05, 21 June 2016 (UTC)

In my view, this proposal is very much to let Crats pick some admins. Its not to create RFA light, or RFA with Crat super vote, as those would carry over many of the diverse problems that plague current RFA. One of the reasons reforms fail, is that while most agree there are problems, we don't agree on what specific things are problems, and thus can't agree on the specific solutions. The Beauty of having a Crat appointment option is that we don't need to decide on all those issues. If one Crat feels RFA is basically a hazing experience, and has extensive personal knowledge of an editor who would make a fine admin, but who wouldn't want to go through the hazing of RFA, they can just appoint the editor based on their own judgement and trust of the editor. If another Crat feels differently, and wants to hold a public discussion of their proposed admin, they can run it how they feel is best. Maybe some Crats want to hold a tribunal to make a joint decision. In supportng the idea, one is saying they trust the Crats enough to let them appoint some admins directly, and so we should also trust them to come up with their own standards for how those appointments are made. Likely we will want a place to allow public discussions if crats want them, and also to serve as a central place to request consideration if you don't already know a Crat personally. Monty845 22:48, 21 June 2016 (UTC)

@Monty845: Yes, but crats already require a very high level of trust. They need to pass at an 85% Ratio, and there are under 30 of them. That should show that they have the required level of trust. ThePlatypusofDoom (Talk) 22:52, 21 June 2016 (UTC)
That is exactly my point. We should give them as much latitude as possible, and even if we decide we don't end up wanting to keep some of the things tried, it will be helpful to see a variety of approaches tried. Then in a year, we will have that much more information to help us decide on either expanding, stopping or refining the trial. And of course regular RFA is still there for those interested in going that route. Monty845 23:13, 21 June 2016 (UTC)
I like this idea. Any bureaucrat can nominate someone for adminship. A nomination page is created, and anyone can comment. The nominator or nominee can withdraw at any time during the week, based on comments or for any other reason. If they don't and no other bureaucrats strongly object, the nominee is made an admin after a certain period of time (a week or less, I would think). If a bureaucrat does object, then all bureaucrats discuss the nomination publicly to come to a consensus on whether to grant adminship. I'm not sure exactly how this would work if bureaucrats disagree. What does everyone else think? KSFTC 23:48, 21 June 2016 (UTC)
We could have the bureaucrats judge close calls based on the general agreement of the commenters. I think we could make it work better than RFA does now by giving bureaucrats more discretion over determining that agreement and by not having numbered support and opposed sections, just having a single discussion area. KSFTC 00:27, 22 June 2016 (UTC)
Okay, I got a response from my email, and he said

"The main thing from my end is that people don't get access to deleted content without going some some sort of RfC style process. We think it's important that there's a community decision-making process before that one opens up. On the other hand, if you want to give out limited rights such as allowing people to assist with deletions or article maintenance without being able to see deleted content, that's more flexible and could be determined by user consensus. "

But, if they are appointed by a small group of crats, and normal users are allowed to comment, it may work. ThePlatypusofDoom (Talk) 11:14, 22 June 2016 (UTC)

That gives us two main options:
  • Tell the bureaucrats to base their final decisions on the comments, but leave it ultimately up to them. This would make the new process very similar to RFA; it would just give bureaucrats more discretion, which I think could help a lot.
  • Unbundle deletion tools and allow bureaucrats to appoint admins however they want. I think this is the worse option for several reasons: Unbundling deletion would be another major part of the RFC that I think a lot of people would oppose, and not having an opportunity for anyone to discuss new admins would also probably be opposed. We would also have to design a new process for just the deletion tools that would have to be very similar to the current RFA. It might be slightly better if that isn't where the main focus it, and its results don't matter as much because people who pass don't get the rest of the admin tools, but it would still take a lot more work to organize.
We've also been mostly ignoring the trial period. No one has disagreed with the numbers in Monty845's proposal; the only change we've made is the discussion before the bureaucrats can appoint admins, so I'm assuming everyone here agrees with it. KSFTC 12:29, 22 June 2016 (UTC)
@KSFT: I like option 1, as option 2 would not work. We should start testing this out, though. @Xeno: can you tell the other crats?

ThePlatypusofDoom (Talk) 17:50, 22 June 2016 (UTC)

Should we do an RFC first to see how people generally feel about the proposal, so we can decide whether it's worth doing a test? KSFTC 23:15, 22 June 2016 (UTC)

Everyone needs to slow down a minute and take a step back. Nobody should be putting this into action without full consensus support from the community at large. I am talking about a RfC, a post at T:CENT, and a watchlist notice. This is a complete change to not only the 'crat mandate but also to the very way administrators are chosen. Even the one year trial period requires a fully advertised RfC in my mind. We also have not heard back from WMF-Legal about whether or not they will even support this radical change (in regards to the viewdelete right). There also needs to be concrete, defined, rules regarding 'crat appointments. I'm really uncomfortable with anyone just being able to flip the admin switch for someone without any community input at all. Yes 'crats have a high level of trust but that doesn't mean they don't make mistakes. A decision by one person ('crat or not) without any other input is not exactly Wikipedia-esque. We are built on community input, not on single, go-it-alone, changes.

So, to-do list (in my mind). 1) Formulate a RfC that clearly and precisely defines the procedures and protocols for the 'crat picking of administrators. 2) See if there is consensus to even do this. 3) Get a response from WMF-Legal regarding their views on this. 4) If, and only if, 1-3 fall into place should this be put into action. There is no need to rush this. Administrative tasks are still being performed. We are not in a situation where this needs to happen immediately. This sort of situation needs to be handled correctly and needs to have the full backing of the community at large. Not a hand full of editors. --Majora (talk) 02:30, 23 June 2016 (UTC)

I have to agree that this is a major change in an area that has been very resistant to change in the past. I think change is important, but it this is something that would need very wide participation to gain consensus. I think the idea has merit, but I think that it needs a fair bit of discussion to both demonstrate acceptance as well as working out the kinks. HighInBC Need help? {{ping|HighInBC}} 02:33, 23 June 2016 (UTC)
Just to note that I have left a message on Maggie Dennis's talk page asking if she could get in contact with legal regarding this proposal. Please see User talk:Mdennis (WMF) for the thread. --Majora (talk) 02:41, 23 June 2016 (UTC)
I oppose the idea. (The idea is wonderful though). Unfortunately, if it goes to Rfc, in my opinion, this will be shot down. Crats are expected to follow procedures by the book for certain areas reserved for them. They were Rfb'd to their position based on the community's perception of what competence was required and who was standing as a candidate wrt those competencies. The moment the proposal is to provide them newer, independent powers to select, I would not support that, unless the crats were re-selected through Rfbs and the community has had a chance to reassess their competence given the new proposed responsibility. My feel is that the community too would not support the decision to provide such wide powers to crats. Thanks. Xender Lourdes (talk) 03:00, 23 June 2016 (UTC)
I wouldn't be opposed to having current bureaucrats go through RFB again if this proposal is accepted. Would that alone change your mind? KSFTC 03:04, 23 June 2016 (UTC)
I mostly agree with you, and I definitely agree that we shouldn't be rushing this, but I'm not sure you've understood the most recent ideas here. There would be community input, but bureaucrats would have more discretion about how they interpret it. Also, the idea for the trial, as I understand it, is to see who bureaucrats would decide to make admins, without actually making them admins, then to see if we're satisfied with the results. We haven't gone through the details yet, and we haven't gotten much feedback from people who would be opposed to this idea yet, both of which I think we should do before an RFC for the trial. Of course, we shouldn't do any of this if most of the community is opposed to the idea anyway or if WMF Legal wouldn't let us even if we did agree. KSFTC 03:04, 23 June 2016 (UTC)
I've made a post at the bureaucrats noticeboard here, letting all the current crats know about this proposal. Omni Flames (talk) 07:00, 23 June 2016 (UTC)

Another horse that won't run. Instead of being out on the track (RFC) where it will be doomed it is sulking around here in the barn. Once this sees the light of day it will bomb - the community has rejected the idea of king makers in the past. Leaky Caldron 08:14, 23 June 2016 (UTC)

The thing is, though, admins aren't supposed to be kings. Their opinions, in fact, are not supposed to have any special weight at all.
I don't know. It's a strange idea; I'm not fully behind it. But RfA is also very strange. It should be just about whether someone can be trusted to use the tools according to the rules. How did it get to be about featured articles and so on? That's almost completely disjoint from the purpose. --Trovatore (talk) 08:28, 23 June 2016 (UTC)
  • The suggestion that bureaucrats appoint admins at their discretion is the logical endpoint of all the unbundling (and permissions granted without voting) that has been done before. It would be nice to see how it works. But I assume the great number of experienced non-admins who erroneously believe that adminship is a big deal will kill this proposal, and these people will then not only not proceed to apply to become admins, but also vote against others becoming admins. While RfA used to work ten years ago, it does not seem to work with the current community, so replacing it by anything that increases admin promotions is likely to be a good move. —Kusma (t·c) 12:22, 23 June 2016 (UTC)
  • Can someone explain to me what would be different about the proposed process here that would make it different to RfA with the % support guidance removed? Bureaucrats listening to community opinions of a candidate for some length of time and then making a decision about the candidate sounds like what we have now, other than the expectation that they won't promote an admin who receives less than a certain percentage support. Sam Walton (talk) 12:31, 23 June 2016 (UTC)

I won't characterise on the pros or contras to Xeno's suggestion, but it would be met with resistantce not only from the community but from many of the bureaucrats themelves in that that's not in the mandate they were elected for. I'll take his opportunity however to repeat my worn out mantra: 'Fix the voters and RfA will fix itself}}' . Kudpung กุดผึ้ง (talk) 18:48, 23 June 2016 (UTC)

@Kudpung: How do you propose we "fix the voters"? — Preceding unsigned comment added by KSFT (talk • contribs) 19:36, 23 June 2016
@KSFT: Kudpung has a point. Especially in the last few RfAs, most people are !voting based on content creation, featured article count, and "things that happened 5 years ago". Adminship is about none of those things, it is about whether or not a user can be trusted with extra buttons. Adminship is supposed to be "no big deal", although everyone is making it seem like it is. — Music1201 talk 22:19, 23 June 2016 (UTC)
@Music1201: I didn't phrase my last comment here well; I completely agree with that, and I think a lot of people are voting wrong at RFA. It would be great if we could get everyone to vote better, but I'm not sure that's possible. If you have ideas, then propose them already! I think another way of achieving the same result (getting more admins) is getting rid of voting entirely. I've explained my reasons for thinking this above. KSFTC 22:35, 23 June 2016 (UTC)
@KSFT: My initial idea was to ban oppose !votes for reasons that did not directly relate to adminship. Maybe (if RfAs stick around) RfAs should be run through Special:SecurePoll and if a user chooses "Oppose", they have to select a pre-set reason for opposing (they wont be able to give just any reason). — Music1201 talk 22:50, 23 June 2016 (UTC)
@Music1201: I would definitely support that, but hasn't it been proposed and rejected before? KSFTC 22:56, 23 June 2016 (UTC)
I doubt people will take too kindly to being told on what basis they can vote (or even !vote). The question is, how do we win that argument? It's so clearly right; basing RfA on content contributions is just nonsense. The only relevant question is, can the candidate be trusted with the tools? But that's not the way people are looking at it. So how do we win hearts and minds? --Trovatore (talk) 06:45, 24 June 2016 (UTC)
How do you propose we "fix the voters"? "Vote fixing"; God, one has to love it. If nothing else Wikipedia is worth being an editor on just for the occasional hilarity...(meow-yes I am the one with all the cat babel on my userpage) Fylbecatulous talk 15:17, 24 June 2016 (UTC)
Our research, IIRR, at WP:RFA2011 demonstrated that most of the RfA voters are one-off or drive-by editors who appear to have possibly never taken the trouble to really a) examine the candidate, and b) apply any objective criteria at all, with many just voting 'as per' someone else. Some of us who have voted on every (or most) RfA since 2010 have a set of criteria such as user:Kudpung/RfA criteria, which are not excessive at all and which are in fact extremely flexible. There are a lot more similar user criteria listed on the bottom of this page. Until one has read all these criteria, it would be presumptuous to assume that the the criteria are too high just because the occasional drive-by voter insists on an exaggerated edit count or a string of GA and/or FA. Likewise, making an issue of 0.01% misplaced CSD, PROD, or AfD isn't, or shouldn't be a deal breaker. Even a very old,short block for something not very egregious can can be safely glossed over. And an editor whose conversational style is succinct and polite rather than full of smarm & charm, should be lauded for being accurate rather than scolded for being rude.
However, I digress, and the short answer for KSFT who might not yet have read up on the tons of research, the dozens of RfC, and the thousands of posts at WT:RfA, is that the entire - and only - problem with RfA is that for some incomprehensible reason, it continues to this day be the only venue where editors can flagrantly abuse WP:5P4 with absolute impunity. Fix that , and RfA will fix itself. Kudpung กุดผึ้ง (talk) 15:28, 24 June 2016 (UTC)
@Kudpung: Of course that's a problem; almost everyone seems to agree on that. How do we fix it? Do we bring every rude comment at RFA to ANI? KSFTC 16:31, 24 June 2016 (UTC)
Regarding "one-off and drive-by editors", original post here a year ago, recently reposted here:
Of the 10 RfAs than ran to completion [as of 8 June 2015]:
  • Participants !voted in an average of 2.7 RfAs.
  • Just under half (46%) !voted in only one RfA.
  • The average edit count of the singleton voters is ~32,000. Most are identifiably experienced users.
  • Only 15 of the singleton voters currently have under 500 edits. Three of those are alternate or renamed accounts of experienced users.
You can't detect trolling, meanness, or poor research with 15 minutes and a regex, but I would say that the pattern of one-off drive-by participation, where a new collection of participants reset the standards every time, seems to have abated in recent experience.
Recent RfAs have involved very little overt incivility, but a great deal of voting based on unfounded speculation, and not just from "drive-bys" and inexperienced editors. Opabinia regalis (talk) 06:04, 25 June 2016 (UTC)
I've been in the vanguard of RfA reform for years. Even my own RfA was a tactical device to help examine how some people become admins who shouldn't, and what brings nasty people out of the woodwork, and who among the regular RfA voters are the ones who systematically oppose all candidates in demonstration of their animosity to the system of adminship as a whole, and who, by the way, don't offer any alternative suggestions and who even go so far as to derail discussions that are looking for solution that they might actually have accepted.(diffs available).
Hence as I see it, the only way forward to getting a) more admins and b) a better class of admins (because there have been some mishaps) is to introduce some form of control over who can vote and/or comment on RfA, and to be totally rigorous in removing the bad faith votes and comments. Nobody is talking about 'vote fixing', and I have no idea where such a suggestion came from - certainly not from me. Kudpung กุดผึ้ง (talk) 07:38, 25 June 2016 (UTC)
It amounts to the same thing even if you geniunely do not intend it to. It's very difficult to be accused of being a bad-faith perennial supporter. Whereas if you take a view that the bar should be high, then even if you justify every oppose based on the merits of the individual candidacy, you're open to being accused of being a bad-faith opposer. StillWaitingForConnection (talk) 07:47, 25 June 2016 (UTC)
@Kudpung: Wouldn't this proposal help fix that? Giving bureaucrats discretion over how to decide consensus would let them ignore those comments and decide more fairly. KSFTC 16:58, 25 June 2016 (UTC)

No, it wouldn't, KSFT, because in that moment the damage is already done. It's the personal attacks, unreflected, unresearched conjecture, and othe disingenous votes for which RfA has a reputation which are putting off candidates of the right calibre from coming forward in the first place. We have to look at making RfA a safer environment - character assassinations are not cool. Except for attempts at RfA by trolls and vandals, most attempts are probably made in good faith whether the candidate has a clue or not and whether or not they have bothered to read the advice pages. StillWaitingForConnection, I'm not quite sure I fully understand your comment - one of the remedies I would like to see introduced is to restrict voting and commenting on RfA to editors who have at least 90 days tenure and 500 mainspace edits, which is a rule (or similar) practiced by other Wikipedias. Kudpung กุดผึ้ง (talk) 17:48, 25 June 2016 (UTC)

@Kudpung: I think that if people knew that comments like that would be discounted, they would be less likely to make them. If there were fewer comments like that, more people would be likely to go through the process. Of course, I can't be sure that this would reduce the frequency of personal attacks, but it seems like it could, so I think it's worth a test. KSFTC 18:26, 25 June 2016 (UTC)

Crats pinged

Just a note to say that the bureaucrats have been pinged at BN to alert us to this discussion. I won't speak for the other Crats, but for myself I'm unlikely to participate in much in the discussion. We're elected to carry out community consensus and I'll always do just that. You might find me speaking up if a single proposal emerges that looks to have a decent chance of attracting sufficient support to be successful but I'm unclear about aspects of implementation or to clarify an apparent clash with existing policy etc. --Dweller (talk) Become old fashioned! 12:35, 24 June 2016 (UTC)

The quote from WMF Legal above only gives a partial picture. Copying this from Maggie's talk page: "I mentioned that another possibility being discussed was having bureaucrats vote on these appointees. This would satisfy the community overview requirements. :) --Maggie Dennis (WMF)". (I'm not making a suggestion, just showing that the options are broader than the first quote suggests.) - Dank (push to talk) 03:44, 26 June 2016 (UTC)

I'm sorry Dank. I meant to post that here after I thanked Maggie and I got side tracked and forgot about it. My mistake. Thank you for following through on what I should have. --Majora (talk) 03:47, 26 June 2016 (UTC)
I wonder if combining these processes would help with, if nothing else, getting this proposal more widely accepted. That is, maybe we should require a bureaucrat vote after (or possibly before) the discussion, and only give adminship to people who receive more bureaucrat votes for than against and who had continued support by the nominating bureaucrat after the discussion.
After typing that, I'm realizing it seems redundant, so my new proposal is that after a bureaucrat nominates a candidate, we have a discussion involving anyone who wants to participate, and then the bureaucrats vote on whether to make the candidate an admin. What does everyone think? Would this be an improvement? KSFTC 03:57, 26 June 2016 (UTC)
No. Leaky Caldron 08:10, 26 June 2016 (UTC)
@Leaky caldron: Care to explain? KSFTC 13:22, 26 June 2016 (UTC)
I resent any involvement in our selection processes by WMF and I think YOUR suggestion is a total bureaucratic shambles. You appear to be steaming in with good intention with not one iota of knowledge or consideration of the litany of previous failed, overlapping discussions WP:RFA_reform, [Category:RFA_Reform]. This is yet another wasteful time sink. The project deserves a break from under-researched, over-excited, ill-advised & misguided Admin selection reform suggestions. You've been around a year and hope to be an admin one day (according to your page). This is not the way to achieve that aim. Leaky Caldron 14:26, 26 June 2016 (UTC)
@Leaky caldron: I'm confused. None of the proposals here include the WMF being involved in the selection process. You're asserting that this proposal is bad with more words than last time; those are not "reasons" as you claimed in your edit summary. KSFTC 15:15, 26 June 2016 (UTC)
@Leaky caldron: I don't understand your reasoning as well. RfA needs to be fixed, as we have an admin shortage. I don't think that everyone agrees what we should do, but something must be done, and this looks promising. Ignoring the problem won't help. ThePlatypusofDoom (Talk) 16:03, 26 June 2016 (UTC)
I may have lost some of the plot, but I do not think I've lost enough of it to have misread your WMF friend's quote above. The fact that they are being quoted here is "involvement" enough for me. The fact that you present no empirical evidence of this supposed Admin shortage / crisis simply fuels my suspicion about this never ending topic and those who swing by with the latest bizarre proposal. Please create a RFC for this. The sooner it is put to the wider community the better. Leaky Caldron 17:16, 26 June 2016 (UTC)
Perhaps you did miss some of the plot. The WMF was only involved to answer the legal question surrounding this proposal. That is their only involvement in this. Would WMF-Legal block this if it actually gained community consensus? No, they will not. End of story. I'm not a particular fan of this proposal either but just because you see (WMF) in a signature on a discussion does not equate to something nefarious afoot. --Majora (talk) 18:08, 26 June 2016 (UTC)
@Majora: Thank you for clarifying. Would you mind explaining what you don't like about this proposal? KSFTC 19:00, 26 June 2016 (UTC)

@KSFT: The main problem I have, and I think this will be a problem that most people have, is that this proposal would allow 'crats to override community consensus in a way. Technically they could do that now by using their discretion and discounting !votes at RfA but they don't. The discretionary range is set and anything below that is an auto-fail. Reversing that is concerning to me. Yes, this proposal also allows for a community discussion period but what exactly would that entail? Are we talking similar to resysops? Here is 24 hours if no major concerns are raised here's your bit, try not to break the site?

Something else that has concerned me regarding this is Xeno's original statement, I can think of at least one user who I'd flip the bit for immediately. I paused after reading that and thought to myself, oh? Really? And who would that be? And why haven't they run for regular RfA? What is stopping them? Are they not running because of the atmosphere at RfA? Or are they not running because the community would reject them? If it is the latter (the community would reject them) then allowing 'crats to override that is really concerning.

I am completely open to changing my mind if and when a RfC comes out that outlines and addresses my concerns. But right now, without that RfC and with the uncertainty of it all, I am not exactly in the support column for this proposal. --Majora (talk) 20:11, 26 June 2016 (UTC)

@Majora: With the current proposal, he wouldn't be able to do that immediately (or, possibly, unilaterally). There hasn't been any discussion, as far as I can tell, about how long the discussion would last, but I would suggest a few days, up to a week, maybe. I would make an unsubstantiated guess that most people who should be admins aren't doing RFAs because many people have very high or irrelevant standards, and because of its reputation for allowing incivility, especially towards nominees. KSFTC 20:49, 26 June 2016 (UTC)

I'm actually very surprised by the statement quoted above that a vote by the crats would suffice as "community review". No disrespect to the crats, who are very valuable long-term Sane People, but you'd have a hard time finding any other established group on Wikipedia that is less representative of the overall community. There's only 22 of them, many are at best semi-active, the most recent new cratting was in 2014, the youngest crat by account age joined in 2008, and (AFAIK) there are currently no women in the group. Those here who are considering an RfA-by-crat-vote proposal should take a look at what happened last year with WP:BARC (a proposal for crat-based desysopping) and what kinds of arguments were made there. Opabinia regalis (talk) 21:10, 26 June 2016 (UTC)

I was surprised that WMF Legal was okay with it, but I'm not complaining. I think it would create a much better atmosphere than RFA does currently. A lot of the opposes to BARC wouldn't apply to this; many of them pointed out that there wasn't a problem to be fixed, while very few people think RFA standards are too low. KSFTC 22:00, 26 June 2016 (UTC)
My point about BARC was that many people (myself included) opposed the idea specifically because it was presented as "community" based, but relied on this very small and unrepresentative group to do a task outside of their mandate. There seems to be some youthful enthusiasm in this thread, which is great, but don't waste momentum proposing things that are unlikely to move forward. Unsuccessful RfCs are opportunity costs. Opabinia regalis (talk) 02:43, 27 June 2016 (UTC)
@Opabinia regalis: I agree that our selection of crats isn't very diverse. ArbCom, the more diverse alternative, has enough on their hands already, though. Can you contact the rest of the arbs to see if they would agree to do this, if it is passed? (But, ArbCom isn't really involved with RFA at all) ThePlatypusofDoom (Talk) 12:11, 27 June 2016 (UTC)
The likelihood of anyone accepting granting Arbcom the ability to unilaterally promote their cronies to positions of power is zero, and if any arb were stupid enough to say they were even considering granting themselves the ability (none will be) it would instantly trigger an impeachment case for acting spectacularly out of their very specific set of powers. I appreciate the enthusiasm, but as OR has already said please don't waste time on proposals which will never happen, as it just detracts attention from working on necessary changes which actually have a chance of passing. FWIW, I very much doubt that a single crat would survive the recall petitions if they voted to grant this power to themselves, either; there are still enough people here who remember the pre-election days when Jimmy & co handed out userrights to their friends, and can remember how badly that worked in practice. The best you could possibly hope for in terms of super-crats would be a mechanism by which a candidate endorsed by a majority of crats had a lower threshold to clear at RFA, and even that would be deeply controversial and probably trigger a wave of resignations among the current admins. If you want a concrete example of what the backlash against "a group of insiders handing out positions of power to their friends" looks like, take a long hard read of WP:ACPD and the RFC linked there. ‑ Iridescent 12:27, 27 June 2016 (UTC)
We just had a very detailed RFC and loosened standards somewhat and increased discretion. And here we are again. I concur with Iridescent, and I will also say I'm not minded to vote for any proposal re admins that does not include enough of a pause after adoption so we can fairly see how it works out in practice. But I think that the status of admin is limited (with a few historical exceptions) to those whom the community has voted is one of the positives of the system, and I think it ought to remain. In sum, I think Leaky cauldrons first reaction encapsulates mine.--Wehwalt (talk) 17:26, 27 June 2016 (UTC)
KSFT, Iridescent is right; this is not a job that either the community or arbcom itself would want us to do. But wait, my cronies would be perfect admins! If you look at some of the BARC discussions, you do see a line of reasoning like the one you used here - that arbcom is regularly elected, while bureaucrats only have to maintain minimal activity standards, thus having desysopping handled by arbcom is more "community" based than giving it to bureaucrats. However, that's a very different context. Even aside from the obvious power-grab criticism, it's important IMO that RfA and for-cause desysopping be handled by different, independent groups. If we somehow woke up tomorrow in a world where pigs have wings, the damned have snowball fights in hell, and arbs are authorized to give the bit to their favorite people, the first time one of these new appointees really crossed the line we'd all probably take the snowball fight over the resulting case. Opabinia regalis (talk) 05:00, 28 June 2016 (UTC)
KSFT @Opabinia regalis: Hmm. A possible idea is that we could create a usergroup that had the ability to appoint admins. They would have to be in an RFA or something similar, and have the same standards of passing as crats (85% or above). ThePlatypusofDoom (Talk) 11:50, 28 June 2016 (UTC)
A usergroup that had the ability to appoint admins. They would have to be in an RFA or something similar, and have the same standards of passing as crats—are you seriously suggesting we hold an election to elect people who will have the right to participate in future elections? This is not going to happen. Why are you so obsessed with the idea of creating cliques of super-users? ‑ Iridescent 12:04, 28 June 2016 (UTC)
(edit conflict) I think that's even less likely to pass than this proposal. Also, I think it's been proposed in the past. KSFTC 12:07, 28 June 2016 (UTC)
  • After skimming much of this it looks like just RfA (perhaps without sections - one can't really prevent people from bolding a word like support/oppose) and most importantly without a percentage. But 1) there is some talk above about "relevant" admin criteria, and in my experience there is currently NOCONSENSUS on such (apart from the rather vague "nonsense" and "trolling" discount criteria) -- years ago, I merely suggested the community come up with a guideline on what admins do and what we should thus evaluate, and that got nowhere. 2) In the last RfA reform there was no consensus to get rid of percentages, the consensus was not to (disclosure, at that time I did not want to do so) - perhaps with a broader reform, a consensus could develope, but I think the nub is my point 1: to get rid of percentage, as a community we probably need to instruct the Crats on what's strictly relevant/irrelevant - and I am skeptical of that happening (in part because if we could come up with that, we would not really need to change RfA, at all, just the criteria.) The reason a strictly articulated criteria has not developed, I can only guess at, but it probably has to do with "do you trust". Alanscottwalker (talk) 12:50, 28 June 2016 (UTC)
  • As the main architect of BARC, I must needs remind the community that the proposal was born out of a demand going around (at the time) for a less bureaucratic desysoping system than the quadmire of Arbcom. A proposal - any proposal, to see if another method was really what the community was asking for. The discussion regarding the Bureaucrats' job description was handled there and the consensus on that issue was that any changes to the 'Crat mandate would meet with resistance because any new tasks were not what the 'crats were elected for; the resistance came from both the 'crats themselves and the rest of the community.
Add to that the fact that the Bureaucrat user group itself is soon going to be a subject for Wikipalaeontology. Kudpung กุดผึ้ง (talk) 23:20, 1 July 2016 (UTC)

Eliminator group

Although unbundling individual tools is a perennial proposal, given the shortage of admins and increase in deletion-related backlogs, I think it'd be a net positive to have an eliminator group described above by Xaosflux. I can see this as a right easily granted and just as easily revoked at discretion by current admins, similar to the processes in place for rollback and template editor. -FASTILY 05:48, 30 June 2016 (UTC)

That was just an example from other wikis - please note that the sample includes that "deletedtext" option that may have legal-eze strings attached. If enwiki wanted to go this way, the community would need to determine what is appropriate. For example we could issue only "delete" but nothing else (this would not allow for viewing of deleted pages, or undeletion). We may need to verify that it does not override the editinterface protection on the mediawiki namespace. — xaosflux Talk 14:52, 30 June 2016 (UTC)
I am very much in favor of unbundling the adminship tools, but I think that closing XfDs is just about the most nontrivial admin task and it should be the last one to be unbundled. I don't think we can make this a user-right similar to rollback, easily granted and easily revoked. I believe that the ability to close XfDs as "delete" should require some sort of confirmation process similar to RfA. However, there are many other admin rights that could be unbundled first, in the form of new user-rights. E.g. deleting expired prods (probably just non-BLP prods), being able to set certain low levels of protection for pages and possibly being able to issue short duration blocks to IP vandals under some clearly defined conditions. I can imagine these kind of rights being granted/revoked in a similar fashion to rollback rights. Nsk92 (talk) 00:55, 2 July 2016 (UTC)

Semi-Protector or protector group

I like what Nsk92 said earlier about setting low levels of protection for pages. A semi-protector or protector group (able to semi-protect and pending-changes protect) seems like it could work. I know that proposals for unbundling the admin tools haven't worked out in the past, but this might work. ThePlatypusofDoom (Talk) 23:35, 3 July 2016 (UTC)

The standard objection to unbundling semi-protection is that having only part of the toolset, when there is a problem, the protector is likely to use protection to fix problems that other tools would be better suited for. So an IP editor is repeatedly vandalizing the same article. The best practice is, after sufficient warning, to block the IP, and only to semi-protect if more IPs keep showing up to the same article after the first couple blocks. But the protector can't use a block to solve the problem, and can only protect. The IP editor is more likely to continue vandalizing other articles than the protection is to stop the issue. We have one more article protected, and the issue no closer to being resolved. We can try to address this in policy, but its a really strong urge to just fix the problem that we need to counter. Monty845 23:55, 3 July 2016 (UTC)
Who would you trust with this right other than people who could pass an RFA? And how much need is there for this right? Several proposals for unbundling have worked in the past, but the successful ones such as Rollbacker and Template Editor have three common features: They are simple cases of an individual tool being unbundled, there are a group of editors who the community would trust with that tool but not with full adminship, there are frequent enough occasions where the unbundled tool might be used for the unbundling to be worthwhile. Unlike the recently proposed moderator userrights bundle unbundling protection does pass one of those three tests. I'm not sure if it passes the other two. ϢereSpielChequers 07:06, 11 July 2016 (UTC)
@ThePlatypusofDoom: I don't have any objection to this proposal, actually. I think it's time for an RFC to open about this and possibly other proposals. This discussion has gone on for almost 30 days. — Music1201 talk 04:27, 13 July 2016 (UTC)

What will we NEVER trust non-admins with? Unbundle everything else.

There are actually only a few things we really need admins for, at the "this requires a huge amount of community trust" level. Some examples:

  • Issue and lift blocks.
  • Close noticeboard discussions with imposition (or removal) of sanctions
  • Close very contentious RfCs.
  • Impose discretionary sanctions.
  • Perform speedy deletions (much of the same judgement is used in closing non-obvious XfDs, executing expired prods).
  • Examine and sometimes restore deleted material.
  • A few other things.

Everything else can be spun off, as the already-unbundled tools demonstrate. Doomsayer predict terrible results every time, and they just don't happen. The community is much more mature now that it was when the "adminship legend" was created (I mean ours, not Jimbo's original WP:NOBIGDEAL). The Wikiapocalpyse doesn't happen when we unbundle even pretty hardcore-seeming tools (template editor, file mover, account creator, page mover), because the community is not collectively stupid, and institutes vetting processes and rules for usage, and tightens them over time as problems pop up. Even things like page protection can be spun out. Page protection was a huge deal when we were in the Great Article and Content Creation Phase of the 2000s, with way more editors, and way more work to do even on basic topics. These days, page protection rarely negatively impacts people who aren't being asshats, other that as a temporary inconvenience, and they do other productive things in the interim.

Anyone who's been around for a few years (actively editing), is not a moron/nutter, and doesn't have a huge block log or bunch of permanent topic bans, should be able to do anything useful here that cannot cause long-term problems in one swell foop. "But this would reduce the role, distinction, honor of being an admin!" Yes, it sure would, so we were more like all a bunch of editors again, a few taking on some additional (mostly dreary) responsibilities, instead of there being the present admin gentry and peon editor caste system. It is not working any more and hasn't been for a long time. But the more the split between editors and admins gets blurred, the less of a big deal adminship is, and the less RfA drama there will be (and fewer under-qualified people going through that wringer).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:30, 6 July 2016 (UTC)

Agreed. SMcCandlish makes some valid points. ThePlatypusofDoom (Talk) 22:10, 8 July 2016 (UTC)
I'm of the firm opinion that even some (speedy) deletion tasks should be unbundled to experienced editors – the two examples that come immediately to mind are, 1) deletion of anything in one's own Userspace (e.g. WP:U1 (and user-authored drafts in Draftspace?...), 2) deleting redirects esp. as a consequence of an WP:RfD discussion (and also WP:R2 and WP:R3). The "arguments" proffered against unbundling both of these strikes me as wholly uncompelling. --IJBall (contribs • talk) 06:43, 14 July 2016 (UTC)
Again, as far as WMF Legal goes any deletion/restoration rights (the two are tied together) must pass RfA. As much as it would make sense, that is a nonstarter. —Jeremy v^_^v Bori! 09:19, 14 July 2016 (UTC)
The WMF's concerns are with article content, not non-article content. Also, from what I'm hearing, what the WMF is saying on this question is different than what they were saying 4 years ago. Regardless, deleting userspace and redirect pages should not require an RfA, and it would be absurd to insist on that. --IJBall (contribs • talk) 15:25, 14 July 2016 (UTC)
IJBall my understanding is close to yours, this is about viewing deleted "content" - but it is not about "namespaces", for example a BLP violation in the revision history of a redirect or in User:Username/Sandbox/Aricle draft is in the same boat. — xaosflux Talk 15:34, 14 July 2016 (UTC)
Yeah, I'm wondering if such a "deleting redirects" userright will have to be "nuanced" – e.g. editors with this right won't be able to delete redirects either with a revision history over a certain length or redirects that have ever been over a certain number of bytes (i.e. redirects that were once articles which were later converted to redirects...). Now, I don't even know if such a thing is technically possible (I'm assuming the discussion to establish consensus for such a thing would cover all that), but I still think it would be worth it to create a modest "delete redirects" right that could be doled out to experienced editors if it's technically possible to do so. I haven't even used WP:Page mover right myself much yet, but I'm amazed at how simply having suppressredirect has allowed me help out on several "maintenance"-type tasks that would have required an Admin before (and thus which I would have ignored before, and "let somebody else figure it out..."). The more we can empower experienced editors to do stuff like this, the better it is for the project. --IJBall (contribs • talk) 15:41, 14 July 2016 (UTC)

Adding extended confirmed to RFPP

I think that WP:BLUELOCK should be added to WP:RFPP and added to the Twinke/Huggle/Other gadgets that allow protection requests. I understand that it is only used on pages designated by ArbCom at this time, but it probably will be expanded to community use. Any target page that has a high level of disruptive editing from standard confirmed users but is too commonly edited for full protection should be eligible for extended confirmed protection. USA 17:27, 15 July 2016 (UTC)

We should simply wait for the community discussion to end before doing so. --Izno (talk) 17:39, 15 July 2016 (UTC)
As with Izno, it's better to wait to see what we mean to do with the scope of 30/500 protection before notifying anyone of tool changes. RFPP can already handle those requests and it was discussed on WT:RFPP some months ago when the new protection level was introduced. We decided to wait on any RFCs before tools get updated and until a decision is made on the scope, it'll need to wait. tutterMouse (talk) 05:37, 16 July 2016 (UTC)

List of sources (reflist), why not to order alphabetically?

I would like to share an idea, maybe it's suitable to post it here: i wonder why wikipedia uses the reference list ordered in the order by their appearance in the article, from beginning to end, but not alphabetically, by sources/author names, and useing the numbering in the text by alphabetically arranged and then numbered sources?

There's a method called alphanumeric citatations. I haven't yet seen this style in wikipedia, but i thought it would be useful and suitable, maybe even preferrable.

Currently dominantly used method gives an alphabetically randomly ordered reflist. This lets an editor to easily make repetitions while adding citations, because the citations list is visually hard to grasp (similar names doesn′t appear side by side and one could not see..). For example: article Moon, source Taylor, G. Jeffrey (31 December 1998). "Origin of the Earth and Moon". Planetary Science Research Discoveries. Retrieved 7 April 2010. two times; source Pahlevan, Kaveh; Stevenson, David (October 2007). "Equilibration in the Aftermath of the Lunar-forming Giant Impact". EPSL 262 (3–4): 438–449. arXiv:1012.5323. two times etc. Possibly almost all longer articles have this type of repetitions. If the list of citations would be alphanumerically ordered, an editor could see more easily when the repetitions happens - helping to avoid/detect unnessecities.

How about using of this "alphanumeric citations" style in wikipedia? --Mustvalge (talk) 22:11, 11 July 2016 (UTC)

@Mustvalge: A few days ago, you started a similar thread at Help talk:Footnotes#List of citations and alphabetical order, which you did not mention when starting this one. Please see WP:MULTI. --Redrose64 (talk) 22:59, 11 July 2016 (UTC)
I started my thread at Help talk:Footnotes#List of citations and alphabetical order with question "are there any way to put reflist in alphabetical order?" Then i came up with the idea of useing this alphanumeric citatations and it was your suggestion that someone at WP:VPT might be able to help, i chose proposals section. Is this right place, i'm not sure.. But please do not kill my idea by starting conversation about how, why etc to post in wikipedia. This thread should be about pros and cons of this "alphanumeric citations" method. Why it's not used, should it be used, how to make it and are there maybe another alternative options besides of these mentioned in thread Help talk:Footnotes#List of citations and alphabetical order. Thanks --Mustvalge (talk) 04:39, 12 July 2016 (UTC)
I suggested WP:VPT because you need some JavaScript to do this, and a fair number of people who watch VPT know how to write such scripts, or can at least advise on the feasibility. This page is WP:VPR, where the proportion of tech-savvy watchers is lower. --Redrose64 (talk) 07:41, 12 July 2016 (UTC)
So u want to say that the thread should be moved to WP:VPT? could you do that please --Mustvalge (talk) 18:42, 12 July 2016 (UTC)
No, this thread should not be moved anywhere because it is not well-thought out. Mustvalge wants, in the end, the list of sources (that is, the full citations of the sources) ordered alphabetically. Now I have already explained to him how to do that, but he thinks it "seems not very convenient for editors to use alltimes." It seems he also wants everything done automatically, but he hasn't recognized the limitations of the example he holds up for emulation. Nor, it seems, does he grasp the difference between a list of sources (what is sometimes called a bibliography), and a list of endnotes as collected by {reflist}. ~ J. Johnson (JJ) (talk) 22:20, 12 July 2016 (UTC)

J. Johnson (JJ) does not understand what i have to say and is unable for constructive communication. Please don't post here to show your attitude. --Mustvalge (talk) 09:15, 13 July 2016 (UTC)

It is not apparent that you understand what you are talking about. And if you can't be civil, it would be better that you don't post at all. ~ J. Johnson (JJ) (talk) 21:58, 17 July 2016 (UTC)
For books, I think that ordering by appearance makes sense because nearby footnotes are more likely to be related to each other. It seems like that would be true for longer Wikipedia articles as well. Editors who want to maintain, say, an alphabetical list of references can always use the {{harvnb}} template scheme. Praemonitus (talk) 20:31, 13 July 2016 (UTC)
That is a good thought that nearby footnotes might be more likely to be related to each other. This is true because article consists of sections/paragraph with different aspects about given main subject. On the other hand it seems more irrelevant in the case of shorter articles, also it's possible to make groups. Don't know how many people prefer to find the list of references in order by how much do they relate to each oder, also it seems subjective, but if one looks literature in general, then it's appearing that alphabetical order is preferred. So the {{harvnb}} template scheme should be preferred.. But it's not. Why? I think it's because it's not so convinient to use than the usual style. Or is it because it's somewhat hidden? Don't know.--Mustvalge (talk) 09:24, 14 July 2016 (UTC)

Whenever I turn to categories to try to find an example to work from, for whatever purpose, I am almost always looking for a high caliber article. It seems to me it would be quite useful if featured and good articles showed up in categories flagged as such:

Anyway, if there was any support for this, the first question would be technical feasibility – about which I have no idea. If it's not technically feasible, then there's little use in talking about whether we might want this.--Fuhghettaboutit (talk) 21:50, 15 July 2016 (UTC)

I doubt you'll get much support to implement that for everyone, but it's fairly easy for individual users to do it via user CSS/JS, as User:Anomie/linkclassifier adds a class to links to featured and good content. If you install the JS script, you can use CSS similar to this to add the icons if the link is in a category listing (the selector works, though I can't get the display of the image to work for some reason):
.mw-category-generated .good-content:after {content:url(https://upload.wikimedia.org/wikipedia/en/thumb/9/94/Symbol_support_vote.svg/9px-Symbol_support_vote.svg.png);}
SiBr4 (talk) 22:28, 15 July 2016 (UTC)
I misplaced the semicolon in the declaration previously; it works correctly now (I've tested the CSS for both icons here). SiBr4 (talk) 21:15, 16 July 2016 (UTC)
Perhaps it could be made into a gadget? — Music1201 talk 19:38, 16 July 2016 (UTC)
If this isn't too hard, then count on me for Support I often want to explain something to someone at OTRS, or give them a good example to look at. I tend to search GA, but it would be more relevant if I could pick a category relevant to the discussion, and easily find a GA.--S Philbrick(Talk) 20:50, 16 July 2016 (UTC)
I strongly support this idea for exactly S Philbrick's reason: a lot of IRC helpers would love to be able to quickly bring up examples of high-quality content in a given topic area or that uses a specific template. Enterprisey (talk!) (formerly APerson) 03:46, 19 July 2016 (UTC)

Update certain outdated icons

Moved to Wikipedia talk:Protection policy
 – Music1201 (talk) 21:33, 19 July 2016 (UTC)

Wikipedia:WikiProject Africa/Contests

I'm proposing to run a series of contests/editathons for different regions of Africa, and potentially get the African wikipedias involved too. Probably the biggest thing we can do to address systematic bias on here. If anybody would be interested in winning $1000-1500 for improving/creating a bunch of articles on Northern Africa in October please sign up in the participants section at the bottom. Even if contests aren't your thing if you think you might like to contribute to an editathon add your name. If there's decent support on this it stands a good chance long term in tackling one of our weakest areas.♦ Dr. Blofeld 20:19, 20 July 2016 (UTC)

RfC: Give the 'tb-override' right to page movers.

The consensus seems clear that it is too early to reconsider this issue at this time, as the same issue was discussed extensively about two months ago at Wikipedia talk:Page mover/Archive 2#RFC - Proposed: "Page mover" permission to be created. Closing early since interest seems to have dwindled. Mz7 (talk) 02:21, 22 July 2016 (UTC)

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

Many page movers assist with technical move requests at WP:RM/TR. A large number of requests occur because the new desired title is blacklisted. Allowing page movers to override the title blacklist was previously proposed upon creation of the user group, but the community did not reach a consensus to allow page movers to override the title blacklist.

See Special:PermaLink/730146201 as an example. This request has been standing here for a full 24 hours with none of the 1300 administrators bothering to perform the move. — Music1201 talk 19:00, 16 July 2016 (UTC)

Support

*Support There are a number of situations where I could've used this right recently, mainly in relation to uncontroversial technical requests at requested moves, but also in situations such as this thread at AN, where the title was blacklisted. Omni Flames (talk) 22:41, 16 July 2016 (UTC) Moving to Oppose. Omni Flames (talk) 23:39, 17 July 2016 (UTC)

  • Support There was no consensus for this before because it was thought to be unnecessary but there seems to be a need for this, and it's already established that an RFA isn't needed for it - it can cause less damage than autoconfirmed although a better understanding of policy is needed. The main risk is that an administrators could give page mover group rights to vandals or spammers and if that's happening the poor decision making is more of a concern than circumvention of the title blacklist. If a blacklisted title is incorrectly created, it can be moved by any user in this group, without leaving a redirect (or any autoconfirmed user, who can tag the title for deletion if necessary); a vandal can already perform page moves that can only be undone by an editor who can override the blacklist. Peter James (talk) 23:26, 18 July 2016 (UTC)

Oppose

  • Oppose I still agree with the original oppose !votes of the last RfC. If it is on the blacklist let an admin handle it. --Majora (talk) 19:13, 16 July 2016 (UTC)
  • Oppose WP:DEADHORSE, It hasn't event been 2 months since we just had an RfC on this exact item, with 39 supporting, and 36 opposing after a month of comments. — xaosflux Talk 20:39, 16 July 2016 (UTC)
  • Oppose now I'm open to revisiting in the future, but not 2 months removed from an RfC. Wait at least a year. --S Philbrick(Talk) 20:47, 16 July 2016 (UTC)
  • Oppose, the RFC was just completed and is not up for review at this time. Nakon 02:29, 17 July 2016 (UTC)
  • Procedural oppose, nothing has changed since the last RfC. It's not reasonable to keep asking the same question like a 6-year-old wanting an ice cream. for (;;) (talk) 09:59, 17 July 2016 (UTC)
  • Oppose (moved from support) Looking back on the RFC a couple of months ago, I'm going to have to oppose after reading the comments of the opposers there (including my own). I don't think this is really needed as it's rather rare that a situation comes up in which this right would actually be useful for page movers, after all, I've only needed it once. I think that we should just leave it to admins and template editors for now. Omni Flames (talk) 23:39, 17 July 2016 (UTC)

Discussion

To be clear what comes with this permission, besides being able to move a page to a blacklisted page:

  1. Creating and changing edit notices
  2. Creating user accounts where the username is blacklisted
  3. Creating pages with blacklisted titles (seems obvious but just to be clear it is not only about 'moves').
— xaosflux Talk 23:22, 16 July 2016 (UTC)
@Xaosflux: Is there any way to only grant the ability to override the blacklist only when moving pages? The account creators group has tboverride-account instead of tboverride, which means that they can only override the blacklist when creating new accounts. Would it be possible to create a new user right, called, say, tboverride-move which only grants that ability when a page is being moved? Omni Flames (talk) 01:38, 17 July 2016 (UTC)
I don't think that would be very useful: because you could just create any page and "move" it to the bad title. It should be technically possible to make tb-override not apply to username creation (since it is a different dedicated function, and already as a permission created that allows for use). — xaosflux Talk 01:43, 17 July 2016 (UTC)

Since the example was placed above and not in the discussion section I am responding here. Got any examples of it taking weeks to perform a blacklisted move? 24 hours is not exactly helping your cause here (and it has been 12 hours by the way). There is no deadline and a request waiting a day is not reason enough to grant the complete overriding of the entire blacklist. There is zero reason that they can't wait. This isn't some instant gratification site where everything you want is done at the drop of a hat. --Majora (talk) 01:41, 17 July 2016 (UTC)

@Majora: It is better if (in general) requests of any kind are handled as quickly as possible. Why wait 24 hours when it could be done in 1? — Music1201 talk 02:21, 17 July 2016 (UTC)
Because we aren't here to perform mindless actions requested by any and every person. I'll reiterate, Wikipedia does not have a deadline. And you failed to answer my question and did not provide a request that was not actioned by an admin for a long period of time. Therefore, page movers do not need this right. If you don't need it, you won't be getting my support to be granted it. Simple as that. It really seems to me that you are just requesting more rights even though you don't need them and the community pretty clearly didn't have consensus to grant this to page movers two months ago. --Majora (talk) 02:25, 17 July 2016 (UTC)
@Majora: Like I said Special:PermaLink/730146201. It hasn't been more than 24 hours on that request, but keep in mind that I even advertised that request in this discussion, 3 administrators have edited this section since, yet no administrator has acted upon the request. — Music1201 talk 04:32, 17 July 2016 (UTC)
Just so everyone is aware here. The "uncontested" blacklisted move that you give such weight to as to why you need this right was denied. It wasn't just denied, but the proposer withdrew the request in the subsequent discussion. So, really, the example you provided is terrible all around and provides zero evidence as to why this right is needed. --Majora (talk) 23:35, 18 July 2016 (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.

Adding the ability for EFMs to access the edit interface at Special:Tags

There is a discussion at the Edit Filter Noticeboard which may interest some editors here -- samtar talk or stalk 11:03, 22 July 2016 (UTC)

Ideas

After researching the history of Wikipedia and talking via email to some former Wikipedians I have a few proposals which would improve Wikipedia

New protection level called 'semi extended confirm protection' which would require editors with at least 255 edits and an account that is at least 17 days old to edit articles that have this protection on them

Restricting the moving of pages to only administrators

Giving the threshold to be an administrator at 60 percent (same as it is to be an arbcom member). Also maybe have admins who get between 60 and 70 percent of the vote have a trial period where an experienced admin takes them under their wing.

Create a vandal bot who will block vandals who have been warned at least 3 times. Callan Eccleston (talk) 22:13, 20 July 2016 (UTC)

See Wikipedia:EXTENDEDCONFIRMED. I don't think the community would ever agree to restricting pages to only administrators, why would we? The discretionary range was recently lowered from 70-80% to 65-75%, I don't think the community would accept sysops with less than 65% support. For the bot, couldn't someone just place 3 warning templates on someone's talk page when they're having a dispute and get them blocked? — Music1201 talk 23:24, 20 July 2016 (UTC)

Actually I think that Wikipedia should have a protection level in between Semi and Extended confirm called 'semi extended confirm' .To edit articles under this protection ,editors would need at least 255 edits and an account that is at least 17 days old. This is good because it would add flexibility to protection levels and stop admins from over protecting some pages with extended confirm (if there was an option like semi extended confirm'. Callan Eccleston (talk) 03:01, 21 July 2016 (UTC)

It just isn't going to happen. 30/500 was an ArbCom decision. It was "accepted" by the community only after being mandated by them. And it was not an easy road to acceptance. Even now there are a lot of editors that believe that we should do away with the extended confirmed level altogether. Also, what would this new semi level be used for? Just seems like looking for a solution to a problem that isn't there. --Majora (talk) 03:15, 21 July 2016 (UTC)
You don't hear me bringing up this essay a lot, but I think WP:CREEP applies here. It doesn't seem (right now) that there's a problem - beyond the need for "flexibility to [be added to] protection levels" (which I don't think exists) - that requires this solution. Enterprisey (talk!) (formerly APerson) 03:58, 21 July 2016 (UTC)
@Callan Eccleston: "Semi-extended confirmed" sounds incredibly WP:BURO and WP:CREEP, and there's no need for such a level of protection. Your second proposal is quite ridiculous, why is that needed? Perhaps you're unfamiliar with WP:RM, but over there, non-admins do most of the work moving pages, and so restricting moves to admins would result in that area becoming extremely backlogged. Your third suggestion could work, but I feel that we've already made the discretionary range low enough. As for your last idea, you need to think that through a little more. That would practically give anyone, admin or not, the ability to block anyone they wanted. All they have to do is slap three warnings on someone's talk page, and bam, they're blocked. Omni Flames (talk) 00:35, 23 July 2016 (UTC)
@Omni Flames: Have a look at the history of this page for 20-21 July and at the contribs of Callan Eccleston. Notice anything unusual? That list was somewhat longer a couple of days ago; I saw some of their other edits at the time, and so I think that their proposal should not be taken seriously, and that this whole section should be hatted. --Redrose64 (talk) 08:44, 23 July 2016 (UTC)

Nominate for GA/FA/DYK/PR automation

Are there any gadgets which automate this process? An automated (again Twinkle-like) menu would probably save days to months of editing time. --Tom (LT) (talk) 02:32, 24 July 2016 (UTC)

I see you just made two similar new sections here. Questions like these are probably better for the help desk. KSFTC 03:08, 24 July 2016 (UTC)

Autoarchiving gadget

IS there a gadget (like TWinkle) where I can click a button and implement auto-archiving on a talk page? This would be a lot less cumbersome than doing it manually. --Tom (LT) (talk) 23:59, 23 July 2016 (UTC)

LT910001 No gadget, however you can just dump one of the templates from Help:Archiving_a_talk_page#Automated_archival on a page and it will just begin. Does that help? — xaosflux Talk 04:19, 24 July 2016 (UTC)

Ability to follow subcategories recursively

Wikipedia:Ability_to_follow_subcategories_recursively — Preceding unsigned comment added by 65.93.215.245 (talk) 18:30, 24 July 2016 (UTC)

Separate the bibliography and footnotes from the actual content (in Markup)

Moved from Wikipedia:Village pump (technical) § Separate the bibliography and footnotes from the actual content (in Markup)

This is an old gripe I've had with Wikipedia: the de-facto standard is inline bibliography and footnes. Editors are practically required to follow it, not just because of inertia, but mainly because all of the editing tools insert all bibliographic information right into the article body. A far better standard would be to separate the bibliographic data as well as any footnotes from the main content. This is already technically possible, via List-Defined Refs, or Sfn. However, it is neither encouraged nor promoted , so 99% of editors use the inline standard.

Here's why I think the current practice of putting everything inline is horrible:

  1. The inline references crowd out the content and each other. Even the average quantity of inline references makes the markup virtually unreadable. It becomes hard to find or concentrate on the content you are editing, which becomes a needle in a haystack. The situation is not helped by the fact that the default size of the editor is rather small—so its like looking at the haystack through a slit in the door. The "syntax highlighting" feature helps a bit, but it's still lipstick on a pig: imagine a computer program where there is no logical or visual separation of components—no amount of syntax highlighting will make it readable. My eyesight is fine and I look at code all day, but even I am afraid that after enough edits I'll develop a cataract. But I cannot even imagine how older people with less than average eyesight can comfortably use the source editor. Wikipedia markup is literally the only place you will encounter inline bibliographies and notes—everywhere else this stuff is logically and physically separated from the body.
  2. Because source are scattered throughout the article, editors are bound to duplicate them, making matters even worse.
  3. What if I want to edit a source and all I see is <ref name= .../> ? I have to comb the entire article to find where the bibliographical information is stored.
  4. What if I want to delete a named reference? I have to comb the entire article for occurrences of this named reference, to make sure I don't end up with orphaned refs. I know there is a bot that tries to fix this, but there is still a large number of articles with orphaned refs.

I propose to change the standard so that all bibliography and notes are placed into a dedicated block(s). Different articles can have different variations of this standard: one may use {{sfn}} with a dedicated bibliography and another may use {{r}} with just a reflist. Both of these are optimal because they allow a book to be cited multiple times with different page numbers without duplicating references. An article should specify which of these two is recommended, and the Visual Editor and citation wizard should change the markup accordingly. ProveIt (which shows the list of references persistently, even if they are in stored a different section of the document), should be enabled by default and hopefully upgraded to allow the {{sfn}} style. Editors should be noted about the new policy.

Anyone else think this is reasonable? It is just so painful to read the existing markup that I feel something should be done about it.Guccisamsclub (talk) 20:46, 18 July 2016 (UTC)

This is a WP:VPR matter, not VPT; and suggestions like this have been brought up (and rejected) several times in the past. I'll state that the widely-used <ref>...</ref> system is somewhat better than the methods that we had early on (see e.g. Wikipedia:Footnote1), but I prefer {{sfn}} (see Shortened footnotes). In a nutshell: Wikipedia does not prefer any ref style, and it's far too late to enforce anything. --Redrose64 (talk) 18:55, 18 July 2016 (UTC)
Well, there's always the Visual Editor.Guccisamsclub (talk) 20:52, 18 July 2016 (UTC)
@Guccisamsclub: You've copied this from Wikipedia:Village pump (technical)#Separate the bibliography and footnotes from the actual content (in Markup) without saying so here and without including my earlier reply. --Redrose64 (talk) 21:58, 18 July 2016 (UTC)
In 2009 the reference system was updated for just this reason. See Help:List-defined references. Make all the references named references, and list them within {{reflist}} using the refs= parameter. If the Visual Editor did this, it would be less confusing for new users, since they often put duplicated of their references into the reference section. StarryGrandma (talk) 23:18, 18 July 2016 (UTC)
Do experienced users than not care about this? They can just look at spaghetti markup and see that a given reference already exists? I've used wikipedia for a year, and the messy markup caused by inline refs still makes me a little sick every time. It just doesn't make sense. And it is a solvable problem—although I realize there are many who don't see it as a problem (unfortunately I'll never understand these people).Guccisamsclub (talk) 02:27, 19 July 2016 (UTC)
Besides VisualEditor, a number of editors use the syntax highlighter gadget (accessible from Preferences → Gadgets → Editing) to make editing wikitext easier. Enterprisey (talk!) (formerly APerson) 04:01, 21 July 2016 (UTC)
I agree with Guccisamsclub about the problem, and the general desireability of not having the sources ("bibliography") scattered throughout the article text. However, this "change the standard ..." seems a bit overreaching. As Redrose64 said, "Wikipedia does not prefer any ref style". The "standard" is what is set by all these editors selecting (perhaps by default) amongst what is possible. To change this "standard" we need to change editor thinking, preferences, and behavior. And to judge by past discussions, this would require coordinated effort by a fairly large group of editors. Would anyone be interested? ~ J. Johnson (JJ) (talk) 21:35, 23 July 2016 (UTC)
The problem is that the visual editor and citation widget put references in line. Another problem is that you cannot view all citations when youre editing a section. These two technical factors create the problem. So it is not exactly true that "wikipedia does not prefer any ref style". It is not really a matter of editor choice. Sure I'd be interested (I could potentially look into writing a bot to clean up inline refs, if we do agree on them being a bad thing)Guccisamsclub (talk) 22:03, 23 July 2016 (UTC)
Even if you and I (and some number of other editors) agreed that inline "refs" (a poorly defined term) are "bad" (for some notion and degree of "bad"), bot-mediated "clean up" would lkely be a very bad idea. That would require a degree of consensus which is not yet in view.
That VE (not Wikipedia per se) favors a certain approach (inline full-citations and "named refs") reflects the preferences of those who designed VE. But that is not the problem itself (though it exacerbates the problem). The problem is that our sentiments on this topic are not broadly accepted by the rest of the community. To proceed we would need to organize, and to formulate those sentiments in a convincing form.
There are certain possible tools that might help. Would you be interested in working on such? ~ J. Johnson (JJ) (talk) 23:36, 24 July 2016 (UTC)
Sure. I can't make any commitments because I am not familiar with writing extensions for Media wiki. But I might be able to write some code that will refactor existing wiki markup.Guccisamsclub (talk) 18:12, 25 July 2016 (UTC)
The alternative being list-defined references, or something else? If LDR, it has its downside, and I'm not entirely convinced it's a net positive. Attempts to shrink its downside, including this one, have received a clear "meh" from the community. ―Mandruss ☎ 02:11, 25 July 2016 (UTC)
Yes, definitely a downside to LDR. I can still remember my first encounter with it, and trying to figure out: where the heck is this coming from???
I doubt if there will be any progress if we wait for approval from the community. But if the argument for this was better articulated, and some of us could start singing in it in harmony, there would likely be more support. And if we had, say, a tool for scraping full citations out of notes and collecting them in a given section, progress could be made incrementally. ~ J. Johnson (JJ) (talk) 00:38, 26 July 2016 (UTC)
@J. Johnson: I was referring to the downside that remains after people know how it works. I could speak at length about that, but I won't at this point. Re conversion tools, see Help:Converting between references formats. I have never tried this, can't vouch for it. ―Mandruss ☎ 00:54, 26 July 2016 (UTC)
Of course. LDR sounds good, but it is upon closer inspection interest wanes. Thanks for the tip, I'll take a look at that. ~ J. Johnson (JJ) (talk) 23:45, 26 July 2016 (UTC)
For the unfamiliar and interested, Shooting of Michael Brown and 2014 Isla Vista killings are two articles that use LDR exclusively, or very close to it. ―Mandruss ☎ 00:54, 27 July 2016 (UTC)
Frankly, I prefer LDR and every article I rewrite or write I use them (see forensic chemistry for an example that uses them exclusively). It keeps the main text uncluttered and makes editing references (to add archive links) really really easy. Interest may wane for others but for me, personally, I am going to continue to use them whenever I get the chance only defaulting to other styles due to WP:CITEVAR. --Majora (talk) 01:25, 27 July 2016 (UTC)

Mobile view

The consensus among most participants is that this idea is worth pursuing; the primary source of disagreement comes from how the new "mobile view" button should be implemented once it is developed. Two options were discussed: either 1) enable the new button by default for all users or 2) modify the existing gadget to include the desired functionality (disabled by default).

Three editors have explicitly expressed opposition to enabling by default on the basis that it would add unnecessary complexity to the editing interface. I count 9 editors who supported the idea for the new button but did not specify a preference for whether it should be enabled by default. I don't see much opposition to disabling by default.

Considering this, I conclude that the result of the discussion is to modify the existing gadget, disabled by default, to include the "mobile view" button described in the proposal. We can reconsider whether to enable by default in the future, once the gadget has been fully developed and the community has had some experience using it on an opt-in basis. Respectfully, Mz7 (talk) 02:51, 27 July 2016 (UTC)

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

This page on a mobile device

(This proposal started at Wikipedia:Village pump (idea lab)/Archive 20#Phone view and includes ideas and information given there)

Most editors change pages on their laptop but most readers check Wikipedia on their phone or tablet. What we see is not what the reader gets. An article full of info boxes and images may look good on a laptop and terrible on a smaller screen. An editor can resize their edit window to get a sense of how it would look, but most would not. Even if they did, they would not see the different layout presented on a mobile device (see screenshot to the right). Better to have a button at the bottom of the edit window that prompts the editor to preview how the article would look on a typical phone or tablet:

Save page
Show preview
Mobile view
Show changes
Cancel

It should give the option to check the views on both a typical phone and a typical tablet, since a page with too many images may look o.k. on a phone, where the images fill the width of the screen and alternate with the text, but bad on a tablet where the text zig-zags around the images.

The effect of a "Mobile view" button may be seen in Google Chrome by pressing Ctrl-Shift-I and then Ctrl-Shift-M, which lets you try different devices such as Galaxy s5 and iPad. If you view Wikipedia with a vector skin (don't ask), you can see the phone (but not tablet) view by using the gadget in Special:Preferences#mw-prefsection-gadgets "Mobile sidebar preview: show page in mobile view while browsing the desktop site". Or you can disable the gadget in preferences and copy importScript('User:קיפודנחש/mobile-sidebarcopy.js'); // Linkback: User:קיפודנחש/mobile-sidebarcopy.js to your User:xxx/common.js to get the same effect, but not for edit preview.

The new button would be easier to use than the gadget or script, and would encourage editors to check how the article looks to the normal reader. Comments? Aymatth2 (talk) 13:55, 22 June 2016 (UTC)

Comments on mobile view

  • Support - makes it easy for users, some of who never even thought of this issue, see what it would look like to such readers. עוד מישהו Od Mishehu 14:55, 22 June 2016 (UTC)
  • Support Conditional Support - would make it easier for editors and readers alike, but depending on the type of computer I use, it sometimes overlaps the menu bar at the top, which make it hard for me to read the menu bar. Sam.gov (talk) 20:17, 23 June 2016 (UTC)
    The implementation of this proposal should not overlap the menu bar. That would be a bug if it did. Aymatth2 (talk) 02:22, 25 June 2016 (UTC)
    And it is a bug, since it is overlapping the menu bar on the web page. Sam.gov (talk) 19:04, 27 June 2016 (UTC)
    @Sam.gov: I was unclear. I was not proposing to implement the existing gadget or script. The gadget only works with a "vector skin". Whatever that is, I do not have one. The script does not work in edit preview mode, which is exactly where it would be most useful. I was looking for support for a "Mobile view" button that would work in edit preview mode in any skin. The new function should not overlap the menu bar or have any other awkward glitches. Aymatth2 (talk) 21:55, 27 June 2016 (UTC)
    Ok, I guess I would agree with the button in preview mode, then. Sam.gov (talk) 22:03, 27 June 2016 (UTC)
    @Aymatth2: Every user has a skin, it's set at Preferences → Appearance, first main box. There are presently four skins listed, have a go at the "Preview" links there to see how the Main Page looks in that skin. All accounts created since about 2010 have Vector skin by default, some of these users have switched to a different one - and some pre-2010 accounts have switched from another skin to Vector. --Redrose64 (talk) 23:09, 27 June 2016 (UTC)
  • Support; anything to make it easier to read on mobile for those who use it. —Jeremy v^_^v Bori! 20:41, 23 June 2016 (UTC)
  • Gadget Support - this would be good, as a set of enhancements for the existing gadget. It should probably not be added to the default interface, which is already quite complex for newcomers, and we want to do all we can to get them to use the existing preview/show changes buttons. Quiddity (talk) 11:30, 24 June 2016 (UTC)
  • Since most readers view articles on their mobile phone, we could have the "Preview" button give the mobile phone view, with the ability to toggle to the tablet or laptop views. Two buttons seems simpler, though. The first shows what the page will will look like to the editor and the second shows what it will look like to most readers. Aymatth2 (talk) 12:26, 24 June 2016 (UTC)
  • Oppose turning it on by default, but definitely support making achanging the gadget for it. Per Quiddity, I don't think the edit interface needs another button to do this. A gadget would perfectly fit the use case of editors who want it as a utility. I disagree with arguments based on the button "raising awareness" of mobile view issues. The edit interface should not be used to send editors messages; it should only provide basic functions that people need and allow for customization. Enterprisey (talk!) (formerly APerson) 00:46, 25 June 2016 (UTC); edited 02:41, 25 June 2016 (UTC)
  • Support I think this is a good idea. A bit more refinement might be required on the actual preview to better integrate it into the page, but that is not a blocker to me. —TheDJ (talk • contribs) 09:11, 26 June 2016 (UTC)
  • Oppose I think there should be a simple and intuitive way of switching between desktop and mobile no matter which you are using. Thus, I support an expanded proposal. Whether or not you're logged in btw.--Wehwalt (talk) 17:41, 27 June 2016 (UTC)
  • @Wehwalt: I don't think I follow what the expanded proposal would be. Very few people make significant changes from a mobile. If they tried to preview a desktop view from a mobile, it would be very hard to see, taking a lot of sideways scrolling. Almost all non-trivial changes are from a desktop (PC/laptop), but maybe 75% - 80% of views are from a mobile, so the ability to easily preview the mobile appearance of a change from a desktop editor seems very important. Am I missing the point? Aymatth2 (talk) 18:17, 27 June 2016 (UTC)
The edits I do from a phone are generally polishing, as it is hard to type obviously. But getting to a desktop screen (which is where I prefer to edit, can be difficult and I have the impression has been made more so, especially when I need to log in. I'll make it a suggestion rather than an oppose if you like, but clearly the fact that some percentage of edits are made from a device suggests that this should be facilitated. Say I want to view my watchlist in desktop. It's tedious to scroll down on my phone to where I can find the "desktop" click.--Wehwalt (talk) 18:33, 27 June 2016 (UTC)
  • @Wehwalt: I was thinking only of wanting to easily see how a page would look on a mobile when editing on a desktop, because we can so easily forget that Wikipedia is usually viewed on a phone. I would prefer that you raise a separate proposal for making it easier to do editor functions from a phone. I think this is a separate issue – but entirely valid. Possibly a step towards it would be a preference that lets you see an extended menu on your phone. Aymatth2 (talk) 21:41, 27 June 2016 (UTC)
  • Very well. It would be helpful if those on the technical side could remember that content contributors use Wikipedia in non-standard ways to accomplish their ends. And we don't get over to the technical side much, so I wonder if communications are always adequate. Perhaps I'm just thinking out given a different audience ...--Wehwalt (talk) 21:46, 27 June 2016 (UTC)
@SSTflyer: Yes, sort of, see response to next comment. Aymatth2 (talk) 22:35, 4 July 2016 (UTC)
  • Support preview button in concept; dubious about but not totally opposed to gadget: With the caveat that the devil is in the details. I never read or otherwise access WP from a phone so I have no clue how it will look, either a "preview" option to show mobile view or a toggle feature would be good. The gadget that exists now cannot be turned off and on with each article, and it's a pain to have the mobile view hovering there all the time. On Wordpress, there is an option to preview in laptop, tablet or mobile view and easy to switch between them; that method may be worth looking at. (Much about the Wordpress interface is clunky and I'm not fond of it, but that feature is nice. ) Montanabw(talk) 19:31, 4 July 2016 (UTC)
It is sort of secret, but if you scroll down to the foot of this page, at the end of the last line you may see a link for "Mobile view". You have to resize the window to get an idea of what it would look like on a tablet or phone, and if you are editing you have to abandon your changes. But the feature is there, sort of. This proposal is not to implement the gadget, or the script, or the link at the foot of this page, but to implement a button that lets an editor preview what their page will look like on a mobile device, what it will look like to 75% of readers. The next step would be to decide on the user interface. This proposal is just to ask for support of a button in principle. Aymatth2 (talk) 22:35, 4 July 2016 (UTC)
  • Comment: I object to the loaded and baiting premise that infoboxes are clutter on mobile devices. They're actually one of the most appreciated features by mobile users like me, because they fit that format well and give a précis of commonly sought details. Often, mobile readers need look no further and if they do, they just flick a finger and it zips away. The days of tedious slow scrolling by clicking buttons on a phone were over in something like 2010. Infoboxes are not a mobile usability problem.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:01, 6 July 2016 (UTC)
  • Support in whatever form, as long as we get the functionality. I don't mind a new button, and can't see why it would be objectionable. A present tool that allows you to kinda-sorta do this, but at the cost of abandoning edit-in-progress, is crippleware, so let's fix or replace it. Same goes or a gadget that shows phone but not tablet view.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:07, 6 July 2016 (UTC)
    SMcCandlish, my primary objection is that not everyone would find it useful. When I'm editing javascript pages or any sort of talk page, am I interested in seeing how the code or discussion looks on mobile? I sincerely hope that this button is implemented as a preference or a gadget that can be turned off, otherwise I'd have to write a script to hide it. And even that would be a problem, because at the moment I have a 2-second delay for some reason before my scripts load, and that would mean my editing interface would suddenly change in the middle of making an edit. Enterprisey (talk!) (formerly APerson) 02:06, 7 July 2016 (UTC)
    Oh, I have no objection to the button being turned on/off by a Gadget; lots of them are. I support the button idea, because I don't want to have to scroll up to page-top to get into the top menu, memorize a keyboard shortcut, scroll to page bottom to find a link, or use some other weird way to get to a tool that should be right there with the rest of them, for anyone who wants it to be there at all. Agree it should not be forced on everyone, though I also have no objection to be being on by default.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:30, 7 July 2016 (UTC)
  • Support either as a gadget or as full roll out. Would be good to collect data on usage regardless. Doc James (talk · contribs · email) 10:13, 12 July 2016 (UTC)
  • Oppose making this on by default. I don't edit for readers and I don't care how it looks on a phone. That said, I use Chrome so I don't need this. Chris Troutman (talk) 16:39, 15 July 2016 (UTC)
  • Support any implementation. Even nicer if it lets us select mobile site or mobile app, a choice that I don't get on this iPad Air. Jim.henderson (talk) 17:16, 15 July 2016 (UTC)
  • Support, preferably as a gadget (to accommodate those who object), but if not, by default (because it's better to have more functionality than less). I've already enabled the mobile sidebar preview gadget, and one of the few drawbacks is that it can't be used in the middle of an edit. As such, this would be a welcome addition. Colonel Wilhelm Klink (Complaints|Mistakes) 02:50, 22 July 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC notice: Designated space for editors to give and seek advice about topic bans and other sanctions

There is an RfC on Meta about creating a noticeboard to help editors who have been sanctioned. Your input is welcome. Ca2james (talk) 03:59, 28 July 2016 (UTC)

Script/Cite error Autofix gadget

When you see a script/cite error, you took many minutes and hours to fix them. If there is an autofix gadget of script/cite error, you might be able to save time to correct these errors with one click. When you add this gadget, would a lot of people will be able to easily fix these errors.--Ijoe2003 (talk) 05:16, 28 July 2016 (UTC)

Blocking the Content Translation Tool

This was enacted. Please see Wikipedia:Administrators'_noticeboard/CXT for follow up discussion. — xaosflux Talk 01:18, 29 July 2016 (UTC)

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

There is currently a discussion regarding activating a filter against the WMF content translation tool from creating pages on the English Wikipedia. Please see Wikipedia:Administrators'_noticeboard#Content_translator_tool_creating_nonsense_pages if you are interested. Thank you, — xaosflux Talk 00:36, 27 July 2016 (UTC)

Especially the last section (Wikipedia:Administrators'_noticeboard#Activating_Abuse_Filter). — xaosflux Talk 00:37, 27 July 2016 (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.

English Wikipedia spokesperson

I've been thinking for a while we should have someone who speaks for us. Jimmy Wales speaks for the whole Wikimedia movement including the foundation and other projects but his foundation board membership obliges him to put the foundation's interests before ours. I'd like us, the writers and builders at en.Wikipedia, to have someone who can speak for us with the foundation, other Wikimedia entities and the wider world. I can think of a couple of people who would fill that role well, and would love to have the opportunity to nominate them. --Anthonyhcole (talk · contribs · email) 12:22, 21 July 2016 (UTC)

Actually, there's more than a couple. I'd trust User:Opabinia regalis, User:Drmies, User:Newyorkbrad, User:Gorilla Warfare, User:Bishonen User:Keilana and many others with the role. They all have good sense and good knowledge of en.Wikipedia governance and society and some have public roles. User:Doc James and User:Daniel Mietchen are very engaged on the wikiprojects' behalf with outside institutions. --Anthonyhcole (talk · contribs · email) 13:22, 21 July 2016 (UTC)

  • Ha, thanks, but I'm probably the last person you want to speak for "us". I'm like Donald Trump: I shoot from the hip and speak from the gut and retweet whatever comes my way. I nominate NYB and OR, though. Can I get a second? Drmies (talk) 14:14, 21 July 2016 (UTC)
  • Like most everything, the devil's in the details. For starters, what assurance would there be that any spokesperson would speak for the (pseudo-)majority of the community, regardless of their personal feelings and biases? ―Mandruss ☎ 14:20, 21 July 2016 (UTC)

Aren't there prior discussions about this??? Millbug talk 02:38, 23 July 2016 (UTC)

  • That list looks a bit like Arbcom... ansh666 01:03, 27 July 2016 (UTC)
  • Anthony, some of the chapters (not projects) have official spokespersons. It's easier to have such a position when there is a formal organization, rather than whoever volunteers doing whatever they want. For example, User:Doc James does a great job of representing Wiki Project Med Foundation, which has a board of trustees and a list of official members. But it's much harder to apply that concept to the whole of English Wikipedia. It'd be like picking a single spokesperson for New South Wales – after removing all immigration controls. WhatamIdoing (talk) 17:23, 29 July 2016 (UTC)

Content Translation Tool: 5000-Edit Requirement

This was enacted, please see follow up discussion at WP:AN/CXT. — xaosflux Talk 05:06, 31 July 2016 (UTC)

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

Earlier today, an edit filter was enabled to restrict the Content Translation Tool. There is currently a proposal to lower the 5000-edit requirement for users who wish to use the tool. If you are interested, please see Wikipedia:Administrators'_noticeboard#Lower/Change_the_5000-Edit_Bar?.

Thank you, Tony Tan · talk 11:43, 28 July 2016 (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.

Generate references in one click

If you want to be able to generate complete references with a single click, then you can use this script: User:Ark25/RefScript but it works only for a limited number of sources (newspapers). If you are using Visual Editor, then mw:Citoid doesn't fill all the fields. We just need the WMF board to create a super-simple web standard and to promote it. In time, more and more publications will adopt the standard, because it will benefit them to be cited on Wikipedia. The people in the WMF board know people in the media and in the blogosphere so they can start moving things. Please support the proposal to implement this standard here: mw:Topic:T8ai4z0p2fcql0ot and then you won't waste huge amounts of time doing robotic tasks like copy-paste author, publication date, title in order to fill the thousands of references you add into articles. We need to get out of the Stone Age and if you support this proposal then we have better chances to succeed. Thanks. —  Ark25  (talk) 20:22, 23 July 2016 (UTC)

Ark25, is there any chance that I could convince you to learn how to write Zotero translators (=the existing open-source web standard for sources)? The citoid service produces complete citations – for all sources that have been properly documented in the standard. If you added your list of sources to their longer one, then not only Wikipedians but also scholars all over the world could be benefitting from your work. Whatamidoing (WMF) (talk) 17:26, 29 July 2016 (UTC)
@Whatamidoing (WMF): What are the Zotero translators? Can't find the word "translator" in the Zotero article. Or are you inviting me to translate the Zotero article into other languages? Is there any chance that any newspaper would adopt the Zotero standard even just for experimenting so that Citoid (and scripts like RefScript or WebRef) can generate complete references? Do you know any Wikipedian or anyone else that has a blog or news website and that would implement the Zotero standard on their website, providing the title, author name and publication date for each article/post? —  Ark25  (talk) 19:46, 29 July 2016 (UTC)
A "Zotero translator" is a script on the Zotero website that says where to find the author, date, title, etc. in the HTML. It's rather similar to what you have done, only not limited to Wikipedia. Citoid and other scripts use the information in the Zotero translator to find all the stuff. The newspaper doesn't have to be involved in this at all, which means that people can write these translators even if the newspaper doesn't care. Zotero translators are how the citoid service currently gives complete references for Google Books, the New York Times, PubMed papers, and many other websites.
User:Czar knows more about how to get started with that than I do. You can watch this YouTube video to learn more about it as well. Whatamidoing (WMF) (talk) 20:08, 29 July 2016 (UTC)
@Ark25: "Can't find the word "translator" in the Zotero article" - You can now; I just added Zotero#Translators. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 31 July 2016 (UTC)
  • @Ark25, if Citoid isn't filling all the fields, it means either (1) the Zotero translator (that matches the regex for that URL) isn't finding the right XPath for the text, (2) that Citoid isn't using the right translator, or (3) no translator has been written. Full list of translators at https://github.com/zotero/translators. To test whether a page has a translator, download Zotero (citation manager software) and the plugin for your browser. The context menu for the browser plugin will put the name of the default and other potential translators in parentheses. Translators are fairly easy to write using "Scaffold" and "framework". See one of my recent translators (e.g., Eurogamer.js) as an example. You may also be interested in User:Salix alba/Citoid.js for the one-click generation you mentioned. I recently wrote a script that scrapes the page for bare refs (my preferred way of adding refs) and automatically expands them—need to generalize it a bit and add some bells and whistles before it can become a bot/tool. I should also add that Zotero uses an "Embedded Metadata" (abbreviated as "EM" on GitHub) that works as a catch-all for all sites that don't have specific translators. It falls back on the major metadata standards and is really great (it collects junk sometimes but it's better than nothing). We were recently working to iron out why EM wasn't working in the Zotero Translator Server (which Citoid uses) but last I checked it was a problem with Citoid and not the Zotero's translator server function. In any event, that should cover many more of the cases that bother you. czar 20:40, 29 July 2016 (UTC)

@Whatamidoing (WMF): @Czar: Sorry, I really don't mean to be rude but I feel exasperation right now. So I came here again, after two years, asking again for creating a super-tiny standard that require about maximum 15 minutes to create, and to try to talk with various people (including the W3C staff) and websites to implement them. Because I am extremely tired to update my script all the time. Please notice that websites like nytimes.com or bbc.com have about 10 different formatting styles for their data. So you need about 10 different translators just for one website(!). And they are adding another formatting style every couple of years. On top of that, sometimes they change the formatting style for all (or many) of their past articles. My script (RefScript) doesn't only work for Wikipedia, it works for any other site. I am using for quickly posting nicely formatted links (references) on forums too, so it's not only for Wikipedia references. My script generates a reference in 1 second, while Citoid is slower. RefScript (and WebRef too) is doing in the source editor what both Citoid and Zotero do together in the Visual Editor.

And now you are asking me to improve Citoid too by always teaching and updating Zotero just like I am doing with RefScript! Just like my script, in order to keep up with the changes, Zotero will accumulate gazillions of lines of code - this is not the solution, and we need a standard, that, in time, it will be adopted, slowly but steadily.

Sorry to ask this but do you people understand that this is a Sisyphean task (= a work that is pointless and that never ends) simply because the newspapers always add new formatting styles all the time and sometimes they even change the formatting style of the title, publication date and author name for all the articles published in the past? I am working at RefScript since 2011 and I really know what I am talking about. I am sick of having to update it all the time. That's why standards exist and are necessary, in order to make the people's life easier.

If there would be a standard like the one I am talking about, then, for the publications that implement it, both RefScript and Citoid would generate the full references without having to add any translator, rendering Zotero useless, or at least reducing it to a 10-lines script. Also RefScript would be reduced to a 10-lines script. Just like Zotero, RefScript contains tons of translators that would become unnecessary for the sites that implement the standard.

None in the WMF board have their own blog and they even don't know anyone having a blog to test such a tiny standard? Really???

Right now I feel like I want to cry. I feel like this a dialogue of deaf people :( —  Ark25  (talk) 21:36, 29 July 2016 (UTC)

Surely you can understand that creating a new metadata standard is nowhere near a 15-minute creation, especially when sufficient metadata standards already exist as the long result of technocratic collaboration. If your complaint is the need to write custom translators, realize that the solution is not another standard but the adoption of those that already exist. A single custom translator can check against multiple different RegEx captures (e.g., different URL set-ups). If you don't mean or want to be rude, it usually helps to cool down before responding. czar 01:20, 30 July 2016 (UTC)
Creating a new standard is almost never the right solution. Whatamidoing (WMF) (talk) 08:19, 31 July 2016 (UTC)

There is an existing standard: COinS. See also the proposed citation microformat. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:11, 31 July 2016 (UTC)

@Czar: It is 15 minutes. Here is the standard (let's call it OpenCite):

  • <span class="cite_title">Rude Wikipedia editor is flaming the Village Pump</span>
  • <span class="cite_publication_date">January 25, 2000</span>
  • <span class="cite_author_name">Joe Sixpack</span>
  • <span class="cite_publication_name">Computing Times</span>

Now you can take another 15 minutes to add a few cosmetic changes and it's done.

In order for a translator to check more (mutliple) different RegEx, you have to actually include more translators into that translator. As I said, the more translators you add, the more work it needs to update them since the newspapers constantly change the way they format those fields (date, author, title). So adding translators is not the solution, but creating a standard that would render the translators useless is.

@Whatamidoing (WMF): what you said there about standards does not apply here. There is no such existing standard at all, so there won't be any competing standards. That's the reason I came here after all - because such a standard does not exist yet. Obviously, if there would be such a standard, I wouldn't have asked to create a new one. And competition is good, a new and better standard has better chances to be adopted than a half-baked, existing standard. Also, according to what you are trying to say, the creation of HTML5, HTML4, HMTL3, CSS4, CSS3, etc was useless, since the HTML2 and CSS1 standards already existed - and that's clearly not the case. Is anyone being paid for writing code or to update Zotero, by the way? I wouldn't write translators for Zotero or for RefScript even if I would be paid for that.

You didn't answer to the question if there is any blog in the reach of the WMF board where such a standard can be tested. So I've created an html page as an example. Let's imagine that I have a news web site and this is a news that I've posted today: https://dl.dropboxusercontent.com/u/46152682/rude-wikipedian-flames-the-board-2016-07-31.htm

That html page is formatting the title, date, author's name and publication name according to the standard presented above. Now, for any other publication that uses this standard, Zotero and RefScript (and any other script) needs only a single translator. That means maximum 20 lines of JavaScript code that works for every single web site that adopts this standard.

@Pigsonthewing: COinS seems to be a standard for bibliographic references (for books) - is there any way it can be used by news websites? How can I use COinS for example in the news article on my web site in order to specify the title, publication name, publication date and author's name?

Thanks. —  Ark25  (talk) 19:30, 31 July 2016 (UTC)

@Pigsonthewing: Wikipedia:WikiProject Microformats/citation looks very much like a standard that I'm asking for. However, I don't understand the role of class="reference-accessdate". This is an element specific only to Wikipedia references, I don't see the point for a newspaper to include such a field. Daily Mail has a somewhat related field: <span class="article-timestamp-label">Updated:</span> 19:35 GMT, 31 July 2016 - for example in this article. But "reference-accessdate" depends on when a Wikipedian creates a referece, and the newspaper can not predict when that will happen. —  Ark25  (talk) 21:01, 31 July 2016 (UTC)

I've just noticed that the user Pigsonthewing worked as a Wikimedian in Residence for the Royal Society of Chemistry, Thinktank, Birmingham Science Museum and many other institutions. Those institutions have news feeds - for example this section - http://www.rsc.org/news-events/articles/ - here is an example article - http://www.rsc.org/news-events/articles/2016/jul/uk-science-and-the-eu/

Since Wikipedia and those institutions already have a very good relation, it's extremely hard to believe that they won't implement the OpenCite standard or Pigsonthewing's citation standard — hCite(or COinS - if COinS can be used here) on such news, if the WMF board would ask them to do that. In time, more and more sites and publications would adopt the standard. —  Ark25  (talk) 20:32, 31 July 2016 (UTC)

Firstly, class="reference-accessdate" is in the existing markup, before the application of the microformat; it's not listed in the set of classes that form the microformat. You can find a [guide to implementing http://ocoins.info/ here]. And no, we can't expect the types of organisations you list to add markup just because we ask them to - it's far from trivial, and would involve re-engineering their various content management systems, which are supplied to them commercially, by third parties. You massively underestimate the effort, cost, and time to would take to do that. In the several years since I drafted that proposal, we haven't even got agreement to apply it to Wikipedia's own citation templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:43, 1 August 2016 (UTC)

There's another "standard" that's quite widespread now for scholarly publications: the one required for inclusion in Google Scholar (it is of course supported by the Zotero translators, hence Citoid). I doubt the WMF would have enough leverage to push for yet another standard which would be redundant with COinS or Dublin Core meta tags. Webmasters will only follow guidelines if they have a very clear interest to do so (for instance, inclusion in Google Scholar). − Pintoch (talk) 17:22, 1 August 2016 (UTC)

@Pigsonthewing: if the format is not applied to Wikipedia's own citation templates and that's because the WMF board doesn't care. I really doubt that nobody would listen to Wikipedia, which is among the the ten most popular websites. In order to apply the standard, the commercial CMS software just has to change a little bit what it sends out when it converts it's database information into a HTML. For example in this article in the NY Times, instead of sending <time class="dateline">, it will have to send <span class="cite_publication_date">. The result would be indeed a massive improvement, but this is not a massive effort at all. The problem is that the WMF board doesn't bother to at least try to promote such a standard in the newspapers. —  Ark25  (talk) 02:48, 3 August 2016 (UTC)
@Pintoch: Google Scholar and COinS are designed for books, not for online news so they are not suitable here. I wouldn't dare to ask a news website to include something like this into their HTML pages: <span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.issn=1045-4438">. Dublin Core can be used by the newspapers but it was not designed with online newspaper articles in mind. It should be extended to make it more friendly for news websites and then promoted to various media organizations. For example to add an "author(s)" field as a complement for "creator" and to also use <span> instead of <meta> - since most of the newspapers already use such fields and for them, adding <meta> would be an unnecessary complication. —  Ark25  (talk) 02:48, 3 August 2016 (UTC)

Arbitration Committee minimum age raised

Snow close. This clearly isn't going to happen. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 3 August 2016 (UTC)

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

I'd wish to propose that the lower age limit for those serving on the Arbitration Committee be raised. Few other organisations or companies of Wikipedia's size, challenges, or assets would have Board Members in their early twenties. Twenty year olds, however capable, and intellectually and emotionally mature, lack the life experience and emotional experience necessary for optimum judgement on many of the sometimes stressful and fine grained issues that face the Committee. It is unfair on them, and it is not right for the project. I propose the age limit for Committee membership be 30 and upwards, but certainly at least older than what the current limit is. Engleham (talk) 08:38, 3 August 2016 (UTC)

  • Oppose and [citation needed]. Pardon, but enacting a policy like this needs some evidence at a minimum that there is an actual problem to solve. Theories often aren't borne out by reality. This proposal would require policing someone's personal information, too, and that needs some good reasons to do.Jo-Jo Eumerus (talk, contributions) 08:46, 3 August 2016 (UTC)
  • Oppose Arbcom isn't the board of directors. As a company director myself (registered with Companies House, but not under the name Redrose64), my responsibilities are mainly to ensure that the company transacts its business within the law, and to ensure that audited annual accounts are filed on time. I don't arbitrate between two employees who have a dispute. --Redrose64 (talk) 09:56, 3 August 2016 (UTC)
  • Oppose - age doesn't automatically bring good judgement, and youth doesn't automatically preclude it. -- Euryalus (talk) 10:05, 3 August 2016 (UTC)
  • Oppose for two reasons: a) unenforceable b) Emily. BethNaught (talk) 10:14, 3 August 2016 (UTC)
  • Oppose ArbCom is deeply flawed in many ways, but no one has shown this particular issue to be the problem. Collect (talk) 13:40, 3 August 2016 (UTC)
  • Oppose. First, ArbCom is not a "board". It is explicitly forbidden from making binding content decisions or enacting policy. The "Board", in that sense, is the community at large. Second, I think these Boards as a whole would do well to include a better age mix. It wouldn't hurt them to have some younger voices who haven't yet learned all the "Can't do that, can't do this". And like such, ArbCom is a body. If one person comes up with a terrible idea, the rest will shoot it down. Finally, I have no idea the exact age of anyone I was on the ArbCom with, but I'm reasonably certain several were under 30. Their input was as good, valid, and reasonable as anyone else's, and losing that due to an arbitrary limit would be a shame. (For reference, such a restriction wouldn't have affected me.) Seraphimblade Talk to me 13:52, 3 August 2016 (UTC)
  • Oppose While I partly agree with the proposer that wikipedia has too many child admins and people running the site and that you wouldn't make kids county judges, some of the older folk here are often just as bad at times. It's also not practical as anybody can claim whatever age they wish on the Internet.♦ Dr. Blofeld 15:50, 3 August 2016 (UTC)

I've SNOW closed this, but {{Archive top}} doesn't seem to like my sig. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 3 August 2016 (UTC)

The problem is that your sig contains an equals sign (three actually, but only the first one counts). The solution is to explicitly number the parameter. --Redrose64 (talk) 19:59, 3 August 2016 (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:WikiProject Frank Sinatra

Hi, if anybody thinks they might be interested in working on some Frank Sinatra related articles feel free to sign up. At present it's just something to loosely tie a lot of material together and help organize it.♦ Dr. Blofeld 11:38, 5 August 2016 (UTC)

Discretionary sanction template should not be given to good new editors

Closing per WP:SNOW. Also, Discretionary Sanctions are issued under the authority of Arbcom, so this rule would need to come from Arbcom. Monty845 01:06, 6 August 2016 (UTC)

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

In conflict related pages, experienced editors often give DS alerts to new editors. Sometimes, this is being misused to scare new editors. New editors get confused seeing such notices on their talk page. This is a form of WP:BITE. Any new editor with a clean block and not more than two warnings in their talk page, should not be given such DS alerts.

Proposal- If any experienced editor gives Discretionary sanction alert on the talk page of new editor with a clean block log and no history of warnings as edit-warring, personal attacks, then the experienced editor should be blocked for WP:BITE. --1.39.38.230 (talk) 15:07, 5 August 2016 (UTC)

Not even warned, just summarily blocked? Good luck with this... You might also want to clarify what you mean by "old". I'm 41 years old, but I'm guessing that's not what you mean. Or did you mean any old editor? DonIago (talk) 15:19, 5 August 2016 (UTC)
Ah, the IP edited their proposal after my initial comment, FWIW. DonIago (talk) 16:40, 5 August 2016 (UTC)
Snow no. They should be confused only if they don't actually read them. The notice template begins with, in the very first line in italics, "It does not imply any misconduct regarding your own contributions to date." Moreover, they're only bitey if you consider "warning high voltage" or "caution speed bumps" signs bitey. Finally, they're given to strip the possibility that people editing in the kinds of contentious areas covered by DS can avoid sanctions by saying that they didn't know about the sanctions. A 1-revert-rule is really a 2-revert-rule, if an editor can get away with it the first time by saying "I didn't know" and thus increasing the disruption at these already-difficult pages. No, just plain no. — TransporterMan (TALK) 17:41, 5 August 2016 (UTC)

Snow no per TransporterMan. These notices are information, not biting, and that is clearly stated. In any case, biting is not blockable. ―Mandruss ☎ 18:16, 5 August 2016 (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.

Make the "Watchlist" button more useful

There could be a preference called "Display a green bullet next to the 'Watchlist' button to indicate one changed page in your watchlist", which could be useful to keep editors motivated in seeing what is going on. Gamingforfun365 (talk) 22:31, 4 August 2016 (UTC)

I'm not opposed to this, but would it help much? Once you get beyond a few dozen pages watched, it'll be be green all the time. In my case, it would be so green as to blind me. Hello, my name is A D Monroe III, and I'm a watchlist addict, currently over 2000 pages. --A D Monroe III (talk) 23:19, 4 August 2016 (UTC)
Gff365, I've already made a user script that displays a "You have new talk page messages"-style badge in the top row; you might find it useful. Enterprisey (talk!) (formerly APerson) 02:16, 8 August 2016 (UTC)

Redesigning the Main Page

As the above is a regular topic on the MP talk page, could a 'separate page for such discussions' be created - there appears to be some support for the idea.

Ideas when ready for general discussion (such as that involving linking the pictures to the topic on the list) can #then# be posted to the MP TP. Jackiespeel (talk) 17:54, 11 August 2016 (UTC)

RFC: should galleries use mode=packed by default?

This discussion has demonstrated that mode=packed is advantageous in many but not all situations. There is insufficient consensus to change the default behaviour and many editors have suggested splitting the default of desktop (default traditional) and mobile (default packed) versions. Editors are welcome to change instances of galleries to packed mode as they see fit. The decision on default mobile behaviour is left for a separate straw poll. Deryck C. 12:29, 21 September 2016 (UTC)

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

Galleries currently use mode=traditional by default, producing a gallery like this:

Should they be change to use mode=packed by default, as below?

(pictures from Wikipedia:Featured pictures/Fungi) —  crh 23  (Talk) 12:29, 24 June 2016 (UTC)

  • Very Strong Oppose -- The captions don't justify correctly with packed mode. An encyclopedia should not only have good looking pictures, but even more importantly it should have excellent typography. Take a look at the following examples:
TRADITIONAL MODE- - - - - - - -PACKED MODE
  • Slide frames, 1940 (metal or card) to 1985 (plastic)
    Slide frames, 1940 (metal or card) to 1985 (plastic)
  • A single slide, showing a color transparency in a plastic frame
    A single slide, showing a color transparency in a plastic frame
  • What packed mode is all about.
    What packed mode is all about.
 - - - - - - - -
  • Slide frames, 1940 (metal or card) to 1985 (plastic)
    Slide frames, 1940 (metal or card) to 1985 (plastic)
  • A single slide, showing a color transparency in a plastic frame
    A single slide, showing a color transparency in a plastic frame
  • What packed mode is all about.
    What packed mode is all about.

You would never see a printed encyclopedia with such a poor caption layout. The purpose of PACKED mode is to cram as many pictures and captions onto a webpage as possible, like sardines packed in cans. This is just a bad idea for WP.

Additionally, on a personal opinion level it may seem trivial but I actually like the traditional look. It reminds me of old-fashioned film slides which were often used in schoolrooms and laboratories before the advent of digital projectors. Somehow these just feel more "academic" to this old bear, and I am of the opinion that an academic feel is the right feel for an encyclopedia. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:17, 19 July 2016 (UTC)

  • Support: yes, please change to packed mode. Visually it is far superior. Thanks. Fylbecatulous talk 14:48, 24 June 2016 (UTC)
  • Support Adam Cuerden (talk) 15:21, 24 June 2016 (UTC)
  • Strong Support - Much better styling. It is visually less jarring to have the top and bottom of images aligned, even in the case of mixed landscape and portrait images, rather than have them arranged erratically inside of gray boxes. Where space is need for longer captions, the width and cellwidth parameters can be used. This style of image presentation is consistent with leading image gallery websites like flickr.com and 500px.com. - MrX 15:22, 24 June 2016 (UTC), 11:34, 25 June 2016 (UTC)
  • Support - Evad37 [talk] 15:30, 24 June 2016 (UTC)
  • Oppose I don't think "packed" mode should be used by default. Images of visual art are not optimally displayed in "packed" mode.

    I've notified WikiProject Visual arts of this here. Bus stop (talk) 17:22, 24 June 2016 (UTC)

Note that this would become the default, not the only style. Visual art images could still be displayed in the old style, the galleries would just need a simple update (which could potentially be done with WP:AWB. The question is whether this is a better style for the average image gallery on WP. —  crh 23  (Talk) 18:41, 24 June 2016 (UTC)
@Bus stop and Crh23: I'd say that that's only true if the traditional-style gallery is modified. Rembrandt#Gallery is hardly the default; it modifies heights, widths, and perrow parameters. We could look for modifications in those (without mode= being specified) and add mode=traditional by bot. Would that suffice? Adam Cuerden (talk) 19:41, 24 June 2016 (UTC)
As in modify instances of the gallery tag under the scope of WikiProject Visual arts that have parameters to include mode=traditional? That seems like a good compromise to me. —  crh 23  (Talk) 21:05, 24 June 2016 (UTC)
  • That wasn't discussed or decided. Two people states their opposing opinions; only one person there held the opinion that you claim was "decided". KSFTC 03:53, 25 June 2016 (UTC)
  • Again, this RFC covers the whole of WP, not just presentation of visual arts. Also note that the single article in question (which is what was decided before) would not be affected if we went ahead with the exclusion for WikiProject Visual arts as discussed before. —  crh 23  (Talk) 07:12, 25 June 2016 (UTC)
  • Support given that for most galleries this produces better out, but recognizing that a project like the Visual Arts might want to be able to use the current style to give more space between images, they would just have to add the necessary keyword in the wikicode. It's not a requirement that all galleries need that space, just that most other uses of galleries outside of visual arts really don't need it and are better suited by the larger images and tighter packing. --MASEM (t) 00:47, 25 June 2016 (UTC)
  • Support, as a large improvement. Enterprisey (talk!) (formerly APerson) 00:48, 25 June 2016 (UTC)
  • Support - in the majority of uses of gallery, this'll be a noticable improvement ... the traditional border is really very ugly indeed and in almost all instances serves no useful nor decorative purpose. --Tagishsimon (talk) 00:55, 25 June 2016 (UTC)
  • Support The images will display larger, which is a benefit to everyone, but especially to mobile users. Cullen328 Let's discuss it 01:02, 25 June 2016 (UTC)
  • Support per above. An unambiguous improvement. MER-C 03:06, 25 June 2016 (UTC)
  • Strong oppose. This proposition has been skewed from the outset. The galleries above depict images that are virtually the same size, proportion and horizontal positioning. As soon as upright images are placed into the mix, a major problem with the packed mode arises. The upright images will appear much smaller than those placed horizontally, as the captions stream downward narrowly. While this can be adjusted in the standard gallery mode, it cannot in the packed mode, since the height of images in packed are all identical. The choice of images above does not represent a random selection of images that would potentially find their way into a typical wikipedia article. This selection makes the packed mode look better than otherwise. I suggest we scrap this proposition, since a more realistic selection of images (of random proportion and positioning), such as shown below, would not yield the same consensus result:
Note, with various image formats the standard gallery produces a homogenous layout (above), while mode-packed (below) results in a widely disproportionate grouping of images sizes and text layout.
Conclusion: The current standard gallery is much better equipped to deal with various image formats than packed mode, and should therefore remain the default gallery mode. In special cases, the packed mode may be more useful, in which case the packed mode may be chosen. Coldcreation (talk) 07:10, 25 June 2016 (UTC)
A note to Edokter. If the default mode is changed to packed mode, the result in the vast majority of cases (with both horizontal and upright images) will resemble the gallery shown directly above, i.e., most galleries would not benefit. The traditional rendering mode should remain the default. Only in 'special cases, where all images are horizontal, pack mode may be implemented in a satisfactory manner. No need to make it the default. Coldcreation (talk) 18:02, 25 June 2016 (UTC)
  • Support. "Packed" gives a much more modern appearance. The layout can of course be previewed and tweaked before saving, see below. See #Mobile view above for previewing on mobile, which is where most readers will see the gallery. Possibly before implementation a bot should run through the articles that contain galleries adding "mode=traditional" to any that do not have a mode specified and have more than five images. Excessively large galleries are usually inappropriate – they belong in Wikimedia. Aymatth2 (talk) 19:21, 25 June 2016 (UTC)

  • Clavariadelphus, by Dr. Holger Krisp
    Clavariadelphus, by Dr. Holger Krisp
  • Ramaria stricta à Javerlhac-et-la-Chapelle-Saint-Robert, Dordogne
    Ramaria stricta à Javerlhac-et-la-Chapelle-Saint-Robert, Dordogne
  • Ramaria sp., possibly R. stricta
    Ramaria sp., possibly R. stricta
  • Annual report of the Regents - New York State Museum, by Dr. Holger Krisp
    Annual report of the Regents - New York State Museum, by Dr. Holger Krisp
No matter how the packed mode is tweaked the result is unfavorable when horizontal and upright images are packed together. The result is neither more modern, practical, or aesthetically pleasing. The example posted by Aymatth2 serves as proof. The result is disastrous when viewed on a large screen, a laptop, a tablet, and even worse on a mobile phone. And by the way, even in the special case, where images are all horizontal, the traditional gallery (e.g., widths="190px" heights="140px") is just as useful, if not more, than packed mode: Coldcreation (talk) 22:31, 25 June 2016 (UTC)

Standard gallery with heights and widths optimized:

Packed

  • Possibly User:Coldcreation has a wider screen than I have. For me, the traditional view shown above with widths="190px" heights="140px" spills onto a second line and looks quite awkward, while the packed view does not. Large galleries tend to have problems anyway – a link to Wikimedia Commons is better. The packed mode looks much better on a mobile, which most users will use to view articles. See screenshots below, traditional view to the left, packed to the right:
|| ||
If it looks better on mobile, it is better. See #Mobile view above for previewing on mobile, which is where most readers will see the gallery. Aymatth2 (talk) 22:47, 25 June 2016 (UTC)
On mobile devices the packed mode makes some images look larger than others, rather than exhibiting a homogenous grouping of photos. That is not better. And let's not forget the other half of viewers that use laptops and desktops. There is little doubt that the current standard (traditional) gallery mode is more homogenous in that sizes are practically identical, whether upright or horizontal. This mode is more versatile in that both height and width can be adjusted, in addition to the number of images per row, whether centered or not. There is no need to change the default gallery, for something that is less versatile and displays images in disproportionate sizes relative to one another. Again, the "Support" votes would not have been so numerous had the gallery comparison at the top of this section represented a typical grouping of images (with both horizontal and vertical images). This proposal is misleading. Coldcreation (talk) 13:20, 26 June 2016 (UTC)
  • The last I saw was 60% of online traffic is from mobile phones and tablets, and rising. I suspect the mobile % for Wikipedia is much higher than that. People look things up on their phone and use the desktop more for video. As shown above, the modern packed view gives larger images on a phone, with less scrolling. It is hard to see why it is important to have all the images roughly the same (small) size. When same-size matters the old-fashioned framed view will still be an option, but it should not be the default. Aymatth2 (talk) 14:04, 26 June 2016 (UTC)
  • I'm kind of annoyed that some of the people arguing against the proposal are not putting things on a level playing field: They're comparing mode=packed to a carefully adjusted heights-and-widths mode=traditional, then declaring their carefully manipulated work as a better default setting, when they're not even showing anything remotely resembling a default. I could tweak the heights= parameter on mode=packed until I liked it - but we're trying to judge a default, not something hand-tweaked for every single gallery. Adam Cuerden (talk) 16:32, 26 June 2016 (UTC)
  • This pole is skewed not because the traditional gallery format (at the top of this proposal) has not been height and width adjusted. It is skewed because the packed mode only looks good when horizontal images are chosen. That is what was chosen above. I made it a point to show a packed gallery when vertical images are placed into the gallery. That is precisely when the problem with mode-packed arises. It so happens that mode-packed cannot be adjusted (as the current default) to fix this problem, since the height of all images in mode-packed are always identical. That is why vertical images appear undesirably small and horizontal large; exponentially with extended proportions. This, as mentioned above, leads to a further problem with mode-packed: the captions associated with vertical images stream downwards in narrow columns. These problems do not arises with the current default gallery. Coldcreation (talk) 18:26, 26 June 2016 (UTC)
  • This is a somewhat valid point, but vertical images aren't arranged excellently by default currently - a gallery with both vertical and horizontal images will probably need adjustment anyway. —  crh 23  (Talk) 20:00, 26 June 2016 (UTC)
  • Fussing too much about layout is a waste of time. Maybe 80% of page views will be on a mobile, with the images arranged vertically. Packed mode gives bigger images with less scrolling, so is better for those 80% of views. A carefully tweaked layout that looks great on your PC will look poor on my laptop and horrible on his tablet. Best to avoid big galleries anyway. Art galleries show pictures of all different sizes, and so do art magazines. We can too. If relative size really matters a composite picture will be the most predictable solution. For all practical purposes packed is the best default. Think mobile. Did I mention #Mobile view above? Aymatth2 (talk) 03:35, 27 June 2016 (UTC)
  • Annulation - I demand the annulation of this survey since the opening post shows an optimized mode-packed set up exclusively with horizontal images (arguably the only configuration that 'looks good' compared with the current default gallery). Had upright images been included the majority of voters would likely have opposed the default switch. Coldcreation (talk) 12:08, 28 June 2016 (UTC)
    No, there's an example of mixed orientation images directly above. Your assumption about how the majority of voters would have votes is unfounded. The style that you are so fond of does not reflect best practices for image galleries across the web. - MrX 12:26, 28 June 2016 (UTC)
    This is not a survey, it is a request for comment. People don't just read the heading and the !vote, they look at the previous responses. Further, the proposal is not to entirely remove traditional galleries, just to make them no longer the default. It has been stated that for galleries without upright images (which is probably a majority) and on mobile (which is a major percentage of the userbase), packed galleries look better. —  crh 23  (Talk) 12:42, 28 June 2016 (UTC)
You say "they look at the previous responses". Yes, "they look at the previous responses" which have been unduly influenced by an improperly designed initial example comparing the two methods of displaying images. Bus stop (talk) 18:32, 28 June 2016 (UTC)
Actually, most photos are probably shot in the upright position (especially on mobile devices). Ironically they are the cause of the problem in packed mode. And 13 (out of 16) people had already cast a votes before I posted the packed mode with upright images in the mix. Following that post, one user retracted his "support" vote. Others may not have been back to see the problems created by the insertion of upright images into a mode-packed gallery. Also, I've never had any problem visualizing images with the current standard default gallery on my mobile phone. They look fine to me. Why change it to a default that is not versatile? Here is another example of mode-packed, with an exaggerated variety of image formats, for emphasis: Coldcreation (talk) 16:44, 28 June 2016 (UTC)

Packed mode

Current default gallery:

In this specific case, of a gallery with upright photos with captions, it is true that packed is inferior (except on mobile, all traditional does is add an ugly border). The question is, however, is if this the majority of cases. It is almost trivial to change a gallery back to traditional mode, for those cases where it is necessary. Note also that even in traditional mode narrow pictures are very hard to make out, as they render so small, so the gallery would need knowledgeable tweaking anyway, rendering the point moot. —  crh 23  (Talk) 17:10, 28 June 2016 (UTC)
Also, I still think that the only real place we see a significant occurrence of upright images in galleries is for art, which we have already said we can change with AWB or a bot. —  crh 23  (Talk) 17:12, 28 June 2016 (UTC)
@Crh23: There's that word again. In which sense are you using it? --Redrose64 (talk) 18:04, 28 June 2016 (UTC)
@Redrose64: As in irrelevant. Had not idea that there was an ambiguity there, I'll try to stop using it, thanks! —  crh 23  (Talk) 18:43, 28 June 2016 (UTC)

Test, mode=nolines:

  • Note, the gallery above has not been formatted. Note too the caption problem, similar to that produced in mode-packed. Coldcreation (talk) 10:24, 30 June 2016 (UTC)
  • There are various ways to format images, none worth spending much time over given how variable the rendering will be on different devices:
Long and low ones display very poorly in the traditional framed format (left), rather better in packed format (centre). And there is always the option of do-it-yourself photo-editor format (right), common in articles about large cities, e.g. London. But Wikipedia is for people to look up information. Wikimedia Commons is where they go for images. mode=packed is a good basic default for formatting a few snapshots of the subject that will look o.k. on a phone. Aymatth2 (talk) 01:20, 30 June 2016 (UTC)
  • Wikipedia is for people to look up information and images. Practically all of these images can only be found on Wikipedia (English). They are in public domain in the US as published before 1923. They are not at Commons as not public domain worldwide. 1. Mode-traditional, 2. mode=packed and 3. mode=nolines (shown above) all have advantages and disadvantages. There is no perfect default gallery. Coldcreation (talk) 10:23, 30 June 2016 (UTC)
  • Support – Cleaner look overall. Attention should be given to cases with thin pictures and long legends, perhaps tweaking the packed mode to have a minimum width per entry. — JFG talk 11:07, 2 July 2016 (UTC)
  • Support this change to the default. It's not ideal for every combination (neither is any other setting, including the current setting), but it is overall an improvement for the majority of galleries that I'm familiar with. We should additionally provide clear, unambiguous guidance to editors that the default is not required and can be overridden in any article (subject to the usual rules about boldly improving articles and never edit warring). WhatamIdoing (talk) 21:16, 3 July 2016 (UTC)
  • Support for mobile only. It produces poor output with long captions on desktops too often, to make it the default in general. This should really be done with a set of templates for different layouts, some with short or not captions, others with a lot of detail.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  16:15, 6 July 2016 (UTC)
  • Strong oppose, stop, and rerun with proper examples per Coldcreation; to me, traditional mode is actually the more clean, consistent layout. ansh666 18:41, 10 July 2016 (UTC)
  • Oppose As demonstrated by Coldcreation, this mode doesn't handle varying aspects ratios well and in particular the captions are a jumble. In an encyclopedia, the captions are just as important as the images; both must look good and the captions be easily readable. It might be possible to fix a packed mode with a minimum width based on caption font size, but typographically, this mode is not ready for prime time. --Mark viking (talk) 19:19, 19 July 2016 (UTC)
  • Support - getting rid of the frames would be a good idea. They draw attention to themselves and distract from the presentation of the images - what Edward Tufte calls a "dominating grid". While the caption problems are real, this can be handled on a case-by-case basis and by good editing of captions. Blythwood (talk) 22:40, 19 July 2016 (UTC)
    Getting rid of the frames can be done with the traditional layout as well. Diego (talk) 12:18, 20 July 2016 (UTC)
  • Oppose, while packed often seems more pretty, the uniformity of the traditional mode always works, so is a much better default. (Something that is nicer in 90% of cases and fails in 10% of cases is clearly worse than something that never fails). We can encourage people to use packed mode where it works. —Kusma (t·c) 09:16, 20 July 2016 (UTC)
  • I concur with Koala. The decision should be taken considering which layout will cause less problems if left unchecked, not if it is tweaked. If the editors creating the gallery know enough to change layouts, they can as well learn to create fine-grain adjustments, and therefore they're not affected by the default case. Diego (talk) 12:11, 20 July 2016 (UTC)
An apology to @Redrose64:, @Coldcreation:, @Kusma:, @Blythwood: and everyone else.

Please accept my deepest apology for this edit, and my sincere gratitude to Redrose64 for reversing it.

I am utterly clueless how that happened and deeply sorry that it did. The only thing I was trying to do is add a comment in reply to Kusma's statement (see the Line 485 section in the diff) -- the "doesn't make sense" edit summary was describing that comment -- but somehow I royally screwed up and I am so very sorry. I would never intentionally delete another editor's comments. I have in fact counseled others on the evil of that behavior. My mind was boggled at how this could have happened. If you look at the Line 456 & Line 469 sections of the diff you will see quite a bit of text being added so it is even more confusing as to what occured.

In the end it does not actually matter how this happened, only that it should not have happened, that it was not intentional, and I am truly sorry that it happened at all. -- Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:24, 20 July 2016 (UTC)

No problem Koala Tea Of Mercy. It was obvious enough, in looking at the edit history at the time, that an involuntary mistake had been made. Best, Coldcreation (talk) 10:02, 21 July 2016 (UTC)
  • Since this is drawing to a close, I'm going to give a !vote. At the end of this discussion, I find myself opposing making code=packed the default, not due to the way the pictures are presented (which I am quite partial to in most cases), but due to the mess it tends to make of captions. I would propose mode=nolines as an alternative, but it looks like the captions are not vertically aligned on that, which is also inferior. I still think mode=traditional looks a bit odd (I don't like grids!), but at the current time I can't see a good alternative for default. —  crh 23  (Talk) 19:02, 20 July 2016 (UTC)

Convenience break in packed mode discussion

  • Stop - I'm pretty sure we can stop voting on this topic. The objectivity of this discussion has been compromised. The initial post does not accurately represent a typical gallery. It excludes upright images and more lengthy captions, both of which create severely problematic results in mode=packed. Tweaking serves not since image heights are always identical. Mode=packed should only be used in rare cases where image formats are all horizontal. The current default does not present problems. Images, however, do appear smaller. This has been considered a shortcoming on mobile devises. A simple click on an image (to view it larger) resolves this issue. Coldcreation (talk) 10:29, 3 July 2016 (UTC)
With respect, this RfC has been open for only nine days at the time of writing this, it would be improper to close it so soon, even if you consider your opinion on it to bethe final one. We will let it run a while longer, until a consensus has been reached (as currently you are in an exceptionally vocal minority in this RfC). You also have yet to respond to the suggestion that we use a bot to, where necessary, fix already inserted galleries in their current form. As to your comment that the poor displaying in mobile view can be fixed with a simple click, the same applies on desktop. We are not removing tradition view, just making it an option (which is almost no additional effort if you have to add other options anyway to make the gallery display correctly). Additionally, do you have any statistics as to the nature of images in a gallery together (all horizontal/vertical), as I would assume that images in a gallery would (outside of visual art) all be similar to one another. Further, looking above at a gallery with vertical images, it doesn't look too bad, and the problem looks like it only arises when images have extreme aspect ratios, like File:Marcel Duchamp, 1911, Coffee Mill (Moulin à café), oil and graphite on board, 33 x 12.7 cm, Tate, London.jpg. —  crh 23  (Talk) 11:43, 3 July 2016 (UTC)
Consensus cannot be obtained objectively in this RfC since the first 13 votes were posted relative to the idealistic "all horizontal images" galleries—the only configuration where packed-mode appears without defects. Coldcreation (talk) 11:59, 3 July 2016 (UTC)
A typical article will feature images that are both horizontal and vertical. See Category:Images for a random selection. Note that while horizontal images appear to be more abundant, vertical images are highly present. Note too that image aspect ratios are not restricted to 1:1, 4:3, 3:2, 5:3. They are often 16:9 or 3:1, or even more extreme in difference. The further from 1:1 (a square format) the more defects (described above) will manifest themselves in mode=packed. Clicking on an image will make it larger (on any device) but it will not fix the problems associated with mode=packed when vertical images and more substantial captions are introduced. (See below) Coldcreation (talk) 12:23, 3 July 2016 (UTC)

Selection of random images, shown in mode=packed (captions are the file name)

  • File:Andenes. Vista de la terminal. Estació de Francia.jpg
    File:Andenes. Vista de la terminal. Estació de Francia.jpg
  • File:Anusvara.jpg
    File:Anusvara.jpg
  • File:Cocktailshaker, Norsk Folkemuseum, NF.1976-0544AB.jpg
    File:Cocktailshaker, Norsk Folkemuseum, NF.1976-0544AB.jpg
  • ile:Bahuvrihi samaasa.jpg
    ile:Bahuvrihi samaasa.jpg

To see these images (and others) in the current default mode, see Wikimedia Commons, Category:Images, Media in category "Images". The assumption that disparate aspect ratios exist only (or predominantly) in the visual arts is erroneous. Coldcreation (talk) 12:40, 3 July 2016 (UTC)

Grabbing random images is hardly a fair comparison, but nonetheless I think that that looks fine for all the images except [[:]] (ironically), which is a diagram and thus wouldn't be included in a gallery anyway. A closing user will see your comments and weigh them fairly when trying to judge consensus, this isn't a vote. (Also, I didn't claim that it would only be in visual arts, just that it would be much rarer outside of that area, as encyclopaedic photographs are usually shot horizontally) —  crh 23  (Talk) 12:53, 3 July 2016 (UTC)
For those who are too lazy to click on the link, here they are in traditional mode:
  • File:Andenes. Vista de la terminal. Estació de Francia.jpg
    File:Andenes. Vista de la terminal. Estació de Francia.jpg
  • File:Anusvara.jpg
    File:Anusvara.jpg
  • File:Cocktailshaker, Norsk Folkemuseum, NF.1976-0544AB.jpg
    File:Cocktailshaker, Norsk Folkemuseum, NF.1976-0544AB.jpg
  • ile:Bahuvrihi samaasa.jpg
    ile:Bahuvrihi samaasa.jpg
And here is how traditional (left) and packed (right) modes will appear to most readers:
- File:Screenshot 4 of random images on mobile device.png
Aymatth2 (talk) 13:21, 3 July 2016 (UTC)
@Aymatth2: Did you purge before doing the left screenshot? I ask because I just cropped a significant border out of it, which looks to be present in your image. —  crh 23  (Talk) 13:38, 3 July 2016 (UTC)
@Crh23: That is interesting. I added the "traditional" gallery above at 12:57 and then took the screenshots a few minutes later, one after the other. I do not think I refreshed the page between screenshots, just repeatedly scrolled, Alt+PrtSc, paste, crop, save. I obviously did not pick up the effect of your 12:48 crop of the "award" image in the "traditional" view, but did in the packed view. Very odd. Anyway, I redid the first image, so here are the four for a fairer comparison: Aymatth2 (talk) 14:33, 3 July 2016 (UTC)
- File:Screenshot 4 of random images on mobile device.png
  • Again, in either case (both which appear fine on a cell phone), a viewer can click on an image to see it larger. The downside is that on both tablets and computers (desktops and laptops) packed mode is not fine when vertical images are juxtaposed with horizontal images. Coldcreation (talk) 15:40, 3 July 2016 (UTC)
  • Strong oppose for desktops; Support for mobile only - I never use this myself, so based on what others says. Objections for desktops are well made above; a long previous discussion re paintings (where the important part of the image goes right to the edge, unlike the fungus portaits here) concluded that the packed mode made these harder to see properly. Johnbod (talk) 15:24, 7 July 2016 (UTC)

Split this for platform?

  • I think we can. The logic would need tweaking, but it does not seem major. I would prefer to see =packed the default on both fixed and mobile, but feel more strongly about mobile. Aymatth2 (talk) 02:20, 4 July 2016 (UTC)
  • I would support mode=packed as the default for mobile clients, while retaining the current default (mode=traditional) for other devices (laptops, desktops etc.). Not sure where iPads and other tablets would fit in. Coldcreation (talk) 18:46, 4 July 2016 (UTC)
  • Note, my suggestion above is just what the "default" (i.e. parameter-less) behavior would be - I think any explicit parameter should take precedence. Also, I'm not exactly sure "where" to code this for type - but we have a lot of people that can probably help! — xaosflux Talk 18:59, 4 July 2016 (UTC)
  • No this is not possible. At least not with the current technology. And I don't think it is likely that the developers will add more divergence, when they have been trying to close the divergence for years. —TheDJ (talk • contribs) 19:47, 4 July 2016 (UTC)
    Thanks for the note @TheDJ: - so no options with mobile specific .js/.css here? (I really have not dove in to the mechanics of this element yet). — xaosflux Talk 19:52, 4 July 2016 (UTC)
@TheDJ:. I would suggest something like:
If mode is not specified
If mobile
set mode to "packed"
Else
set mode to "framed"
End if
End if
That would be easy to implement in COBOL, the language I am most familiar with, or PHP. Is the problem that the developers would be opposed to having any special logic for old-fashioned non-mobile devices? Aymatth2 (talk) 22:49, 4 July 2016 (UTC)
Everything is possible (it is code afterall), but that doesn't make it a good idea. You are happily stepping over the dozens of caching layers that will have to vary on such a difference as well as many other specifics. This is a top 10 website, not your local computer. —TheDJ (talk • contribs) 07:34, 5 July 2016 (UTC)
  • The fixed and mobile modes already get different gallery layouts, and the code already deals with null and invalid modes. The change may be no more than replacing $mode = "framed"; with $mode = "packed"; in one place that deals with mobile galleries. Caching should not be a concern when the change is made in just one place. The possibility should not be dismissed out of hand if there is consensus here that it would be a real improvement. Aymatth2 (talk) 10:56, 5 July 2016 (UTC)
at the level you are talking about, there is no difference between mobile and desktop. That's only at levels after the skin is added. There is no different layout between mobile and desktop currently, only different styling. Varying on framed vs. packed does require different layout however, which means splicing the content and object cache between mobile and desktop, roughly doubling the size of those caches. This will not happen. Many other things can happen, including changing the styling of the gallery on mobile to be different from the one on desktop, changing the default overall etc etc. But not what you are suggesting. —TheDJ (talk • contribs) 12:10, 5 July 2016 (UTC)
  • @TheDJ: Perhaps the question was poorly phrased, and implied a specific technical solution. To put it differently, the effect we are after is:
  • Where mode has not been specified, the mobile view of a gallery should take an appearance similar to that of a mode=packed gallery, while the fixed view of a gallery should take an appearance similar to that that of a mode=traditional gallery
  • Where mode has been specified, the mobile and fixed views should be as they are today
The question is whether there is any way to achieve this without too much difficulty. I hesitate to suggest an approach, but possibly it would help to have a sixth mode called "default" in addition to the "traditional", "nolines", "packed", "packed-overlay" and "packed-hover" modes. Aymatth2 (talk) 15:07, 5 July 2016 (UTC)
Think it's pretty clear the vote is for mode=packed on all platforms, by a large margin. Adam Cuerden (talk) 23:17, 6 July 2016 (UTC)
"Disputes on Wikipedia are settled by editing and discussion, not voting." And "Consensus is not what everyone agrees to, nor is it the preference of the majority. Consensus results in the best solution that the group can achieve at the time." Per WP:WHATISCONSENSUS. Consensus appears to favor the use of packed-mode (as default) for mobile devices. Coldcreation (talk) 10:05, 7 July 2016 (UTC)
While true, you also lost the debate. Consensus is also for using it on all platforms, with Visual Arts galleries being hit by a bot to keep them in traditional mode before the changeover (I'd personally be inclined to do that for any gallery with the widths= and heights= parameters set as well. Adam Cuerden (talk) 22:27, 15 July 2016 (UTC)
Let's wait and see. There may be no need to change the default to one that creates serious problems within captions, and introduces widely disparate image scales on non-mobile devices. Coldcreation (talk) 08:17, 16 July 2016 (UTC)
And there may be no need to leave the default as one that turns wide or tall images into ribbons with no real details visible. Again, you're comparing a hand-tweaked traditional mode with untweaked packed, and saying the former is better, when actually packed is far, far better at handling wide images out of the box, and neither handles very tall images well. Adam Cuerden (talk) 08:48, 16 July 2016 (UTC)
Panoramic images do not generally go in galleries (e.g., see here). Traditional and packed show identical upright images. Mode-traditional (default) needs to be compared to mode-packed (default), with both horizontal and upright images. Coldcreation (talk) 10:48, 16 July 2016 (UTC)
At Commons, of course, panoramic images are in the default mode=traditional. They look just fine. See Category:Uncategorized panoramics, and Category:Vertical panoramics. I would hate to see either of these in packed mode, with their respective captions. Coldcreation (talk) 11:13, 16 July 2016 (UTC)
  • I agree. I would still like to pursue the idea that "mode=default" could give distinctly different styles on fixed and mobile, but that is another discussion. Aymatth2 (talk) 00:17, 7 July 2016 (UTC)

Packed mode with upright panoramic images (selected from here). Note the streaming down of captions, here simply the file name, rendered non-readable.

  • File:2007-07-25 Alp Grüm vertikal 04.jpg
    File:2007-07-25 Alp Grüm vertikal 04.jpg
  • File:2011-04-07 15-17-57 Italy Trentino-Alto Adige Caldaro sulla strada del vino - Kaltern an der Weinstrasse.jpg
    File:2011-04-07 15-17-57 Italy Trentino-Alto Adige Caldaro sulla strada del vino - Kaltern an der Weinstrasse.jpg
  • File:2008-10-12 Flums 01.jpg
    File:2008-10-12 Flums 01.jpg
  • File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
    File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
  • File:2011-08-02 15-11-18 Switzerland Diavolezza 8hp.jpg
    File:2011-08-02 15-11-18 Switzerland Diavolezza 8hp.jpg
  • File:Avenue de la République (Paris), numéro 22, porte 01.jpg
    File:Avenue de la République (Paris), numéro 22, porte 01.jpg
  • File:Elektrownia Siersza 8.jpg
    File:Elektrownia Siersza 8.jpg
  • File:Sagrada Familia interior stereographic vertical panorama 2010.jpg
    File:Sagrada Familia interior stereographic vertical panorama 2010.jpg

Packed mode with horizontal panoramic images (from here). Note the enormous size of the images, unsuitable for a gallery presentation.

  • File:2 Stunden Wartezeit vor der Fähre Glückstadt-Wischhafen (2008-08) - panoramio.jpg
    File:2 Stunden Wartezeit vor der Fähre Glückstadt-Wischhafen (2008-08) - panoramio.jpg
  • File:87527 Sonthofen, Germany - panoramio.jpg
    File:87527 Sonthofen, Germany - panoramio.jpg
  • File:87544 Blaichach, Germany - panoramio - holger mohaupt.jpg
    File:87544 Blaichach, Germany - panoramio - holger mohaupt.jpg
  • File:87544 Blaichach, Germany - panoramio.jpg
    File:87544 Blaichach, Germany - panoramio.jpg
  • File:A courtyard - panoramio.jpg
    File:A courtyard - panoramio.jpg

Packed mode with horizontal and upright panoramic images. Note that both problems observed above are compounded here.

  • File:2007-07-25 Alp Grüm vertikal 04.jpg
    File:2007-07-25 Alp Grüm vertikal 04.jpg
  • File:2 Stunden Wartezeit vor der Fähre Glückstadt-Wischhafen (2008-08) - panoramio.jpg
    File:2 Stunden Wartezeit vor der Fähre Glückstadt-Wischhafen (2008-08) - panoramio.jpg
  • File:2008-10-12 Flums 01.jpg
    File:2008-10-12 Flums 01.jpg
  • File:2011-04-07 15-17-57 Italy Trentino-Alto Adige Caldaro sulla strada del vino - Kaltern an der Weinstrasse.jpg
    File:2011-04-07 15-17-57 Italy Trentino-Alto Adige Caldaro sulla strada del vino - Kaltern an der Weinstrasse.jpg
  • File:87527 Sonthofen, Germany - panoramio.jpg
    File:87527 Sonthofen, Germany - panoramio.jpg
  • File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
    File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG

Traditional mode with horizontal and upright panoramic images. Note, images are homogeneous in size, captions are readable, the viewer can click to enlarge. Perfect for a hypothetical gallery presentation.

  • File:2007-07-25 Alp Grüm vertikal 04.jpg
    File:2007-07-25 Alp Grüm vertikal 04.jpg
  • File:2 Stunden Wartezeit vor der Fähre Glückstadt-Wischhafen (2008-08) - panoramio.jpg
    File:2 Stunden Wartezeit vor der Fähre Glückstadt-Wischhafen (2008-08) - panoramio.jpg
  • File:2008-10-12 Flums 01.jpg
    File:2008-10-12 Flums 01.jpg
  • File:2011-04-07 15-17-57 Italy Trentino-Alto Adige Caldaro sulla strada del vino - Kaltern an der Weinstrasse.jpg
    File:2011-04-07 15-17-57 Italy Trentino-Alto Adige Caldaro sulla strada del vino - Kaltern an der Weinstrasse.jpg
  • File:87527 Sonthofen, Germany - panoramio.jpg
    File:87527 Sonthofen, Germany - panoramio.jpg
  • File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
    File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
  • File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
    File:2012-08-19 13-00-12 Switzerland Kanton Graubünden Alp Grüm 4h v39°.JPG
  • File:A courtyard - panoramio.jpg
    File:A courtyard - panoramio.jpg

Coldcreation (talk) 15:45, 16 July 2016 (UTC)

These are also hardly realistic examples. Show me one extant gallery that looks at all like the last one, and I'll show you a gallery that should've been hand-tweaked years ago. Adam Cuerden (talk) 14:29, 16 July 2016 (UTC)

Improving packed ?

I guess there is something we could do serverside to improve the concernes surrounding 'thin' elements in packed mode. First, we could set a minimum width on a thumbnail, so that it will never be smaller than say 100px. This would improve the visibility of the text, but would break up the 'packedness' of the packed mode. Then again, if you are adding thumbnails less wide than 100px, you are already doing something wrong in my opinion (adding an almost indistinguishable image), and this would just be a 'safesty net'. Call it the readability-over-prettyness option. An alternative would be to detect when the width of a thumbnail is below 100px, and automatically adapt heights to make sure the width is at least 100px. That might have some technical blockers however. Can't be sure until I have looked further into that. —TheDJ (talk • contribs) 20:27, 4 July 2016 (UTC)

This would probably be the perfect solution, removing the problem with packed mode. User:Coldcreation is pretty sure that very thin images are present in the majority of galleries, so if the system can be adapted to work with them better that would be good. —  crh 23  (Talk) 21:52, 4 July 2016 (UTC)
Upright images are present in a wide variety of galleries, not necessarily Ultra Panavision 70 or silver ratio. Coldcreation (talk) 22:35, 4 July 2016 (UTC)
The only advantage of trditional mode for them, under default settings,isthat thecaption will be legible - any substantially tall image in a traditional-mode gallery, without tweaking, is going to be a meaningless ribbon anyway. Traditional mode, however, handles wide panoramic images incredibly poorly with default settings. We can find failure points for anything. Adam Cuerden (talk) 04:38, 14 July 2016 (UTC)
Substantially 'tall' images in traditional-mode appear virtually identical in size as in mode-packed. As you point out, the caption will be readable in the former; in the latter not. In traditional-mode, panoramic images are homogenous in sizes relative to upright images. In packed-mode, however, panoramic images may appear several orders of magnitude larger than upright images. There is no compelling justification for displaying images of greatly disparate scales under default gallery settings. Coldcreation (talk) 21:09, 14 July 2016 (UTC)
Just remove the extra padding from traditional, done. Samsara 08:32, 15 August 2016 (UTC)

Improving traditional ?

The largest drawback of the traditional layout seems to be the gery grid. As one editor pointed out, Tufte's advice is to get rid of decorative "ink" that doesn't provide information. If you get rid of the grey box, you get the improved looks of the packed version without the drawbacks of distorted captions and messy layout of irregular images.

You can give it a try yourself - if you squint slightly and look at the traditional layout, the grey lines vanish and you'll get a glimpse of the result, which looks like an orderly version of the packed layout with more white space and more regular captions. Diego (talk) 08:58, 20 July 2016 (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 keyboard shortcut layouts, 2 each, Color Blind friendly

Hello, I would like to create two wikipedia based keyboard shortcut layouts. They would cover the two Wikipedia implementations for editing 1) Source Editor and 2) VisualEditor. Here are the specifics I need help on:

  1. Edits of the raw data/text of the keyboard shortcuts table groups, i.e.; Should the VisualEditor's Layout list the CLIPBOARD shortcut keys? Remove the CLIPBOARD group and replace the shortcuts with Zoom, Full Screen, Print, Cursor movement? Logic, Clipboard ⌃ Ctrl + C, etc shortcuts are kindergarten knowledge for this 'age of information', scrub them out and list other shortcuts increasing editor skills.
  2. The implementation of the key icons, i.e.; Is a given icon too big, too small, should it be color coded to match table groups? Or should the icons or keys be filled with a patterns of; horizontal lines, vertical lines, dots, dashes?
  3. To satisfy the Color Blind friendly request i.e.; Should there be two versions of a given layout one version is color coded, while the other version is published as gray scale or is a 'combined' layout a better or worse idea?
  4. Keyboard key icons, should the individual keys styling be a derivative of the current Wikipedia Key/Button templates; Template:Key_press Ctrl ⌘ Cmd, Template:Key_top ⌃ Ctrl ⌘ Cmd or Template:Button Ctrl?

The items above are BASIC ideas, please let me know of anything else that you can think of while reviewing this workup.

Here is the link for BOTH the 'Source Editor' and 'VisualEditor' shortcuts DRAFT;
http://vwanweb.blogspot.com/2016/07/wikipedia-shortcuts-source-edit.html

I have an idea to create a combined color and Color Blind friendly version by applying different stroke (boundary) styles to a given set of keys that make up a 'group of keys'. As an example all Site Navigation Keys will be enclosed with brackets [ X ], while Current Article Tools would be completely enclosed in a rectangle, see graphic link above.

Your feedback is welcomed.

Vwanweb (talk) 08:03, 5 August 2016 (UTC)

You could leave wider margins around each panel, to take advantage of the law of proximity and separate each section from the others; it looks cramped with the current grey separators. Otherwise, the grouping by colors is easy to follow, so the overall structure is easy to follow. Diego (talk) 10:32, 5 August 2016 (UTC)
I rather think that this is a WP:VPT matter, somebody may already have written a gadget. But please don't post code proposals to blogspot, not only is it outside the Wikimedia foundation, my virus scanner does not like that site one bit. --Redrose64 (talk) 19:14, 5 August 2016 (UTC)
  • Thank you Diego I widened the margins under DRAFT02, if you have time can you check if the margin edits are in-line with your guidance or did I have a 'dee dee dee' moment and misunderstand your feedback Vwanweb (talk) 19:27, 5 August 2016 (UTC)
  • This isn't a code proposal, it is simply a keyboard layout in support of the current shortcuts available to wikipedia viewers and editors. Vwanweb (talk) 19:27, 5 August 2016 (UTC)
  • I added the DRAFT for the VisualEditor to link above, I would appreciate any feedback, please note I am trying to make the two shortcut versions color blind friendly. Vwanweb (talk) 09:57, 6 August 2016 (UTC)
  • I was thinking about the space between tables. "Personal tools" is too close to the "Z...Main page" above it, and "Site navigation" too close to "Firefox-Mac OS X". Instead of the grey bar, it's best to use wide strips of white space as separators among blocks. Diego (talk) 12:56, 6 August 2016 (UTC)
  • Now that you've added the colorblind-friendly signs to the keys, I don't think using positions of the lines alone is enough to differentiate among the different groups of keys. You could try to differentiate each group with a different line texture, like discountinous and dottetd lines, double lines, and "bold" lines with more weight. Diego (talk) 13:05, 6 August 2016 (UTC)
  • Thanks again Diego, I will beef up the thickness of the separators for the tables. Gentle reminder there are 2 each keyboard layouts; one is without icons and is for use under the 'Source Editor' (b. Edit Source, DRAFT 02), the other shortcuts layout (a. VisualEditor, DRAFT 00) is for the 'VisualEditor' version, hence the icons placed on the appropriate keys. What are your thoughts on version a. VisualEditor? Thank you very much for all of your help on this workup. Vwanweb (talk) 19:59, 6 August 2016 (UTC)

Graphic updates:

VisualEditor 01 and Source Editor 02 Shortcuts
VisualEditor draft 01 notes:

  1. Table groups: dotted lines changed to unique styled lines per group.
  2. Function and Punctuation keys reduced height to allow for addition of document title text.
  3. Table removal of Clipboard group? These shortcuts exist web wide, research to replace with potential html shortcut (access) keys.
  4. Table text increased line spacing of text to remove dead space at bottom of table, see draft 00.


Source Editor draft 02 notes:

  1. Widened the margins of table groups. (lower half)
  2. Added strokes (borders) to combination and shortcut (access) keys

Any and all feedback is appreciated, please help.
Vwanweb (talk) 01:07, 9 August 2016 (UTC)

If Ctrl-[ is really a Visual Editor shortcut, it's a terrible one. What, for example, am I meant to press? Alt Gr-8 is the [ on my keyboard. The / shortcuts also don't work as well when / is Shift+7. Adam Cuerden (talk) 10:39, 13 August 2016 (UTC)

It's a very standard one for indentation in editors though. I understand that not everyone has an English style QWERTY keyboard of course, but there is only so much you can do to deal with that and this is the English wikipedia after all. However, do note that this particular command has 2 shortcuts, tab and shift-tab trigger the same commands as ctrl-[ & ] do. Similarly, ctrl-/ has in addition ctrl-shift-/ which actually is the same as ctrl-? should be accessible on most keyboards. The only reason ctrl-/ probably even exists is because it requires one key fewer than ctrl-? on en-US keyboards. —TheDJ (talk • contribs) 09:36, 15 August 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_133&oldid=1161044806"