Wikipedia:Village pump (proposals): Difference between revisions

• 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)[reply]
• 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)[reply]
• 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)[reply]
• Support. Herostratus (talk) 03:23, 18 June 2016 (UTC)[reply]

Discussion (chess)

• As this thread moves closer and closer to the top and the replies become fewer, I'm worried this will be archived and slip through the cracks again. I've created Wikipedia:WikiProject Chess/Interactive chess boards, drawing from some of the material here (it's incomplete, though). Perhaps we should continue there? Pinging participants: קיפודנחש, Fred Gandt, Izno, Strawberry4Ever, Naraht, Maproom, Wugapodes, MaxBrowne, Tpdwkouaa, Cobblet, Altamel. — Rhododendrites ^talk \\ 14:20, 28 May 2016 (UTC)[reply]

I've added {{

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

]

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)[reply]

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 [t^hɔk] [kantʃɻɪbz] 18:02, 28 May 2016 (UTC)[reply]

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)[reply]

Past discussions

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:

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)[reply]

I agree assuming it's technically feasible. Strawberry4Ever (talk) 15:45, 12 May 2016 (UTC)[reply]

Maproom, this might interest you. --Redrose64 (talk) 17:48, 12 May 2016 (UTC)[reply]

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)[reply]

• 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)[reply
  ]

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)[reply]

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.

Iridescent 16:51, 16 May 2016 (UTC)[reply

]

Hi, thanks for the mention

talk) 17:48, 16 May 2016 (UTC)[reply

]

@

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

]

At a guess, you'd need to set up a process akin to

Iridescent 15:45, 17 May 2016 (UTC)[reply

]

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)[reply]

@

Iridescent 17:00, 1 June 2016 (UTC)[reply

]

@

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

]

@

talk) 22:17, 1 June 2016 (UTC)[reply

]

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)[reply]

@קיפודנחש: 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)[reply]

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)[reply]

@

WP:VPT. Otherwise, is there anything others can do to help? — Rhododendrites ^talk \\ 12:29, 19 May 2016 (UTC)[reply

]

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)[reply]

PGN viewer 1 - demo

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)[reply]

@קיפודנחש: 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)[reply]

@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)[reply]

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)[reply]

@קיפודנחש: 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)[reply]

@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)[reply]

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

]

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)[reply]

I guess the big question for kipod and Fred Gandt is what would be gained/lost.

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

]

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)[reply]

PGN viewer 2 code

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)[reply]

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)[reply]

• 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)[reply]

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)

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

Nearly done; Lua was kicking my ass, but I'm fighting back. Fred Gandt · talk · contribs 10:29, 26 May 2016 (UTC)[reply]

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)[reply]

Request for Comment: Implementation of interactive chess boards

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia style and naming Wikipedia technical issues and templates Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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.

• קיפודנחש (aka kipod)'s PGN viewer demo takes Portable Game Notation (PGN) and optional Forsyth–Edwards Notation (FEN) for non-standard set-up.
  • It will output the PGN in a raw format for users with JavaScript disabled.
• Fred Gandt's chessDemo takes algebraic chess notation and optional partially plain English instructions for non-standard set-up.
  • It will fallback to an animated .gif (if provided) for users with JavaScript disabled.

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)[reply]

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)[reply]

Chess RfC: Developer Q & A

• 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)[reply]
  • 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)[reply]

• 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)[reply]
  • 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)[reply]

Chess RfC: Comments

• 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)[reply]

• 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)[reply]

• @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)[reply]

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)[reply]

• @קיפודנחש: (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)[reply]

• @קיפודנחש: @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)[reply]

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

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

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)[reply]

(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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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

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)[reply]

@קיפודנחש: 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)[reply]

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)[reply]

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)[reply]

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 minified (versus 3K minified for yours), 11K 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)[reply]

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)[reply]

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)[reply]

Maybe talk pages should have some sort of indicator that says whether a particular user is online (to be specific, has one or more Wikipedia tabs open logged in to his/her account) or not. It's just a suggestion.98.195.88.33 (talk) 21:45, 1 June 2016 (UTC)[reply]

Even assuming this were technically feasible, it would raise serious privacy issues. Newyorkbrad (talk) 21:48, 1 June 2016 (UTC)[reply]

Making it optional would solve the privacy issues, but, without much knowledge of web development, I don't think there's any continuous communication between a browser and a server when a page is open, so the server would have no way of knowing whether the user is looking at the page; there's nothing preventing someone from requesting a web page and then closing the connection, anyway. I would guess that constant pings from every Wikipedia tab open anywhere would not be ideal either. KSFT^C 05:39, 4 June 2016 (UTC)[reply]

Many editors already do this. It is, and ought to remain, optional.--S Philbrick(Talk) 17:32, 4 June 2016 (UTC)[reply]

I am not quite sure what is meant here. surely, if one were reading Wikipedia, one would be online.Vorbee (talk) 23:42, 9 June 2016 (UTC)[reply]

I am confident it is suggested that you could see if the person whose talk page you are reading is online. – Finnusertop (talk ⋅ contribs) 23:56, 9 June 2016 (UTC)[reply]

For this purpose, User:PleaseStand/User info is pretty good. It displays on the user page you are viewing the time that editor has most recently edited. If someone has edited 10 seconds ago, or a few minutes ago, it is likely that they are 'online'. – Finnusertop (talk ⋅ contribs) 23:56, 9 June 2016 (UTC)[reply]

A relatively resource light possibility would be to provide all logged in users a I'm Online button in their User interface which, only when pressed, added the user to a site wide list of online users. This list could be accessed by various methods including the API, and users would be instantly removed from the list on closing their last open Wikipedia tab or when manually clicking the button which would then read I'm Offline. That manual method doesn't need any continuous server-client communication, requires no hacks or special server side config (like Node.js for non blocking server events and stuff) and is entirely opt-in. The devil's in the details, but if it were wanted, it could be easily implemented without extraordinary measures.Fred Gandt · talk · contribs 01:19, 10 June 2016 (UTC)[reply]

I would think Step 1 would be to show the need; i.e., what significant problem is solved? The OP didn't do so, and none of the responders have done so either. Without significant need we have unjustifiable feature creep. ―Mandruss ☎ 01:31, 10 June 2016 (UTC)[reply]

I can't say I'm in favor of this proposal because this isn't intended as a social networking site. But if it were enabled I'd prefer a means to disable it for my talk page. Praemonitus (talk) 19:08, 13 June 2016 (UTC)[reply]

If it's just a tool of convenience, I might be amenable to a "Last contribution date/time" field being added to a user's Talk page and being auto-updated. While it's not a huge burden to check a user's contribution history, I'm sure I'm not the only one who's initiated a conversation at a user's Talk page only to find out they were essentially dormant. DonIago (talk) 19:40, 13 June 2016 (UTC)[reply]

DonIago, that's one of the things that User:PleaseStand/User info does. I recommend installing it; I find it very handy.

If you're having trouble figuring out how to install it, it's the last two lines at m:User:WhatamIdoing/global.js. Just copy those into a global.js file on Meta for your own account (i.e., at m:User:Doniago/global.js). WhatamIdoing (talk) 04:39, 15 June 2016 (UTC)[reply]

Well now, that's pretty nifty! Thanks! DonIago (talk) 04:50, 15 June 2016 (UTC)[reply]

Due to the increasingly heavy use of

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)[reply]

You're thinking Forbes, probably? --Izno (talk) 19:59, 7 June 2016 (UTC)[reply]

• 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
  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)[reply
  ]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]
• 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
  verifiability. --Guy Macon (talk) 14:05, 9 June 2016 (UTC)[reply
  ]
  • @
    talk) 10:27, 11 June 2016 (UTC)[reply
    ]
  • 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)[reply]
• 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)[reply]
• 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)[reply
  ]

the reverse situation, looking for what *does* already link, is handled by 'what links here' — Preceding unsigned comment added by Fmadd (talk • contribs) 03:29, 13 June 2016 (UTC)[reply]

if i understand the proposal correctly, this is already supported today: prefix the search term with tilde ( ~ ): for instance, Special:Search/Washington links to Washington, but Special:Search/~Washington should show you articles containing the word, in either the text or the article name. you can even ask to see articles containing the search term in the text but do not contain some phrase in the article name (can be the search term or something else) by using "intitle:" together with "do not contain" (precede the search term with "-"): Special:Search/Washington -intitle:Washington. for more about search, see Help:Searching. if i did not understand the proposal correctly, assume that there was at least one more person who did not understand, and rephrase the proposal. peace - קיפודנחש (aka kipod) (talk) 19:05, 13 June 2016 (UTC)[reply]

It's nice to know that. I've been searching with a null field to get the search form, then entering the term. Thanks. Praemonitus (talk) 18:59, 16 June 2016 (UTC)[reply]

I have started an RFC at

Template talk:Infobox civilian attack#Bioterrorism as an example for the type field
proposes to remove Bioterrorism from the examples for the type field of {{Infobox civilian attack}} and replace that with Mass shooting. See proposal for rationale. ―Mandruss ☎ 09:03, 14 June 2016 (UTC)[reply]

Just a reminder that in just over a week at Wikimania there's going to be a cross-Wiki discussion about the systems of control of new pages. This is a round-table rather than a presentation or a lecture. On the agenda are reforms to the new article reviewing systems and ways to help new users better understand our content policies. Anyone who is going to Italy and would like to take part, please check out the conference schedule, and I look forward to seeing you there. --Kudpung กุดผึ้ง (talk) 16:44, 14 June 2016 (UTC)[reply]

The session is intended to focus on edit-review tools at all stages, not just the page creation stage, particularly around support for good-faith new editors. We hope to discuss everything from RC to Huggle. (The full conference schedule is at wm2016:Programme). Thanks for the help and interest. :) Quiddity (WMF) (talk) 21:07, 15 June 2016 (UTC)[reply]

It's ridiculous that most experienced editors avoid requesting adminship because they don't want to go through the RfA process. After

• 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)[reply]
• 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)[reply]
• 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. –xeno^talk 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.][reply]

  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. Monty₈₄₅ 03:06, 17 June 2016 (UTC)[reply]

  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)[reply]

• 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)[reply]

• Agree, the person should definitely have to agree. — xaosflux ^Talk 14:39, 18 June 2016 (UTC)[reply]

• 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. ~ Rob^Talk 12:50, 18 June 2016 (UTC)[reply]
• 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)[reply]
• 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. KSFT^C 15:46, 20 June 2016 (UTC)[reply]
  • 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)[reply]

Basic facts

1. The community has repeatedly agreed that there are significant problems with the current RfA system.
2. The community has repeatedly rejected every single proposal to fix these problems.
3. At this point, there appear to be no proposed solutions left that have not been rejected by the community multiple times.

--Guy Macon (talk) 14:38, 18 June 2016 (UTC)[reply]

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)[reply]

Create junior-admins?

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

Dozens of times.

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

]

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)[reply]

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)[reply]

Bureaucrats Appointed Admins

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

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

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

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. KSFT^C 00:16, 21 June 2016 (UTC)[reply]

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. Monty₈₄₅ 00:46, 21 June 2016 (UTC)[reply]

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

APerson) 01:10, 21 June 2016 (UTC)[reply

]

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. KSFT^C 02:39, 21 June 2016 (UTC)[reply]

• Hey guys. I just thought I'll leave a note here about the above RFC. Those interested in commenting may leave their opposes, supports or comments here:
  talk) 16:10, 17 June 2016 (UTC)[reply
  ]

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

- 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Moved to Wikipedia:Bots/Requests for approval/GreenC bot 2

A bot request to perform a large scale update of internet archive links on pages is being discussed at

• Support. The main task being done here is to fix the formatting of certain Wayback Machine links to use https and use the full version of the URL from WM. There was wide consensus to convert such links to https at this discussion. Additionally, around 5% of the edits will either remove a non-working archive link or replace it with an appropriate archive. That's obviously useful. The rest of the fixes affect a relatively small percentage of the total here, but they're all useful fixes to ensure all archive links are working properly. ~ Rob^Talk 01:46, 18 June 2016 (UTC)[reply]

The WP:OABOT project aims at enhancing citation templates with free to read links to references, when they are available. We plan to change the visual appearance of many citation templates so we seek consensus here first - we need your input!

Concretely, we plan to change the style of links that are known to link to a free to read resource. Just like links to PDF files have a small PDF icon at the end, we plan to add a small logo indicating that a link is paywall-free. For instance, we know that all links defined by |arxiv= are free, so all citation templates using this parameter would become like this:

{{cite arXiv | collaboration = LIGO Scientific Collaboration and Virgo Collaboration | last1 = Abbott | first1 = Benjamin P. | arxiv=1602.03840 | title=Properties of the binary black hole merger GW150914 | date=11 February 2016}}

Abbott, Benjamin P.; et al. (LIGO Scientific Collaboration and Virgo Collaboration) (11 February 2016). "Properties of the binary black hole merger GW150914". arXiv:1602.03840

In this case, the free to read icon would appear without changing any of the template arguments - the Module:Citation/CS1 would be modified directly and this would affect all citation templates globally. We would make this change for other identifiers that are necessarily free to read, such as |pmc=. Technically, the icon would be inserted using CSS code (the same way PDF icons are currently displayed). It could replace the external link icon (- >) to save space.

We also want to be able to add this icon on arguments that are not always free to read such as |url= or |doi=. To do so, we would need to change the template to indicate that the link is free, for instance by adding |doi-free=true or |doi-free=10.1016/S0168-0072(03)00052-6

{{Cite journal| doi = 10.1016/S0168-0072(03)00052-6| doi-free=true| issn = 0168-0072| volume = 124| issue = 1–3| pages = 71–106| last1 = Coquand| first1 = Thierry| last2 = Sambin| first2 = Giovanni| last3 = Smith| first3 = Jan| last4 = Valentini| first4 = Silvio| title = Inductively generated formal topologies| journal = Annals of Pure and Applied Logic| date = 2003-12-15}}

Coquand, Thierry; Sambin, Giovanni; Smith, Jan; Valentini, Silvio (2003-12-15). "Inductively generated formal topologies". Annals of Pure and Applied Logic 124 (1-3): 71-106.

ISSN 0168-0072

.

Of course, multiple links in the same citation template could appear with the free to read icon. − Pintoch (talk) 15:16, 19 June 2016 (UTC)[reply]

Please discuss this change at Help_talk:Citation_Style_1#Adding_open_access_links_to_references. This will impact millions of pages, we need a clear consensus! − Pintoch (talk) 20:59, 19 June 2016 (UTC)[reply]

Hi, I'm from the Norwegian Wikipedia, and I'm currently working on the Barbra Streisand article. I would like to use the Barbra Streisand - 1966.jpg file, but it was uploaded "by a user who is currently the subject of a contributor copyright investigation. As such, until the file is thoroughly investigated it should not be moved to Commons." However, it seems as though the investigation has ended, while there still is 132 pictures left. Could anyone with the right authority check the Streisand file to check if it's okay to upload on Commons? Torfilm (talk) 18:50, 19 June 2016 (UTC)[reply]

The CCI investigation is/was this one ... it looks like it rather fizzled out. The uploader, Wikiwatcher1 (who is presumed also to be user Light show) asserted that there was no copyright on publicity stills, Wikimedia legal advice came close to the same conclusion, but there was some haggling about the fine print (can we prove images were not registered/reregistered) and not a meeting of minds (uploader dealing in "publicity stills", wikimedia lawyers talking to "production stills". My feeling is that it is indeed good to go. But ping @Moonriddengirl:, who may be able to opine further. --Tagishsimon (talk) 19:06, 19 June 2016 (UTC)[reply]

In Preferences, Watchlist tab, the option "Expand watchlist to show all changes, not just the most recent" shows the usernames in ascending edit count sequence. Assuming we're most interested in the highest contributors, it would be more useful to sort in descending edit count sequence instead. Then you wouldn't spend time scanning to the end of the list. You would start at the beginning and scan until you deemed the edit counts too small to continue. Worth doing? ―Mandruss ☎ 02:16, 20 June 2016 (UTC)[reply]

@Mandruss: I'm not quite understanding your proposal - Special:Watchlist is sorted chronologically - can you provide some more information? — xaosflux ^Talk 03:32, 20 June 2016 (UTC)[reply]

@Xaosflux: With that option enabled, you also get a list of the contributors to each page, on that date, with edit counts when they exceed 1. Those lists are what I'm referring to. You might enable the option and have a look. ―Mandruss ☎ 03:43, 20 June 2016 (UTC)[reply]

OK, I see now - combination of "group changes" and "expand watchlist to show" has to be on for that behavior. - I uploaded a screenshot above. — xaosflux ^Talk 03:57, 20 June 2016 (UTC)[reply]

I think the next question is to determine where this is being generated - anyone know without climbinis g though the code? — xaosflux ^Talk 03:59, 20 June 2016 (UTC)[reply]

And the list can go to two, three, or more lines, depending on the number of usernames and the width of the window. Since it doesn't end in a predictable or consistent location, finding the end takes a non-trivial amount of scanning. One occurrence is nothing, but this stuff adds up. ―Mandruss ☎ 04:58, 20 June 2016 (UTC)[reply]

not sure why do you claim that the users are listed in ascending or descending order of # of contributions. did you read it in the docs somewhere, or is it an observation? if the latter, maybe you should look for one or two more samples - this simply does not seem to be true.

i can't quite understand the order in which users are listed in this mode - it may be completely arbitrary, but i'm pretty sure it has nothing to do with # of contributions. i do not think this number is readily available, and obtaining it just so the names can be sorted by it seems excessive - it will have significant cost, and no gain whatsoever. peace - קיפודנחש (aka kipod) (talk) 05:22, 20 June 2016 (UTC)[reply]

Maybe we're looking at different things. Here's another real-life example of the list: [Lowercase sigmabot III‎; Neutrality‎; 71.182.239.232‎; DHeyward‎; WWGB‎; Computationsaysno‎; Shearonink‎ (2×); Ad Orientem‎ (2×); Victorgrigas‎ (2×); Wnt‎ (2×); Penwhale‎ (3×); Felsic2‎ (3×); MrX‎ (4×); Pincrete‎ (5×); Ianmacm‎ (5×); Alanscottwalker‎ (6×); Mandruss‎ (15×); InedibleHulk‎ (15×)]. The number is clearly readily available, as I see it displayed on my screen. I claim it is in ascending edit count sequence because it is in ascending edit count sequence (I'm pretty good at this kind of thing). Just in case, I have double-checked my entire watchlist, and every list is in ascending sequence. I believe the significant cost is already being spent. Thanks. ―Mandruss ☎ 05:31, 20 June 2016 (UTC)[reply]

It's probably not edit count but account ID, indicating age of account. --Izno (talk) 11:07, 20 June 2016 (UTC)[reply]

I can confirm that the ordering is ascending by edit count as stated. To see it for yourself the user preferences Group changes by page in recent changes and watchlist and Expand watchlist to show all changes, not just the most recent must be checked. The processing is done server side in the extension, as the HTML page source contains the markup (it's not worked out by JavaScript). Fred Gandt · talk · contribs 13:13, 20 June 2016 (UTC)[reply]

i think there's some lingo confusion here. in wp lingo, "edit count" usually meas the total number of edits the user made on the specific wiki, since she initially registered. the "edit count" mentioned in this thread, is something else entirely: it's the number of edits this user made in one specific day, on one specific page. this explains the previous confusion. that said, the suggestion makes sense, but i don't think it makes sense to behave differently on enwiki than anywhere else, so i think something like this is more appropriate on phabricator than enwiki proposal page. peace - קיפודנחש (aka kipod) (talk) 17:42, 20 June 2016 (UTC)[reply]

Ah, that clarification helps! I don't think the sorting matters that much. I think I'd most like to see the order by who most recently changed the page personally, but I don't really care any which way. --Izno (talk) 17:46, 20 June 2016 (UTC)[reply]

It's been my experience that we get consensus here first, then go to phab. ―Mandruss ☎ 21:08, 20 June 2016 (UTC)[reply]