Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:

New ideas and proposals are discussed here. Before submitting:
« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132
Centralized discussion
Proposals: policy other Discussions Ideas
For a listing of ongoing discussions, see the dashboard.

Note: entries for inactive discussions, closed or not, should be moved to the archive.

Confirm on save when adding links to disambiguation pages[edit]

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 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)
      • No-one's forcing them to fix them. If they chose to, that's there priority. I don't really give a shit about them being "more productive". Lugnuts Dick Laurent is dead 09:56, 21 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. Mb66w (talk) 19:57, 25 May 2016 (UTC)
I second Mb66w'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)

Discussion[edit]

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

Interactive chess boards[edit]

Bumping thread for 30 days. Fred Gandt · talk · contribs 16:34, 28 May 2016 (UTC)

I would like to see a chess widget in chess articles which allow you to go through the moves as exists in other sites. Peace. — Preceding unsigned comment added by 37.46.38.33 (talk) 23:07, 11 May 2016

What encyclopedic benefit would this extra utility offer? See what Wikipedia is not before answering.
As a keen chess player, code wrangler with a bent for UI and UX, and general autodidact, I can see value in interactive resources that assist reader's understanding. But, wouldn't simple animated gifs be enough? Fred Gandt · talk · contribs 23:54, 11 May 2016 (UTC)
A chessboard, programmed using standard notation, could provide an alt automagically, but that's about the only benefit. You might also be able to allow users to consider variations, but that's of questionable value in chess, I suppose. --Izno (talk) 00:25, 12 May 2016 (UTC)

This is probably possible using mw:Extension:Graph, and if it not is currently possible the plugins can installed to make it possible, as d3 or some variant is used in the backend. See:

I don't think Animated gifs provide the same level of help, given the desire to "scroll" through the game. Nothing really interactive here other than being able to take steps backwards and forwards.(In fact I'd like to be able to do this with Animated gifs) Naraht (talk) 14:22, 12 May 2016 (UTC)

This does add encyclopedic value, the same way that video or audio do. Otherwise there would be no need for anything aside from static images or text in any article. It would also add a nice way for readers to have a more interesting view of chess articles or gain a better understanding of them. In any case, even if wikipedia doesn't see any use for it, this would certainly be very useful for wikiversity. 197.218.80.220 (talk) 14:09, 12 May 2016 (UTC)

  • Support: This would add value to the chess articles on Wikipedia by letting users play through games and game fragments at their own pace without having to set up the position on a chessboard. Strawberry4Ever (talk) 15:03, 12 May 2016 (UTC)
  • I've had enough of your filthy attitude kipod; this comment was added in good faith at the start of a thread about implementing interactive chess on Wikipedia. I simply thought it worth mentioning that there exists some software that might be useful. It was not a suggestion that we should use it (as-is at least) or that we should even be using anything like it. Polite conversation on any subject should be open to all manner of input that is quite obviously relevant, as it may inspire/reveal paths worth following. However, since you joined this thread (and another linked discussion), all I (personally) have received from you is negativity; you are targeting me and anything I do or say with complaint. I would ask that you act more in accordance with the best interests of the project, and keep your personal issues to yourself. Hypocritical of me to discuss this with you on a public stage? If I am attacked in public, I shall respond in public. That is all I have to say on this matter. Fred Gandt · talk · contribs 17:12, 1 June 2016 (UTC)
i have no idea how am i supposed to react to this kind of attack. i will only say i read your last comment. קיפודנחש (aka kipod) (talk) 00:35, 2 June 2016 (UTC)
  • Support. It would make many chess articles more accessible, by allowing readers to step forwards and backwards through games, at their own pace. It would also be much less work for editors than animated gifs: you just include the display widget (or template, or whatever it becomes) along with a game record, instead of having to create an animated gif with 30-odd frames. Maproom (talk) 21:29, 12 May 2016 (UTC)
  • Support gifs don't have the ability to scroll through or stay on a particular ply for a particular amount of time. For people reading about a particular game, being able to analyze the board for as long as they wish is highly encyclopedic as they can look at it and come to their own conclusions about the value of a particular move. Further, it allows editors to discuss particular moves and readers to look at them on a board as they read an article. Wugapodes (talk) 18:23, 13 May 2016 (UTC)
  • Strong Support for the idea in general. See below for some background. — Rhododendrites talk \\ 13:52, 17 May 2016 (UTC)
  • Support. This would have tremendous encyclopedic benefit for wikipedia's chess articles. We talked about this a while ago but somewhere along the line we lost momentum. What would we need to do to implement Kipod Nakhash's script or similar on English wikipedia? Ideally we'd want to be able to use it for side lines as well, like the one they use at chessbase.com (sample page). MaxBrowne (talk) 02:15, 18 May 2016 (UTC)
  • Comment. While I can't say I've decided one way or another yet, this proposal is very exiting. Above, What Wikipedia is not was cited, and looking through it I really can't find any reasons why this proposal would be disruptive in that sense. Frankly, what Wikipedia is not, in my mind, is just a simple encyclopedia. Adding something like this could be a step towards redefining how we compile meaningful information, and I don't think it should automatically be discounted just because it could't exist in a book. Tpdwkouaa (talk) 01:28, 19 May 2016 (UTC)
  • Comment FTR and Support: I'd just like to add for the record that my citing NOT was only aimed to ground the proposal before it flew ahead with grand notions contrary to NOTHOWTO - which would could almost certainly end in political opposition. I personally agree with Tpdwkouaa (and others), would go a long way further and would love to see a more aggressive move away from treating Wikipedia like a paper bound encyclopedia, but that's just my personal opinion, and not the current consensus (I disagree with consensus quite often). As long as this functionality doesn't get too fancy, and is purely used to visually demonstrate what is practically impossible to describe any other way, I think the proposal can stand against opposition based on it not being encyclopedic. Technically, it can be a walk in the park; HTML5, JS and CSS make the web an almost magical place; where there's a will, there's a way. Fred Gandt · talk · contribs 02:31, 19 May 2016 (UTC)
  • Strong support In this day and age people should not have to whip out a chess set in order to understand an article like Modern Benoni. An interactive chess board would motivate me to write more articles like that. Cobblet (talk) 16:47, 21 May 2016 (UTC)
  • Support I've gommented, but I haven't formally said I support the idea yet... Two things to think about. 1) GPL and 2) what should the readers for the Blind do with the gadget?Naraht (talk) 20:43, 21 May 2016 (UTC)
  • Support Absolutely. It's much easier than trying to visualize all the moves on a mental chessboard. Altamel (talk) 17:38, 22 May 2016 (UTC)
  • Support. Herostratus (talk) 03:23, 18 June 2016 (UTC)

Discussion (chess)[edit]

I've added {{bump}} to the thread to keep it alive. I think it best we maintain the conversation here for a while, since it's not a trivial proposal (additions to MW JS and CSS), and although I haven't helped by stalling the proceedings (nearly there!), it still needs input from many more users before there's any chance of a technical implementation being even considered for site wide adoption. Fred Gandt · talk · contribs 16:34, 28 May 2016 (UTC)
I would suggest the valuable outcome of this thread is the demonstrated support for the idea in general, and that it served as the impetus to move forward with development. As for the specific implementation, when a plan is ready to go, I think it would make more sense to start a new thread focused on that proposal, pointing to the demo. This thread is already quite long and diffuse, making it difficult to get new people to read it/participate. Once there's a proposal ready to go, people won't need to know the process which led to it (to me, too much contextualization can make it seem more confusing/cumbersome than it needs to be). I started the other page to continue discussion, work out features/bugs/parameters, and work on developing a coherent proposal, operating on the assumption that a clear proposal for sitewide implementation is not imminent (i.e. there's more to the proposal than finishing a prototype). — Rhododendrites talk \\ 17:37, 28 May 2016 (UTC)
I agree with Rhododendrites. There's clear consensus for something like this to be attempted which is great. We should plan the project somewhere else, and when it' done bring it back here for an RfC to get consensus to add it to MW. Wugapodes [thɔk] [kantʃɻɪbz] 18:02, 28 May 2016 (UTC)
I would prefer the development process to be more immediately public than off and away in a quiet corner; we could work on the perfect proposal for months only to find that with the wider input of others it requires either massive reworking, or collapses. Since this topic is already out in the open, we can more quickly get a basic idea of how to proceed by tagging a child section (TBA) with an RfC and encourage readers to see how, why and when the proposal came about without explaining it all somewhere-or-when else. However, maybe that's just me; to me, it's simply more efficient to keep the ball rolling than to pick it up, put it on a shelf and dust it every now and then for a while, then take it back off and kick it. We can always collapse some of the junk, and create new sections as we go. Fred Gandt · talk · contribs 18:27, 28 May 2016 (UTC)

Past discussions[edit]

This probably would've been a good thing to ping WikiProject Chess about. :) There's even Wikipedia:WikiProject Chess/PGN Chess Viewer. The most recent discussion, I think, was this one from Dec 2013/Jan 2014. That thread references some past ones, including one here in March 2013 (there's also November 2012 and December 2012).

User:קיפודנחש (goes by Kipod) developed a template to make this work that's live over on the Hebrew Wikipedia (see also the English demo page there). There's also a prototype page on enwiki, but it doesn't look like it went anywhere.

Frankly I'm not sure where we lost the thread last time. I supported it, but wasn't very active in those threads, so let's ping some people who were: MaxBrowne, TheOriginalSoni, Mattj2, and קיפודנחש. — Rhododendrites talk \\ 13:52, 17 May 2016 (UTC)

Other games[edit]

I think that presuming Chess is done that Go would be reasonable. Not sure of others beyond that. Maybe draughts/checkers, maybe Chinese Chess.Naraht (talk) 15:23, 12 May 2016 (UTC)

I agree assuming it's technically feasible. Strawberry4Ever (talk) 15:45, 12 May 2016 (UTC)
Maproom, this might interest you. --Redrose64 (talk) 17:48, 12 May 2016 (UTC)
Thank you, Redrose64. Some embeddable Go widgets are described here, including Eidogo, which uses Javascript. Eidogo is widely used, for instance in the main English-language Go forum, e.g. here. Maproom (talk) 20:32, 12 May 2016 (UTC)
  • I'd strongly urge all those taking part in this discussion to view (and play around with) the interactive lead image at Juego de la vida which should give a good idea of just how much is possible with Mediawiki, as well as a feel for what an article containing an interactive .js game board actually looks and feels like. ‑ Iridescent 13:29, 14 May 2016 (UTC)
Iridescent Do you have any idea why that interactive tool is in the Spanish Wikipedia but not in the English Wikipedia? In English at Conway's Game of Life there are non-interactive images. Is there any barrier to copying that to English Wikipedia?
Having that kind of tool for chess would be useful for illustrating notable games. Blue Rasberry (talk) 16:07, 16 May 2016 (UTC)
Different attitudes towards embedding auto-running javascripts on Wikipedia pages, which is something the en-wiki community has always been extremely wary about as it slows down page load times and introduces security vulnerabilities. This and this were the discussions in which the proposal were blocked. User:Felipe Schenone is the guy you want to talk to about getting a chess version written, although bear in mind that enabling it here would probably need explicit authority from the WMF devs and is likely to attract fierce opposition. ‑ Iridescent 16:51, 16 May 2016 (UTC)
Hi, thanks for the mention Iridescent. I recently returned from the MediaWiki Hackathon in Jerusalem, where I worked next to Brion Vibber, Lead Software Architect for the Wikimedia Foundation, on the best way to include JavaScript widgets into Wikipedia articles. The issue is being tracked at https://phabricator.wikimedia.org/T131436 My old proposal here at the Village Pump has now evolved into the WikiWidgets project, which requires only a single line added to MediaWiki:Common.js in order to start working here at the English Wikipedia. Regarding the chess widget, I just added it to the list of requested widgets at the WikiWidgets project page, but I'm currently working on two others, so I won't promise anything. However, I checked the EidoGo source, and I may be able to turn it into a WikiWidget. I will keep you updated about this, but even if I do adapt it, the widget will not go live in the English Wikipedia unless the larger WikiWidgets project is accepted by the community. Cheers! --Felipe (talk) 17:48, 16 May 2016 (UTC)
@Felipe Schenone and Iridescent: Thanks both of you. I was unaware of these previous discussions and proposals. If the issue is raised again, then I think it would be worth reconsideration. I cannot imagine English Wikipedia community support for this right now just because of general community fear of encroachment but if there is a time when conversation can be more peaceful then I think people would want the benefits of this option. Blue Rasberry (talk) 14:14, 17 May 2016 (UTC)
At a guess, you'd need to set up a process akin to WP:BRFA to vet and approve everything before it went live. As well as the fear over security vulnerabilities, bear in mind that English (and to a lesser extent French) Wikipedia has issues which don't exist to the same degree for the other language projects, in that Wikipedia is the primary source of information for much of Africa and Asia, where internet connections are often very slow and data can be heavily metered. Thus, anything which significantly adds to page load has the potential to have significant impact on the very people the WMF are trying hardest to reach, since if it's taking too long to load the pages they'll just give up. Someone from the WMF will no doubt have the figures. ‑ Iridescent 15:45, 17 May 2016 (UTC)
The scripts could (and would, most likely) be excluded from loading in mobile view. This would largely avoid the issues you're concerned about, I think, as it is generally only mobile data that is so tightly metered. — This, that and the other (talk) 09:35, 22 May 2016 (UTC)
@This (belatedly, sorry only just noticed this), this is something where the WMF's uncomfortably close relationship with Google will be an advantage, as they've already done the legwork with regards to bandwidth and metering issues so the figures should be easy to come by. As I understand it, the issue isn't just data metering, but that internet connections in much of Africa and Asia (and a surprising proportion of the West as well, particularly rural parts of the US and Canada; even in relatively high-density and high-tech cities like London, download speeds are often incredibly low) still work at dial-up speeds, so anything which adds significantly to load times will likely cause readers to give up waiting. (As a concrete example, Google allows background-downloading YouTube videos for offline viewing in India, as their research showed a staggering proportion of users there got bored waiting for buffering to complete.) I've no idea how much embedding widgets would add to page load times (paging RexxS, who generally seems to know these things.) ‑ Iridescent 17:00, 1 June 2016 (UTC)
@Iridescent: I've had a look at the widget on the Spanish Wikipedia and it's really no bigger than a comparably sized image. I've created Java-based widgets in the past and they tend to be no more than a few tens of kilobytes in size, so I've no reason to suspect that a JavaScript-based widget would be a lot more. It's not like there's any content being streamed, as all of the work is done in the client browser after the initial download as far as I've been able to ascertain. Perhaps Felipe can confirm my impressions? If I'm right, there really is no issue with data usage: anywhere you can get static images, you'll have no problem getting these sort of widgets. --RexxS (talk) 18:48, 1 June 2016 (UTC)
@RexxS: Vivarium, the widget at the Game of life article in the Spanish Wikipedia, has two files: a 25 KB JavaScript file and a 4 KB CSS file. Formicarium, the widget at the Langton's ant article, has a 29 KB JavaScript file and a 4 KB CSS file. There is also a 4 KB initialisation script. So adding up and rounding up, loading a widget costs 50 KB. They both are pure client-side. Future widgets are likely to be similar. Cheers! --Felipe (talk) 22:17, 1 June 2016 (UTC)

PGN viewer 1[edit]

trying to answer some of the question asked above, plus some additional information:

i did a demo on testwiki last round to demonstrate the implementation, and i'll try to describe it here:

enwiki deployment recipe
  1. add a hidden gadget. this adds the script and the css to RL, but does not actually load it for any user, so there is practically no extra load/bloat for pages not containing chess games
  2. add 2 lines to common.js, such that after a page finish loading, it checks if the page contains games (by testing for some specific CSS class), and loads the viewer if needed
  3. (maybe) add a couple of lines to common.css and/or to mediawiki:noscript.css, to support correct display for readers with and without JS.
  4. create a template that displays the viewer for readers with JS enabled, or the PGN for readers with no/disabled JS.
viewer features / behavior
  • it is purely a game viewer: it is not meant to, and cannot, be used to play chess. it just shows previously played games using the games' PGN
  • like any other pgn viewer, it has forward, backward, jump to a move, and animate ("autoplay") buttons. (it also has a somewhat unusual feature: it can rotate the board to show the game from the black POV, though i am not sure how useful this is).
  • a single viewer can display any number of games, using HTML selector, and multiple viewers can exist on one page. an example can be seen on this page on hewiki, which contains every single game from Tata Steel Chess Tournament of 2013 - one viewer per round, containing all the round's games (note that the games are contained in collapsed elements - expand to see the viewer).
  • it supports FEN for initial position, so in addition to traditional games, it can be used, e.g,, for chess problems, or for Chess960
  • to support the chess community on hewiki, an editor can add a line to her personal JS page, and then the viewer shows one more button, to generate Template:Chess diagram for the currently showing position
  • the source is about 928 lines of JS and ~20 lines of CSS, weighs about 29 KB (not minified - with RL i expect it to be significantly less). it can be seen here: he:Mediawiki:Common.js/pgn.js

i will be happy to try to answer any additional question. peace - קיפודנחש (aka kipod) (talk) 05:04, 18 May 2016 (UTC)

@קיפודנחש: Thanks for the overview. Some clarifications/questions:
  1. It would be opt-in through a user's preferences (enabling a gadget)?
  2. If so, what, if anything, would be displayed for a user who does not have it enabled?
  3. When you say it may require adding two lines to common.js, you do mean MediaWiki:Common.js, correct? (as opposed to me adding it as a user script to my own common.js)
  4. If necessary, would it work as a script enabled on an individual user basis? (this is not ideal, of course -- more for my own curiosity if it would work without modifying sitewide settings) — Rhododendrites talk \\ 13:45, 18 May 2016 (UTC)
answers:
  1. i do not think this makes sense as an opt-in. opt-in features make sense for interface and behavior, not for content. there is an "inbuilt" opt-in, which is enabling JS on the browser. this is similar to other content-related behaviors, such as collapsible elements
  2. as described above, users with no/disabled JS see the raw PGN. we currently display raw PGN in many chess-related articles.
  3. i meant the site's common.js, aka MediaWiki:Common.js.
  4. this is possible, for demonstration purposes. it requires some work setting this up and testing it on this wiki, and i'll try to set up local demo (which will require loading a personal script) sometime soon.
peace - קיפודנחש (aka kipod) (talk) 14:23, 18 May 2016 (UTC)
@קיפודנחש: It looks like there's support for this, with no compelling arguments in opposition and no formal "oppose" !votes above (as of now, anyway). I don't want to see it get lost again. What do you need in order to move forward? Edits to common.js look like they have to go through MediaWiki talk:Common.js or WP:VPT. Otherwise, is there anything others can do to help? — Rhododendrites talk \\ 12:29, 19 May 2016 (UTC)
i will work on creating a full demo system here. it will probably be made of the script itself (already on enwiki, more than once - one in my userspace, and a second time where another user copied it to WP space for some inexplicable reason). i expect the demo to be comprised of the following parts:
  1. the pgn viewer script in my userspace (~ 27K of non-minified JS)
  2. a small CSS in my userspace
  3. a small "wrapper" script to load the previous two, also in my userspace
  4. a template that accepts order-based parameters, each of which is a game using the PGN notation
  5. a sample page using this template. interested users will be able to try it on any (non article-space) page
  6. an instruction page explaining what need to be done to add the whole shebang to enwiki. to implement the system, a local sysadmin will have to follow the instructions.
to review the demo, one will have to add the wrapper script to their personal js.
i am not 100% confident the demo will work for no-javascript viewers: this may require adding a line to Mediawiki:Noscript.css.
i can't commit to a timetable - i have some other obligations, but i expect this to be done by the end of the week, hopefully earlier. peace - קיפודנחש (aka kipod) (talk) 15:42, 19 May 2016 (UTC)

PGN viewer 1 - demo[edit]

ok, so i created the template and the demo.

  1. add to your personal JS page the line importScript('User:קיפודנחש/pgnwrapper.js');
  2. view User:קיפודנחש/pgn viewer demo. (notice the "flicker" when opening the page, where you see the raw PGN before it disappears and replaced by the viewer. this will not happen once all the right pieces are in place).
  3. to test it yourself, create a page and add to it
{{Pgnviewer
| 1 = pgn of game 1
| 2 = pgn of game 2
| ... up to 30 games 
}}

and open the page. the viewer is a bit restrictive about comments: comments can't be nested, and should only use { .... }, not ( ... ). if the pgn contains comments, an extra button is added, to hide/reveal the comments.

peace - קיפודנחש (aka kipod) (talk) 04:28, 20 May 2016 (UTC)

@קיפודנחש: It doesn't seem to be loading for me. I tried in both Chrome and Firefox. It flickers, but then they page is just blank. — Rhododendrites talk \\ 13:41, 20 May 2016 (UTC)
@Rhododendrites: my bad. i had a typo in the wrapper. i think i did not notice it b/c some old forgotten junk in my personal js script still loaded the script anyway... please try now (you may have to hit "refresh" or something).
however, this incident clearly shows that nobody else tried the demo. i propose that anyone participating in the discussion, will at least indicate whether or not they tried it. peace - קיפודנחש (aka kipod) (talk) 16:33, 20 May 2016 (UTC)
I haven't tested it yet but I'm planning to do so when I have some free time. Thanks for adding it. Strawberry4Ever (talk) 19:41, 20 May 2016 (UTC)

@קיפודנחש: I've tried to use it for myself, but I'm having trouble. Arbitrarily used Deep Blue versus Kasparov, 1996, Game 1, copied into my userspace. So the first attempt is User:Rhododendrites/Deep Blue versus Kasparov, 1996, Game 1 (pgn), which basically replaces removes the diagrams and turns the notation/annotations into a PGN in the template. Then I stripped the references and wikimarkup to see if that was the issue, leading to this version (there wasn't really any reason for me to create a separate page, though). Then I removed all of the annotations to see if that was the issue. Then finally removed the punctuation (exclamation/question marks). Still the same result at every step :/ What am I doing wrong? — Rhododendrites talk \\ 22:19, 20 May 2016 (UTC)

@Rhododendrites: the problem was with the PGN. i restored an older version and fixed the PGN. the problem was with the castling at move 15: the pgn you copied from wikipedia had "0-0" instead of "O-O" (zero instead of the letter O). in general, when something is wrong with the PGN, load the page with "debug=true" in the address line, and look in the JS console: the script squirts out the first difficulty it finds. in this case, it complained about move 20, so it was of limited help. eventually, i downloaded the pgn from one of many places it's available (in this case, here, only b/c it was the first google hit), and compared manually. notice, that in the version i restored, there are tons of comments: when the PGN contains comments, the buttons row grows a new button, "{...}" that lets the reader hide/show the comments. HTH, peace - קיפודנחש (aka kipod) (talk) 00:36, 21 May 2016 (UTC)
Ah! Ok thanks. So as it is, it's kind of cumbersome on the page. Some parameters to control the style of presentation would probably be necessary before incorporating it into pages. The default should probably be to hide everything other than the game board and the controls at the bottom. Given there doesn't look to be a way to use references or wikimarkup in the PGN it'll probably be preferable to keep annotations in the text of an article (or at least hide them by default). The notation is important, but takes up a lot of room that, again, could be integrated more flexibly into the text (maybe?). Maybe this would be a good opportunity to solicit implementation help at WP:VPT. — Rhododendrites talk \\ 01:06, 21 May 2016 (UTC)

PGN viewer 2[edit]

I have constructed a rough working outline for a chess game viewer using a great deal less code than kipod's PGN viewer. I've done this because 1000 lines of JavaScript required by the script to understand the rules of chess to decipher the PGN instructions is personally tough to swallow. Although PGN may be a standard, this is Wikipedia on MediaWiki and all we need is an annotated slideshow with certain UX requirements specific to the project. My intention is not to tread on toes or pooh pooh the efforts of kipod; I am just suggesting an alternative before it's too late. I'd have said something earlier, but wasn't expecting the rush to thrust this proposal forward.

I'll put together a working draft here in my userspace tomorrow sleep first. Fred Gandt · talk · contribs 08:21, 20 May 2016 (UTC)

I guess the big question for kipod and Fred Gandt is what would be gained/lost.
PGN is very well known in the chess world, which means it would be easy to (a) copy a game from a personal library or existing pgn, (b) export a game found on Wikipedia for use offline (I suppose we're getting into WP:NOT territory if we made that a priority, but would nonetheless be handy as an educational tool), and (c) include metadata and annotations. Template parameters are an obvious substitution for metadata, as it's just fields and values, but I'd be curious about what would be lost. Perhaps it's a matter of taking a ground-up approach to add code/features only as needed? We could also go with a solution that keeps the code light on the page, but have a separate tool with more features that a user can opt to use... thinking too many steps ahead now, I suppose. — Rhododendrites talk \\ 13:40, 20 May 2016 (UTC)
i can't comment on pro/con of Fred Gandt's post, because i have no idea what he is suggesting. his comment "all we need is an annotated slideshow with certain UX requirements specific to the project" is puzzling - i can't imagine what slideshow he refers to, and how the slides in the show will be generated. peace - קיפודנחש (aka kipod) (talk) 19:39, 20 May 2016 (UTC)

PGN viewer 2 code[edit]

If you can please just bare with me; I only started this yesterday (as I said, I didn't expect the rush for the finish line), and am working on en passant, castling etc. right now.
The notation I'm using is based on standard notation so it should be easy for those used to it, and essentially easy for those who aren't too.
Due to the typical last little fiddly bits being slightly frustrating, I might not have it finished tonight, but will make every effort to get something that at least offers a substantial hint up for demo. Fred Gandt · talk · contribs 01:40, 21 May 2016 (UTC)
In an aim to keep the notation as close to standard as possible, the whole thing is more complex than it practically needs to be - so I'm dragging my feet a bit. Without the notation concerns it'd be half the size and finished!
Here's what I'm working with (so far); it's a HTML file you can copy to a local file and view in your browser. For those who don't know how, there'll be a demo on the wiki soon(ish).
It's unfinished, but shows basically of what I'm doing. The use of Modules and Templates will do a lot of heavy lifting. Please reserve feedback about the actual code; it's a work in progress with all kinds of sloppy and many things to change (planned but not yet executed); I just grabbed what I have and dumped it here unedited. I'll have a fully operational Module driven template includable demo done as soon as I can. Fred Gandt · talk · contribs 07:50, 21 May 2016 (UTC)
  • Code was here, but has been moved to here.
I've updated the HTML file a few times since first posting, and it's currently nearly fully working. Once en passant is programmed and I've run a few tests and tweaked it to my liking, I'll do the next bit, which is building the Template(s) and Module(s) to wikify it for fully fledged demo.
But as you can see, there's substantially less code, and bar some tweaking after discourse, provides all the functionality we need. Fred Gandt · talk · contribs 10:43, 22 May 2016 (UTC)
I couldn't resist updating the HTML code above one last time; it's basically finished, and really cool (even though I do say so myself) Face-grin.svg
The demo game contains captures, en passant, castling and check, recovery and mate. There are more options for output than demoed, but they'll become clearer with the wikified version. The instructions will be compiled along with the HTML by the Module(s), from editor placed Template calls containing fairly standard game notation.
The code can still be whittled a bit, but that's pretty much what I propose. The Template-Module bit will come ASAP. Time to walk my dog though. Fred Gandt · talk · contribs 12:29, 22 May 2016 (UTC)
I find this disruptive. This is the proposal page, not your sandbox. Please find some appropriate place to place any code, templates, modules, and anything else required, set up an appropriate demo, and come back here once it's set up, with insrtuctions how to use it. Until then, please try to minimise the noise on this page. Thanks, peace, קיפודנחש (aka kipod) (talk) 19:06, 22 May 2016 (UTC)
It doesn't bother me. Someone tweaking code on this page is really no different from someone tweaking their comments on this page. WhatamIdoing (talk) 19:59, 22 May 2016 (UTC)
Providing updates of a demonstration (albeit not wikified yet) of a solution to a proposal is completely within the normal scope of this page's purpose. Posting chronologically unnecessary personal complaints about user activity is well outside the scope of this page's purpose and should be done on either this page's or the user's talk page. This comment I am adding now shouldn't be here, but I'm gonna cite WP:MULTI and sleep easy.
While I'm here again (unplanned): I've locked the height to a user setting so it won't make the layout jump about (the width was already user adjustable) and tweaked the code about as much as needed (possibly too far for maintainability), but that will certainly be changed in any review process before it goes anywhere near the common.js. I just have a repeat option to add (so it can be used like a .gif for little things like demonstrating en passant or castling), which shouldn't take long. Then there's all the fun of testing and finding that I did it all wrong and have to start again! ;-)
I should get the wikifying done tomorrow. Fred Gandt · talk · contribs 23:44, 22 May 2016 (UTC)
I've started work on the template and its supporting module, and the JavaScript and CSS will need to be edited a little to make them wikisafe.
I underestimated the complexity required of the module, and since I'm just a learner with Lua, it may take a little longer than I initially inferred; sorry, I will endeavour to not keep you waiting too long.
While here, I've updated the HTML again to the last version it'll ever be. From now on, all the work I do to finally make a demo will be done on the wiki. But at least you can play with the HTML demo, while you're waiting, if you like. Fred Gandt · talk · contribs 05:47, 24 May 2016 (UTC)
@Fred Gandt: There may be more than one chessboard in an article. As such, having an ID selector for the board is not compliant with HTML 5. You should change that to a class .chessboard or .chess. Probably .chessboard. --Izno (talk) 07:54, 24 May 2016 (UTC)
I might suggest also that your other HTML classes can be vague (".information"? ".black"?)--I would suggest you clean that up as well. --Izno (talk) 07:56, 24 May 2016 (UTC)
@Izno: Yep; as I said ... will need to be edited a little to make them wikisafe. The CSS especially, but there are some vital changes required to the JS to make it work here. The HTML demo is self contained; only the render and rough idea of weight are demonstrated by it. Don't worry; it's all in hand. Fred Gandt · talk · contribs 11:03, 24 May 2016 (UTC)
Nearly done; Lua was kicking my ass, but I'm fighting back. Fred Gandt · talk · contribs 10:29, 26 May 2016 (UTC)
My sincere apologies for delaying this discussion (although of course the discussion can continue without me or the scripty thing I'm building), however, the Lua is almost complete; I just have some rather complex fiddling to do to get the correct notation output. The CSS is effectively done but will require some tweaks. I've tried to make the template(s) as user friendly as possible, including an optional helper template for editors unfamiliar with standard notation. Once the Lua is finished (although it will definitely benefit from serious code review (when I'm done)), I just have the JavaScript to rewrite to work with the wikified markup which will be a quick job.
So although it's all in a constant state of flux right now, the way it's shaping up can be seen in the (also unfinished) documentation of the template. The user script will need to be added to your common or skin JS to see the demos correctly. It offers the opportunity to see what they'd look like if you had JS disabled, by loading the first wave of CSS (which would be delivered to everyone all the time without JS being involved) but not continuing unless you tell it to.
You'll note how editors are provided some visual feedback if the fallback .gif (a possible solution for users with JS disabled) is omitted or invalid in preview mode, and if the fallback is missing or invalid for noscript readers, a message is displayed explaining why they see no demo.
Obviously there will be a lot to discuss, as I'm positive changes will be requested or even insisted upon, but I would prefer to leave that until I have it fully functional please. The actual raw code (not the functionality or aesthetics) will absolutely without question need to be carefully reviewed and altered as necessary before going anywhere near the site-wide common files, so there's little point discussing it. Fred Gandt · talk · contribs 02:39, 30 May 2016 (UTC)

Request for Comment: Implementation of interactive chess boards[edit]

It is requested that the community comment on the possibility of implementing site wide, JavaScript enabled, interactive chess boards for visual demonstration of described plays. Two example implementations are available for viewing and to aid discussion of the requirements for this proposal.

Both these demonstration examples require the addition of JavaScript to your common JS to see them.

This RfC is to determine if and how such a feature might be woven into the fabric of Wikipedia such that ALL users will see the proposed functionality by default. Although not necessary, it would be helpful to please first view the demonstration examples in their scripted and unscripted conditions before commenting. Be aware that some CSS styling is also required, which is imported by the JavaScripts; the unscripted display may not be exactly as intended in any eventual site wide implementation.

Related discussions
Wikipedia:Village pump (proposals)#Interactive chess boards - the parent section of this RfC.
Wikipedia:WikiProject Chess/Interactive chess boards

Fred Gandt · talk · contribs 22:59, 5 June 2016 (UTC)

I cordially invite the community to edit (as necessary and within reason) the RfC statement above. Fred Gandt · talk · contribs 22:59, 5 June 2016 (UTC)

Chess RfC: Developer Q & A[edit]

  • How difficult would it be to generate a fallback animated GIF from the source data if one is not available? Rwessel (talk) 06:28, 6 June 2016 (UTC)
    • I've been thinking about that myself, and although something may be is (but at what cost?) possible with <canvas>, I think the required code would be unwieldy (and "derp" - requiring JS to generate); it might be possible on the back-end, but I'm not very familiar with the architecture (perhaps tools.wmflabs.org or with an extension?). It would be ideal.Fred Gandt · talk · contribs 11:16, 6 June 2016 (UTC) P.S. Another possibility is to use CSS animation as the fallback, but that would only work on modern browsers and would (without a lot of faffing about) only work when - T483 - proposed dynamic CSS is available.Fred Gandt · talk · contribs 11:26, 6 June 2016 (UTC) P.P.S. This is a job for a bot: It would monitor a category of demos with missing fallbacks, get and parse the instructions, generate the .gif (relatively trivial in PHP) and upload it to commons, then add the link to the demo. Each set of instructions can be hashed and checked against existing .gifs to avoid redundancy, and every .gif would be manufactured to a standard for continuity. This method should be preferred over user uploads, and is effectively ideal.Fred Gandt · talk · contribs 12:09, 6 June 2016 (UTC) P.P.P.S. It's possible that creating the whole bundle as an extension, thus avoiding the need for a bot, is the ideal way to implement. Falling back would be a doddle in that case.Fred Gandt · talk · contribs 19:11, 8 June 2016 (UTC)
  • The link to kipod's viewer above does not present any obvious way to see it in action. Rwessel (talk) 06:28, 6 June 2016 (UTC)
    • There's a statement at the top of the linked page that his script needs to be imported first (as with mine) to see his viewer.Fred Gandt · talk · contribs 11:16, 6 June 2016 (UTC)

Chess RfC: Comments[edit]

  • I'm going to try to start the ball rolling here, by outlining why I chose to write an alternative suggestion to kipod's. At first, my reasoning was simply that 27Kb of JS seemed like a lot of code for something that didn't strike me as requiring that much. I scrolled through his code, and learned why it was so large (relatively); it needs to understand the rules of chess to function, as it has nothing but the PGN notation to go on, and chess notation (either standard algebraic or PGN) contains little disambiguation i.e. only when a human would need it. There's no reason to expect the programming to do all the leg work; we can build the program to accept any input we like and are not limited to using PGN, a language (see below) designed for computers to read and write, not humans. Since most editors on enwiki are English speaking humans, the instructions we supply to any element of any article should be understandable to English speaking humans. It translates that plain English instructions are easier to process than PGN (with some caveats), and so the code size is reduced significantly, whilst the accessibility is increased greatly.
Further to that:
  1. I felt that his interface design (although he's updated it since) was not aesthetically aligned with Wikipedia's usual style.
  2. It's weighted in favour of displaying multiple full games in a single instance, which although handy on a chess blog or forum, seems less than useful here. I think any need we have to display user controllable animated chess moves, is almost invariably going to be for focussed attention to a few details/moves. A page like Ruy Lopez demonstrates perfectly the encyclopedic need for a better way to visually describe moves being made.
  3. It requires special knowledge to implement, or requires copying code from elsewhere. These two issues are IMO major pitfalls; like any other template, infoboxes being ideal for example, the implementation should be simple to understand and require no special language constructs or coding knowledge. Any editor should be able to freely make changes to all parts of every page (unless protected for reasons) without their being expected to learn a new language to do it. PGN and FEN are basically computer languages, designed for programs to read and write. For an editor unfamiliar with these languages, implementing a simple demonstration of a few chess moves would be impossible without first learning how to write that special code. The alternative of requiring editors to copy the required code from somewhere else, is IMO definitely not something we should encourage - for obvious reasons.
  4. Standard algebraic notation, although also being a special language requiring some learning to understand, is used pretty much exclusively in our chess articles, for describing chess theory and/or practice. It's very similar to PGN to read and write, so using it for implementation could be considered not much better, but importantly, it is the standard notation used on practically all the other articles. Where we're showing any chess notation, it should always (except in articles specifically about PGN) be algebraic, and not PGN. I realised though, that expecting editors to be able to write algebraic notation fluently was unacceptable, so I created a template that takes plain English input, and outputs algebraic notation.
  5. For setting up the board in a non standard way i.e. not the way a game is usually started, I opted to use mostly plain English. This is again to make the implementation as simple and accessible for all editors as possible. FEN on the other hand is insensible gibberish unless you've learned it. We can safely assume that editors of enwiki have a reasonable understanding of English after all, but to assume they all read and write FEN is ludicrous. I, for one, do not; and I am not inclined to learn it either.
  6. Stylistically, I consider it vital that the widget (for want of another word) blends into articles, and designed mine to do just that both rendered and raw. The wall of PGN used to fuel kipod's viewer looks out of place in both it's raw and rendered (for users with JavaScript disabled) form IMO. We need to allow editors to position and manipulate the demos to fit into sections and paragraphs in many different ways, and the implementation thus needs to be as similar as possible to how we'd build most other types of common image display or infobox type of thing. I've also focussed on falling back to an animated .gif image for users with JS disabled, rather than outputting what is basically machine code, directly into articles. Although originally I thought to have editors provide the .gifs, I've decided to construct a MediaWiki Extension to do it accurately and consistently as and when needed. This would mean that every instance will have a visually appealing and useful fallback without any editorial effort.
I'd like it to be understood that I am not biased in favour of my own code being used, so much as biased against kipod's. Yes you read that right. This however is not an opinion about kipod - just the PGN viewer.
I am certain that the code I've written for this to date will absolutely need to be rewritten before it goes anywhere near the site's common files. The Module is probably very naive (it's only my fourth ever) and due to the insanity (IMO) of supporting ancient browsers, the CSS and JS will have to be dumbed down. Fundamentally though, other than some fiddling about it won't need to change in functionality that much (except where the community decides that it should). As such, I would argue that my code shouldn't be used. However, no matter how much fiddling about is done to kipod's code, whilst it requires special knowledge or copy/pasting to implement, and outputs machine code into chess articles, and has no suitable fallback, and is focussed on the display of multiple full games instead of smaller simpler demos, it is, without damning it for what it is, not suitable for English Wikipedia.
I will gladly support a better implementation than my own, if it meets or exceeds the requirements as I've attempted to outline them above. And it is these requirements that I think the community needs to carefully discuss here. Fred Gandt · talk · contribs 02:36, 10 June 2016 (UTC)
  • Great work from both developers, much appreciated! My opinion:
    • Input of a game with dozens of parameters is cumbersome, no matter if you're novice or experienced. Stick to PGN, which also allows embedded comments easily. Input of metadata such as player names and tournament info should be optional. So in Fred's examples, as an editor, I'd like to replace all the |1= |2=… parameters with just |pgn=.
    • FEN input is very machine-like. While it should be supported for interoperability, I like Fred's natural-language description of a position such as "white king b1, black king e8, white rook d1, black rook e4", however it may get a little verbose for non-trivial positions, so I would suggest shorthand such as "white Kb1 Rd1, black Ke8 Re4", and call it |position= accepting either FEN or the human-readable notation.
    • Kipod's viewer has a helpful switch between black and white points of view, this needs to be in the production version.
    • Comments along the game should be visible at each step, not merely highlighted in the notation view (both implementations show the whole game, I think we should show just the current move pair and its comments).
    • Generating an animated GIF for non-JS browsers is a distraction; let's get the basics working first.
Thanks again, looking forward to round 2 of improvements! — JFG talk 09:07, 10 June 2016 (UTC)
  • @JFG:
  • For the examples, I purposefully (perhaps not the best idea it seems (more of a documentation issue that a technical one)) used the fullest longhand setup syntax; setup can be written as "white K e1" or even "white k e1" and can trivially be shortened to "w k e1" if desired, although this starts to become inaccessible gibberish for future editors. Accepting a full English piece name allows a less machine-code-like setup, but I too like to be able to use shorthand when I'm familiar with the application, so included it. Although setting up with FEN might be handy for a particular editor, the markup will remain in the article, and be incomprehensible to others. This IMO opens us up to demos being inaccessible to future editors without special knowledge. Like programming code in a multi developer environment, it needs to be maintainable, by anyone, at any time later, without a need to track down the previous editors to ask what something means or how it works.
  • I toyed with the idea of also accepting PGN, but decided to focus on a purely Wikipedia oriented syntax, as there are no interoperability issues; we don't need to use code from elsewhere or have code from here work elsewhere. It also leads to the same issue of resulting in something that made sense to the editor that added it, but may not make much sense at all to any future editors. There also is a concern worth consideration, that allowing multiple syntaxes for input, creates incontinuity from article to article. I really think it best to have a single, consistent syntax that is as accessible as possible. Defaulting to natural language may be cumbersome for editors who are comfortable with PGN, but that can still manage; PGN is incomprehensible to everyone else, and editing becomes problematic. I personally find that a numbered param per move is simple to understand and hardly difficult to write, but will give some (more) thought to accepting a natural language alternative requiring fewer params.
  • In my first few drafts of the demo code I wrote, I had notation and any attached commentary being printed as the associated move was made. I changed this to a permanent display with highlighting after realising how disruptive and distracting the dynamic display was. One major issue is keeping the demos compact, and having them fit into articles in whatever way editors feel is appropriate. In that case, the demo needs (as much as possible) to be a reliable shape and size, without unnecessary empty whitespace. A dynamic display without a fixed aspect large enough to accommodate the largest notation will change size and shape every move. This causes the layout of the article to be altered every move. It's extremely annoying. Further to that, semantically, it's important to have a complete rendering of all the encyclopedic content, all the time. Screen readers and the like depend on a reliable and standard HTML page structure; dynamically altering bits is fine and often great for frivolous websites, but I think not here. As much as possible, the article content should be static and organised. I have included options for formatting the notation output, giving editors some freedom to customise the content as they see fit.
  • The fallback for users with JS disabled is arguably more important that the scripted demo. If the fallback doesn't work, it's like building a house on jelly; the fallback is the basics. We have to have a strong foundation, or the whole thing falls down. I personally think users of the internet in the second decade of the 21st century should expect the web to be rubbish if they turn off JS, but this isn't some trivial blog; we have a duty to offer useful content to as many people as possible, even if their technology sucks. Falling back to a .gif doesn't actually change any functionality (for me), and is not in any way distracting. I have already started on the code (although I'm not rushing).
  • Question: Is switching perspective really that important? I find it visually confusing personally. Fred Gandt · talk · contribs 14:04, 10 June 2016 (UTC)
i am glad this rfc gets some traffic. i will try to relate to some of the points raised so far, and maybe some new ones.
we can break the discussion into two main areas:
  1. The reader's UX
  2. the editor's interface (i.e., the parameters passed to the "chess viewer template", whichever it is).
i will only relate here to the 2nd point, and for this, i make the following assertion: editors in enwiki who actually edit Chess-related articles, are serious about chess.
i claim that the best way for these editors to feed in chess games to the chess-viewer template is the most familiar notation used by people who are serious about chess. this notation is PGN for actual games, and FEN for initial positions. User:Fred Gandt wrote above: FEN on the other hand is insensible gibberish unless you've learned it. We can safely assume that editors of enwiki have a reasonable understanding of English after all, but to assume they all read and write FEN is ludicrous.. IMO, this statement demonstrate lack of knowledge or lack of understanding. people serious about chess, read and write FEN. this is how people record mid-game board position. every member of Wikipedia:WikiProject Chess, and anyone ever likely to actually write or edit a chess-related article (at least the part related to the game itself), is extremely unlikely to be perplexed by FEN. i would love someone from the actual chess community to weigh in here, and tell me whether this assertion is correct or not, but until someone does, this is my assumption. i believe Gandt that for him it's gibberish, and you may be surprised to hear it's gibberish for me too, but it's *not* gibberish for any serious member of the chess community in enwiki.
as for PGN, i don't even need to assume: chess articles in enwiki are rife with games presented using PGN notation *today*. this is the standard way to show games. for instance, look at the article Deep Blue versus Garry Kasparov: it contains the PGN of all 12 games (6 games each of two matches). the most natural way for any editor, even slightly familiar with chess to feed in a chess game to a game viewer is via the PGN.
moreover: we do not do original research in wikipedia. any game likely to require either of these viewers is some notable historic game, sourced in some book or database. guess what? every single one of those games, appearing in a book, newspaper article, or a database is presented in the form of its PGN. requiring any other format forces the editor to deconstruct the pgn, and translate it to some notation that some developer in wiki invented. this makes zero sense to me.
just to demonstrate this point, i added to my "demo" page all the games from Deep Blue versus Garry Kasparov. i did not take the PGN from one of the dozens of online databases containing them: i copied it from the wiki article itself (with one change - the article shows castling as 0-0 instead of the standard O-O, which i fixed). it took me all of 4 minutes to set up the viewer, again, *from content already existing in the article*. this is sub-optimal (for instance, it's lacking all the metadata routinely found in PGN), and was done mainly to stretch the point: PGN is *not* some "foreign notation meant for computers but not humans". PGN was designed to be consumed by both computers *and* humans, and in fact, it is the standard way we present chess games in enwiki *today*.
i had some other points, mainly related to the UX, but this comment is already too long, so i'll leave it for another day. peace - קיפודנחש (aka kipod) (talk) 23:29, 10 June 2016 (UTC)
  • @קיפודנחש: (aka kipod): That (Deep Blue versus Garry Kasparov) is not PGN; that's algebraic notation, which is very similar to PGN. The reason you had to convert the castling to the PGN Os from the algebraic 0s is because it's not PGN. And it's not PGN because most chess articles use algebraic notation - not PGN.
  • this book about "Deep Blue versus Garry Kasparov", chosen without bias from the article's "Further reading", also uses algebraic notation, albeit formatted in tables. That's just one example of how the standard notation may be presented in a non-standard way.
  • Strictly requiring PGN formatting of algebraic game data is restrictive, and it is exclusive to require that only people who are serious about chess may understand the article content in both its raw and rendered state's.
  • However, after reading JFG's comments (whilst out walking) I gave some thought to the issue and decided to allow more freedom and options in the setup of demos using my code. I will allow the use of FEN and PGN (I already allow PGN castling notation), but if used as an input, it will be converted to standard algebraic notation for output.
  • P.S. I didn't invent algebraic chess notation. Fred Gandt · talk · contribs 06:51, 11 June 2016 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
  • @קיפודנחש: @Fred Gandt: Thanks for your feedback. Quick notes:
    • I don't see the point of arguing at length between PGN and algebraic notation: PGN is algebraic notation of the moves + optional game metadata, so any discussions on their relative merits and intuitiveness are moot. For convenience, the code should allow both 0-0 and O-O for castling input, and keep game metadata optional. In this way, no matter where editors copy the game from, it will be valid.
    • I would strongly advocate against allowing the suggested alternative input syntax in the form of having one template parameter per move; this is both cumbersome and unused anywhere.
    • I very much doubt that chess amateurs can read/write FEN fluently; I for one can't, even though I'm both a chess amateur and a programming professional; position input requires a human-readable shorthand notation such as the ones suggested by Fred and myself above (but do accept FEN input to allow copying from/to other places)

Let's agree on the input methods first and look at UI improvements later. Good day! — JFG talk 09:44, 11 June 2016 (UTC)

first, a side: 0-0 vs. O-O: i just taught the script/template to accept either as castling, to reduce the noise in the discussion.
the main point is, the issue is not "pgn vs. algebraic notation", really: it's "pgn/algebraic notation vs. Fred Gandt's template input", or, more broadly, using standard notations and syntax vs. a proprietary one invented for wikipedia. for the first question the difference is clear (i chose arbitrarily the first game in "Deep vs. Kas" - the contrast becomes even starker when choosing a game with 60 or 70 moves instead of 37, such as game 2 in the same series):
pgn/algebraic notation Fred Gandt's viewer input 
 {{Template name
 | some parameters controlling whatever
 | 1 = 1.e4 c5 2.c3 d5 3.exd5 Qxd5 4.d4 Nf6 5.Nf3 Bg4 6.Be2 e6 7.h3 Bh5 8.0-0 Nc6 9.Be3 cxd4 10.cxd4 Bb4 11.a3 Ba5 12.Nc3 Qd6 13.Nb5 Qe7 14.Ne5 Bxe2 15.Qxe2 0-0 16.Rac1 Rac8 17.Bg5 Bb6 18.Bxf6 gxf6 19.Nc4 Rfd8 20.Nxb6 axb6 21.Rfd1 f5 22.Qe3 Qf6 23.d5 Rxd5 24.Rxd5 exd5 25.b3 Kh8 26.Qxb6 Rg8 27.Qc5 d4 28.Nd6 f4 29.Nxb7 Ne5 30.Qd5 f3 31.g3 Nd3 32.Rc7 Re8 33.Nd6 Re1+ 34.Kh2 Nxf2 35.Nxf7+ Kg7 36.Ng5+ Kh6 37.Rxh7+ 1–0
}}

 {{Template name
 | some parameters controlling whatever
 | 1 = e2 e4    
 | 2 = c7 c5     
 | 3 = c2 c3     
 | 4 = d7 d5     
 | 5 = e4 exd5   
 | 6 = d8 Qxd5   
 | 7 = d2 d4     
 | 8 = g8 Nf6    
 | 9 = g1 Nf3    
 | 10 = c8 Bg4
 | 11 = f1 Be2  
 | 12 = e7 e6    
 | 13 = h2 h3    
 | 14 = g4 Bh5   
 | 15 = e1 0-0   
 | 16 = b8 Nc6   
 | 17 = c1 Be3   
 | 18 = c5 cxd4  
 | 19 = c3 cxd4  
 | 20 = f8 Bb4
 | 21 = a2 a3   
 | 22 = b4 Ba5   
 | 23 = b1 Nc3   
 | 24 = d5 Qd6   
 | 25 = c3 Nb5   
 | 26 = d6 Qe7   
 | 27 = f3 Ne5   
 | 28 = h5 Bxe2  
 | 29 = d1 Qxe2  
 | 30 = e8 0-0
 | 31 = a1 Rac1 
 | 32 = a8 Rac8  
 | 33 = e3 Bg5   
 | 34 = a5 Bb6   
 | 35 = g5 Bxf6  
 | 36 = g7 gxf6  
 | 37 = e5 Nc4   
 | 38 = f8 Rfd8  
 | 39 = c4 Nxb6  
 | 40 = a7 axb6
 | 41 = f1 Rfd1 
 | 42 = f6 f5    
 | 43 = e2 Qe3   
 | 44 = e7 Qf6   
 | 45 = d4 d5    
 | 46 = d8 Rxd5  
 | 47 = d1 Rxd5  
 | 48 = e6 exd5  
 | 49 = b2 b3    
 | 50 = g8 Kh8
 | 51 = e3 Qxb6 
 | 52 = c8 Rg8   
 | 53 = b6 Qc5   
 | 54 = d5 d4    
 | 55 = b5 Nd6   
 | 56 = f5 f4    
 | 57 = d6 Nxb7  
 | 58 = c6 Ne5   
 | 59 = c5 Qd5   
 | 60 = f4 f3
 | 61 = g2 g3   
 | 62 = e5 Nd3   
 | 63 = c1 Rc7   
 | 64 = g8 Re8   
 | 65 = b7 Nd6   
 | 66 = e8 Re1+  
 | 67 = g1 Kh2   
 | 68 = d3 Nxf2  
 | 69 = d6 Nxf7+ 
 | 70 = h8 Kg7
 | 71 = f7 Ng5+ 
 | 72 = g7 Kh6   
 | 73 = c7 Rxh7+ 1–0
}}
it's the same thing about opening position, considering FEN vs. some wiki-invented syntax: note that one of the very first things you see in Wikipedia:WikiProject Chess#Diagrams, annotation and notation is a link to convert FEN to {{Chess diagram}}. this is because when an editor in wikipedia writes a chess related article related to some specific game or position, the FEN is usually available, while some "wikicode" invented by someone in enwiki is usually *not* available, so a "converter" is needed. for instance, any game for Chess960 which is available anywhere on the net, will have the FEN of the opening position. if we require some invented syntax, every editor who wants to use it will have to write the whole shebang manually (and maybe, eventually someone will create a "fen-to-wikipedia-chess-viewer" converter...). we should cut the middleman and simply accept FEN. anyone should take some arbitrary chess960 game and use either of these methods to describe the opening position to get a feel of the issue.
inventing "more english-like" new syntax, because "after all, this is wikipedia", makes as much sense as inventing wiki-specific syntax for mathematical formulas instead of accepting LaTeX, or inventing some wiki-specific syntax for musical notes instead of processing lilypond's notation: sure, LateX and lylipond syntax looks like gibberish to *me*, but mathematicians and physicists use it routinely, and musicians use lilypond's notation, so <math> and <score> tags accept those. similarly, the "language" of chess is pgn/algebraic notation and FEN, and this is what makes most sense for chess-related templates to accept. as an exercise, try to encode the opening position of some Chess960 game using Gandt's notation, and compare to the FEN.
as a side note, just b/c i mentioned "chess960": i realized that my viewer does not handle castling correctly for this variant. this is clearly a bug, but currently it's very low priority for me: nobody ever wanted to use it for chess960 game. if enwiki will decide to adopt the viewer, i guess i'll have to fix this bug. peace - קיפודנחש (aka kipod) (talk) 01:11, 12 June 2016 (UTC)
(later addition): apparently, i did not fully understand Gandt's viewer's limitations, so i posted misinformation in the comparison (collapsed) table above. i fixed it now. in it current state, i think this viewer is not usable - it requires significant amount of work from the editor in order to convert available algebraic notation/pgn to the parameters the viewer requires: each of the parameters represents "half a move", i.e., for move #9 in the algebraic notation, the editor has to add parameters 17 and 18, and add to each of them the the "from" square, which is not available in the notation. Gandt claims he is going to teach his viewer to consume PGN/algebraic notation at some point - once he does this, his viewer may become usable. קיפודנחש (aka kipod) (talk) 13:26, 16 June 2016 (UTC)
  • Richard L. Peterson is a math editor on Wikipedia, and probable math whizz elsewhere. He and I worked together a couple of times (first time and second time), due to my being relatively comfortable with coding stuff, and him finding it comparatively challenging. I don't speak "math" at all, but he speaks "math" fluently; he found the editing difficult, not the subject. His expertise with maths, didn't help him at all when it came to writing a foreign language. If only someone had written a Wikipedia specific, editor friendly, plain english markup language for compiling equations in maths articles, he wouldn't have needed any help, or had so many challenges.
Templates are entirely wiki-specific markup, and the slight difference between "1.e5" and "|1=e5" should hardly baffle too many chess notation (I'm pretty good at chess, but had never read or written algebraic notation until this proposal popped up) experts. A long string of notation though (especially in PGN formatting with possible optional commentary) might be quite daunting to any but the most familiar with it. Rather than asking for someone from the actual chess community to weigh in we should be asking for feedback from general Wikipedia editors, WikiGnomes and folk like me who bumble about doing all kinds of odd jobs. We're not experts in anything very much (well I'm not anyway), and are often unfamiliar with the article subject(s) (which is often why I'm reading it), and should not be excluded from editing ANY chess article because we're not a serious member of the chess community in enwiki.
What standard I ask you, is the markup used for wiki tables, or infoboxes? It's a wiki standard, plain and simple. Why ask editors to learn an entire other pair of languages in order to edit the English Wikipedia?
As I have already said (BTW: glad to see you've updated your code to accept standard algebraic castling - a wise move), I am adding code to also accept FEN and PGN, so this part of the discussion is effectively moot now. However, I will not be outputting PGN into articles, and will continue to focus on maintaining and developing (as much as possible) a wiki-specific, plain English syntax, since anything and everything developed specifically for enwiki should be entirely wiki-specific, and requiring only the speaking of English.
Serious question: Do you really have anything against editors being enabled to use multiple formats, or is the argument in strong favour of "PGN only" due simply to your code accepting only PGN? Is the idea of making life simple for as many people as possible really so bad? Fred Gandt · talk · contribs 03:32, 12 June 2016 (UTC)
Frankly I'm not sure I see the advantage your (Gandt) notation has over PGN. At that point I can see no justification for supporting anything other than PGN. Perhaps an easy simplified-notation-to-PGN template or tool would be of use to editors, but I don't see a justification for the alternate format in articles. Rwessel (talk) 04:07, 12 June 2016 (UTC)
to answer the question ("Do you really have anything against editors being enabled to use multiple formats") first: having options is good. if the template can accept either standard algebraic notation (or PGN), and in addition it can also take some home-brewed other syntax, then it's groovy. if it *forces* the editor to use this home-brewed syntax, then it's not. saying that "the slight difference between "1.e5" and "|1=e5" should hardly baffle" does not make sense to me. wikipedia uses sources, and what available on those sources is algebraic notation of games (or, more precisely, PGN). forcing editors to manually convert the available material to some other syntax you invented because "this is wikipedia", makes no sense.
as a side, i believe your system already uses some non-negligible amount of lua code anyway - why not teach it to consume straight algebraic notation (or better yet - also teach it to consume straight PGN) - this way we can drop this silly discussion and concentrate on the pros and cons of the viewers?
Gandt claims he is "pretty good at chess". i can say the same thing myself, but i never contributed to any chess-related article on wikipedia, and i will be very surprised to hear that Gandt did. i believe that the people who do, are not "pretty good at chess" - they are actually experts. these are the people whose opinion matters: not because they are "experts", but because they are the editors who will actually have to use (as editors) whatever viewer is added, if this will ever happen. this is why i think it makes tons of sense to actually reach out to Wikipedia:WikiProject Chess and solicit the opinion of the people who are the *real* "customers" of this tool from the editor POV.
it also ake sense to reach out to everyone else (representing the "readers") to solicit opinions about the UX, but it seems we are not there yet.
peace - קיפודנחש (aka kipod) (talk) 16:53, 12 June 2016 (UTC)
if i understand correctly the angry-red comment above, it means Gandt's script/module/template/demo is not quite finished yet. i am happy to learn that he decided to support the standard notation, in addition to the homebrew input, but i do not know if it's a small change or a huge one, and how much time is required. maybe we should pause this thread until he is done? peace - קיפודנחש (aka kipod) (talk) 03:32, 13 June 2016 (UTC)
  • Angry? Stop being so combative.
There's no reason to pause the discussion; we need to discuss how the implementation should look, and what styling options are needed/wanted. Also, I've been thinking that it may be best to push the eventual agreed code into an optional Gadget for a while, to get some real user feedback and experience before possibly rolling it out to the default. This would of course means that users without the Gadget enabled would need to see something useful, so the Gadget would act to enhance otherwise stable and encyclopedic content - i.e. replacing current diagrams with potentially Gadget enhanceable alternatives. This should be discussed.
There's no rush (half the reason I started work on another option); we should take this carefully and as slowly as that requires. Apart from any technical or stylistic concerns, the whole idea needs a much wider response that a handful of enthusiasts; it's a big deal trying to add default JS and CSS to enwiki (as it should be), and we have a responsibility to do our best to arrive at a solid, agreeable, technically sound, ..., etc. solution. I wouldn't expect this RfC to be the last on the subject; this is just the beginning. Fred Gandt · talk · contribs 03:52, 13 June 2016 (UTC)
regarding "look and feel" feedback: i will be happy to provide some, and even happier to receive some. i asked for criticism/feedback/suggestions several times. as to the appropriate "fallback" - i have an opinion there also, and will be happy to provide it. i do not see need for gadget, as long as there are clear and simple instructions to test either of these demos.
some feedback: (1) it is expected (i.e., any other chess viewer i saw to date supports it) for the user to be able to select specific position/move and switch to it directly, without having to cycle through all the previous moves. traditionally, this is done by clicking on the move in the "notation" pan. (2) when the game is in progress, the current move notation is highlighted. however, the last time i tried your viewer, the highlighted move can be outside the scroll region. it's a reasonable expectation that when this happens, the current move will autoscroll into view. (3), "heavily weighted" aside, the ability to show more than one game in the same viewer is very useful. (4) conditional loading of the code is good. basing the condition on some category is not, and IMO is not acceptable.
i hear you when you say "no rush", but it will be good to get *some* estimate of ETA. peace - קיפודנחש (aka kipod) (talk) 04:27, 13 June 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Rhododendrites, Izno, Strawberry4Ever, Naraht, Maproom, Wugapodes, MaxBrowne, Tpdwkouaa, Cobblet, and Altamel: Fred Gandt · talk · contribs 14:11, 17 June 2016 (UTC)

this ping did not take either (you didn't actually add the links, just moved them from one place to another). are you done with your viewer? if not, when do you expect to be done? peace - קיפודנחש (aka kipod) (talk) 14:20, 17 June 2016 (UTC)
@קיפודנחש: I was pinged. The addition of the new signature block and new spot on the page caused a ping. (You should review the criteria.) --Izno (talk) 14:25, 17 June 2016 (UTC)
i stand corrected. thanks. i failed to notice that i was simply omitted from this one. peace - קיפודנחש (aka kipod) (talk) 14:30, 17 June 2016 (UTC)
No קיפודנחש I'm not done; and have no ETA or even know exactly what I'm doing (chuckle - I'm doing lots of things in dribs and drabs). This conversation should be about what's needed/wanted and how that should be implemented; who writes what code isn't important; it's what code does what that matters. What I'm doing is developing ideas to provide working examples for discussion, and am currently responding to feedback and several other issues I've noticed along the way. I don't expect to ever have a complete package that is inarguably the exact thing enwiki should use. As I've said before, I wouldn't support my code being added to the MediaWiki common files without major review; I'm just working to present example demonstrations for discussion, and the discussion is not dependant on me or my code. More specifically, I'm working to reduce the JS dramatically by offloading more calculation to the Module, and I still have an extension to build, which will take a lot of development, time and discussion before it has a hope of being used by enwiki (I propose that using the ImageMagick PHP library via a MW extension is the most bestest way to implement a reliable, consistent fallback to something aesthetically and encyclopedically useful). I'm working on accessibility and browser compatibility concerns, and with that in mind redesigning the HTML, CSS and JS... I'm doing lots of things, and have no idea how long any of it will take. Fred Gandt · talk · contribs 15:43, 17 June 2016 (UTC)
i don't think the discussion should be about what needed/required and how it should be implemented. i think the discussion should be about one simple question: "should the existing viewer be added to enwiki?"
if we decide _not_ to use it, then whenever you feel comfortable with your viewer, you can open another proposal to add it. if the decision is to use it, then, whenever you wish, you can propose to replace the viewer with something better. if anyone wants to make suggestions for possible improvements, they can make them, before or after the viewer is added, and those suggestions will be implemented or not. this proposal (with quite a few "support", and not a single "oppose") have been in limbo since you announced you can do better. as it is now, i don't think your viewer in its current state is usable. suggesting that this needs to be designed and implemented, is ignoring the fact that we are talking about an existing, mature viewer that's already "in production" on another wiki for more than 3 years, with no reported issues. all we need to do is make a simple decision: whether or not to use it.
as a side: you seem to take it as a given that doing the work (i.e., analyzing the PGN) on the server using LUA rather than on the browser using JS is "better", even though some JS is still required for the viewer itself. can you justify this claim by some rational argument? *why* is it better to "offload" the readers browsers and make wikimedia servers do the work? the only argument i saw so far is "because 1000 lines of JavaScript required by the script to understand the rules of chess to decipher the PGN instructions is personally tough to swallow.". this can't be considered a rational argument: first, the script is actually 854 lines, not 1000. it weighs about 11K 15K minified (versus 3K minified for yours), 11K 15K that the browser gladly caches. second, nobody asked you to personally swallow those lines. third, using your scheme seems to actually inflate the HTML itself by 1-3K per game (the difference between "algebraic notation"/PGN, and "Gandt's notation" which the module, once you write it, will add to the HTML), so even without caching, the "gain" might actually be negative once an article contains more than 3-4 games (in hewiki, some articles using the viewer display dozens of games), and last, but not least: offloading the server and letting the browser do as much of the work as possible seems to be the direction everyone else in the world is going. peace - קיפודנחש (aka kipod) (talk) 21:22, 17 June 2016 (UTC)
I'll be elsewhere if anyone wants anything. Fuck that shit; life's too short.Fred Gandt · talk · contribs 22:22, 17 June 2016 (UTC)
thanks. if i understand this comment correctly, it means that Gandt practically stopped working on his viewer, and has no intention to resume the work. this simplifies the decision, i guess. hopefully, the proposal is not damaged to such an extent that it's completely dead. קיפודנחש (aka kipod) (talk) 23:44, 17 June 2016 (UTC)

Disclosures in citations for sites that scan for ad-blocking software[edit]

Due to the increasingly heavy use of ad-blocking software for various reasons (primarily security and maintaining web browser performance), and the similarly increasing use of counter-measures against users who employ them, I feel that citations should have notices to inform users if a particular source employs technical measures to scan for ad-blocking software, and generate messages or outright restrict access to content if an ad-blocker is detected. We already do something similar for sites that employ paywalls or require registration (i.e. {{subscription required}}); An explicit requirement to view ads in order to access content should, due to its prominence, also be disclosed in a similar manner.

I do not know how we would word this, but it would be presented similarly to the Subscription required notice, and would only be used on citations that restrict access to content or present notices if the web page attempts to detect ad-blocking software. Ad-blocking is typically used as a privacy measure, and these scans cause the execution of scripts intended to detect for ad-blockers by reading its behaviour. ViperSnake151  Talk  19:40, 7 June 2016 (UTC)

You're thinking Forbes, probably? --Izno (talk) 19:59, 7 June 2016 (UTC)
  • Oppose: Editors are free to have whatever principles concerning internet advertising they like, but their reluctance to verify something because of ads (or ad-blocking detectors) has zero effect on the verifiability of a source. Whatever their opinions on ad-blocking, we have agreed not to change Wikipedia policies to make a point. The reason we have {{subscription required}} is because cost or registration can be a real-life hindrance for verifiability (but as WP:PAYWALL notes, does not entail that verification will fail). The presence of ads (or ad-blocking detection) on a website on the other hand, has no negative effect on the verifiability of the source. Security issues are already covered by WP:ELNO; and ad-blocker detectors probably don't amount to "malicious scripts". There is nothing that readers need to be "warned" about except for their own principles (of which of course they are already aware). – Finnusertop (talk ⋅ contribs) 20:08, 7 June 2016 (UTC)
Well but wait User:Finnusertop -- I agree that these sources can be used as citations (maybe), but if a site is acting agressively against user's interests, isn't it pretty unfriendly to not at least warn our readers? As a thought experiment, suppose there's a site that that reliably verifies a fact, but going to that site causes an unpreventable installation of malware that copies all that user's files to the Russian Mafia and then formats her hard drive? We wouldn't use that site as a ref at all, let alone do so without warning people, right? Suppose it was otherwise reliable proof of the fact, and even assuming it was an important fact and it was the only reliable verification (again, thought experiment) -- we still wouldn't. Right? I hope. I don't know where the adware-blocking sites fit on the continuum "Russian Mafia, then format <--> No Problem", but since the editor said "Ad-blocking is typically used as a privacy measure" I'd like to hear more about how much privacy loss we are talking about before signing onto the we-don't-need-to-worry-about-this-at-all ticket. Herostratus (talk) 00:19, 9 June 2016 (UTC)
I don't think we should go to the enormous effort of flagging all the references Wikipedia makes to sites using ad blockers today (which might be different to the number using them tomorrow) on the basis of some absurd strawman about malware-toting Russian Mafiosi. There are any number of behaviours a website might adopt (at any time) that a reader might not like. Wikipedia can't be expected to police that. All we can do is say "this site verifies this statement" (keeping that up to date for millions of links is more than enough work to do). Chuntuk (talk) 13:01, 9 June 2016 (UTC)
Regarding Herostratus's claim "if a site is acting aggressively against user's interests", As the Adblock Plus page says,[1] "ads fuel a lot of the content we enjoy for free online". One could argue that if a significant number of ad-supported websites such as Google, Youtube and Facebook shut down because of declining ad revenues, that would be "against user's interests". I personally really like Adblock Plus's "General criteria for Ads that shall be treated as Acceptable Ads"[2] as an acceptable compromise between blocking all ads and blocking no ads. --Guy Macon (talk) 00:39, 10 June 2016 (UTC)
  • Oppose. This is going to be an entire waste of time if a website changes its mind about subscription notices and we have to revise all references to a particular citation for whatever point is going on here. And why sites that search for ad blocking software? Should we identify webpages with poor privacy policies? Webpages that have pop up ads? Webpages with excessive or third-party scripting? If this is that offensive, then propose a remedy for a particular website's links or propose the removal of web links to a particular page. Or else blacklist the site itself if you want that done. -- Ricky81682 (talk) 09:07, 9 June 2016 (UTC)
  • Oppose: First, the question asked is biased. "Ad-blocking is typically used as a privacy measure" is almost certainly factually incorrect. The most common reason is most likely reducing user annoyance. Compare the websites for the ad blockers Adblock Plus[3] ("Surf the web without annoying ads! ...Unobtrusive ads aren't being blocked...") and Privacy Badger[4] ("Privacy Badger is a browser add-on that stops advertisers and other third-party trackers from secretly tracking where you go and what pages you look at on the web.") Adblock Plus tries to block the annoying ads and let the unobtrusive ads through, while Privacy Badger tries to block the ads that track you and let the ones that don't through. The web is full of sites that use counter-measures to try to defeat Adblock Plus, but I have never heard of any site that tries to defeat Privacy Badger. Second, ad blockers are a terrible way to protect privacy. They address another issue entirely and any privacy benefits are an accidental side effect. Third, it is not Wikipedia's place to take any position on the ongoing arms race between ad blockers and sites that are supported by advertising. Unlike paywalls, ads do not interfere with verifiability. --Guy Macon (talk) 14:05, 9 June 2016 (UTC)
    • @Guy Macon: It doesn't matter if someone is using Adblock Plus or Privacy Badger, the website may still block you for using Privacy Badger if their ads happen to be blocked as trackers, which is pretty common for the big ad networks. Personally, I use uBlock Origin with filter lists to block ads and trackers. Anyway, I agree this idea is not feasible. An alternative could be to add pre-emptive archiving, e.g. at WebCite. It wouldn't be the most prominent link with |deadurl=no, and it would be useful for preservation anyway. nyuszika7h (talk) 10:27, 11 June 2016 (UTC)
    • I don't think that paywalls, ad-blocker-scanning, country-based restrictions, or anything like that interferes with verifiability. You personally may not be able to verify the source if you won't or can't pay for it, if you won't or can't use the software settings that the website prefers, you won't or can't access the internet from a country that the website approves of, etc., but verifiability isn't about what's possible for you personally. It's about what's possible for someone (someone who is not the person originally adding that material), not what's possible for every single reader. WhatamIdoing (talk) 04:48, 15 June 2016 (UTC)
  • Oppose. In an ideal world, it may work, but it'd just take too long to tag everything with it, unless there's a sort of list that automatically adds it and removes it (such as |publisher=Forbes, |publisher=Wired (magazine)). Also, if this were to be implemented, where would the line be drawn for other things? As Ricky81682 said, would we also notify for popup ads, etc? Anarchyte (work | talk) 07:24, 11 June 2016 (UTC)
  • No objection I don't think this is a critical template, but there's nothing wrong with having it and using it when someone believes that it's appropriate. {{Subscription needed}} isn't used very often, and I expect this would be less popular, but it's not harmful. WhatamIdoing (talk) 04:48, 15 June 2016 (UTC)
  • Oppose, these don't seem to have taken off much. They're pretty easily circumvented with Noscript or Greasemonkey/Tampermonkey scripts anyway, and those scripts are readily available. Seraphimblade Talk to me 17:47, 22 June 2016 (UTC)

5th RfA reform[edit]

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)
  • Agree, the person should definitely have to agree. — xaosflux Talk 14:39, 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)
    • The proposal to rename adminship to make it seem like less of a big deal reminded me of this TED talk. Anomie⚔ 20:13, 20 June 2016 (UTC)

Basic facts[edit]

  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)
  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?[edit]

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[edit]

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)
  • That is the main change. In my opinion, that's the biggest problem with RFA, as I explained above. KSFTC 12:59, 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[edit]

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)

Eliminator group[edit]

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)

quick web citation tag[edit]

Currently when citing from the web, I type

<ref>{{cite web|title=blah blah blah|url=http:/somewhere/foo/bar/blah_blah_blah}}</ref>

Could a lazy shortcut citation tag be devised to streamline this to something like

{{quickcite|http:/somewhere/foo/bar/blah_blah_blah}}

- which would add the 'ref' tags, *and* extract a title from the link. this might seem trivial but it would let editors keep their focus on the article, and reduce the laboriousness in actually adding the link. It would result in titles being obscure file names sometimes, but I think it would be the lesser evil, given that it would allow lazy people to actually source more links in the first place. (laziness is really about keeping focus on something else and conserving energy) — Preceding unsigned comment added by Fmadd (talk • contribs) 20:57, 17 June 2016

You seem to be asking for lots of new features in recent days, and rarely sign your posts; also, it's not always easy to work out what you are asking for. But Wikipedia templates cannot "extract a title from the link" because the title is not part of the link. Also, <ref>...</ref> tags and templates don't work as expected if you pump them full of extra spaces. --Redrose64 (talk) 22:19, 17 June 2016 (UTC)
I'm suggesting that at worst it just uses the filename, (which is sometimes related to the title.) I can also imagine a commonly useful function for getting a title from a web-page. Computers are here to save us from repetitive tasks, dotting I's and crossing T's. Fmadd (talk) 23:03, 17 June 2016 (UTC)
Fmadd, what you want is available in the mw:citoid service. Switch to the visual editor to try it out: Open an article, find and click on the pencil icon in the upper right corner, and wait a moment until it transforms into something that looks like a modern word processor. The "Cite" button in the middle of the toolbar has an "Automatic" setting that provides excellent citations to some popular sources (e.g., PubMed, The New York Times and Google Books) and will extract a title for nearly all (non-pdf) URLs.
The [[ ]] button next to "Save" will take you back to the wikitext editor. Whatamidoing (WMF) (talk) 22:59, 17 June 2016 (UTC)
thanks, i will try it. i usually use the low level editor, but I'll take a look. Fmadd (talk) 23:04, 17 June 2016 (UTC)
Let me just echo the suggestion - I use the VE editor for references and it does more than what you just requested - much more, and does so easier than your proposal.--S Philbrick(Talk) 02:58, 18 June 2016 (UTC)
  • User:Ark25/RefScript. Fmadd, I use Ark25's reference generator. I don't have to switch to VE. And it generates {{cite}} references with the click of a button, extracting the title from almost any link and filling up many of the parameters without any issue. Positives: Saves a lot of time. Negatives: you need to double check stuff (including the name of the reference which is unusually long; I shorten that) and sometimes, where the news link does not have appropriate meta, some of the parameters remain unfilled. Also, if you are referring books or non-webnews stuff, the reference generator would still generate a cite web instead of a cite book or relevant cite template. You would need to manually change that, but that still saves a lot of time. Try it out and tell me how you found it. Works amazing for me. Lourdes 00:57, 24 June 2016 (UTC)

Two new maintenance tags[edit]

I had a suggesion that there should be a maintainance tag that said - this article contains links that are dead (or which link to pages that dont exist) and This article has external referances that are in a language other than english --VarunFEB2003 Talk • Contribs • Guestbook 14:25, 21 June 2016 (UTC)

This is also posted at Wikipedia:Village pump (idea lab)#A suggesion. -- GB fan 14:28, 21 June 2016 (UTC)
This is specific enough to be here, and more so than many that stay here. I'm removing the idea lab version per WP:MULTI. ―Mandruss ☎ 14:35, 21 June 2016 (UTC)
@VarunFEB2003: I removed your idea lab copy of this proposal per WP:MULTI, and I changed your heading here. ―Mandruss ☎ 14:50, 21 June 2016 (UTC)
@VarunFEB2003: We don't have a template for "this article contains links that are dead", probably because it's vague (how would people know which are the good links and which the dead?). What we do have is {{dead link}} which should be applied to those specific links that are non-working. However, if those links are not used as references, but are merely entries in a "External links" section, and there is no way of updating them to a working link, normal practice is simply to remove them, see WP:ELDEAD.
Regarding non-English external links - again, each external link should be considered separately, so an article-wide template isn't appropriate. Not all non-English external links are problematic, see WP:NONENGEL; consider each non-English external link in turn, decide whether it is useful or not. If not, remove it; if useful, add an appropriate language marker such as {{es icon}} for a Spanish-language external link. --Redrose64 (talk) 22:14, 21 June 2016 (UTC)
These seem like minor issues that are best dealt with using inline tags. There's already enough pages cluttered up with maintenance tags at the top. Praemonitus (talk) 18:53, 23 June 2016 (UTC)
I'm inclined to agree with above. What problems are these tags intended to solve, especially when it appears that they'd be general tags referring to specific problems? DonIago (talk) 19:37, 23 June 2016 (UTC)
@Doniago: VarunFEB2003 (talk · contribs) has been working on Ramal Talca-Constitución which at the time of the original post looked like this. --Redrose64 (talk) 19:48, 23 June 2016 (UTC)

Mobile view[edit]

This page on a mobile device

(This proposal started at Wikipedia:Village pump (idea lab)#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[edit]

  • 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)
  • There is a mobile view gadget already. "Preview" is a basic function. This proposal is to let editors more easily preview what readers will see. Aymatth2 (talk) 02:22, 25 June 2016 (UTC)
    Updated my !vote. Thank you for pointing that out. Enterprisey (talk!) (formerly APerson) 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)
  • Support. I edit entirely off a mobile and at first had a lot of issues on account of not seeing things others on desktop were seeing. White Arabian Filly Neigh 01:01, 28 June 2016 (UTC)

RFC: should galleries use mode=packed by default?[edit]

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)

  • Support. --Izno (talk) 12:38, 24 June 2016 (UTC)
  • Support, a big improvement. the wub "?!" 13:46, 24 June 2016 (UTC)
  • Oppose for now. User:Coldcreation raises a very good point below about the packed mode being problematic with upright images. I think we should try to improve that before adopting it as a default. the wub "?!" 12:23, 25 June 2016 (UTC)
  • I made a phab task to try and improve this with upright images. the wub "?!" 20:14, 25 June 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)
  • Support, most galleries would benefit. And a note to Coldcreation, we are talking about changing the default mode, not about removing the traditional rendering mode. -- [[User:Edokter]] {{talk}} 16:42, 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

  • Ramaria stricta à Javerlhac-et-la-Chapelle-Saint-Robert, Dordogne

  • Ramaria sp., possibly R. stricta

  • 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:
Should galleries use mode=packed by default. 1.png|Should galleries use mode=packed by default. 2.png| |Should galleries use mode=packed by default. 3.png|Should galleries use mode=packed by default. 4.png
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, wether 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)
  • Support - A much better improvement to what we're using now, Personally I've never liked the big useless box anyway, –Davey2010Talk 02:53, 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)
  • Support - An improvement in the majority of cases. Since I became aware of this here, I have changed a few galleries to packed and like the results. I agree it is a better default view. Mb66w (talk) 16:12, 28 June 2016 (UTC)
    This is yet another option, called mode=nolines:

Test, mode=nolines:

Mode=nolines with small captions

Mode=nolines with the initial images and captions:

Gallery mode=nolines with upright images:

  • There are various ways to format images, none worth spending much time over given how variable the rendering will be on different devices:
2016-06-29 AYM Screenshot 1 Montage.png 2016-06-29 AYM Screenshot 2 Montage.png 2016-06-29 AYM Screenshot 3 Montage.png
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 languages: Basque Wikipedia has 250.000 articles[edit]

Yes check.svg Done Resolved at Template_talk:Wikipedia_languages#Euskara_passes_250.2C000 — xaosflux Talk 17:25, 25 June 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.

Hi everyone. I'm a basque wikipedian and I just saw on the panel "Wikipedia languages" that Basque Wikipedia (Euskara) is listed on the "More than 50,000 articles" section. I'm congratulated to tell you that yesterday Basque Wikipedia completed its 250.000 article so I think it should be now on the "More than 250,000 articles" section. Thanks. Euskaldunaa (talk) 11:37, 24 June 2016 (UTC)

@Euskaldunaa: This is a duplicate of Talk:Main Page#Wikipedia languages: Basque Wikipedia has 250.000 articles. Please observe WP:MULTI. --Redrose64 (talk) 20:41, 24 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.

Mobile Main Page changes[edit]

I don't mind having some extra options but please bear in mind that there are a wide range of screen sizes. In my household, these range from the 4 inches of the Galaxy Ace 2 through the 6 inches of the iPhone 6+, the 10 inches of the Galaxy Tab, 13 inches of multiple Chromebooks all the way up to my current 2 x 21 inch dual monitor setup. One size does not fit all. Anyway, my main point is that I noticed just today that the mobile view had changed. I'm used to viewing it on my iPhone 6+ while commuting. Usually, the main page shows the featured article with the ITN section then following underneath. The other sections are not shown. But today, for the first time, the mobile view (https://en.m.wikipedia.org) shows all the sections in a compressed version of the standard main screen. This doesn't work very well because there isn't enough space to show multiple columns. Who controls this and where do they hang out? I'd like to provide some feedback... Andrew D. (talk) 13:05, 24 June 2016 (UTC)

This appears to be related to phab:T32405. the wub "?!" 13:32, 24 June 2016 (UTC)
Turns out this was a bug (phab:T138578) and has now been fixed. the wub "?!" 13:23, 25 June 2016 (UTC)

Try #2: File:Barbra Streisand - 1966.jpg ... good to go?[edit]

(try #1) Can anyone help me further? Torfilm (talk) 17:32, 28 June 2016 (UTC)

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