Wikipedia:Village pump (proposals)/Archive 123

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

RfC: Proposal to add global JavaScript and redirect all IRC help links through a disclaimer page

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

---

Propose moving User:PhantomTech/sandbox/IRC Disclaimer to Wikipedia:IRC help disclaimer and redirecting all links that connect users to the #wikipedia-en-help channel to Wikipedia:IRC help disclaimer in addition to adding the script at User:PhantomTech/Scripts/IRCNick.js to MediaWiki:Common.js. PHANTOMTECH (talk) 04:02, 12 April 2015 (UTC)

Details: There are currently several problems with the IRC help channel, a few of those problems are that people often ask the same questions and that helpers sometimes have issues helping people because of the nicks they're given. Right now, almost all links give the default nick "WPhelp" with a nice long number at the end. As this post points out, this not only causes issues for people trying to help but also the people being helped. The proposal aims to cut down on the number of repeated questions (though not everyone may read the page) and give user's a friendlier IRC nick by default. Not all issues with the help channel are solved by this but it is a pretty simple modification that can solve one of the bigger issues. Currently, the script picks nicks in the following way:

• Users who do not support javascript fallback to using one of the current "WPhelp" nicks
• If the user is logged in, their nick is the first 11 characters of their username with anything non-alphanumeric characters replaced with an underscore and "-WP##" added to the end, where ## is a two digit number unless the username has 4 or more characters replaced with an underscore, then the next option is used.
• All other users are given a username that starts with a random color with "-WP###" added to the end, where ### is a three digit number. Colors are used because they are the least likely to offend people.

Example: Someone whose username is User might get the nick User-WP42, someone with the username Full.Stop might get the username Full_Stop-WP20 and someone who is not logged in might get the username blue-WP493. Note, "might" is used because the numbers at the end of the usernames are chosen randomly and the color in the last example is also chosen randomly. Feel free to ask for any clarification or any more examples, the script can be tested by following instructions at the top of the page at User:PhantomTech/sandbox/IRC Disclaimer to see what nick you would be given. PHANTOMTECH (talk) 04:02, 12 April 2015 (UTC)

Cross posted to WikiProject AFC, Teahouse and the help desk. PHANTOMTECH (talk) 16:54, 15 April 2015 (UTC)

• OpposeSee explanation below the disclaimer as written, could support it with some heavy revision. Oppose adding such a script to Common.js as that is not the appropriate place for such a thing. I could see a nick picker added to an on by default gadget though (such as the Teahouse Ask a Question script), and I would support such a suggestion. — {{U|Technical 13}} (e • t • c) 15:41, 13 April 2015 (UTC)

Could you be more specific about what you think is wrong with the disclaimer? I have no issue making this a default gadget instead of something in common.js, assuming that default gadgets are enabled for IP users. PHANTOMTECH (talk) 19:44, 13 April 2015 (UTC)

• Full support. I'm not commenting on implementation as a default-on gadget or as an addition to common.js, but whatever is according to convention is fine by me. --L235 (t / c / ping in reply) 16:35, 13 April 2015 (UTC)
• Support. Because it's nice to give people some context around the Freenode webchat interface, and the username consistency is a nice touch. But I think that it's unnecessary and unhelpful to tell questioners to RTFM before asking. I'd strongly prefer that language be removed if you plan to implement this for the Teahouse IRC channel (TH is the anti-RTFM). That said, no one uses the TH IRC channel anyway, so it's basically a non-issue. Cheers, - J-Mo ^{Talk to Me} _{Email Me}
  • Yeah, I don't see new editors in there often, but I'm pretty sure that is because -en-help is what is linked to from the THQ page and the only one ever mentioned. That kind of makes -en-help the Teahouse channel also, which suggests that it should be the anti-RTFM as well. — {{U|Technical 13}} (e • t • c) 16:41, 16 April 2015 (UTC)
• Support. Great solution and implementation. APerson (talk!) 03:29, 17 April 2015 (UTC)
• So...you want to provide people with a link that will very easily associate their username with their IP address? Legoktm (talk) 03:39, 17 April 2015 (UTC)

@Legoktm: Yes, but not much more than is already done. The script doesn't force the username on them, it just prefills it so they do still have the option to change it if they wish. As it is, people are already associating their username with their IPs, probably without knowing it. One of the first questions people tend to be asked are "What's your username" or "What article/draft" so that they can be helped easier, while the last one isn't direct, it isn't hard to figure out their username from a draft with one contributor and IRC gives us their IP when they join. With this solution, the association is more automated but there's a warning for anyone who's unfamiliar with IRC, something that doesn't exist right now. PHANTOMTECH (talk) 16:50, 17 April 2015 (UTC)

• Support - I think it works well, it's cool, and provides a central place to link all of IRC to. We need a disclaimer talking about IP addresses anyway, and some of the other stuff is also pretty useful. Am not opposed to revising the disclaimer in a way that Technical 13 is happy with. — kikichugirl ^oh hello! 17:02, 20 April 2015 (UTC)
• Support, although I would avoid unnecessary jargon (like "IP" instead of "IP Address", "IRC" without any explanation, "FAQ" instead of "Frequently Asked Questions", and "#Wikipedia-en-help") in the green box. I mocked up a more "noob friendly" version of the green box at User:Ahecht/sandbox/IRC_Disclaimer --Ahecht (TALK
  PAGE) 17:18, 20 April 2015 (UTC)

@Ahecht: Feel free to merge your changes into my sandbox, your version does seem more user friendly. PHANTOMTECH (talk) 20:09, 20 April 2015 (UTC)

• I've trimmed the code and made it HTML5 compliant. That works fine for me. As for the IRC nicks, I've added another option that both addresses the WPHelp/Guest issue and the anonymous issue that Legoktm brought up here. — {{U|Technical 13}} (e • t • c) 20:30, 20 April 2015 (UTC)

• Assuming this isn't closed yet, I'd like to say it sounds like a good idea. I'm not sure why something odd involving revision IDs has been implemented instead. That seems like a creepy way to find out what someone's draft is; better to just have their username, and the -WP### thing is a good workaround for registered nicks. ekips39❦talk 01:54, 28 April 2015 (UTC)
• Strongly oppose forcing additional global JavaScript on every user on the encyclopedia for something that will not work most of the time due to the IRC naming restrictions which limits nicks to 16 alphanumeric characters, plus underscore, hyphen, and pipe, where the first character must be a letter. Many of the people who come to help in the channel are IP editors, so the script wouldn't work for them (can't start with a number or include a period), many of the editors with accounts I've found to have non-latin usernames (Múññå ShÈœhzÄdå), start with a number (2-Door), or include disallowed punctuation (Dermont~enwiki or As'ad A R).

Also, the current scheme for nicks is being misrepresented (as it was modified per consensus yesterday). WPHelp usernames have been deprecated in favor of nicks that offer the helper a starting point for where to help the person that is showing up for help. Quite often, people don't know how to link their draft, don't have a username, can't point the helper to their draft or question, and those people get sent away with "Sorry, you can't be helped, go away and come back when you get a clue", this damages editor retention. Currently, all of the templates give the status of the draft or a single letter indicator and the revision id of the page they came from which allows helpers to help those people who would otherwise be unable to be helped increasing friendliness and improving editor retention.

This proposal to take away the links to IRC from drafts (you have to navigate through a separate page adding to frustration of "can't I just please get some help?"), adds global JavaScript bloat to Common.js (using code that isn't compliant with WMF standards for a gadget no less). I know I suck at explaining things, but this community just made me the Editor of the week for being "a strong voice of the technically-oriented editors", and I hope that says something to some of you that my goal here is to protect the wiki from the damage this highly technical proposal will cause. — {{U|Technical 13}} (e • t • c) 19:23, 28 April 2015 (UTC)

With respect; Technical 13, posting two times with two separate bullet points, with bolded votes for each, is misleading. And I say the following as the person who wrote the nomination statement for your being awarded Editor of the Week: EotW should definitely not be cited in a community discussion as anything that would influence anything. Thanks, --L235 (t / c / ping in reply) 04:10, 29 April 2015 (UTC)

@Technical 13: Not sure why you decided to !vote twice instead of just expanding on your original post or why you felt the need to add so much formatting to your "strong oppose" but guess I should start replying to your points. I don't know what you're talking about with there being problems with IP users, you read the proposal right? I even explained to you in IRC earlier that anonymous users are accounted for by the script with colors instead of trying to use their nonexistent username. Usernames that can't be used as nicks are also accounted for, and again that's explained in the proposal, non alphanumerical characters are replaces with underscores and there's a fallback to colors if too many characters are replaced. You mentioned that there are a lot of users who have usernames that would create a problem, you don't by any chance have any statistics to back that up do you? Sorry for "misrepresenting" the nicks, as you pointed out it was changed after this proposal was made, you wouldn't mind pointing to where the consensus for the change was by the way? It doesn't seem like there was any. Again for the point about people unable to point to their draft or whatever they need help with, could you provide some statistics that show how many people have this problem, excluding anyone that wouldn't have the problem as a result of this proposal? Even if there is no consensus for this proposal, the current (new) system has to be replaced, it appears to have been implemented without any consensus and is a major privacy issue, it uses what looks to users like a random number to effectively link usernames to IP addresses.
As a side note related to your EOTW message, it seems that to say the "community" made you editor of the week is a gross misrepresentation since it looks like only a very small number of users participated in the discussion. Additionally, it seems somewhat dishonest and petty to advertise yourself in this way. There are editors who are familiar with you, these editors have their own opinions of your skills, how much you should be trusted, etc. so to them this is pointless. What you have left are the editors who aren't, for whatever reason, familiar with you and may not be familiar with EOTW, presenting this information to them creates an unnecessary bias in the same way one would be created if sysops advertised their admin status on their replies and it is for these reasons that they don't. It is possible that your concerns are valid however it is counterproductive to say "this code isn't formatted right, let's just throw out the idea, trust me." Surely it would be trivial for someone with the technical expertise you seem to claim to have to make the code compliant with whatever standards it may have an issue with and it doesn't help that you explicitly said that you would support a nick picking gadget in your original oppose !vote. PHANTOMTECH (talk) 04:37, 29 April 2015 (UTC)

Agreed. I wrote something similar but it wasn't as good and didn't add much, so I won't bother posting all of it. I did have a couple of additional points, though: I haven't seen people turned away for the reasons T13 gives, and many people come in with custom nicks, which defeats the purpose of the revision ID nicks. ekips39❦talk 04:43, 29 April 2015 (UTC)

• I struck the above !vote with a note to see down here. It would have been inappropriate to add that much text indented above, and you would have accused me of trying to sneak it in there like last time. So, I added it down here. I very much think that adding JavaScript code to compromise editors privacy and security is a big deal, especially when the code is as badly flawed as it is from a technical standpoint. Also, since the title for this section is very deceitful, I've reworded it to be appropriate. — {{U|Technical 13}} (e • t • c) 14:19, 29 April 2015 (UTC)

• Interesting new title. The proposal is about the help channel, not all IRC links (how would we add a disclaimer to all IRC links, anyway?), and "proposal to add global JavaScript" sounds as if we didn't have any global javascript before. I think the previous title was less misleading, though it's worth including something about the nick bits, I suppose. Something that makes clear what the purpose of the global javascript is. Can't think of a way to say it that doesn't sound too long-winded. Also, that's not what the javascript will be doing, but this has been explained at length... ekips39❦talk 23:17, 29 April 2015 (UTC)

• @Ekips39: I've edited the title to make it more accurate. Also, still not buying Technical 13's objections, seeing as PhantomTech clearly explains that their script would fix all of the alphanumeric character problems. The current revid usage is also a potential privacy issue as someone mentioned somewhere in this textwall... — kikichugirl ^oh hello! 18:23, 30 April 2015 (UTC)
  • While the current revid usage is not a privacy issue as it only connects any IP/person that can view a draft to the draft, this proposal is certainly a privacy issue as it directly connects a username to an IP and in doing so outs the user. — {{U|Technical 13}} (e • t • c) 03:07, 7 May 2015 (UTC)
    • The disclaimer is meant to solve that problem. It warns you that it will reveal your IP. If you willingly enter the room anyway, then you willingly disclose it and connect it to your username. The RevId, done without consensus, does not clearly state that it is a privacy issue at all, or even that an IP will be revealed. — kikichugirl ^oh hello! 03:38, 7 May 2015 (UTC)
    • It is a safe assumption to say that a user who joins the IRC help channel from a draft link is the major, or usually only, contributor, and your original mention of the current system seems to recognize this lack of anonymity by stating that the extent to which their anonymity is important is limited to anonymity perceived by the helpee. There is no worse level of anonymity than near complete transparency which is disguised as anonymity, and, by using what looks like a random number, that is exactly what the current system does. By using usernames, users are fully aware of the information they are sharing and free to change it prior to connecting. PHANTOMTECH (talk) 04:00, 7 May 2015 (UTC)

• Support the disclaimer. I've always thought editors connecting to the help channel were insufficiently warned that their IP would be revealed. As they would need to take further steps to identify the IP with an on-wiki account, it wasn't a huge deal, but did make me a bit uncomfortable. The current implementation has made the issue much more severe. Now, the default nick you enter IRC with, ties your session back to a revision of the page you came from, which in most cases, means that your IP which was already visible on IRC, can with a reasonable certainty, be tied directly back to your account here. In my view, in the absence of a clear notification to the user that this will be possible, this is a violation of the foundation privacy policy. I would actually go a bit further, and explicitly state that it will be possible to connect the IP and username by connecting. We may also want to ask someone from foundation legal whether they feel the language provides sufficient warning about what is going to be revealed. (As an aside, I think many people are unreasonably sensitive about revealing IP information, but the community has decided to respect their concerns, and so we should be consistent) Monty₈₄₅ 14:37, 29 April 2015 (UTC)
• Support the disclaimer for that channel. Not sure if I can get behind adding that script to common.js. We should also all be aware that adding an interstitial page between the IRC link and the channel will cause fewer people to actually go to the channel to get help. On balance that's probably ok (given that inadvertently revealing your IP can cause actual harm), but it's a likely consequence. Protonk (talk) 00:13, 8 May 2015 (UTC)

@Protonk: Would you support adding the script as a default gadget instead of to common.js? PHANTOMTECH (talk) 01:06, 8 May 2015 (UTC)

Well, I don't know. First, if we're going to mangle the usernames to fit them into IRC (and de-dupe, I'm assuming?) why not just assign a random name? Protonk (talk) 01:15, 8 May 2015 (UTC)

• Why not have the nick be a direct link to the page the helpee wants help with so they don't have to be sent away without any help because of language or technological barriers? (that's what it currently is now btw, a status indicator and a revid number so the helper can actually help the helpee). — {{U|Technical 13}} (e • t • c) 01:49, 8 May 2015 (UTC)

@Protonk: Usernames make it easier for helpers to find the information they need to help helpees, a random name (color, since some names could be considered offensive) is assigned to IPs. @Technical 13: Usernames don't look like a random number, so helpees know what information the nick contains, and revids don't solve the problem of making it easy to tell helpees apart that both helpers and helpees have. PHANTOMTECH (talk) 02:04, 8 May 2015 (UTC)

That sounds reasonable. I'll take another look at the code. Protonk (talk) 02:25, 8 May 2015 (UTC)

. I'm onboard with the code now. I'm still skeptical that we want to mangle the usernames in the first place especially imagining a long username truncated and with some "_"'s added could be worse than a random one in a lot of cases. Protonk (talk) 16:55, 14 May 2015 (UTC)

I agree that having to edit usernames at all isn't ideal and that usernames can exist that would be better off just being random but I don't think they'll be too common. I think most of the time a username gets changed it will still be useable, but I'm usually in the live help channel so if I'm wrong, I should notice and be able to modify the script. PHANTOMTECH (talk) 17:57, 14 May 2015 (UTC)

• Oppose Both especially oppose the JavaScript. I hate to say it but JavaScript is a security flaw and a bunch of issues waiting to happen. And the other point, I don't think linking users to yet another page is going to help. When I was new, all I wanted was to actually converse with a real person, not get sent round in circles in Help: pages and Wikipedia: pages... I also want to point out that anyone editing from an IP probably knows their IP is being thrown around (should we add more disclaimers to that -_-) and in general Wikipedia isn't "private or one on one". In my opinion it would make more sense to add a small something to the IRC chat page, like it already has. "Hi there, WPhelp44410...other crap...Replies could take several minutes. If you are asking about a particular page, please provide a link and/or your on-wiki username to make it easier for our volunteers to assist you. " Makes more sense to just toss something on there, instead of routing users away from help and to more useless FAQ's and Instruction pages. EoRdE6^{(Come Talk to Me!)} 01:27, 14 May 2015 (UTC)

Wikipedia already uses JavaScript, what additional security flaws and issues would this script introduce? The disclaimer warns about linking usernames to IPs, not IPs to IPs. Adding a disclaimer inside the IRC channel is like not letting someone read a contract until after they sign, it's too late at that point. PHANTOMTECH (talk) 06:18, 14 May 2015 (UTC)

The issue with "anyone editing from an IP probably knows their IP is being thrown around" is that it doesn't matter if they're logged in or not, if you join the IRC channel your IP is visible unless you have a cloak (which 99.9% of helpees don't). Sam Walton (talk) 08:59, 14 May 2015 (UTC)

• Oppose the JavaScript because people don't read the small print (or the big print, for that matter), and will unwittingly link their IP with their account without meaning to. Support a disclaimer which warns users of the possibility, though not all will take notice, per Monty. Alakzi (talk) 01:49, 14 May 2015 (UTC)

I've said this before somewhere above but there's a lot there now so, people already unknowingly link their IP to their account when they say what draft or whatever they need help with, (or while the current revid system is in place, just by joining) using usernames as the default makes autocompleting nicks easier, is less confusing for helpers/helpees and can help helpers help helpees faster. PHANTOMTECH (talk) 06:18, 14 May 2015 (UTC)

• Unarchived, waiting for formal close. PHANTOMTECH (talk) 07:42, 22 May 2015 (UTC) New timestamp for archive bot PHANTOMTECH (talk) 05:08, 28 May 2015 (UTC)

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

Which usergroups should be allowed to add and remove tags ?

It is now possible to manually add tags, provided they have been defined by admins at Special:Tags, and to remove these as well as undefined tags. Two userrights are added :

• The applychangetags right allows to add a tag when making an edit, which is useful for scripts since it allows to track edits made by the script. It is given to all registered users by default, and it is not proposed to change this.
• The changetags right allows to add tags after the edit has been made (typically by another user) and remove tags provided they are user defined or not defined at all. It is useful especially for bot tagging (vandalism, copyvios, etc), and the ability to remove them is needed in case of abuse or bot failure. It is given to all registered users by default.

In the original feature request, there was consensus to provide the abilities offered by the changetags userright to bots and sysops, but not beyond these two groups. As such, I suggest that this second right, changetags, be removed from the 'registered user' group, in accordance with the previous consensus, and added to 'bot' and 'sysop', for the following reason :

1. The user interface is quite visible in histories, logs and once phab:T98611 will have been resolved, contributions; which could be confusing for inexperienced users and of little general use. On the other hand, sysops already have the chechboxes of revision deletion so it's a minor change for them. (It is not shown currently since no manual tags have been defined. EDIT: But as soon as tags will be created for use by bots or scripts, the UI will be visible again.) See also Wikipedia:Village pump (technical)/Archive 136#Edit Tags.
2. The use case is relatively small, and when needed a sysop can be asked to make the cleanup (same as moving without redirect).
3. It's relatively easy to cause disruption with this feature by removing undefined tags which might still be of use, and in other ways once multiple manual tags will have been defined.

It has also been suggested to grant the 'changetags' userright to template editors and edit filter managers, to which I have no objection but which would require a consensus. Cenarium (talk) 16:58, 8 May 2015 (UTC)

• You do realize it is already hidden from all other users except sysops right, so we can't use it anyway. It was solved on VPT last week and in phab, don't know the number RN. EoRdE6^{(Come Talk to Me!)} 17:05, 8 May 2015 (UTC)
  • This was 'solved' only temporarily (and sysops can't see it either, for your information). When tags will have been defined, the UI will be visible again. I made this clearer. And even though the UI is hidden, the action can still be used. Cenarium (talk) 00:32, 9 May 2015 (UTC)
• I think we should move it to auto confirmed. Then hide the interface behind some type of opt in, requiring either a preferences setting or css/javascript to enable it. It seems no more likely to be abused than many other things auto-confirmed editors can already do, and the issue with it being so visible on the interface of everyone is mitigated. Also, so few editors commented on the user rights question in the previous discussion that it is a really weak consensus. Monty₈₄₅ 00:54, 9 May 2015 (UTC)
  • That was not a weak consensus. The proposal was for bot tagging of (other users') edits, and everyone supported bot tagging of edits, but nobody suggested going beyond that, i.e. allowing ordinary non-bot users to tag edits. Sysops need to be able to remove these for cleanup, which I described as 'mass untag' in the original proposal, so they should also have the right. You suggest to somehow 'hide' actions available to a usergroup by default. Is that some sort of security by obscurity ? I disagree with this approach. If a userright is not useful to a group, then we should not grant it. If it is useful, we should grant it. There is no preference option to hide/show this UI, and I do not expect one to be created. As for gadgets, these tend to be unreliable. And this would have the significant disadvantage of not showing the UI for those where this would actually be useful, i.e. sysops and members of the template editor or abuse filter manager groups. Cenarium (talk) 10:58, 9 May 2015 (UTC)
• I think this should be limited to bots and sysops, with the ability to grant it to other users should a strong need arise (I don't know if it ever will but its a possibility). I'm under the impression this feature was added so that bots could tag edits, not so that anyone could. Sam Walton (talk) 11:07, 9 May 2015 (UTC)
• I'd like this ability to be used for all sorts of scripts from the teahouse script, twinkle, to Technical 13's^[†] OneClickArchiver^[†] script. Since not all the maintainers for scripts that would be using this are sysops, TEs and EFs should be able to manage the tags for their scripts. I don't care if it's given directly to those existing group or if it's added to a new script/gadget maintainer group with a set of api/gadget/technically related permissions. — {{U|Technical 13}} (e • t • c) 11:35, 9 May 2015 (UTC)
  • Okay, so I created a test tag for OneClickArchiver on testwiki:Special:Tags and learned that in order to add labels and descriptions, tag managers would need to be able to create and edit pages in the MediaWiki namespace (I had to create testwiki:MediaWiki:Tag-OneClickArchiver and testwiki:MediaWiki:Tag-OneClickArchiver-description for my test to work properly). That being said, knowing that there has been some objection to the ability to edit interface pages being added to TE in the past (although I suppose WP:CCC), I'm thinking the best way to handle this is to create a new usergroup for "Scriptmaintainers" I'd suggest that this new group should be a vetted nomination RfX style process and that any permissions that may be needed to work on scripts should be granted to this new group. I'd think that at a bare minimum:
    • managechangetags Create and delete tags from the database
    • editinterface Edit the user interface (needed as mentioned above because tags use these interface pages, this is also where gadgets are stored)
    • edituserjs & editusercss Edit other users' JavaScript files & CSS files (this is why I suggested a vetted process, there is a lot of abandoned code that needs to be repaired on this wiki and forking it may not always be sufficient or appropriate because it is hard to maintain the attribution that way)
    • noratelimit (probably not minimum necessary, but would be useful)
    • apihighlimits (script = api = very useful for testing and working on scripts and improving ability to update template transclusions as needed.
    • tboverride per  Template editor
    • templateeditor per  Template editor
    • rollback (to quickly rollback a change to a script that has an undesired result that proper testing didn't reveal that could be damaging to the encyclopedia)

    I have to run, but I will happily finish this train of thought later and hope to see some feedback on it. — {{U|Technical 13}} (e • t • c) 22:49, 10 May 2015 (UTC)

We should settle this one way or the other, otherwise once user-defined tags will get created, we'll have another panic, so here's a poll. Cenarium (talk) 01:14, 17 May 2015 (UTC)

I should clarify that the poll is only on the changetags userright, for the reasons given in my original post. Cenarium (talk) 15:28, 17 May 2015 (UTC)

Option 1 (tag editing permissions)

The following usergroups may add or remove tags on arbitrary edits and logs (changetags userright) : bot, sysop, edit filter manager and template editor.

1. Support Since there's only consensus for bot tagging and script tagging, but not for manual tagging. Those usergroups would benefit from access, they may need to cleanup after bots and scripts, but autoconfirmed users in general have no use for it, and hiding the interface for all would make it harder for the former to find out about it when the need arises. Cenarium (talk) 01:14, 17 May 2015 (UTC)
2. This should be for managechangetags and related rights needed to accomplish this task if not already present. — {{U|Technical 13}} (e • t • c) 03:21, 17 May 2015 (UTC)
3. Okay, but this has nothing to do with editing templates..? — This, that and the other (talk) 04:15, 17 May 2015 (UTC)
   • I should note that I support giving this right to edit filter managers. It is conceivable that they may set up an edit filter that tags edits in error, and they might wish to remove those tags from edits after deactivating the relevant filter. — This, that and the other (talk) 01:31, 23 May 2015 (UTC)
4. Bot, sysop: yes. Edit filter manager and template editor, no, neither needs it for their job. A "changetageditor" group assignable by admins at WP:PERM, sure. Anomie⚔ 11:05, 17 May 2015 (UTC)
5. Support for admins and bots - I see no reason, in general, to allow non-admions to do it, except for plausably the need to rename tags - and this would be done by a bot. עוד מישהו Od Mishehu 11:21, 21 May 2015 (UTC)
6. Support, but only for admins and bots. Tags, as others have already stated, have nothing to do with editing templates. APerson (talk!) 18:45, 22 May 2015 (UTC)
7. Support the more limited proposal, at least for now. Let's see how tags work for a while. We can always come back and examine the use cases for autoconfirmed later. Also as others noted above, I don't see why template editors would be included here, aside from the general idea that they are "trustworthy". "Trustworthy" isn't really a use case. Alsee (talk) 02:33, 24 May 2015 (UTC)
8. Support admins and bots only. --L235 (t / c / ping in reply) 14:05, 24 May 2015 (UTC)
9. Support for admins, bots, and EFMs (to clean up after a bad edit filter). Not for template editors, though, as it seems out of scope. Jackmcbarn (talk) 01:34, 28 May 2015 (UTC)
10. Support for admins, bots, and EFMs, per Jackmcbarn. And for Template Editors, per SMcCandlish below. All the best: Rich Farmbrough, 17:43, 31 May 2015 (UTC).
    

Option 2 (tag editing permissions)

All autoconfirmed users may add or remove tags on arbitrary edits and logs (changetags userright), but the interface is hidden by default in common.css or js.

1. Support As its pretty much what I proposed above. I don't really see how disruption incorporating tags will be any worse than other auto-confirmed vandalism, so this seems the right permission level. By setting it up so that editors need to turn it on, hopefully most people will educate themselves on how they work (any any relevant policies on their use) before using them. Monty₈₄₅ 02:02, 17 May 2015 (UTC)
2. Yes, this should be for applychangetags and changetags — {{U|Technical 13}} (e • t • c) 03:23, 17 May 2015 (UTC)
3. Support: This isn't "dangerous" enough that it needs to be limited to admins. At worst limit it to templateeditors and similar. And allow templateeditors to do what was above suggested for "scriptmaintaners". We don't need yet another caste of editors. Either we're responsible and technically competent, or we're not. We don't need to fork the tech stuff into little techie sub-fiefdoms. If it's not so fraught with peril that only admins should be allowed to do something, just have templateeditors be a general class of technically proficient editors and stop making it so hierarchically, bureaucratically complicated.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:48, 24 May 2015 (UTC)
4. Support: not dangerous enough. Creating a new group for tagging and giving tagging permissions to template editors may create a new generation of hat collectors. Esquivalience ^t 21:53, 28 May 2015 (UTC)

Discussion (tag editing permissions)

WP:Tags has some technical details, but there should be an outline of why adding/removing tags might be desirable before discussing who is able to perform that operation. Are there any examples of how this activity would benefit the encyclopedia? I recently added a discretionary sanction notification here and its history shows the useful "Tag: discretionary sanctions alert". However, if it is technically possible for, say, template editors to manually add or remove that tag, its utility would be diminished. At the moment, the "Tag filter" search on a long history page provides a guaranteed way to quickly show whether or not a notification has been delivered. Things would be less certain if such tags could be added/removed manually, perhaps by accident. Why would it be helpful, say, for someone to add "references removed" tags to hundreds of edits? It sounds like just another thing to argue about, unless there is some known reason why manual tagging would be useful. Johnuniq (talk) 01:54, 17 May 2015 (UTC)

Any tag must be specifically activated for user editing before it could be edited. And further, a tag applied by an existing edit filter cannot be marked for user-editing (although the reverse could be done). So much of this is worrying about things that will probably never happen (i.e. unless some admin does something stupid). Anomie⚔ 11:05, 17 May 2015 (UTC)

• We'll also need to contact bot operators to see if they're interested in making their bots tag edits, for which I guess a BAG approval would be needed. A couple of bots I think of : ClueBot NG (talk · contribs) (for edits with a high prob of vandalism but not high enough for rollback), CommonsDelinker (talk · contribs) (some of the deleted commons files may be acceptable on enwiki), CorenSearchBot (talk · contribs) (copyvios, copy pastes, templates often get removed), EranBot (talk · contribs) (copyvios) and XLinkBot (talk · contribs) (bad links/spam).

Now, for scripts and such : WP:TW, WP:HG, WP:STiki. Should we have some sort of process for approving these, or just a discussion at WT:Tags ?

The last part would be replacing some of the tag-only edit filters, with bot requests. Cenarium (talk) 15:22, 17 May 2015 (UTC)

I'm not sure what sort of standard we need for new scripts, but well established widely used scripts should be fine with a basic discussion at WT:Tags. Alsee (talk) 02:53, 24 May 2015 (UTC)

Agreed. Cenarium (talk) 23:33, 24 May 2015 (UTC)

• I suspect I am not the only one who would appreciate it if someone could explain in plain, non-technical English what this is and why we might want to use it. Beeblebrox (talk) 14:31, 24 May 2015 (UTC)
  • Tags are useful for tracking certain kinds of edits, so that you could find all of the edits that did "X" through RecentChanges. Imagine, for example, that you care about the addition of a particular piece of wikitext markup (or spam-looking links, or copyvios, or whatever interests you): you could have a bot tag edits that insert it, and manually remove the tags after you review the edits. So that's one use: finding the exact diffs in which a given action was taken, even if it's since been reverted.
    Not knowing exactly how people will want to use this is IMO the strongest argument in favor of letting (almost) anyone use it/experiment with it. That's what we did with templates: anyone could create one, and the original creators of the template system were surprised to find that what editors ultimately wanted was a programming language. Letting a lot of people use it increases the odds that we'll find (and refine) useful and efficient ways for using this tool. I think this is something that would benefit from a brainstorming or "fail quickly" model: try lots of things, and quickly reject the ones that don't work. I don't think that a top-down or centrally planned model is going to work as well. WhatamIdoing (talk) 10:25, 29 May 2015 (UTC)
• FYI, there is already half a dozen manual tags in use on fr.wiki. Cenarium (talk) 23:33, 24 May 2015 (UTC)

Rating template

Hey,

I would like if someone could do a rating template for books such as recipe with 1-5 starts for use in another wiki-media.

thanks, --79.179.121.146 (talk) 18:37, 29 May 2015 (UTC)

There is already a {{rating}} template that produces a number of stars. E.g. {{rating|4|4}} will produce four yellow stars: . Alternatively, it can display a fraction of the maximum number of stars: {{rating|3|5}} → . De728631 (talk) 18:44, 29 May 2015 (UTC)

Date and time in contribution lists

When viewing a contribution page of an editor with many edits per day, after selecting year and month, it is not uncommon to skip several pages of 50 edits each, before arriving at the desired edit. Therefore I suggest there be added boxes for selecting Day, Hour and Minute on user contribution pages and page history pages. I know that it is possible by editing the URL, but I still feel this suggestion will make things better. Iceblock (talk) 16:41, 14 May 2015 (UTC)

• Support Useful feature, no downside except the time necessary to code it. --Jayron32 01:50, 18 May 2015 (UTC)
• Support adding a 'Day' field, no question. (I can't tell you how many times I've wished for that!) I dunno about 'Hour' or 'Minute' fields (especially 'Minute') – I suspect that might make the proposal more complex for implementing than we'd want... --IJBall (talk) 01:17, 19 May 2015 (UTC)
• Comment: While I have no specific support or opposition to this, I'm pretty sure that any consensus gained on this will be a WONTFIX in Phab on the grounds that the interface is too cluttered. I'm not saying just give up on this proposal, but that's what I expect if we ask for it to be implemented that way. If there is consensus for this (or even if there isn't but there are enough people that want it), it could probably be implemented as a userscript (if it doesn't already exist, which I think it does which is why I'm posting this comment in the first place). — {{U|Technical 13}} (e • t • c) 02:06, 23 May 2015 (UTC)
  • Concur: The date and time is coded in the url so a gadget should be easy for a gadget writer. All the best: Rich Farmbrough, 11:54, 23 May 2015 (UTC).
    
• User:Jayron32, User:IJBall, User:Technical 13, User:Rich Farmbrough: If just a 'From day (and earlier)' field be added, outside a userscript, will this make the interface too cluttered? Iceblock (talk) 21:36, 23 May 2015 (UTC)
  • Well I would like it - I'm used to typing the date and time into the url, and it is very error prone. If you want to make a request at Phabricator, go ahead! All the best: Rich Farmbrough, 22:22, 23 May 2015 (UTC).
    
• Support, down to the hour at least. I'm not sure we need it to be minute-specific.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:23, 25 May 2015 (UTC)
• Maybe thisis just me, but I'm having trouble imagining a scenario where I know down to the hour and minute when someone made an edit, but still somehow can't find it. Beeblebrox (talk) 20:48, 27 May 2015 (UTC)
• This is not about being able or unable to find an edit. It's about making it a lot easier. Iceblock (talk) 20:00, 29 May 2015 (UTC)

File renaming

Wikipedia:File names currently lists eight acceptable reasons for renaming a file, and I've proposed that a ninth be added. Your input at Wikipedia talk:File names#Proposal for ninth reason would be helpful. Nyttend (talk) 22:20, 29 May 2015 (UTC)

Editor numbers and recognition

I'd like to propose that more can be done by way of editor recognition as a potential way of encouraging more editor involvement on en Wikipedia. Proposed changes are:

• changing the text at: https://tools.wmflabs.org/xtools/pcount/ to present something like "Contribution statistics" rather than "General statistics" and to gear presentation, as far as may be possible, to be CV/resume/record of achievement friendly.
• expanding or extending the "View history" tab on Wikipedia pages. On the expansion interpretation perhaps this could mean converting it into a drop down menu entitled "Contributions".
  • The first item in the menu could be entitled as something like "Contributor history" or just "Contributors" and be composed as a link to a relevant search via a tool such as : https://tools.wmflabs.org/xtools-articleinfo/ . Again, in this tool, I think that "General statistics" can be swapped to "Contribution statistics" or "Contribution summary" and perhaps the title "Top editors" might be changed to a potentially less competitive "Contributors".
  • The second item on the menu could then perhaps link to the current "View history" content but, perhaps, under a name such as "Edit history".

The issues mentioned here have been on my mind for a while but they were set into motion after seeing a comment regarding "shrinking editor numbers especially on En Wikipedia" via a link at: Wikimedia Foundation Board of Trustees Elections 2015 and after development of ideas during discussion with Doc James.

I think that any form of certification that could be developed may be positive and perhaps this could cover such topics as getting articles to higher rated standards. GregKaye 16:07, 29 May 2015 (UTC)

Yes would be interesting to take [1] and add further measures of contributions.

We have a gadget that does some of this here under "A three-month test" that can be turned on. There is still a lot of work required to get it functioning well enough to leave alpha testing though. Doc James (talk · contribs · email) 11:22, 30 May 2015 (UTC)

Moving subpages

When a page is moved, all of its subpages should be automatically moved as well. GeoffreyT2000 (talk) 01:55, 30 May 2015 (UTC)

That is an option available in the admin toolset. I would guess it being restricted has to do with the havoc moving a page with a particularly large number of subpages could cause. Some have several hundred. Monty₈₄₅ 02:55, 30 May 2015 (UTC)

Yes you have to always consider do you want to move sub pages or not, eg moving a talk page to an archive, you don't want to make and archive of an archive. Graeme Bartlett (talk) 12:07, 30 May 2015 (UTC)

RfC: Proposal to add optional multi-factor authentication to the English Wikipedia

Should optional multi-factor authentication be enabled on the English Wikipedia? PHANTOMTECH (talk) 23:30, 21 May 2015 (UTC)

Details

Multi-factor authentication allows users to require that, in order to sign in to their account, they provide a code generated by another device (their phone) in addition to their password. The extensions mw:Extension:TwoFactorAuthentication and mw:Extension:OATHAuth allow for multifactor authentication on sites that use MediaWiki, note that only one is required, there are just two that I'm aware of. This proposal will take up to 2 phases:

• Phase 1: Determine if there is consensus to implement optional multi-factor authentication. If there is not, this will be the only phase.
• Phase 2: Determine recovery options, what someone who decided to turn on multi-factor authentication would have to do to have multi-factor authentication on their account disabled without logging in, in case they lose their phone or something. Each possible option here will have its own subsection, any possible options that have consensus will become recovery options.

Phase 1

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

---

Should optional multi-factor authentication be enabled on the English Wikipedia?

Support (optional multi-factor authentication)

1. Support As proposer. Not aware of any reason to not allow optional multi-factor authentication. PHANTOMTECH (talk) 23:30, 21 May 2015 (UTC)
2. Support. I use 2FA for almost all my services (email, Dropbox, finance, heck even Wikimedia Labs) myself, so I personally support this and would use it fully, but I would also ask those who don't to still support, as there will be no disruption or difference to those who do not use MFA/2FA. --L235 (t / c / ping in reply) 02:14, 22 May 2015 (UTC)
3. Support. Absolutely. -- King of ♥ ♦ ♣ ♠ 04:36, 22 May 2015 (UTC)
4. Support. Multi-factor authentication would be a very good idea. I have seen evidence of someone trying to break into my admin account before, when I received notification emails from external sites after someone had used the "reset your password" feature with my Wikimedia email address. And a lot of damage can be done with a compromised admin account before it is locked, some of which is not easily recoverable. Multi-factor would make it much harder for password-snooping attacks etc. to be effective, and I can't see any downsides, especially if it would be optional. — Mr. Stradivarius ^{♪ talk ♪} 06:26, 22 May 2015 (UTC)
5. Support - Sounds like a very good idea to me, it should be strongly recommended for admins. I would be interested to hear from the developers of tools such as AWB and PyWikiBot as it seems to me that Bots are another type of account that would benefit from extra protection, however the tools would have to be updated to work with whatever multi-factor might be used. Jamesmcmahon0 (talk) 10:28, 22 May 2015 (UTC)
6. Support Seems completely sensible as an option. Sam Walton (talk) 11:10, 22 May 2015 (UTC)
7. Support. Most other websites I use allow this, so why not Wikipedia? APerson (talk!) 18:31, 22 May 2015 (UTC)
8. Support as optional. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 22 May 2015 (UTC)
9. Support as optional. --Wolbo (talk) 23:18, 22 May 2015 (UTC)
10. Support as an option. If people wnat to use it great, if not then they dont (still fine.. Amortias (T)(C) 10:07, 23 May 2015 (UTC)
11. Long overdue. Essential for editors with advanced permissions (that includes myself). - Mailer Diablo 05:25, 24 May 2015 (UTC)
12. Support - The additional security would be a welcome addition. I dont see any downside, per PhantomTech's arguments refuting privacy concerns, below.- MrX 15:28, 24 May 2015 (UTC)
13. Support, as long as it doesn't require personally identifiable information, per PhantomTech's explanation below.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:25, 25 May 2015 (UTC)
14. Support: unauthorized access to an autoconfirmed, admin, bureaucrat, steward, or (worst case nightmare) Jimbo Wales' account can be catastrophic. Multi-factor authentication significantly enhances security: a MITM attack or a careful examination of the 2FA system would have to be done, which automatically puts account cracking out of reach of 99% of amateur hackers, and increases the workload for the remaining 1%. Inconvenience issues can be resolved by having an alternate account for public computers. Esquivalience ^t 02:45, 26 May 2015 (UTC)
15. Conditional support: While I like the idea of additional authentication—particularly for privileged accounts—I can't support a system that would require I provide highly-identifiable personal information (like a phone number), especially when the system would require that the information be stored retrievably (compare phone numbers, which must be retrievable to be used, with passwords, which are salted). {{Nihiltres|talk|edits}} 07:24, 26 May 2015 (UTC)
16. Support but strictly optional only. Stifle (talk) 14:44, 26 May 2015 (UTC)
17. Support This would be a very good thing to have, especially for users with additional rights. Mike V • Talk 22:27, 26 May 2015 (UTC)
18. Support as an optional feature. This seems like a no-brainer. --Ahecht (TALK
    PAGE) 14:13, 27 May 2015 (UTC)
19. Conditional support I think Phase II is the tricky part. It needs to be carefully thought out, not simply opened up for votes.--agr (talk) 00:25, 28 May 2015 (UTC)

    I agree, decisions made in Phase 2 can turn a security feature into nothing more than a nuisance. PHANTOMTECH (talk) 01:20, 28 May 2015 (UTC)

20. Support Absolutely no reason to not add this as an opt-in feature. Jackmcbarn (talk) 01:32, 28 May 2015 (UTC)
21. Support this could be a very good layer of securuty. As some editors have explained above, compromised accounts can have a catastrophic effect on the operations of the site. 2600:1003:B12D:D329:9442:C04B:E459:ED40 (talk) 04:09, 29 May 2015 (UTC)
22. Some of us have access to things better left private --Guerillero | Parlez Moi 05:26, 29 May 2015 (UTC)
23. And this should be implemented at once by every functionary/arbitrator, (as should their email accounts). Courcelles (talk) 05:38, 29 May 2015 (UTC)
24. NativeForeigner ^Talk 06:12, 29 May 2015 (UTC)
25. Long overdue. T. Canens (talk) 07:00, 29 May 2015 (UTC)
26. Support as vital for functionaries and arbitrators. Doug Weller (talk) 09:45, 29 May 2015 (UTC)
27. Lankiveil ^{(speak to me)} 09:47, 29 May 2015 (UTC).
28. Support As optional and highly recommended Lor^Talk 10:00, 29 May 2015 (UTC)
29. Support as optional. Notwithstanding that I have no idea about the cost/implementation of this, I have used this sort of thing for logging into accounts in the past (although with a dongle, rather than a smartphone app). I see no issue with this sort of thing when I log in, and would welcome the additional layer of security. --kelapstick^(bainuu) 11:00, 29 May 2015 (UTC)
30. Support - I use 2FA for several services, and feel that Wikipedia is way behind on this. Particularly for those of us with advanced permissions, this is a very important extra layer of security. ​—DoRD (talk)​ 11:53, 29 May 2015 (UTC)
31. Support - there is literally no reason to oppose this proposal. — foxj 13:07, 29 May 2015 (UTC)
32. Support as optional.   ~ Tom.Reding (talk ⋅contribs ⋅dgaf)  13:12, 29 May 2015 (UTC)
33. Support per RGloucester. Ironholds (talk) 15:40, 29 May 2015 (UTC)
34. Support, would be very useful as an option for rights holders. Nakon 15:48, 29 May 2015 (UTC)
35. Support the principle, but... I think optional two-factor authentication should be enabled for login to Wikimedia CentralAuth. As I've outlined below, I don't think there's any way it could be implemented solely on one local project (like en.wp). I support the principle that we should have optional two-factor authentication, but I don't think that it can be implemented at the per-project level. The best course of action is probably a discussion on Meta-Wiki and/or mediawiki.org. If we can show the Foundation that numerous projects would be keen on having 2FA at the CentralAuth global login level, then that might give them the incentive to do the work to enable it. There are some issues with doing it (like, making sure that there are good, secure FLOSS TOTP implementations that support internationalisation (people should be able to two-factor in their own languages). —Tom Morris (talk) 16:05, 29 May 2015 (UTC)
36. Suppport. I think the main opposition arguments (unnecessary collection of personal information, and unnecessary complication for non-technologically inclined editors) are mostly negated by the 2FA being optional. I see no problems with this, if it's kept as an option (and Wikipedia doesn't go the Google route of bugging you mercilessly until you enable it). The extra layer of security would also be welcome, I think, for users with elevated permissions. –GlottalFricative (talk) 20:09, 29 May 2015 (UTC)
37. Support - all the privacy concerns are mitigated by the fact that this is optional (and I assume, opt-in). I'd imagine if this was implemented there'd be some spiel on the information you provide WMF/servers/etc when you enable the feature. Steven Zhang ^{Help resolve disputes!} 07:38, 30 May 2015 (UTC)
38. Support optional implementation, but also making usage mandatory for individuals with access to non-public data. At any tech company or finance firm, lack of strong multifactor authentication for employees with access to sensitive information would be borderline negligence. While we're volunteers here, the data protected is in many cases equally sensitive. LFaraone 06:11, 31 May 2015 (UTC)

Oppose (optional multi-factor authentication)

1. Oppose: This seems to require the collection and retention of potentially large amounts of personal information such as email addresses, phone numbers etc. This would pose severe privacy problems if the was hacked into or misused. While I'm sure that people will endeavor to keep this information secure, the best way to avoid the risk of it being divulged is to not have it in the first place.Nigel Ish (talk) 16:08, 22 May 2015 (UTC)

   While some types of multi-factor authentication require personal information, by using a Time-based One-time Password Algorithm, no personal information has to be stored or shared. The server (Wikipedia) provides the client with the information it needs to generate codes, ideally that information is shared only once and is shared securely. From that point, both the client and server keep the information and use it, combined with the current time, to check what the current code should be. So to summarize, the only information shared is from Wikipedia to the client and is not personal, after that the client requires nothing but the current time to generate a code, which is checked by the server using the information it sent and the current time. PHANTOMTECH (talk) 18:55, 22 May 2015 (UTC)

   It looks like that editors would have to either have their phone with them and charged every time they log on or have to have specific software (i.e. browser extensions) installed on the computer they use to edit Wikipedia. This would limit the ability of many people to log on - i.e. no edits from computers where the user isn't allowed to install software (such as work, libraries, schools etc.). Going through this sort of routine every day seems extreme, and OTT compared to other uses of multi factor authentication that I have seen (generally for setting accounts up, or changing passwords). Also, I do have a concern about Slippery Slope issues - while what is being suggested here is an optional proposal, there is a danger, that like use of HTTPS, it will be expanded and made mandatory.Nigel Ish (talk) 12:15, 25 May 2015 (UTC)

   It is true that editors who chose to enable the feature would be required to have their phone or computer with the software installed with them whenever they logged in to Wikipedia. This may limit some people from editing, if they enable it, specifically those who can't access a device while logging in and that is something editors would have to consider when deciding to enable it. This type of mutli-factor authentication is the standard type offered by many sites including Facebook and Google and it's one of the few with a genuine security benefit so I wouldn't consider it extreme. I don't think there's any chance of this becoming mandatory any time soon. I'm not aware of a single site, including financial sites, that requires multifactor authentication, it wouldn't make sense to require it on Wikipedia and I don't think the WMF would be willing to make it a requirement. PHANTOMTECH (talk) 15:41, 25 May 2015 (UTC)

2. Oppose – I don't know what this is, but I imagine it is just some kind of "techie" rubbish. Any complications added on top of the existing system are unacceptable. We needn't bow to those with minds rooted in the technological. The most basic and simple programme should be used to run Wikipedia. RGloucester — ☎ 11:48, 24 May 2015 (UTC)

   RGloucester, This proposes that we implement an optional feature. Those that opt in would need to send or receive a message (probably a text message) via their phones (or other device) to log in to Wikipedia. As the proposal is for this to be optional, not required, it would have no effect on any user who does not opt in, as I understand it. DES ^(talk) 16:21, 24 May 2015 (UTC)

   DES is right that users who do not opt in would be unaffected, other than seeing a setting in their preferences allowing them to opt in. The extensions I'm aware of don't use text messages, they use a secret key that is shared between the server and user during setup, the user's device then uses that key and the current time to generate a code that is valid for at least 30 seconds by default which has to be entered while logging in, along with the normal password. PHANTOMTECH (talk) 19:19, 24 May 2015 (UTC)

   Ah my error. I have worked with a non-wiki two-factor authentication protocol that did use text messages. I also worked (several years ago) with a physical key system, where the key device displayed a code that changed I think once a minute, or maybe it was 30 seconds. This sounds similar but using a smartphone or other device instead of a dedicated piece of hardware. DES ^(talk) 20:01, 24 May 2015 (UTC)

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

Discussion (optional multi-factor authentication)

This RfC provides very little context. What is the reason for requesting it i.e. what issue does it address? What are the consequences, advantages, disadvantages, if any? --Wolbo (talk) 23:55, 21 May 2015 (UTC)

@Wolbo: The reason for the request and advantage of having it is that multi-factor authentication increases security for users who use it because in addition to needing the user's password an attacker needs access to the device the target uses for authentication, their phone. I'm not aware of any disadvantages of having it as an option, though the "risk" of enabling it is that if you lose your device and don't have any backup codes, it's like losing your password except you have no chance of remembering it since it changes about every 30 seconds, the second phase of the RfC would be to create ways for users in that situation to regain access to their account without completely removing the security benefits of multi-factor authentication. If implemented properly, users who decide not to opt-in to multi-factor authentication would notice no difference, the only way they would be affected is that the possibility of multifactor authentication being enabled on their account may discourage some attackers from trying to access their account. PHANTOMTECH (talk) 00:11, 22 May 2015 (UTC)

I would add that possible disadvantages are; multifactor may not work initially with 3rd party tools such as AWB, Huggle, PyWikiBot, WP Cleaner etc. Though I expect that would be resolved reasonably quickly. Another downside would be additional coding and server processing etc. I have no idea what scale this would be on though I would guess fairly minimal as there are a number of standardized options for multi-factor already in widespread use. Jamesmcmahon0 (talk) 10:34, 22 May 2015 (UTC)

Phone? I'm in China, so that might not work. The article on the subject says other thing could be used, like a question about a favourite pet or something. Anna Frodesiak (talk) 23:59, 23 May 2015 (UTC)

Multi-factor authentication is the broad term for what the extensions allow for, questions about something like your favorite pet would not be a significant improvement when combined with a password. Specifically, the extensions I'm aware of use a Time-based One-time Password Algorithm which is supported by apps on the popular smartphone OSs, a Google Chrome extension and popular computer OSs. I've never used it besides on mobile devices since the "further" the code generation is from where the site password is being entered the better but a program on your computer should still provide a significant security benefit in most situations, specifically situations where your computer hasn't be compromised by a virus or something. There is also a web application but, though it does seem to use local storage, at that point you've lost most of the security benefits, if you do use the web app I'd recommend keeping a backup of all the keys on your hard drive just in case. Hopefully you can find a way to make use of it, if not you shouldn't be any worse off since it's optional. PHANTOMTECH (talk) 01:59, 24 May 2015 (UTC)

• As always, I note that I know next to nothing about the technical aspects of such things so maybe this is totally wrong, but this sounds like it will cost money to implement. While I can see the utility of such systems I have to wonder if the WMF is even remotely willing to pay for it. Until we have some idea of that I'm not sure there's a point to discussing this. I also think that actual incidents of admin accounts being hacked are basically an urban legend, in eight years of contributing here I cannot recall a single instance in which an admin account was actually hacked and used by an unauthorized person. Beeblebrox (talk) 14:23, 24 May 2015 (UTC)

Multi-factor authentication that relies on text messaging would likely have a cost associated with its implementation, however, this type of multi-factor authentication uses a secret key held by both the server and the user's device. Both the server and the user's device use the code and the current time to generate a code, the user gives the code while logging in and the server checks to see if the code it generated matches the given code, allowing for at least 30 seconds of error on the user's clock by default. Since information is only sent once, to share the secret key, and the information is sent through the browser, (it gives you the key in your preferences or something while you're setting it up) no money has to be spend on sending the keys. The only potential cost would be to handle the additional load of computing codes from keys whenever a user logged in and that would likely be insignificant. PHANTOMTECH (talk) 19:10, 24 May 2015 (UTC)

Forgot to address what you said about admin accounts being hacked. It might be true that no one will ever have any interest in hacking an account on Wikipedia, (what would you get for all that work? a bit of time to play around with the tools before being blocked?) and so it wouldn't make too much sense to implement a costly solution to prevent hacks, but this isn't a costly solution. If Wikipedia accounts are never targeted by hackers, this is like someone coming up to you at your house on a mountain in the desert asking if you want free flood insurance, do you need it? No, probably not. Will you take it? No, you'll assume it's a scam because who goes around offering free insurance for anything? But if you knew it weren't a scam you'd probably take it. PHANTOMTECH (talk) 19:32, 24 May 2015 (UTC)

Accounts have been hacked in the past, quite a few times. Some are by people just getting their kicks out of vandalizing, and an admin account in the hands of a malicious person, esp if that person is using scripts for automated editing, can do a LOT of damage that is not easy to repair in a short time. I'm not going to suggest specific things such a person could do, per WP:BEANS, but think about the possibilities. In any case trust me, some quite nasty things have been done in the past. i remember when a change was made requiring all admins to have strong passwords (for some definition of "strong"). The other major reason for hacking is to use a hacked account to spam. Wikipedia is very widely read, and a spammer with a valid account, particularly an admin account, can make spam links very visible in a lot of places. This can be worth money to the spammer. And ther is also the posibility of more subtle vandalism, either for fun or profit. DES ^(talk) 20:11, 24 May 2015 (UTC)

It's also worth remembering admins are only one level of permissions. AFAIK, all that can be said about admins can be said about higher level privileges like checkuser or access to supression (oversight). The WMF does have clear expectations about account security for such high level privileges and perhaps they have some additional security that isn't discussed much (like checking for logins from odd locations) but I think there are more than admin tools that some people would like to get access to, that 2FA would hopefully make more difficult. Nil Einne (talk) 23:03, 24 May 2015 (UTC)

Mind you, I should clarify I'm not saying high level privileged accounts are the main reason. Ultimately it doesn't matter whether the account doesn't even have rollback or reviewer. People may not want their account to be compromised for various reasons. Now the people most likely to have their account compromised aren't likely to use 2FA probably because they don't care, but there is going to be a subset of people who do care and who would feel more comfortable with the benefit of 2FA. I presume the OP of the thread Wikipedia:Village pump (proposals)#Additional Security for Wikipedia Editors and authors which I think is the catalyst for this is one of them. Nil Einne (talk) 23:23, 24 May 2015 (UTC)

Some examples of compromised or believed to be compromised admin accounts include Wikipedia:Administrators' noticeboard/IncidentArchive239#Another hacked admin account and site-wide vandalism and Wikipedia:Wikipedia Signpost/2007-06-18/Account compromised. These examples came from before the sysops begun to try and bruteforce priviliged accounts and appeared to involve weak passwords (not sure about VCG), and in fact it sounds like we possibly didn't even have any sort of Captcha or other limits to prevent attempts to brute force an account, however I think there were at least some after the WMF got more serious. Nil Einne (talk) 23:33, 24 May 2015 (UTC)

• Any opinion on making it mandatory for certain user groups (ie. Stewards)? EoRdE6^{(Come Talk to Me!)} 13:27, 27 May 2015 (UTC)

Stewards are not bound by any local policies here, so you would need to take that to Meta and/or the WMF itself. Good luck with that.

As for other, local groups with advanced permissions, is there really a problem that needs solving here? I've been an admin for six years, a functionary for five years, and did a year as an arb, and somehow managed not to need this. I don't object to it being opt-in for those that desire it, but I don't think it needs to be mandatory for anyone. Beeblebrox (talk) 20:52, 27 May 2015 (UTC)

Lack of problems in the past is no guarantee. Things on the computer security front are getting worse, perhaps at an accelerated pace. Putting additional security in place proactively makes sense. I wouldn't object to being required to pass an additional layer of security before using admin tools.--agr (talk) 00:39, 28 May 2015 (UTC)

• Comment. This idea needs a detailed proposal and a thorough review before anything is done with it. We must verify:

• A free-licensed hash-based message authentication code generation mechanism must be actually available for users and known to work on Wikipedia (not just hypothetically or with customization by experienced users). In other words, we do not recommend or promote Google Authenticator.
  • I don't see what's so wrong with supporting RFC 6238, for which there are many compatible freely-licensed apps including, but not just limited to, Google Authenticator. I also don't see what's wrong with including GA as an option among other RFC 6238 implementations. After all, we fully support users editing Wikipedia using closed-source browsers and operating systems, but we make sure that a freely-licensed option is available. --Ahecht (TALK
    PAGE) 20:19, 29 May 2015 (UTC)
• Any possible risks of app revocation must be avoided. We cannot wake up one morning and 10,000 users are begging for someone to wave the magic wand because Google just settled a patent dispute by somehow disabling its app. (I don't know if they can do that but I would want to)

• Any possible privacy risks involved with the generation and transmission of tokens must be evaluated. Wikipedia has made great strides in going to https to defy surveillance; there must be no backsliding.

Wnt (talk) 20:24, 28 May 2015 (UTC)

@Wnt: Here is an open source app for Android and iOS. Here is an open source one for desktop OSs, though it's more on the "experienced users" end of things. Don't think this one is open source but it is another alternative to Google Authenticator. Keys are stored on the device and apps don't need (and shouldn't use) an internet connection to generate codes, so unless an app is uninstalled by force users should still be able to use it to generate codes, even if it is discontinued. I've talked about what information is shared before, but to expand on that, here is how an ideal (and typical) implementation works:

1. User decides to enable multi-factor authentication
2. Server (Wikipedia) generates a key and gives it to the user
3. User gives the key to their multi-factor authentication application, which stores it on the device it is installed on
4. The user's application generates a code based on the key and current time, this code is independent of any information other than the key and current time
5. The user gives the server (Wikipedia) they generated code to confirm the user is able to generate valid codes
6. The server (Wikipedia) generates multiple codes, (by default) one based on the current time, one 30 seconds earlier and one 30 seconds later (in case the time on the user's device is off a bit)
7. If the code the user gave matches one of the 3, multi-factor authentication is enabled on the account
8. In future logins, the user's application uses the stored key and current time to generate codes, the server (Wikipedia) does the same thing it did to verify the first code

PHANTOMTECH (talk) 21:21, 28 May 2015 (UTC)

• Agreeable provided that the second factor is in no way dependent on hardware. Messages to mobile phones are (1) expensive and (2) unreliably available. (I wound up disabling a two-factor authentication system because it was phone-based and resulted in a $40 additional bill in just one month of generation. Remember that we have a huge number of participants for whom cost would be a genuinely limiting factor.) Physical tokens (e.g., USB-based tokens) are limited to being usable only on equipment that is compatible, which is increasingly problematic as more and more people use platforms other than traditional desktop/laptop computers; the technology also is probably illegal to provide to people in certain countries. So...the objective is to identify a cost-free process that is not dependent on any form of technology and is available around the clock and around the world without costing the users. Keep in mind that high cost or difficult access is more likely to result in users keeping themselves logged-in pretty much constantly and continuously, which is a far, far greater security risk than what is being discussed here. The topic of two-factor authentication has been batted around within the WMF security and developer group for several years now, and it strikes me that any proposal that commits the WMF to doing anything needs to get buy-in from that group even before dreaming up ways of implementing it. Risker (talk) 13:00, 29 May 2015 (UTC)

I brought up the fact that this sounds like it would cost the foundation money up and we should find out if they are even willing to do this above, five days ago, and the answer I got was basically "probably, but we should do this".. Apparently we're going to decide we are doing this, and then afterword try to figure out if we actually can. Seems a bit backwards to me, but so does a lot of stuff that goes on around here. Beeblebrox (talk) 15:46, 29 May 2015 (UTC)

Eh, it's all up to the developers anyway. When we have an RfC that requires technical intervention, we're not really deciding anything, we're having a community discussion where the end result is "hey, nice people at WMF, can you do this please? Pretty please?" It's worth doing in as much as it gives our collective consent to the Foundation implementing it if and when they decide to do so. But there's no real way to make them do it if they don't want to. —Tom Morris (talk) 16:08, 29 May 2015 (UTC)

Tom Morris, I think you'll find that it's a bit more complicated than that, but anyone who wants to become one of the volunteer devs (which outnumber the WMF's staff devs by a significant margin) should see mw:How to become a MediaWiki hacker. WhatamIdoing (talk) 03:10, 30 May 2015 (UTC)

@Beeblebrox: Sorry if my reply to your earlier message wasn't clear, certain types of multi-factor authentication would come with a (probably significant) cost but the extensions I've linked use a type that does not require anything like text messages and so would not cost WMF money to implement. PHANTOMTECH (talk) 16:42, 29 May 2015 (UTC)

Technical issue: how would this work with CentralAuth?

CentralAuth exists, and global accounts have now been set up and normalised. When you login to Wikipedia, you login to the CentralAuth server and thus can visit any other Wikimedia site (the sister projects like Commons and Wikinews and Wiktionary etc., Meta-Wiki, MediaWiki.org and a bunch of others) and be logged in.

This proposal seems to be about consenting for it to be enabled on English Wikipedia. I broadly support the idea but how would this fit with CentralAuth? This is really a question that needs developers familiar with CentralAuth to answer.

When you type your username and password into Wikipedia, you aren't logging into English Wikipedia anymore, you are logging into Wikimedia's CentralAuth (login.wikimedia.org), which then logs you into a global account across the various different wikis. When you visit a new wiki for the first time, a local account is set up to match your global account username.

It seems likely to me that if the Foundation were to implement 2FA, it'd be on a global scale rather than on a per-wiki basis. Why? Because...

1. User visits wiki.riteme.site and types in their username and password. They are then asked to type in their two-factor authentication token. They don't have their 2FA device on them so decline. As Wikimedia Commons does not have 2FA turned on, the user goes to Wikimedia Commons and can start editing but they can't edit on English Wikipedia.
2. On Wikimedia Commons, the user (who is an admin or file renamer locally on Commons) renames a file. When you do this, the edits propagate back to English Wikipedia... except they don't, because they are logged into Commons but not English Wikipedia.
3. The user then visits Wikidata. For the sake of argument, Wikidata has not enabled 2FA. As with Commons, the user is allowed to edit. The user makes some edits on Wikidata which then propagate out to other Wikimedia sites, except they aren't because some of those require 2FA.

I just don't see any way that 2FA could sensibly be implemented on a per-project basis. It's all or nothing: optional two factor authentication for CentralAuth or not. It seems like deciding on local consensus on what is highly likely to be a global change is a bit of a waste of breath... —Tom Morris (talk) 15:57, 29 May 2015 (UTC)

CentralAuth is certainly a problem, and one I didn't think of when creating the original proposal. The only way to implement per-project 2FA would be to split authentication, which would be a bit odd. English Wikipedia consensus can't affect all Wikimedia wikis but if consensus here is any indication of what it would be across the other project, I don't think there would be much opposition to project-wide 2FA. Based on this issue, and some other people having concerns about the willingness of WMF to implement 2FA, I think I'd be a good idea to get a dev to comment. (Though I'm not sure how to go about that) PHANTOMTECH (talk) 16:42, 29 May 2015 (UTC)

So this discussion was mentioned on IRC, and as the main person working on this on the developer-side, I figured I'd give some background on what I'm doing. Right now there are two extensions, mw:Extension:OATHAuth and mw:Extension:TwoFactorAuthentication. The reason two exist is an accident on my part, and right now I am in the process of merging the two extensions together. Once it is done, there will just be one extension. The technical problems that need to be fixed are:

• Allowing for storing credentials in a central database, so it works with CentralAuth. As said already, it is basically impossible to do this on a per-project basis, so it would be all or nothing. However, as a means of a test run, we were thinking of only allowing certain user groups to use it, just as a test trial, before opening it to everybody.
• The extension in its current form adds a "Token" checkbox below the login form, which is terrible because it confuses anybody who doesn't know what 2FA is and doesn't use it. I have a series of patches in mw:Gerrit right now that are fixing that. It'll be a little while before they are merged, but once they are this should be fixed.
• We are also worried about recovery. If somebody loses their two-factor device (which is usually their phone, but can be something else), then they are basically locked out of their account. We can't allow email recovery, because then it defeats the point, so MetaWiki would have to have some sort of steward-based process. Hence why we want to have a test trial.

That's about it. Once my series of patches for the extension are merged, this can maybe start moving forward on testwiki or some other private wikis that are not in CentralAuth. — Parent5446 ☯ ^{(msg email)} 17:31, 29 May 2015 (UTC)

Parent5446: the second point you bring up - adding a 'token' checkbox - is definitely a poor UX. Sites I've used that have 2FA tend to do it after you've submitted your username and password. I think if there eventually becomes (global!) consensus to enable this on Wikimedia sites, that would have to be the UX that would work. Affecting the login UI for non-opt-in users are not acceptable. —Tom Morris (talk) 21:37, 29 May 2015 (UTC)

Continuation of RfC

As has been brought up, CentralAuth prevents any per-wiki implementation of multi-factor authentication. This makes the second phase of this RfC useless as a proposal but potentially beneficial for generating ideas. Since 2FA doesn't seem to be coming too soon, I don't think there is much need to discuss recovery options at this time so I don't think I'll be starting phase 2. If someone else feels there is a need for recovery options to be discussed right now, feel free to start it, but keep in mind that since this is a WMF wide change the discussion would just be for generating ideas. PHANTOMTECH (talk) 17:54, 29 May 2015 (UTC)

As I said above, it might be an idea to set up an RfC on Meta. And by an RfC, I don't just mean a "should we do this?" but one where all the various technical and policy issues are presented and hashed out (global vs. local logins, recovery options, SMS fallback, the availability of TOTP clients for different platforms and their support for Wikimedia's many different language communities, whether the Wikipedia mobile apps should contain TOTP functionality) rather than a simple up/down vote. Once we've got a handle on the issues, then it makes sense to then have a global vote. —Tom Morris (talk) 07:29, 30 May 2015 (UTC)

@Tom Morris: I've never started or participated in a discussion on meta so I'm probably not the best person to start it. If you or anyone else would like to, please post a link here and I'll join in. PHANTOMTECH (talk) 18:09, 30 May 2015 (UTC)

Counter

Wikipedia Counter
PLEASE permanently ADD A COUNTER TO EACH WIKIPEDIA PAGE now.
Why?
So that the most VIEWED/VISITED PAGES on WIKIPEDIA can be identified and are UPDATED first before less popular pages are.
No point in RUSHING to UPDATE information on a page on WIKIPEDIA that nobody views. Update the most viewed pages first.

Can't help pass onto something that will help.

Thanks

Stuart — Preceding unsigned comment added by 81.131.208.20 (talk) 03:29, 31 May 2015 (UTC)

Page counts are published by the Wikimedia Foundation, and searchable on stats.grok.se. LFaraone 06:03, 31 May 2015 (UTC)

You can also click the "Page view statistics" link on any article's page history, which you can access by clicking "View history" at the top of the article page. ―Mandruss ☎ 06:27, 31 May 2015 (UTC)

Wikipedia is an ongoing project, we are not rushing to get pages complete for a deadline. Also, Wikipedia is maintained by independent editors working within their specific interests. Although there are features to highlight areas that need work, it is not possible to enforce which articles are to be updated first. Periglio (talk) 11:42, 31 May 2015 (UTC)

Is this Male chauvinism ?

Few months ago i saw a banner from Wikipedia which was something like this: "Why there so few female editors in Wikipedia, give your valuable suggestions and ideas to encourage the participation of more female editors."

Now when I wanted to keep the pages Heroine, Actress, Empress under my watchlist; I found that they exist as redirect to their male version. Now why can't we have an independent page of them, instead of redirect?

Please don't tell me, "You have come to the wrong place, you can discuss at the talk page of those articles." This is a subjective topic. One has to do lots of research and find sources to define those pages. I can't do it.I am a science student. Someone else must do it.--C E (talk) 13:05, 23 May 2015 (UTC)

Having articles at the female version of those terms would only make sense if there was a significant amount of content related specifically to women that could be placed there. The articles on those terms seem to have very little such material. Nor is having the article at that title necessarily sexist: the article on hero says that the term can be gender neutral and the article on actor notes that the term is increasingly being used to describe women as well as men. I don't think Wikipedia would be any more feminist by maintaining segregated content about women in areas where the material is almost entirely gender-neutral. Hut 8.5 13:47, 23 May 2015 (UTC)

I have seen articles with smaller notability with minimum content. Should Mother be a redirect for Father.C E (talk) 17:56, 23 May 2015 (UTC)

So... you would like Wikipedia to have seperate pages for the female terms for the same subjects, but you refuse to do any actual work to make that happen and demand that someone else do it? Good luck with that. Beeblebrox (talk) 18:35, 23 May 2015 (UTC)

Take a look at the Mother article. It goes into detail about biological, social, religious and cultural aspects of motherhood, none of which is applicable to fatherhood. If you can write that much about actresses that doesn't apply to actors as well then we can certainly have an article at actress. However to judge from the current state of the actor article being an actress is almost exactly the same as being an actor. (In any case this isn't a very fair comparison because "actor" can be gender-neutral and "father" can't.) Hut 8.5 20:39, 23 May 2015 (UTC)

I am not discussing it for animals:: Bitch , Tigress, if you are referring to them.C E (talk) 18:52, 23 May 2015 (UTC)

There are arguments both for and against separate treatment. Wikipedia traditionally avoided such, for example deleting the category for female American senators several times back in 2006-8, after which it stayed. More recently the creation of a category "Female American novelists" caused a (minor) media storm as it was claimed that it was denying that female novelists were "proper" novelists. The category, however, remained, and is now (as was inevitable) accompanied by "Male American novelists". For more detail on recent history of the debate see WT:GGTF and its archives. Please also join the ongoing debates there. All the best: Rich Farmbrough, 22:41, 23 May 2015 (UTC).

This quote from The Handbook of Non-Sexist Writing by Casey Miller and Kate Swift may also be of interest:

Of all the techniques for avoiding linguistic sexism, none is simpler than using the same agent-nouns for both sexes."

--Boson (talk) 22:55, 23 May 2015 (UTC)

Yep, and if you read the actor article it makes it clear that in recent times that term is increasingly considered gender-neutral, and "actress" is mainly just a category at awards shows now. I think the same probably applies to hero/heroine. Empress is the only one I would consider to be really debatable out of three mentioned in the initial post. Since we don't have emporers and empresses anymore there isn't really any chance of a linguistic shift to more neutral usage. Beeblebrox (talk) 00:58, 24 May 2015 (UTC)

Well, for actors and actresses in particular, these are not really interchangeable things, really; if you hire Jessica Lange for a part and she falls ill you can't really replace her with Keanu Reeves or whatever, without making significant script changes. This isn't true for all films and plays but is for most, and this constriction of roles greatly colors the careers of actors and actresses. The practical difference between an actor an actress is certainly more than between a shortstop and a third baseman (a shorstop can fill in at third base better than an actress can fill in for an actor), and we have separate articles for those.

But if you're going to have one article for both, it's rather silly to assume that its going to fall under the male rubric without even thinking about it. Which y'all have and you know that you have. What I would suggest is that the article Actor be moved to Actress and the opening sentence changed to "An actress (actor for a male; see terminology)..." and other changes to body text as appropriate.

The objection that "Well other people don't do that" is meaningless of course (I mean, so what?), and any appeal to preponderance of reliable sources completely misunderstands what reliable sources are for: for establishing statements of fact, not for tying us to the dead corpse of the past centuries. Reliable sources have little or nothing to do with what our article titles are. And the objection "The male role should have pride of place as nature intended" I do not not find particularly edifying.

It's hardly worth talking about because, for various reasons, we're not going to do this.

But we should. Herostratus (talk) 01:29, 24 May 2015 (UTC)

Your first paragraph is a complete red herring. The term "actor" can apply to all sexes. Jessica Lange is an actor, Jessica Lange is an actress. You cannot say Keanu Reeves is an actress. --NeilN ^{talk to me} 15:19, 25 May 2015 (UTC)

I can and I will: Keanu Reeves is an actress. There's not a shred of a reason, beyond mere habit, or the unthinking assumption that "male" is the default status for a human being, or the mindless parroting of people who are of that mind, not to embrace that nomenclature. Join the 21st century. Not worth arguing over as I don't expect to make much headway on this point, notwithstanding being correct. Herostratus (talk) 18:17, 26 May 2015 (UTC)

Sure, one can call Keanu Reeves, actress -- indeed, if he was really superb at his art everyone could and would suspend disbelief and go along with him in the role. Regardless, on the original issue Hut makes the most sense. Alanscottwalker (talk) 18:59, 26 May 2015 (UTC)

Yes indeed! Meanwhile, back at the question, as anyone who follows entertainment news has become aware over the last decade or so, most thespians of the female persuasion now refer to themselves as actors, not actresses. On the one hand, this is informed by the egalitarian impulse that has pushed aside "stewardess" for "flight attendant" and, less successfully, "waitress" for the ungainly "waitperson" or ambience-free "server." Methods of interpreting dramatic roles may vary from school to school, performer to performer, but there is no gender-defined difference in process. An actor is an actor. On the other hand, if there is no difference in craft between men and women, why are there separate Oscar and Emmy award categories for males and females? I don't see that custom changing anytime soon, just as I don't see any imminent change in WP customs in this regard. DoctorJoeE ^{review transgressions}/_{talk to me!} 19:38, 26 May 2015 (UTC)

There are separate categories in the Oscars because some organizations are behind the egalitarian curve, and because the Oscars show would be cut in half, and because actors don't want to see the available awards halved, and .... The fact that some organizations do gender-divided things doesn't mean WP has to follow suit. We already do far too often.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:48, 28 May 2015 (UTC)

• If you ask me, having separate articles at heroine, actress and empress would be male chauvinism. It would suggest that the females are different, and imply inferior, to their male counterparts. And in the case of heroine, that is actually true, as in traditional literature, the heroine is rescued by the hero, rather than being a real hero in her own right. Oiyarbepsy (talk) 13:28, 28 May 2015 (UTC)

There is a discussion here, about merging an female-specific category. One of its arguments is that such gender-seperation is 'marginalising'. … … ps it occurs to me that most professions DON'T have gender-specific names (driver, lecturer, doctor, politician, teacher, singer, artist etc.), therefore it would be inherently arbitrary to have articles for the (relatively few) that do. This is of course in addition to the 'gender being irrelevant to achievement' argument.Pincrete (talk) 23:35, 31 May 2015 (UTC)

There is quite a lot of false logic on this page, 'er'/'or' are two of the common suffixes for 'person who does this', an inventor is someone who invents. The created word only becomes gender-specific when a 'female' form of the word also exists (temptor/temptress). If there is a distinct need for a gender-specific article (I cannot think of examples, but they may exist), we should have one, but otherwise there is no point in having a general rule to have them.Pincrete (talk) 10:22, 1 June 2015 (UTC)

Linking to disambiguation pages

There should be a tool that automatically replaces Foo with Foo. GeoffreyT2000 (talk) 01:25, 22 May 2015 (UTC)

Moved from Wikipedia talk:Village pump § Linking to disambiguation pages.

 – Redrose64 (talk) 06:57, 22 May 2015 (UTC)

Links to disambiguation pages without " (disambiguation)" should be automatically fixed by a bot to link to the redirect with " (disambiguation)". 2602:306:B8E0:82C0:5151:4DE4:D781:AD4C (talk) 22:32, 21 May 2015 (UTC)

Why? PrimeHunter (talk) 02:02, 22 May 2015 (UTC)

AWB could do this, but we still want a human to check it is doing sensible things. Graeme Bartlett (talk) 05:46, 23 May 2015 (UTC)

No there shouldn't. If it was desirable (in that instance) then Foo should be a redirect to Foo (disambiguation). If anything (and there would be much weeping and wailing and gnashing of teeth, for good reasons as well as bad ones, should anyone try it) Foo should be replaced with [[Foobar|Foo]]. All the best: Rich Farmbrough, 11:59, 23 May 2015 (UTC).

No; let's say that somebody links to North Eastern Railway, which is a dab page. How is a bot to know that the dab page was linked on purpose? The user may have meant to link to the page about the railway in the United Kingdom, and hadn't realised that others exist. The link should indeed be fixed, but it needs to be examined by a human because a bot cannot tell whether a link to a dab page is accidental or intentional. Only the intentional ones (see WP:INTDAB) should be altered to e.g. North Eastern Railway (disambiguation), the accidental ones should be fixed to an appropriate link such as North Eastern Railway. --Redrose64 (talk) 06:57, 22 May 2015 (UTC)

There is (already) a bot which corrects the intentional ones (as in uses of {{for}} for example). --Izno (talk) 14:11, 22 May 2015 (UTC)

The bot can correct the intentional links in a small set of circumstances. There are many more where human correction is needed, but no one has gotten around to checking the link yet. bd2412 T 20:57, 23 May 2015 (UTC)

How many? (I tried attacking this problem manually some years ago, and some of them are very hard and need research. Not "London, England" vs "London, Ontario" at all...) All the best: Rich Farmbrough, 22:27, 23 May 2015 (UTC).

No we don't need this, and it wouldn't be workable. AWB, with human oversight, can do this when we need it done. There are (not frequent) times when we want to intentionally link to disambiguation pages (and you can prevent people undoing them by using code like this: [[Foo|Foo<--Yes, this is an intentional link to a disambiguation page.-->]] One serious problem with automating replacement as GeoffreyT2000 and the anon suggest is that part of the very process of establishing a disambiguation page is going through uses of that character string as a link in articles before the decision was to make the link target for that string be a disambiguation page, and figure out which of the actual subjects to be disambiguated each instance actually refers to.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:31, 25 May 2015 (UTC)

The reason we use [[Foo (disambiguation)|Foo]] links rather than a notice on the page is to prevent editors from having to waste time looking at tens of thousands of pages containing intentional disambiguation links, in order to ferret out the links that do need fixing. bd2412 T 15:02, 25 May 2015 (UTC)

There aren't tens of thousands of intentional links to DAB pages (other than in hatnotes). In article text, it's a rarity.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:52, 28 May 2015 (UTC)

I can assure you that there are because I have seen them myself - most often in the "See also" sections of other disambiguation pages. They do pop up in unusual places, however. There is no telling when an article on a particular person or battle or city will note in the text that there are others by that name (or named after it) with a link to the disambiguation page. bd2412 T 04:03, 28 May 2015 (UTC)

Most see-also cases are not intentional links to DAB pages, it's just sloppy editing. I agree that a "lots of things are named after it" kind of link qualifies. These links aren't terribly common, and don't seem to be a problem.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:05, 2 June 2015 (UTC)

Query strings in URLs and other languages

Words in query strings in URLs under other language versions of Wikipedia should also be written in that language, rather than English. For example, on the Spanish Wikipedia, instead of displaying "title=", it should display "título=". GeoffreyT2000 (talk) 18:18, 25 May 2015 (UTC)

You could file that suggestion in phab: if you wanted, but I'm not sure that it's a good idea. For most languages, some users will get an encoded, unreadable string of ASCII characters instead of their own language. (What you see in your web browser will depend upon your computer.) For all its flaws, "title" may be better than "t%C3%ADtulo" (the encoded version of título). Whatamidoing (WMF) (talk) 08:44, 27 May 2015 (UTC)

Perhaps generalised labels such as t= (title), d= (diff) or v= (version), o= (oldid), a=e (action=edit), s=3 (section=3), etc., so their language-specific nature were less obvious? —sroc 💬 11:52, 2 June 2015 (UTC)

RfC: Allow "Edit in Wikidata" links for templates using data from Wikidata

Please comment on the RfC/discussion at Wikipedia talk:Wikidata#Edit_in_Wikidata_links. Thank you - Evad37 [talk] 01:32, 3 June 2015 (UTC)

A way to prevent revertwars from erupting

I propose a way to eliminate the current separation between the discussion and revision history pages, as it is a major cause of edit wars. For example, if one's contribution is undone (itself a much-abused tool), what is often the first instinct? To revert it! And leave a message in edit summary explaining why the undoer is wrong. They will in turn likely do the same... leaving an edit summary message saying why you are wrong. This only leads to reversion wars, because the only way to reply, to leave a message on that page, is to make an edit... The talk page? Indeed, leave the edit conflict, go there and navigate the wall of text, edit the page (which is more cumbersome than a message box system), then try to attract the other's attention... and who is going to start the discussion? The one whose version is current doesn't care anymore, the other one only cares about making their version current! If only messages could be posted inline on the revision history page, the whole process would become so much less reversome and smoother. The messages would be posted through a message box, and be posted on the page as expandible stubs, shown in chronological order between the revision versions. There would be clickable tags inside the messages that would scroll to the message being replied to, and tags to scroll to any replies. If there are more than eg five or ten messages between two revisions, the list could be collapsed. Messages posted privately from one of the users to another would show up as stubs that are only expandible by the sender and receiver. And a captcha in the messagebox would prevent spam and overuse.

The current system makes it pathologically ready to invalidate another user's contribution by deleting it entirely (which is distinctly inflammatory), and far too cumbersome to discuss changes instead. And this creates disproportionate damage when the edit in question is large, as it's more likely to be reverted. So even though most edits aren't reverted, reversion is a big problem.

Regarding undo: 'undo' is far too often a way of saying 'I sort of disagree, and can't be bothered to show subtlety'. Instead of 'undo', the button should be 'see changes' (with an edit box below a comparison of this version and the one preceeding it, and the ability to select and copy text from the two sides separately). This would encourage people to treat others' contributions with greater respect. — Preceding unsigned comment added by 85.211.109.208 (talk) 03:55, 7 May 2015 (UTC)

How often have I thought this: what a clumsy system - if you want to know for sure whether an editor has provided any justification for, e.g. a content removal, you have to check both the edit history and the talk page. In practice, article talk pages seem to be going out of fashion, with whole elaborate discussions taking place through a sequence of edit summaries. IP is also right that we have a structure that makes for conflict, not collaboration, owing to the fact that reverting is very much less trouble than judicious editing and discussion. If a system along the lines described turned out to be technically feasible it would be well worth pursuing. We do, though, need to keep the "undo" button, for straight reversion of straight vandalism: Noyster (talk), 11:15, 7 May 2015 (UTC)

WP:BRD. --Atlasowa (talk) 12:19, 7 May 2015 (UTC)

Posting nothing but a WP link, without anything in your own words, is unconstructive or even borderline linkspam. BRD?? there's a joke. Thag whole page is nothing but a wall of politically correct refusal to admit straight up that a monster has been created (and no offence to monsters), that noone seems willing to do something about 'undo' abuse, when it's so pathologically easy to wipe a contribution out in two clicks rather than bother editing with consideration, or devote entire days to discussion on a separate page...

I do think Noyster is right about the need to have a way to easily undo vandalism. I do think, however, that a Report Vandalism button could work better, by invoking a third party (an admin), to resolve arguments over whether deletion of a content the editor dislikes is vandalism or not. 85.211.108.179 (talk) 08:38, 9 May 2015 (UTC)

IP editor, the problem is that you (and other editors at that article) are engaging in WP:REVTALK. Don't Do That, chuckle. REVTALK actually encourages reverting because the only way to communicate is by preforming more reverts. Your proposal would actually make the problem worse.

A simple revert with edit summary is appropriate - the first time. Do not simply make an edit that you know is contentious and is likely to be reverted. Generally, you know someone already objects to your edit the moment you would be reverting a revert. I have a trick that actually works in your favor. If you would be reverting a revert, first explain your case on the Talk page then and make the revert with an edit summary pointing to the Talk page explanation. That breaks the REVTALK cycle and sends the other person to Talk. By being the person to break the cycle you (usually) get the advantage of keeping your version live on the article page during Talk discussions. If the other person reverts instead of Talking then they are blatantly at fault for editwarring.

P.S. You have the right to IP Edit, but it's easier to work here and you'll get more respect if you make a named account. Alsee (talk) 11:04, 10 May 2015 (UTC)

I've got a better solution: No more anonymous edits. Everyone who wants to edit Wikipedia should open up his/her/their own accounts. Statistics had told us that 80% of vandalism on Wikipedia are done by those hding behind IP addresses. If people truly want to contribute to Wikipedia, identifying themselves by opening up accounts really isn't that much to ask for. Cedric tsan cantonais 17:20, 11 May 2015 (UTC)

Preventing revert spats from occuring, is like preventing editors from having emotions. Nobody likes to see their additions or deletions reverted & quite often our reaction tends to be revert back. At that very moment, tempers flair. The only way you're gonna cut down this occurances, would be a Wikipedia-wide 1RR rule. GoodDay (talk) 17:40, 11 May 2015 (UTC)

'The only way to communicate is by preforming more reverts' is exactly what the proposal is addressing; to have comments posted in between page versions on the revision history page, instead of the (no) talk page where only tumbleweed proliferates. The very existence of the REVTALK article is like an admission that people find the talk pages way too separated from the centre of activity, and REVTALK for the convenience of having the conversations where the edits are.
Indeed noone likes 'being reverted' (or so it feels), and yes tempers flare... but often they flare even before that time, as soon as the dark red messages notification square appears in the top middle of the screen, clashing with the rest of the color scheme. The 'message' is often the automatic undo notification, meaning you are supposed to go and BRD the other... well-intentioned editor. This is why I don't browse logged in anymore - I want to read my beloved Wikipedia in peace, without looking over my shoulder all the time, for someone potentially reverting an edit I made months or (on quieter pages) years ago.

The problem is that the 'undo' gives people the wrong kind of power. By its design a powerful anti-vandalism tool, using it essentially says 'this edit is vandalous/superfluous'. All in just two clicks. If people instead edited actual text, they would put some care into it, and be less casual about erasing it. If i stead there was a button to open the altered section of the article for editing, and to show the difference that that revision had made, that would decrease the incidence of complete reversion. An infopopup should appear, telling that the other editor would be notified - this should be a prominent element, and give people a moment's pause.
-And by showing the differences, any vandalism would be obvious and easy to reverse, too. (the preceeding version of the page should be available in a box below in case of restoring deleted material)
85.211.108.179 (talk) 18:58, 12 May 2015 (UTC)

Would encouraging editors to perform dummy edits (edits that don't change the article in any visible way) with either a response or a "see talk page" instead of a response also address this problem? Darkfrog24 (talk) 04:43, 17 May 2015 (UTC)

Please don't do that. Histories are sufficiently hard to follow without a bunch of pointless dummy edits cluttering them further. The advice above is correct: the first revert should use a decent edit summary, and any second revert should be only after posting on talk, in which case the edit summary would include "see talk". Johnuniq (talk) 12:09, 17 May 2015 (UTC)

Darkfrog24: - I too thought about the leaving summaries via dummy edits, but people might be too tempted to edit once they have the edit window open. A more elegant way of posting short/collapsible comments on history would work better.

Johnuniq: - this advice would be an improvement compared to the current BRD, as it would not require people to plead, and then wait to receive the reverter's consent before putting back the material. The design of BRD is a prominent example of misunderstanding of humans, and misplaced expectations. It was supposed to 'highlight opposing views'... and it does this alright. BRD as it is might as well be 'Bold Rage Delete'. As a policy BRD altogether goes out the window in revert conflict. But at the start, it is what helps trigger it. BRD 'emboldens' potential 'reverters' (especially with the 'undo' link as prominent as it is). It implies that the immediate way to deal with (potentially any) edit is to obliterate (revert) it, rather than try to adapt it to the article content. The policy (once one reads it) does of course encourage people to work with the new edit. But that is not the popular perception borne from the phrase 'bold revert discuss'. People see BRD as excusing hair-trigger reverts. Most people do not actually see their edits as 'bold', and being reverted triggers a feeling of unfsirness, and a reaction to put it back. And maybe add the reason in an edit summary (not the talk page). And you'll find it hard to convince them of the fine difference. But there wouldn't be a whole WP waggling its finger at people for talking via edit summaries, if only there was a way to post 'summaries' without the 'edit' part. It would make it a nonissue, as people would post a reply on the history page and then edit. The entire edit cycle would go a lot smoother with this.

-- The preceding comment was unsigned.

I'll respond to this whole thread at once rather than interleave any more small replies:

1. WP:BRD process works fine usually, and when it is ignored (it's not a policy, remember), there's WP:3RR, so revertwarring cannot continue indefinitely.
2. We don't need a new way or place to leave messages. Edit summaries are for summarizing edits and providing concise rationales for them, not for carrying on conversations. Talk pages exist for that purpose.
3. Dummy edits to abuse the edit history system as an instant messaging system are a bad idea. Use a dummy edit to correct an erroneous previous edit summary of your own, not to try to carry on a conversation. Use the talk page for that.
4. If you get reverted, without there being a clear rationale for the revert, opening a talk page discussion justifying your change, then undoing the revert, with a pointer to that discussion in your edit summary, puts the pressure back on the other party to engage in the D part of BRD process instead of continuing to revert. But they may do it again anyway, on the grounds that your change was bold (B), has now been reverted (R), and so it should be discussed (D) and consensus reached. Such an observation is usually correct.
5. If the original revert had a clear rationale to begin with, in talk or in edit summary, the the ball is in the bold editor's court to convince others that the desired change should be made. (Note that this necessarily means you should check the talk page for relevant discussion before undoing a revert, and doing so has at least a little bit of a cooling-down effect on the knee-jerk reaction to want to undo a revert.)
6. If a revert or pattern of reverts is a one-editor WP:FILIBUSTERing attempt against a change no one else has a problem with, this should become apparent quickly in discussion, as will lack of any actual revert rationale, or one that doesn't make sense. If a filibusterer is going out of their way to cloud discussion to evade a finding of consensus against their view, open a formal WP:RFC about the proposed change. While that process is slower than some of us would like, it's more difficult to "game".
7. A third way of resolving such a dispute is often to pay attention to what a reverter is specifically objecting to and address it, while otherwise proceeding as usual, working around the objection. Far too often, someone objects to one change among three or ten or 40, and mass-reverts everything another editor has done at a page (or even everything all editors have done at the page), since the reverter's preferred version. While this is usually rude, sloppy, and disrespectful, more editwarring can often be forestalled by re-inserting the edits that were not specifically objected to, and taking the one contentious point to the talk page (and perhaps asking the other party not to do blanket reverts, since these tend to imply bad faith and discourage the participation of editors, whom we need more of not fewer).
8. That said, there are times when resetting a page back to a stable version is actually the best course of action, especially when one editor or camp of editors is insisting on one version of a change, and another is demanding an alternative change, but questions have been raised about whether any such change is needed at all. Not all reverts, even mass reverts, are a bad thing. This is especially true when the talk page already has active discussion(s) of the proposed changes and the various rationales for them.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:07, 25 May 2015 (UTC)
   

“WP:BRD process works fine usually” - are you even joking? There is absolutely no grounds for such a statement whatsoever. Why was 3RR was strengthened with a 'bright line rule 'etc, if it's all fine and and dandy?

Merely saying 'the talk page is preordained as the place for discussion by the Admin Gods' doesn't mean people actually use it. The gulf between 'history' and 'talk' remains unaddressed, and is such that many reverts often pass before anyone goes to talk. Going to the talk page feels like giving up, like being dragged down into a discussion that's out of sight, away from relevance and will stumble on forever.

And the part about WP:FILIBUSTER doesn't address kneejerk filibustering that comes from some editors' instinctive OWN, plus xenophobia.

So far these are just an intellectual rehashing of the status quo, while refusing to admit that there is any kind of problem at all. It's all 'go to page x' or 'open a thread on page y', except that when the solution is not intuitively, readily at hand, it's approaching uselessness in a majority of cases. To wit: the fact that people revtalk much rather than go to the talk page. It's unintuitive, clumsy, nauseatingly long. A place for endless geekish arguments may in fact strangely appeal to some wikipedians, but refusing to acknowledge that the talk page is regarded with instinctive distaste by a great many editor is a misjudgement of human psychology.85.211.108.65 (talk) 23:09, 26 May 2015 (UTC)

Consensus is Wikipedia's primary mode of decision making. That's not my opinion, that's a very well established and widely supported site policy. There's no way to form a consensus without discussion. The only way to prevent revert wars is to block people who engage in them and/or protect the page from editing. If you can't get down with that you aren't going to have a very good time editing Wikipedia. Beeblebrox (talk) 23:31, 26 May 2015 (UTC)

It might be possible to form a consensus without technically "discussing", in the simplest cases. (I'd bet that you and I could do it.) WhatamIdoing (talk) 08:24, 27 May 2015 (UTC)

The vast majority of consensus is formed without discussion, simply by edits being accepted silently.  — SMcCandlish ☺ ☏ ¢≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:21, 28 May 2015 (UTC)

True, but I assumed that Beeblebrox was thinking of a situation in which there was an actual dispute, rather than the most common case of silent-consensus editing. WhatamIdoing (talk) 09:43, 29 May 2015 (UTC)

(edit conflict) @85.211.108.65: I'm not sure what the point of all that hyperbole is. Moving past it, your response doesn't make sense to me. I made a statement that WP:BRD works (present tense), but you've replied with complaints about changes that were made a long time ago to WP:3RR, which isn't closely related. BRD is an optional, but generally expected practice, that relates strongly to WP:Consensus processes; 3RR is part of WP:Edit warring policy, which is about restraining disruptive behavior. The fact that reverts have something to do with both doesn't mean they should be confused with each other. I agree kneejerk filibustering by would-be page WP:OWNers is a real problem, but it wasn't the one I was addressing at the time, and is resolved the same way, anyhow. Admins don't tell us to use the talk page; Consensus policy does. Psychological incompatibility with using the talk page is a WP:COMPETENCE matter; not every human on the planet is temperamentally suited to editing WP collaboratively, and that's just too bad. If they won't engage in basic processes here, like having conversations, instead of abusing edit summaries to snipe dismissive barbs at each other, their participation tends to become increasingly disruptive and unsatisfactory, both for the encyclopedia and its editing community, and for themselves. I agree that the talk page system is clumsy, but it's what we have. I've seen the draft version of what they're developing to replace it, and feel that it's even worse in innumerable ways, but I"m sure I'll get used to it after they roll it out. Anyway, if you're going to play football, you learn the rules and play with the right equipment, you don't show up with a bowling ball and a fishing rod, and try to get everyone on the field to play some new game you want to invent using what you brought.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:20, 28 May 2015 (UTC)

Instead of 'psychological incompatibility' with the talk page, I meant recoil from its unwieldiness. (vs a more elegant discussion format that doesn't require re-editing and reloading whole pages). What's the point of saying - existing layout 'is what we have', 'yes it's bad and 'they' will replace it with something even worse in innumerable ways, but we'll get used to it? Might as well shut down the Village Pump, give up on discussing constructive changes. I didn't 'complain' about the changes to 3RR - I was saying that if BRD had been adequate in the first place, nobody would be making these changes. Being categorised differently won't stop them happening alongside. Although the gap between 3RR and BRD is the biggest problem, other than the revert-happiness encouraged by BRD itself.
Saying I'm trying to turn football into bowling/fishing is senseless. Not trying to create a 'new game', but to improve the existing one, by making collaboration easier. The point about BRD is that it's making consensus more difficult to achieve (especially with existing layout), and improvement is needed, that will make it easier for people to show their 'suitable temperament'.
I haven't seen the new system yet, but it's hard to imagine it's clumsier than this..? 85.211.105.223 (talk) 08:19, 4 June 2015 (UTC)

Proposal on including sister-project links in nav templates

FYI

 – Pointer to relevant discussion elsewhere.

There's an open proposal discussion, that could use more eyes and minds, at Wikipedia talk:Categories, lists, and navigation templates#The inclusion of 'Commons', 'Wikiquote', and 'Wikisource' on appropriate templates.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:36, 3 June 2015 (UTC)

@SMcCandlish: This is now an RFC. --Rob Sinden (talk) 12:08, 4 June 2015 (UTC)

Non-neutral commentary does not belong here; this is just a neutral notice that the discussion exists and may be of interests to VPPRO regulars.

The question, as you can see from the above open discussion notice, is really about limited sister projects, "Wikiquote" and "Wikisource", but Robsinden wants to make it about all sister projects (the RFC by Sadads was mistaken in its scope, and Sadads asked us to modify it. I changed it to reflect the original question minus 'Commons' (which was removed after a legit concern), Robsinden brought that into an edit war, and now I can't revert a third time, leaving the inaccurate RFC question visible for the time being until Sadads can come by. Please take the original question, which pertains only to 'Wikiquote' and 'Wikisource texts' into your consideration and not adding the entire sister project universe to templates, which, although I presented the original question, even I would oppose. Thanks. Randy Kryn 12:04, 4 June 2015 (UTC) This is not the forum for this, this is nothing more than a notification of discussion. Stop being childish. If you have a problem with the question as it was asked in the original RFC, bring it up at Wikipedia talk:Categories, lists, and navigation templates#Comments and other opinions/approaches, rather than edit the question. --Rob Sinden (talk) 12:26, 4 June 2015 (UTC)

Sockpuppet Investigations (Random SPI checks is not always fishing)

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

---

https://wiki.riteme.site/wiki/Wikipedia:Sockpuppet_investigations/OccultZone

I am shocked to find that User:AmritasyaPutra turned out to be a sockpuppet of OccultZone. User:AmritasyaPutra's account was opened on 10 August 2008 and he became (pending changes reviewer, rollbacker). Few months ago I saw an old user User:Darkness Shines blocked as a sockpuppet of Mark Nutley(which was renamed as Darkness shines 2). Now Darkness Shines is unblocked.

SPI cases are filed when there is some suspicious behaviour by two accounts, or when three/four new accounts support some old blocked account. Then SPI clerk asks for CU check, if he is provided with sufficient evidence . SPI cases without evidence is considered personal attack.

I suggest:

"There must be compulsory CU check on a user when he/she gets some extra rights as rollback rights, pending changes review rights,Auotopatroller, Template editor rights, Mass messaging rights along with Administrator rights. And Users should not feel bad about it. In airport all has to face metal detector test even if they are not terrorists. So the editors must be ready to face compulsory CU checks to get those extra rights mentioned here in WP:UAL".

On a different note, in most SPI cases only one clerk is working on all cases. There must some other clerks also. In most pages I see Vanjagenie's comment. What happened to other SPI clerks? --Cosmic  Emperor  18:33, 3 June 2015 (UTC)

Those who are typing oppose, oppose: can you give a solution to stop these clever sockmasters. CU is not for fishing. But how to stop socks from becoming powerful editors like User:AmritasyaPutra and Darkness Shines? People think that there will be too much burden on Check Users. Most Check Users don't work in SPI. Those Check Users who work in SPI, i don't want to increase their burden. But those who have Check User rights , still don't perform CU checks in SPI, i want them to do this.--Cosmic  Emperor  01:40, 4 June 2015 (UTC)

• Support concept: although CU is not for fishing, I really support the concept of this (if it would amend the scope of CU for this specific purpose and not put too much burden on the CUs) having been on the "wrong side" of both the cases in question that revealed such users to be sock puppets of their older, disruptive, accounts. I'll like to support an agreeable version of this which ensures all loopholes are covered both to protect the user being CU'd and to enforce such a concept. It wouldn't make sense to CU on a single rollback right but maybe for sysop or say when a user gets 3-4 such rights which give them tools that experienced editors are trusted with, it might be a good idea to ensure they are not socking. --lTopGunl (talk) 18:45, 3 June 2015 (UTC)
• Oppose as per CU is not for fishing. Moving from social to technological methods of behaviour enforcement is the path of arms races. Stuartyeates (talk) 20:30, 3 June 2015 (UTC)
• Oppose (edit conflict)A:overreaching use of CU and B:some users legitimatly use multiple accounts without disclosure but within policy and don't won't them disclosed at rfp.

EoRdE6^{(Come Talk to Me!)} 20:34, 3 June 2015 (UTC)

I agree with you. In that case the Check User who will perform the test must be E-Mailed about those legit socks.--Cosmic  Emperor  01:50, 4 June 2015 (UTC)

• The harm to the community from a sockpuppet receiving access to most of those rights is minimal, and as such I think automatic checkuser fishing would be unjustified. For candidates for admin, template editor, edit filter manager, and Arbcom, I could see supporting a check. But then the problem becomes if everyone knew they would get checkusered as a result of candidacy, it becomes trivial for any serious sockmaster to make sure they waited until they were outside the window for technical evidence. So at most you catch sloppy socks trying to get permissions. All in all, not sure its worth it. If you really wanted to stop it, you would need some type of random checks of existing holders of the rights your concerned about. Monty₈₄₅ 22:42, 3 June 2015 (UTC)
• oppose. Those metal detectors everyone goes through at airports? Security theater which does little to stop determined terrorists, and anyway entirely irrelevant. No, CU is not for fishing. People granted additional rights are already subjected to heightened examination of their editing, before and after gaining such rights. How much so varies greatly by the rights. If you think e.g. admins become admins to easily then take it up at RfA. But CU is not the way to do it.--JohnBlackburne^words_deeds 22:52, 3 June 2015 (UTC)
• To answer your last question first, two of our most active SPI clerks became CheckUsers in March, so they've been focusing more on the other side of cases. As for the proposal, I must oppose. I don't think, for most userrights, that such checks are necessary or even allowed by policy. Also per the preceding opposes, particularly Monty845 and JohnBlackburne. ​—DoRD (talk)​ 02:05, 4 June 2015 (UTC) Edit: Also, the OccultZone case was a complex investigation. I have doubts that any of the accounts would have been caught in a cursory "rights check". ​—DoRD (talk)​ 02:13, 4 June 2015 (UTC)
• Oppose. CheckUser should not be used unless there is sufficient evidence to suggest that a user is abusing multiple accounts. Furthermore, since CheckUser can reveal a user's location, using it without prior evidence of abuse (obtaining a new right is obviously not abuse) would be baseless invasion of privacy. --Biblioworm 02:08, 4 June 2015 (UTC)
• Not going to happen. This is a flat-out violation of the privacy policy; "is applying for a permission above autoconfirmed" doesn't come close to the required criteria for doing a check. Risker (talk) 02:44, 4 June 2015 (UTC)

@Risker: The privacy policy has a catchall provision that says information may be shared with the permission of the user. While it seems pretty clear this proposal isn't going anywhere, if a process was structured such that consent to having a checkuser performed was explicitly given at the time of application for the user right, I think it would be permissible under the privacy policy. There also doesn't seem to be anything in Meta Checkuser Policy that would prohibit it either. Our local checkuser policy is much stricter than the baseline Meta policy, which I think is probably a good thing, but it does mean we do have flexibility if we as a community want it. Monty₈₄₅ 04:56, 4 June 2015 (UTC)

Sorry, no. It is not possible to require users to surrender their privacy, not to mention the privacy of every other user who might show up in an otherwise unjustified check, so they can gain access to what is, at the end of the day, a rather inoffensive and harmless tool. There is no other user permission anywhere in the entire WMF sphere that requires the user submit themselves to a checkuser in order to be considered for the permission, simply because there is no justification for it. (Notwithstanding, checkusers and oversighters do need to supply personal information as required by the privacy policy. That's not the same as running a CU - which also compromises the privacy of others.) Risker (talk) 05:08, 4 June 2015 (UTC)

• Oppose - per Risker, this is a pretty heavy privacy policy violation. Also violating a lot of other people's privacy.--Jorm (talk) 02:47, 4 June 2015 (UTC)
• Oppose I see no need to stop anything not being used deceptively or disruptively. If there is no direct suspicion of misbehavior, we should not be using exceptional investigative tools to find them. The OP's premise, that hidden alternate accounts present a scourge that needs rooting out, is not a position I support; at least not that we must sacrifice core values of due process and privacy to do so. --Jayron32 02:52, 4 June 2015 (UTC)
• Not happening. First, we don't go on fishing expeditions. Secondly, what do you draw the line? - Mailer Diablo 06:17, 4 June 2015 (UTC)
• Oppose and will not be done as a violation of the privacy policy. Reaper Eternal (talk) 02:57, 4 June 2015 (UTC)
• Oppose per the others who have noted that it is contrary to policy.--Bbb23 (talk) 04:20, 4 June 2015 (UTC)

Some Administrator must close this discussion, after DoRD's statement about OccultZone's case.Cosmic  Emperor  04:51, 4 June 2015 (UTC)

• Comment. I am bemused by the claims that checkuser violates the privacy policy - if so, why do we have it? The existing threshold for making one is ostensibly a community lynch mob, really an admin deciding whether or not he is curious. The process needs more transparency - there have been stories about people being checkusered over three year old accounts. I don't feel like there's any real protection now, so the shocked invocations of privacy seem to be 'protesting too much'. That said, I don't see petty little rights like reviewing and rollbacking as being that important, nor should they be. Checkusering the admins routinely might be more interesting, but I'd rather see the whole capability uninstalled. Wnt (talk) 12:21, 4 June 2015 (UTC)

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

Scrub SourceForge links?

Proposal to scrub all SourceForge links or mark them with some sort of exclamation icon due to their recent unscrupulous behavior. See: http://www.gimp.org/ http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html http://arstechnica.com/information-technology/2015/06/black-mirror-sourceforge-has-now-siezed-nmap-audit-tool-project/ — Preceding unsigned comment added by Abdd0e77 (talk • contribs) 21:36, 3 June 2015 (UTC)

Our role is not to punish websites for their behavior. How would "scrubbing" all the links be in line with WP:EL? VQuakr (talk) 22:24, 3 June 2015 (UTC)

I didn't look into it enough to see if it is still an issue, (saw something saying they've stopped) but the links seemed to have been violating WP:ELNO by tricking users into installing adware and other unwanted software instead of just what they came there for. With many of the SourceForge links on Wikipedia being to actual project sites and simply going to SourceForge not being an issue, it would be better to just include a warning instead of removing them if any action is required. PHANTOMTECH (talk) 23:15, 3 June 2015 (UTC)

ELNO prohibits links to malware, not adware. VQuakr (talk) 23:25, 3 June 2015 (UTC)

Open an issue at MediaWiki_talk:Spam-blacklist#Proposed_additions and discuss it there; the editors there will have experience of such situations. Stuartyeates (talk) 23:28, 3 June 2015 (UTC)

Adware is a form of malware. 'Malware' is an umbrella term used to refer to a variety of forms of hostile or intrusive software, including computer viruses, worms, trojan horses, ransomware, spyware, adware, scareware, and other malicious programs. (emphasis added) The spam blacklist doesn't seem appropriate because links to the site do have some validity, since some open source projects with articles use it as their only distribution method, but a cross-post to WP:VPT might not be a bad idea for getting more input. @Abdd0e77: Do you know if there is any evidence SourceForge is continuing to replace installers or have there been no cases since they've said they stopped? PHANTOMTECH (talk) 23:48, 3 June 2015 (UTC)

How I read the situation is that it only affects the download of source code and/or software, and not for the general web sites themselves. I don't think this would be an ELNO aspect, as these are valid project sites that would be linked to from articles on the open source projects, but I do agree that having a template that one can wrap links it to caution them about downloads possibly containing adware from the site. --MASEM (t) 23:56, 3 June 2015 (UTC)

There is a strong case made here that any SourceForge link is now suspect, since the official projects in general seem to be preferring other distributors. I think it would be useful for someone to go through by hand and see how many of these links can be changed to something else. However, if push comes to shove, it is still likely better to link to a creepy commercial website than to link to nothing. Warnings are still an option... Wnt (talk) 12:16, 4 June 2015 (UTC)

Lists of the links that we are talking about: [2] [3] [4]. I have some serious concern here as well, but then again, download.cnet.com is only slightly better than sf.net right now. Yes, there is a lot of bad stuff out there, but it's also a bit the geocities of the 2000s open source development world, and in that regard, there is still a lot of valid links in our articles I think... (perhaps archive.org versions instead?) —TheDJ (talk • contribs) 15:38, 4 June 2015 (UTC)

Good Lists

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

---

A new class of article to be introduced. It will be a good list. It is similar to good article criteria but in a list format. The step up from list to FL is too great and, like an article, we need a good list. The criteria are below.

It covers a topic that lends itself to list format (see WP:List) and, in addition to meeting the requirements for all Wikipedia content (particularly naming conventions, neutrality, no original research, verifiability, citations, reliable sources, living persons, non-free content and what Wikipedia is not) a good list has the following attributes:

1. Prose. It features a good standard of writing, with no major copyedit issues,
2. Lead. It has a lead that introduces the subject and defines the scope and inclusion criteria.
3. Comprehensiveness.
   • (a) It comprehensively covers the defined scope, providing all of the major items and.
   • (b) In length and/or topic, it meets all of the requirements for stand-alone lists; does not violate the content-forking guideline, does not largely duplicate material from another article, and could not reasonably be included as part of a related article.
4. Structure. It is easy to navigate and includes, where helpful, section headings and table sort facilities.
5. Style. It generally complies with the Manual of Style and its supplementary pages.
   • (a) Visual appeal. It makes suitable use of text layout, formatting, tables, and colour; and a minimal proportion of items are redlinked.
   • (b) Media files. It has images and other media, if appropriate to the topic, that follow Wikipedia's usage policies, with succinct captions. Non-free images and other media satisfy the criteria for the inclusion of non-free content and are labeled accordingly.
6. Stability. It is not the subject of ongoing edit wars and its content does not change significantly from day to day, except in response to the good list process.

TheMagikCow (talk) 17:09, 3 May 2015 (UTC)

This has been discussed before, though I don't have any links handy. Personally, I do not believe there is much value in creating another review process that is ultimately redundant to the Featured List process. There will not be enough difference between a "good" list and a "featured" list to make the process worthwhile. Resolute 17:11, 3 May 2015 (UTC)

How does this proposal compare to FL? What are the similarities and differences? — {{U|Technical 13}} (e • t • c) 17:32, 3 May 2015 (UTC)

There is not much difference between these criteria and those at WP:WIAFL. Apart from changing the word "featured" to "good" throughout, the differences are in just two main criteria and one subcriterion:

In criterion 1, "... professional standards of writing" is replaced by "... a good standard of writing, with no copyedit issues"

In criterion 2, the word "engaging" is omitted

In subcriterion 3(a), the words "at least" are omitted, as is the phrase ", where practical, a complete set of items; where appropriate, it has annotations that provide useful and appropriate information about the items."

In short, I think that the above proposal is expecting too much for a Good List. Compare the requirements for a Featured Article with those for a Good Article - the differences are much greater. In particular, although FA and FL both require compliance with the Manual of Style, GA need only meet the MoS in five areas: lead sections, layout, words to watch, fiction, and list incorporation. I don't think that a GL proposal should require full MoS compliance either. --Redrose64 (talk) 09:58, 4 May 2015 (UTC)

I've found that WikiProject Military history (MILHIST) has a quality scale for lists, which has intermediate levels CL, BL and AL - but there is no "Good List" level, see WP:MHA#SCALE. Accordingly, I've sent MILHIST a note. A shorter version of that has been sent to some other talk pages (example). --Redrose64 (talk) 10:36, 4 May 2015 (UTC)

• Oppose I think we revisit this idea about once a year. As Redrose64 notes, the proposal is very close to FLC already, and trying to define a deliberately weak set of criteria for a "good list" doesn't serve our community well. Full MOS compliance isn't actually that difficult for any article, but it's actually quite important from a technical perspective with lists, so downgrading that would be a bad thing too. The Rambling Man (talk) 10:21, 4 May 2015 (UTC)
• Support Yes and those many thousands of years-related articles that are being maintained for ages with reliable sources needs some recognition. OccultZone (Talk • Contributions • Log)

  Could I ask what is preventing any of those many thousand of years-related articles from meeting the FL criteria? Do you have an example of one which you consider to be good enough to be a good list? The Rambling Man (talk) 10:46, 4 May 2015 (UTC)

2012 in the United States, 2014 in the United States and more. Due to the lack of concentration and dedication that is actually required for FL, they cannot achieve this FL milestone. OccultZone (Talk • Contributions • Log) 11:00, 4 May 2015 (UTC)

You're supporting a proposal because we're lacking concentration? Yes, those articles are awful, awful, but we have many "timeline" featured lists which could be used as a basis if someone could be bothered to look into it. The Rambling Man (talk) 11:18, 4 May 2015 (UTC)

• Support I think the biggest difference between F(L)C and a G(L)C is in the procedure. It takes multiple reviewers to approve a F(L)C nomination, it would only take one reviewer to approve a G(L)C nomination. You can only nominate one article/list at a time for F(L)C but you could nominate multiple for G(L)C simultaneously. The quality of a F(L)C article/lists increases by the diversity of multiple reviewers contributing. Subsequently a list reviewed by just one person most likely will suffer in quality because every review has weaknesses and strength. Having said that, I think a GL-class makes sense, although the criteria may only be marginally different. MisterBee1966 (talk) 12:16, 4 May 2015 (UTC)
• Partial Support The WP:MHA#SCALE approach seems good, I find that the top levels of perfection are unattainable in many cases, but there is a need to bring a start class list upto a C. If you are documenting List of watermills in the United Kingdom or worse still List of watermills in the World then having some lower level goals would be helpful. New editors would probably be happy to work in this uncontraversial area if we had low level goals to set them. -- Clem Rutter (talk) 13:27, 4 May 2015 (UTC)
• Question it looks, to me at least, like the most usual candidates for this "good list" idea are those which are just very long and therefore a lot of work is required to suitably format and reference them, is that the idea? The Rambling Man (talk) 13:38, 4 May 2015 (UTC)

  No the idea is that lists that are not FA class get recognition. There is no minimum entries to a list as long as it is WP:NOTABLE — Preceding unsigned comment added by TheMagikCow (talk • contribs) 16:14, 4 May 2015

  I'm afraid I don't understand your point at all. The Rambling Man (talk) 19:44, 4 May 2015 (UTC)

• I really wish this discussion had not been fragmented on Wikipedia:Village pump (idea lab)/Archive 17#Good Lists. That said, I Support this proposal. — {{U|Technical 13}} (e • t • c) 14:03, 4 May 2015 (UTC)
• Oppose we've had this discussion before (probably been a few years, though) and my opinion is unchanged: There does not exist a quality gap necessary to fill with a Good List concept. Any putative "Good list" would essentially be a featured list anyways. --Jayron32 14:56, 4 May 2015 (UTC)
• Oppose - any "good list" would still need to be complete and be referenced, right? Just like GAs? At that point you might as well nominate it for FL- you're basically there, most lists don't have enough prose to get tripped up on. I appreciate the idea of having an intermediate level for really long lists that take a lot of effort, but "a lot of effort but is not done" isn't really a good point to slap a star on something. I'd like to see some examples from the supporters of what current lists they'd consider "good" - the examples posted so far are just "would take a lot of work to complete", which isn't the same thing at all. --PresN 16:13, 4 May 2015 (UTC)

  Exactly. It's just about lists which need more work, nothing more. The Rambling Man (talk) 19:44, 4 May 2015 (UTC)

• Support As nominator. TheMagikCow (talk) 19:13, 4 May 2015 (UTC)
• Oppose I don't see any tangible benefit to this idea. Beeblebrox (talk) 23:58, 4 May 2015 (UTC)
• Oppose. Per Beeblebrox. --Dweller (talk) 09:30, 6 May 2015 (UTC)
• Oppose featured list is already very easy to achieve and we seem to have a disproportional mount of these already. So having this would just make a lower quality bar that would enable an easy to achieve recognition. Instead just go for FL. Graeme Bartlett (talk) 08:32, 8 May 2015 (UTC)
• Oppose. What nonsense, this is simply lowering the standard of a list. FLs are very easy to achieve. HYH.124 (talk) 08:46, 8 May 2015 (UTC)
• Oppose. It is not difficult to promote any regular list to featured list. If the process itself is like the good article review process, it would probably take less time to promote an article to featured list than good list, due to the relatively little work needed and the backlog of a unilateral review process. Esquivalience ^t 02:55, 9 May 2015 (UTC)
• Oppose. The English Wikipedia is biggest wikipedia; but I think there is not enough list article to make GL.--Skky999 (talk) 02:36, 10 May 2015 (UTC)
• Support: there are multiple lists present that are not FL but they can make GL and need recognition. It might also help identify, which lists have potential to be GLs and would redirect short term efforts towards those lists as well. --lTopGunl (talk) 16:32, 16 May 2015 (UTC)
• Support. I am in agreement with MisterBee1966 regarding the process of GA and FL assessments. Progressing to expand List article's assessments is in the right direction for improvement of List articles in the encyclopedia by giving editors a process to improve List articles in the same manner as Articles rather than the antiquated back of the bus assessment of Lists (Stub, List and FL). Gmcbjames (talk) 01:38, 18 May 2015 (UTC)
• Support: It's good to encourage incremental article improvement with milestones like this, and lack of this particular one is kind of glaring.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:27, 24 May 2015 (UTC)
• Strong Oppose. The criteria is pretty much the same as FL, plus featured list don't take that much effort to make; the difference between the two would be splitting hairs and just make more backlogs for the sake of more backlogs and bureaucracy. Most of the supports not only don't persuade me, but convince me of how pointless an exercise GL would be. Wizardman 17:48, 25 May 2015 (UTC)
• Support --- :D Derry Adama (talk) 14:08, 29 May 2015 (UTC)
• Oppose The amount of work that goes in to writing an article makes it worthwhile to have a pause and recognize that it's at a decent level ("good") and another when it reaches featured level. Lists don't have the same level of work to them; once they're complete and referenced, there's not a lot more to be done to make it featured. Matt Deres (talk) 15:56, 5 June 2015 (UTC)

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

Diff generator enhancement

Hi, for as long as I can remember, the Wikipedia diff generator for revisions has failed to handle the insertion or removal of paragraph breaks sensibly. If a paragraph break is added or removed, the whole of the paragraph is shown as having changed, like this and/or the diff generator mistakenly tries to compare existing content with an insertion, rather than realising that the insertion has pushed existing content further down, like this. I would like to request that the enhancement to make this work properly is given some impetus and developer effort. I really do think it is about time it was fixed. 109.157.11.203 (talk) 20:40, 31 May 2015 (UTC)

For logged-in users, there is a gadget for an enhanced diff view that does not mark a split paragraph as having changed (only the inserted line break). SiBr₄ (talk) 20:51, 31 May 2015 (UTC)

Great, well let's roll that feature out to all users. 109.157.11.203 (talk) 20:59, 31 May 2015 (UTC)

(OP) Does no one else think this is worth doing?? What are the objections? 86.183.129.51 (talk) 17:32, 5 June 2015 (UTC)

The main thing is that someone has to do the work, which would mean that something else would have to wait. So they prioritize things, and I doubt this would ever make it to the top of the list. Especially considering that User:Cacycle/wikEdDiff is already available, stable, and time-tested. If anyone wants the tool and needs help installing it, such help shouldn't be hard to find. They may click my talk button, for example. ―Mandruss ☎ 17:56, 5 June 2015 (UTC)

Wouldn't stuff like this be extremely right to do by all this techies payed by our contributions of the wealthy WMF instead of rubbish like Flow? They are wading in multi-millions and don't get basics done right, but push unwanted stuff like MV with superprotect against the communities. But hey, it's not as sexy as some brand new stuff, and it's really useful, not just pretends to be, so why bother? Grüße vom Sänger ♫ ^(talk) 07:37, 6 June 2015 (UTC)

Establish Wikipedia talk:MoS as the official page for style Q&A on Wikipedia

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

---

Because the proposal to establish a dedicated style noticeboard has fallen through, it is now proposed that Wikipedia talk:MoS be established as Wikipedia's official page for style Q&A. This would involve the following actions:

1) Adding text to the effect of "and for questions about the use of capitalization, punctuation, organization and other matters of style on Wikipedia" to "This is the talk page for discussing improvements to the Manual of Style page."

2) Inserting text to the effect of "ask style questions at Wikipedia talk:MoS" any place that would otherwise have pointed to a style noticeboard.

3) Inserting text to the effect of "ask style questions at Wikipedia talk:MoS (and not here)" in the talk pages of other style guide pages so that style Q&A is more centralized.

Here are the kinds of questions that people ask: 1, 2, 3.

The goal of this proposal is make help with Wikipedia style issues easier to find and more centralized without increasing opportunities for forum shopping. WT: MoS has already served as an unofficial Q&A board for many years. The discussion leading up to this proposal is available here. 05:06, 14 May 2015 (UTC)

Support: WT:MoS for Q&A

1. Support 1, 2, 3 The MoS has provided clear, low-drama Q&A for years. The problem with the current system is that not enough people know about it, there's overlap across multiple talk pages, and, because it's unofficial, people might think they're breaking rules by using it. A noticeboard might have solved these problems more cleanly, but actively guiding users with questions to the existing system will also do it. Darkfrog24 (talk) 05:06, 14 May 2015 (UTC)
2. Support 1, 2, 3 Moved to Support: One official page will help new editors/ editors with a question. TheMagikCow (talk) 14:40, 16 May 2015 (UTC)
3. Support 1, 2, 3 - Centralizing style issues is a good idea. Disagree with the editors who oppose. Robert McClenon (talk) 21:43, 16 May 2015 (UTC)
4. Support 1, 2, 3 Much as a greatly dislike the MoStafarian 'reasoning' process and the mad beaating by the reggaelation players here, there is a need for an identified place to ask questions that will be seen and responded to. My recent question on a side talk page probably didn't get seen by more than one morlock dreadlocked being. So while my emotional impulse is much the same as Beeblebrox, I see the need for "where to go" for reviewed questions. Shenme (talk) 05:13, 17 May 2015 (UTC)
5. Support 1, 2, 3 - An official page for Q&A about Wikipedia's Manual of Style would really help the newcomers. Having newcomers ask about MoS at the Administrator Noticeboard should not be the place to ask such questions: An official Q&A for MoS would serve as that place for questions about the policy in context. CookieMonster755 (talk) 23:03, 22 May 2015 (UTC)

   No-one has proposed the Administrator Noticeboard for such questions. The sensible alternative is the Help Desk. Maproom (talk) 10:58, 23 May 2015 (UTC)

6. Support. Given the amount of opposition, this is a rather token support. I honestly don't see the problem here. If there's problematic behavior or users, there's ANI. Also, MOS pages are already under discretionary sanctions, so problematic users can be removed quickly. NinjaRobotPirate (talk) 04:52, 24 May 2015 (UTC)
7. Support 1, 2, 3 - we need it. --Atsme^📞📧 16:41, 6 June 2015 (UTC)

Support giving express permission

Users who support action #1 but oppose the rest of the proposal:

@Scs: (Steve Summit)

@Tevildo:

Put me down as Neutral on this issue. In my opinion, people should be encouraged to ask such questions on WP:HD rather than WT:MOS, but I don't think they should be required to, or prevented from asking them on WT:MOS. In short, I'm in favour of retaining the status quo. Tevildo (talk) 00:42, 2 June 2015 (UTC)

@SMcCandlish:

@Finell:

All users have permission to add or remove their own name from this list. Ask for any other changes. Darkfrog24 (talk) 23:04, 1 June 2015 (UTC)

Oppose: WT:MoS for Q&A

1. Oppose all – This flies in the face of the recent RfC, whereby a clear consensus was to not have any such designated place for style. What's more, locating the proposed space at the MoS gives the proposal a partisan air, allowing MoS editors to have undue influence on outside disputes. There is no way that this can be tolerated. Do not buy Mr Frog's canards about an "existing system". There is no existing system. The MoS talk page is only for discussing changes to the MoS, and nothing else. RGloucester — ☎ 14:27, 14 May 2015 (UTC)

   The previous proposal concerned whether or not to create a new noticeboard. No decision whatsoever was made regarding existing pages where Q&A is already taking place. By "existing system," I mean the fact that people ask style questions at WT:MoS and receive answers there: [5]. Darkfrog24 (talk) 20:09, 15 May 2015 (UTC)

2. Oppose largely per RGloucester. This is basically a rehash of the rejected proposal to create a style notice board. Calidum T|C 23:26, 14 May 2015 (UTC)

   Oppose We have the WP:HD TheMagikCow (talk) 14:38, 16 May 2015 (UTC) Moved to Support: One official page will help new editors/ editors with a question. TheMagikCow (talk) 14:40, 16 May 2015 (UTC)

3. Oppose I understand the intent here. If you have questions for admins you go to WP:AN. If you have questions about biographical articles you go to WP:BLPN, for sourcing we have WP:RSN and so on. So it should logically follow that if you have questions about writing style you go to the MOS, where the experts or "gurus" are. And that's where we run into a problem that is going to hamstring any attempt to do this unless and until it is fixed: the ranks of MOS regulars include a lot of grammar/punctuation obsessives, who wrongly believe that in each every situation there is a hard and fast rule. This would not be an insurmounatable problem if they at least agreed on what that rule was, but they pretty much never do. So this would just draw innocent, curious users into a cesspit in the back rooms of Wikipedia, A simple question about style could end with a giant drama fest in which multiple users are blocked, as has happened time and again in the MOS area in recent years. I'd much rather have some slight inconsistencies in our overall style than allow these obsessive types to have undue influence over actual content. Beeblebrox (talk) 16:03, 16 May 2015 (UTC)

   You seem misinformed about what actually happens when people ask style questions at WT:MoS. Please click these links (or check the archive): 1, 2, 3. Darkfrog24 (talk) 21:26, 16 May 2015 (UTC)

   Indeed. The dramafests are almost exclusively limited to axe-grinding to insert some pet new "rule" (usually from wikiprojects) or delete something someone personally doesn't like. For some reason a tiny percentage of the WP editorship refuse to absorb the obvious fact that it's essentially impossible for anyone to personally agree with every single thing in MOS, because on every style point imaginable at least one off-WP style guide offers conflicting advice from others, so we all have differing expectations. MOS is, necessarily, a compromise (i.e. something that no one is perfectly happy with every single aspect of), and we agree to abide by it here so we can actually get some consistent editing done and not drive our readers and other editors crazy over style nit-picks. The drama comes from people who can't get past their confusion of what they want/expect in their day-to-day writing vs. what WP editors are compromising on in a consensus process to get on with the content. MOS is not a style guide for the world, only for WP, and virtually every MOS flamewar comes out of failure to understand or remember this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

   Clear-cut questions may be answered simply, but what happens if a questioner inadvertently asks about a topic which touches on someones pet "rule"? It'd be intimidating to new-ish users to touch off a dramafest due to an innocent question. ("WT:MoS is the place to ask style questions ... but don't mention the war.") -- 162.238.240.55 (talk)

   @162.238.240.55: Actually that happened once. While I don't approve of the belittling "pet" term, WP:LQ has both fierce supporters and fierce opponents. (It gets challenged about once a year; chains of RfCs and related discussion can last for months.) This is what happened when someone asked about it: [6] Darkfrog24 (talk) 02:31, 30 May 2015 (UTC)

4. Oppose - Absolutely not. MoS and its ridiculous intractable debates are a 6,000 watt beacon for obsessive-compulsive moths. The last thing I want to do is to give such creatures venomous fangs with a noticeboard. Carrite (talk) 16:29, 16 May 2015 (UTC)
5. Oppose While I respect and appreciate the work MOS editors do, I feel most editors just want to write and improve content. So far, I have found that general legibility requirements like grammar, spelling, sections etc. can be achieved by discussion on the talk page and people coming and copy-editing. Every time I have seen the MOS be used in a dispute, it has not gone well (generally due to lack of focus on content, wikilawyering etc.). Since the goal is to produce a useful encyclopedia, I think that if MOS issues are causing disputes, it's time to drop the MOS and focus on the content. I fear any MOS noticeboard-type entity would attract those who either see MOS as the goal of Wikipedia, or those who want to use it to wikilawyer (in short, wp:NOTHERE). Don't get me wrong, I think most MOS edits are non-controversial and beautify the encyclopedia, but those edits don't need a forum/noticeboard anyway. Happy Squirrel(Please let me know how to improve!) 17:43, 16 May 2015 (UTC)
6. Oppose all. The Help Desk is experienced in, and I believe good at, dealing with new editors who ask things like "what is the recommended way to capitalise section headers?" The MoS talk page has no experience in dealing with human beings. I never knew of its existence until today. I have just looked at it, and read a long debate on the correct shape for the apostrophe-thing in "Qur’an". While I appreciate that such discussions need to be held, and admire the scholarship of the editors who hold them, I believe that such discussions should be kept out of sight of ordinary users. Asking one's first question on Wikipedia is a stressful experience. Adding a redirect to it adds to the stress. And redirecting new users away from a place where they are likely to get a helpful answer is crazy. Maproom (talk) 07:34, 17 May 2015 (UTC)
7. Oppose all. This just does not fit into the structure and feels wrong to me per RGlouster and Beeblebrox. SpinningSpark 12:24, 17 May 2015 (UTC)
8. Oppose all per Beeblebrox and Maproom. Everything I'd like to say has already been said by them, but I'll emphasize that WT:MoS is definitely not where we should be sending new editors. APerson (talk!) 18:29, 18 May 2015 (UTC)
9. Oppose. The recent consensus was that people don't want a designated area for style questions. Anyone can ask a style question anywhere, and if they want to go to WT:MOS they're welcome to do that. Sarah (SV) ^(talk) 19:29, 20 May 2015 (UTC)

   That wasn't the consensus at all. It was that they don't want a noticeboad, because those are generally for policy matters that require enforcement (or entirely procedural things like bureaucrat and bot owner matters), not guideline matters subject to interpretation. There are exceptions like the RS noticeboard, and WP:NOTICEBOARDS lists a lot of things that aren't noticeboards.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

10. Oppose. As a general proposition, we should be less concerned about enforcing "rules" about the minutia of style, not more. —Steve Summit (talk) 21:16, 20 May 2015 (UTC)

    I would be fine with 1a. Adding text to the effect of "and for questions about the interpretation of the Manual of Style" to "This is the talk page for discussing improvements to the Manual of Style page." —Steve Summit (talk) 21:25, 20 May 2015 (UTC)

    Well, that doesn't sound like an "oppose" then, just a brevity suggestion for proposal point #1, and a preference against #2 and #3  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

    I was afraid the rewording I suggested was more significant than could be accommodated by those words "to the effect of". (Anyway you don't need VP/Pr consensus to change the intro text on a talk page.) —Steve Summit (talk) 11:32, 25 May 2015 (UTC)

11. Oppose, what is this? Didn' we just have an RfC regarding this? Why does there need to be a centralized location? Why not just place a please see link on the WikiProject's page? — Preceding unsigned comment added by RightCowLeftCoast (talk • contribs) 21:29, 22 May 2015‎ (UTC)

    This is not a game of wackamole, or kick as many balls towards the goal, and see what comes through.--RightCowLeftCoast (talk) 21:29, 22 May 2015 (UTC)

    While I'm not supporting the proposal either, I have to observe that it's standard operating procedure to modify failed proposals in ways that were suggested in the original run, and see if the alternative approach gains traction. It's actually rare for proposals of any real scope to not go through multiple iterations. The rationale for centralizing in both proposals (and the third idea, for a Help Desk page) is that centralizing discussions on the same general topic is usually helpful to editors. That's why we do it so much.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:37, 24 May 2015 (UTC)

12. Oppose any further move to empower or give special designation to the MoS black pit. The last thing any productive content editor (new or old) needs is to get mired in the MoS's idiotic maelstrom. Neutrality^talk 21:35, 22 May 2015 (UTC)
13. Oppose. The place for questions about style on Wikipedia is WP:HD, or the article talk pages - the place for questions about style in general is WP:RD/L. Of course, if people want to ask questions about style on WT:MOS, they can, but I don't think we should require them to use it to the exclusion of our more official support pages. Tevildo (talk) 21:36, 22 May 2015 (UTC)
14. Soft oppose I supported the proposal of a centralized style and format discussion space, but this is just not the right place for it. In effect, the MoS talk page does tend to function more or less in this fashion already, and there's no real reason to (or even a reasonable possibility of) discouraging that ad-hoc practice, but I can only imagine that to codify that role for the talk page of a major guideline would invite nothing but bedlam. I will say that some of the other oppose !votes here which allege a general level of "obsessiveness" on that talk page strike me as being predicated on excessively straw-man-like and accusative generalizations that are both needless and no way provable. In my experience, the editors active on that page generally follow a very helpful, collegial and consensus-based approach. But all of that said, I agree this move would likely only lead to increased intractability and an expansion of the weight accorded to the views of this one page in areas where there is not an established and broad community consensus. In short, I'd rather see the formal noticeboard notion refined and proposed again, hopefully not too far down the line. Snow ^{let's rap} 22:49, 22 May 2015 (UTC)
15. Oppose because the Help Desk is fine for such questions. And because WT:MoS is where the obsessives hang out. AndyTheGrump (talk) 22:56, 22 May 2015 (UTC)

    Why the mass personal attack? Are you somehow unaware that hundreds of editors post on that page every year, and people, from longest-term veterans to firstday newbies, regularly use it as the place to ask legitimate WP style questions?

16. Oppose any further codification or crystallisation of the MoS in any way, shape or form.—S Marshall T/C 23:14, 22 May 2015 (UTC)
17. Reluctant oppose because it's not helpful to fragment first line places to ask questions, or to muddy MoS talk pages with simple style queries. WP:Tea House and Help Desk should be a first port of call. I have no objection to abstruse questions being shared with WT:MoS. All the best: Rich Farmbrough, 11:50, 23 May 2015 (UTC).
    
18. Oppose all: absolutely most astonishingly oppose! I did so in the last iteration of this and I most certainly care enough to keep after this. I have read the entire conversation leading up to this latest proposal: what RGloucester wrote there is my objection: The "CREEP" objections, as I understand them, are based on the premise that such a page (or direction to this page) would be a form of overregulation, whereby editors uninvolved with an article would be directed to interfere with local page processes: except I would also include any changes to an article in addition to during its creation. No article is static here. If that is not enough, I invoke what Beeblebrox has written in the opposition here and echo that. Did I say oppose?? I most certainly did. Fylbecatulous talk 12:38, 23 May 2015 (UTC)
19. Oppose - Help Desk, AN/I and various other boards all do the job so pointless having this. –Davey2010^Talk 18:56, 23 May 2015 (UTC)
20. Oppose We don't need another place to deivert editors from editing Wikipedia. It is easy to answer MOS questions where they arise.—Finell 23:30, 23 May 2015 (UTC)
21. Oppose seems to be an attempt to sneak in a thoroughly rejected proposal without much fundamental improvement. Andrew Lenahan - Starblind 10:41, 24 May 2015 (UTC)

    Why the assumption of bad faith? A proposal to create a noticeboard (which is usually for enforcement of policy) is nothing like a proposal to accurately note the fact that WT:MOS is generally used by editors to ask WP style questions (and to use redirects to point people there).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

    Noticeboards are NOT used to "enforce policy". RGloucester — ☎ 15:08, 24 May 2015 (UTC)

    Um, OK. I guess you don't read noticeboards much, since that's about 90% of what most of them do, either basic operational policy like WP:CONSENSUS, etc., at WP:ANI, or specific policies like WP:V with their own noticeboards. Yes, there are some noticeboards for some guideline matters (remember I said "usually"?), but I submit that they're odd ones out, and a poor model for how to deal with questions about guideline interpretation. Most of those are about guidelines that border on policies, like WP:RS. They're dissimilar to MOS. (There are also entirely procedural noticeboards, like the bot owners NB and the bureaucrat NB, but I think we all know I don't mean those. Nor the large number of non-noticeboards that are listed at WP:NOTICEBOARDS.) Regardless, the point obviously was that while a MOS noticeboard isn't a good approach (and you opposed that proposal yourself), it's clearly not the same proposal as this one, and an assumption of bad faith behind this different proposal on the basis that they're the same isn't appropriate. I think Starblind can respond for himself, and doesn't need you to leap in and sport-argue for him. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:20, 24 May 2015 (UTC)

    I did not "oppose" that proposal. I wrote that proposal and submitted it. Your definition of noticeboards is incorrect. The convention on this matter, WP:PNB, makes it clear that what you think a noticeboard is is not what a noticeboard is. RGloucester — ☎ 15:39, 24 May 2015 (UTC)

    Sorry on the first point; I lost track of who I was responding to. I didn't offer a definition of noticeboards, anywhere. I'm pretty clearly referring to pages with "noticeboard" in their names, most of which (when not covering procedural stuff like 'crat business) are in fact used for policy enforcement matters. Maybe you're just negatively responding to the word "enforcement", but I'd defend it; I'm not sure what else to call warnings, blocks, topic bans, and other community and administrative sanction to ensure that policy violations by someone stop (or discussion in which consensus determines there's not actually a policy violation). I'm not sure how I could be any clearer about this, and I decline to re-explain it to you again. I also already referred to WP:NOTICEBOARDS a.k.a. WP:PNB, so I don't know what point you have in directing me to the very page I just pointed out lists a lot of things that are not actually noticeboards but just sort of similar. I have no further interest in this circular conversation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:02, 24 May 2015 (UTC)

    @Starblind: In response to your concerns about bad faith, the conversation leading up to this proposal is linked in the proposal.[7] If you don't want to click, the jist is that I ran a breakdown of the opposition to the proposal for a style noticeboard. Because so many people said, "Let's not make one more page for style," and some said "we should have the talk pages do this," I figured there would be less opposition to simply endorsing an existing talk page. Darkfrog24 (talk) 05:33, 25 May 2015 (UTC)

22. Weak oppose, though I prefer the brevity suggestion "and for questions about the interpretation of the Manual of Style" (which was made in an "oppose" !vote that is actually only opposed to the 2nd and 3rd points). WT:MOS has already been consistently used this way for years, and there's no need to "hide" the fact that people can and will use it that way, but I've come around to agreeing that WP:Help Desk is the proper venue, because the it's more newbie-friendly. (It's actually perfectly legitimate for a discussion at WT:MOS to decide for or against the idea that the page top can inform editors that they may ask such questions there, BTW.) To address some other points:

    The objection by an MOS detractor that MOS regulars would dominate the answers is silly; it doesn't matter where people ask these questions, the editors who know MOS best will tend to be the ones who provide most of the answers and provide the most accurate ones. Obviously. If you want facts about physics you should consult physics books instead of astrology or baking books, and if you want legal advice you go to a lawyer, not a nurse.

    A large number of the oppose !votes here are incivil, assumptive of bad faith, and in some cases patent personal attacks on a mass scale. How would you like to be name-called "obsessive-compulsive" because of what pages you edit here? There no such thing as a special caste of "MOS editors". Every single person who cares to edit MOS or WT:MOS, ever, is "a MOS editor". Everyone who wants to work on List of Firefly episodes can be "a List of Firefly episodes editor". Such labeling is ridiculous, imagining a false dichotomy, a hierarchical caste system that demonstrably cannot possibly exist.

    That fallacy is, notably, closely related to the equally false conception, shredded by WP:LOCALCONSENSUS policy, that wikiprojects are sovereign little fiefdoms that get to make up their own rules about "their" articles, in defiance of site-wide guidelines and policies. It's no accident that most MOS detractors and outright deletion advocates are editors who also advance or operated under this false view of wikiprojects, trapping themselves into an "our tribe vs. your tribe" WP:WINNING stragedy that generates almost all of the strife at WT:MOS. Only an MOS detractor with a WP:BATTLEGROUND axe to grind against the guideline itself could even conceive of the un-wiki notion that wanting to help people with MOS-related questions gives a "partisan air" to WT:MOS. If I work on articles about pool players, and someone personally thinks pool players are categorically not notable, does that make me a "pool player partisan", or does the problem perhaps exist between that editor's own keyboard and chair? Or let's flip it around: If you create a template for formatting reference citations to Canadian periodicals, and I observe (in my view, entirely righteously) that it's pointless, being redundant to {{Cite journal}}, is it civil for me to call you "partisan" about your {{Cite Canadian journal}}? Clearly not.

    Next, it doesn't require some VP proposal to create a page here, BTW. If someone wants to actually run a HD page for style questions, go create one and do the work. That's how all of WP gets done.

    Finally, I agree with the earlier consensus that a MOS noticeboard is inappropriate, since MOS is not a policy matter and cannot be "enforced" (the closest thing we have is that disruptive anti-MOS editing can result in blocks at WP:ANI sometimes, but those are blocks for WP:DE, not for "disobeying" MOS).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:58, 24 May 2015 (UTC)

23. Oppose. I can understand the thinking behind a single place for newcomers to ask questions about Wikipedia's house style, but the crazy den of pigs at WT:MOS is certainly not it. Someone, somewhere, should probably write an even more simplified version of the simplified MOS for new users, briefly skimming over what parts should be taken seriously and which parts are just a couple of MOS authors expressing a personal preference, but it would probably be impossible to get consensus about what it would say. – iridescent 11:50, 25 May 2015 (UTC)
24. Oppose; just talk about style on the article pages; don't send it over to that bottomless pit that is the MoS, and the people who watch the talk page. Handle it at the site of the issue, I'd support some kind of {{help me|MoS}} tag to be placed on article talks, but keep it there. Kharkiv07 (T) 12:55, 26 May 2015 (UTC)
25. Oppose, seems like a mess. Stifle (talk) 14:45, 26 May 2015 (UTC)
26. Strong oppose for all BMK (talk) 08:30, 5 June 2015 (UTC)

Discussion: WT:MoS for Q&A

Without opposing or supporting per se, right now, I will note that the previous discussion was opposed for many reasons, and the fact that it was rejected was not universally agreed upon. The devil is in the details here, and unlike what RGlouscester asserts here (and elsewhere), we cannot say "The community unilaterally rejected any and all forms of centralized style discussions". All we can say is that the community rejected one very specific proposal for one very specific way to manage style-based discussions, and because people had many different reasons for opposing that discussion, it is perfectly fine to have a new discussion about different ways to handle the problem. The community did not reject having centralized style discussions. The community rejected one proposal to do it one specific way. I think it is fine to revisit the issue from a different perspective. --Jayron32 20:18, 15 May 2015 (UTC)

I did a breakdown of the reasons that participants gave for supporting and opposing the creation of a style noticeboard here if anyone wants to look at it. Many opponents said that they didn't want to create one more page for style discussions. It's reasonable to say that at least some of these participants would support endorsing an existing page with a proven track record. Some even explicitly said that they thought a talk page system would be better than a noticeboard. Darkfrog24 (talk) 21:11, 15 May 2015 (UTC)

• Comment. If an editor has a question about style, telling him to read MOS isn't bad. If he has a question about MOS, then WT:MOS is the right place. But if he has any other question - for example about some decision not prescribed in MOS, if any are left - that's for article talk, or just try it and see what happens. Wnt (talk) 20:09, 28 May 2015 (UTC)

What usually happens is that no one who knows the answer sees the question.

The kinds of questions that we're talking about involve things like, "Does modelling have one L or two? Is this an ENGVAR issue?"[8] "So-and-so has been reverting my changes. Who's right?" "Does Wikipedia have a rule about X?" "I've been editing multiple articles about discontinued aircraft; should they be in past tense or present?"[9] "Is there one right way to start this sentence or do I have options?"[10] Not all of them pertain to a specific style page. Darkfrog24 (talk) 16:44, 29 May 2015 (UTC)

If someone has question relating to style, where should they go to ask it?

This really is the first question that needs to be answered... The answer may be that there is not one single "official" page... but if not, what are the options... it would help to know where to direct them. Blueboar (talk) 21:04, 15 May 2015 (UTC)

Article talk page. RGloucester — ☎ 21:05, 15 May 2015 (UTC)

that may work if there are a lot of style guru's who work on the article... but what about an article with few editors... it is quite possible that none of the editors working on the article (ie those watching the talk page) will know the answer to the question. So where do they go to find out the answer if asking on the talk page doesn't work? Blueboar (talk) 21:10, 15 May 2015 (UTC)

There is no need of "gurus", who do not exist. A consensus of editors on a given talk page is enough to resolve a dispute, and if a consensus does not form, the usual channels remain open, such as DRN. RGloucester — ☎ 21:21, 15 May 2015 (UTC)

Sorry, I wasn't talking about resolving disputes ... I was asking where editors go if they have a simple question about style, if they need help and advice. For example: An editor who knows he/she isn't great at punctuation - and wants to ask for help and advice... Where would that editor go to ask for help? Blueboar (talk) 02:14, 16 May 2015 (UTC)

WP:HD. --Redrose64 (talk) 05:11, 16 May 2015 (UTC)

Quite right, Mr Redrose. If someone feels a bit off with his English orthography, that has nothing to do with the MoS at all. That belongs at the existing venues for such matters. RGloucester — ☎ 13:43, 16 May 2015 (UTC)

Except the MoS is where we wrote down all the rules concerning those matters, and it's where most people already go. Darkfrog24 (talk) 21:32, 16 May 2015 (UTC)

Agreed. This situation is analogous to that which leads to a desire path; we can try to insist upon an exact methodology which we believe would be most ideal, but it won't stop a strong majority from following the approach which is most intuitive to them in the moment, unless you give them another obvious and efficient option -- good public space engineers account for this kind of factor these days and we should here as well. The MoS talk page clearly gets much more traffic in the from of style inquiries than does the help desk (which frankly is not a readily apparent option to newer editors, at least when compared to MoS, which is linked to across numerous policies and guidelines). I actually do oppose formalizing this role (as my !vote above indicated), but I do think that some form of centralized space for style and formatting issues would be ideal. Snow ^{let's rap} 03:34, 23 May 2015 (UTC)

A page that is specifically for style help but also isn't WT:MoS would make it easier to keep the "what should the MoS say" separate from "what does the MoS say," but there was concern in the talk page discussion that any such page would be construed as gaming the system considering that the noticeboard proposal failed to gain consensus. Jayron and FormerIP recommended creating a sub-page, WT:MOS/questions Darkfrog24 (talk) 06:19, 23 May 2015 (UTC)

Well I'm not talking about doing an end-run around the no consensus result of the previous proposal by essentially creating the same kind of noticeboard in a different-than-proposed space. Rather I'm suggesting the original proposal be tabled for a time and then brought back for central community discussion once the argument for it (and its proposed format and dimensions) are more significantly refined. The somewhat lopsided !votes of the previous discussion not withstanding, I think this proposal is bound to gain traction and broad approval in the community sooner or later, since the need is (to my view) certain. In the meantime, I think it would be counter-productive to the priorities and concerns espoused by most editors on both sides of the major divide (amongst those who spoke in the VPP thread) to try to establish a guideline talk page as a formal resolution/help space. Snow ^{let's rap} 07:54, 23 May 2015 (UTC)

That's interesting. What would you change about this or the previous proposal? Darkfrog24 (talk) 04:38, 24 May 2015 (UTC)

Right now, no there isn't one official page for style Q&A (though WT:MoS has done a large part of the job unofficially), but I feel there should be just one. Call it a noticeboard, call it a help desk; I don't much care so long as the Q&A that we currently do at WT:MoS and other talk pages all happens in one place and is made easier for editors to find. If we use multiple pages, then people get contradictory results. Other editors have also expressed concerns about forum shopping. Darkfrog24 (talk) 21:16, 15 May 2015 (UTC)

I agree that it does notmatter what we call this proposed forum. The problem, as I noted above, is that these self-appointed "gurus" are often extremely obsessive rule-mongers, often disagree with one another to the point where everyone else decides that they don't care anymore and they just walk away, and sometimes even resort to socking and other unacceptable behavior to get their way in whatever is their latest utterly pointless dispute. It would be a terrible idea to direct anyone to go to these people for help. So, regardless of the name of the page, we just shouldn't do this. In fact, I would support large notices at the current MOS talk pages advising users to go elsewhere with their inquiries. Beeblebrox (talk) 17:50, 16 May 2015 (UTC)

Beeblebrox, please click the links of example questions, if you think they're cherry-picked, check the WT:MoS archive. People show up, ask their question, get their answer and move on. When people say "What should the MoS say?" yes we fight about that, but when people ask "What does the MoS say?" it's pretty straightforward. Or on the flip side, can you post a link to a time when an editor asked a style question and it devolved into a fight with sock puppets (or comparable viciousness)? Darkfrog24 (talk) 21:30, 16 May 2015 (UTC)

Responding to Darkfrog24's notice at WT:HD. I have worked the Help desk with some frequency for about a year and I can't recall seeing a style question, not that I have seen everything or that my memory is perfect. I would consider that outside the scope of HD, being in the realm of editorial rather than how-to, so I would personally direct such a question elsewhere. That said, I haven't seen a clear consensus as to the scope of HD (no surprise there), or much concern about enforcing any such scope. Regardless of the question, many responders will try to answer it rather than direct the OP to a place where they might get a higher quality answer. ―Mandruss ☎ 22:00, 16 May 2015 (UTC)

User:Darkfrog24 you said "the MoS is where we wrote down all the rules concerning those matters, and it's where most people already go." That's not quite correct. The Wikipedia:Manual of Style is not a list of rules it is a Guideline. That is, a set of best practices that can, within reason, be ignored. Is Wikipedia talk:Manual of Style the page where most people go to ask? I really don't know as I rarely look at any MOS talk pages. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 22:15, 16 May 2015 (UTC)

Guidelines in name, rules in practice. Whether that's a good thing is a matter for another discussion, but I refer to the MoS's contents as rules quite deliberately. As to whether it's "most," I'll concede that we'd have to count them. The whole point of this proposal is the idea that lots of people with style questions give up before they ask them anywhere. But certainly a lot of users ask their style questions at WT:MoS. Darkfrog24 (talk) 22:19, 16 May 2015 (UTC)

And that's why you are getting resistance to a single style Q&A page governed by MOS experts. Too many see them as rules that must always be obeyed. As to them being "rules in practice" there are many pages that do not conform to the MOS. I've ignored the MOS when it seems like a good idea to do so and so do many others. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 22:28, 16 May 2015 (UTC)

Actually, many of the MoS experts disagree with me about whether they should be considered rules or not. But if you check the example questions provided (or the WT:MoS archive), you will see that the people who ask questions want to know what the MoS's rules/whatever-you-call-them are. I remember one question that was about "Someone else is doing X and I want to do Y; tell me whom the MoS supports." Most of them are more along the lines of "What's the right-or-at-least-MoS-compliant way to do Z?" This isn't about reaching out to other editors and telling them to stop doing what they're doing. The other editors are already reaching in to the MoS and asking what they should do differently. Darkfrog24 (talk) 23:59, 16 May 2015 (UTC)

I had not known about the recent RFC, and only saw the proposal above. Reading here and there I am glad (though sadly...) to see my feelings about MOS are shared by many. However, since I do want "a place" to ask questions related to 'style', I saw in comments to User:Darkfrog24's summary of objections to the RFC that WT:MOS is suggested as 1) existing, 2) likely to be seen by MOStafarians who can volunteer opinions. I may repost my question about "JaMon 1st" vs. "JaMon Ist" there. Shenme (talk) 04:53, 22 May 2015 (UTC)

This is a really good question. My own answer may seem heretical. I don't think it's any secret that the MoS exists. So if someone is writing something, and they're not sure what the "official" way to write it would be, and they somehow don't know about the MoS, or they do know about it but they're not sure how to interpret it and they can't figure out where to ask, my own preference is that they simply not worry about it, and write whatever sounds best to them, and let the style take care of itself later. —Steve Summit (talk) 01:20, 23 May 2015 (UTC)

There are two problems with that, Steve. 1: The explanation at the top of WT:MoS says that the page is for discussing changes to the MoS, not for asking questions about the MoS (easily fixed if you ask me). 2: If a Wikieditor has a question about style, that means that they think that style is important enough to spend their time on. Some of these questions are "Why did so-and-so revert me?" and "Stop caring about it" isn't a good answer to that. Darkfrog24 (talk) 02:51, 23 May 2015 (UTC)

• There should be no official "should" location. What already happens (and should remain) is that editors go somewhere they believe will be an appropriate forum and where they feel most comfortable asking for help. These are in my noticing: 1. article talk page, especially if there has been already previous friendly conversation on that TP. 2. a users talk page (sometimes found from prior discussions at article TP). 3. The Teahouse serving up warmth and tea and then advice or direction to a more appropriate forum. 4. The Help desk. 5. An Administrator's talk page if it is an open forum (and there are some, actually); proposing question to the admin and talk page stalkers to answer. 6. Village Pump. 7. Noticeboard to fight for their right to party in drama. 8. WikiProjects: some are actually quite receptive and grateful for questions about style. Fylbecatulous talk 14:09, 23 May 2015 (UTC)

And what about the ones who 9. give up because they can't find anyone to answer their question? Darkfrog24 (talk) 04:11, 24 May 2015 (UTC)

Since this is hypothetical and you have provided no specifics, I will speculate that they possibly make an incorrectly styled edit in an article. (EEK! The horrors...WIkipedia will surely slide into the abyss). Fylbecatulous talk 14:38, 24 May 2015 (UTC)

You seem to think this is about MoS regulars reaching out to impose their preferences on the article space. Remember this is about questions. This is about other editors reaching in. They don't want to write improperly styled articles. "Stop caring about that" isn't a good answer, not when a better one would be easy.

As for specifics, I did provide examples of questions that were asked and answered on WT:MoS. If you want something else specific, how about you say something a little more specific about what it is? Darkfrog24 (talk) 05:24, 25 May 2015 (UTC)

You seem to be totally discounting all eight locations for help that I listed, as though they are of no use and thusly leave a poor editor stranded all alone in the world of style (what is formal wear after dark? Help I haz to buy a tuxedo!! Do I wear white after Labour Day?). I am saying these avenues work. Here is a diff to an active discussion at the Teahouse. Nice and tame and helpful at the same time. No harm, no foul. I am going to link the current diff but might have to relink to the section after the faithful bot automatically archives it. updated after archive: this is its final resting place: [11]. Why the cats meow is this not an exchange that worked ( in your opinion)? I just want to see all the current avenues for style advice remain active. I do not wish to have every writer rerouted to what I see as an alternate bad route with negative outcomes. See, that Teahouse inquirer received virtual tea of kindness and I do not want that cut off. Thanks. Fylbecatulous talk 13:58, 25 May 2015 (UTC)

Actually, I'm not. I checked out the help desk, teahouse and other spots before I made this proposal, and if I were a new user and hit help desk, I'd think it was only for technical issues. Their archive doesn't have many style questions in it, and the answers given there aren't as clear-cut as the ones provided at WT:MoS. According to Help Desk regular Mandruss, the help desk doesn't really cover this stuff and the regulars there often don't know the answer when it does. As for the others, article talk pages don't usually have style experts on them who can answer these questions, I'm not clear why asking just any other user or just any administrator would necessarily result in accurate style advice, and there is no style noticeboard.

I'd like you to do the same. I'd like you to either click into the MoS archive or try the three links offered in the proposal and take a look at the way the MoS regulars handle questions about style, the way we have been handling them for years. I think you'll find that at least some of your concerns are unfounded. Darkfrog24 (talk) 20:37, 25 May 2015 (UTC)

See, that is it right there. We do not need a "style expert". This just reiterates that what is desired here is the setting up of a Style ARBCOM to handle issues and to nail down the "one correct way". Sorry. Fylbecatulous talk 13:09, 26 May 2015 (UTC)

I'm not sure why any of this makes think we don't need style experts. People keep asking for us to help them. That shows that there's a demand for style help. Darkfrog24 (talk) 16:42, 26 May 2015 (UTC)

Since the other discussion is closed, I'll just chime in here to say that with now 37 watchers on that page, I'd support the style noticeboard as a viable venue. Samsara 11:50, 26 May 2015 (UTC)

The biggest legit objection to the noticeboard was "we don't want to create a new page just for this." But the biggest objection to endorsing the existing page WT:MoS for help is "We don't want the same people at WT:MoS officially endorsed." Putting them on separate pages might help with that. Of course, we're still going to get at least some of the same people on the same page, but it would be a lot easier to say "Remember this is for help only; do not disgress into what the MoS should say" if they were on two separate pages. Darkfrog24 (talk) 16:42, 26 May 2015 (UTC)

Brainstorming support for users with style questions

It looks pretty clear that making the current system official isn't a popular decision, but we can see very clearly that there is a need to provide users with some way to receive answers to style questions. According to Mandruss, the Help Desk is not currently meeting this need. Let's talk ideas. The previous proposal, creating a style noticeboard, met with a split that was close to fifty-fifty. One of the objections was the idea of giving MoS regulars and other style experts too much power. How would everyone feel about creating a separate page, specifically for style questions, that did not have the weight that most of us associate with noticeboards? A separate "style Q&A page" would also make it easier to keep discussions focused on the asker's needs rather than on what the MoS should say or how it should be changed. Would any of you who object to endorsing the MoS support a proposal along these lines? Other ideas? Darkfrog24 (talk) 16:49, 29 May 2015 (UTC)

• No! How many times must people tell you the same thing? How many RfCs must be held to make it clear that the community does not want such a page? RGloucester — ☎ 14:54, 30 May 2015 (UTC)

RG, for the fifth time, revising and improving failed proposals is normal and expected on Wikipedia. Also, I'm a bit confused. You proposed that we establish a style noticeboard. Were you kidding? Darkfrog24 (talk) 17:35, 1 June 2015 (UTC)

Indeed. I second that response to RG's outburst. More practically, the obvious answer to me seem to be to let this entire VPPRO thread die, and see if there's consensus at WT:MOS to add a note to the top of the page saying it's okay to ask style questions there, pertaining to editing Wikipedia, and then just leave it alone. I really don't think we need to do anything further. If a year from now, there's still some problem, then let's revisit the issue. This entire VP thread is now just a distraction, and a temper-flare magnet.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:01, 2 June 2015 (UTC)

I proposed it, and the proposal FAILED. The view of the community is clear, regardless of whether I endorse that view. The method that SMcCandlish proposes is gaming the system, and nothing else. A local MoS consensus cannot override a community consensus. Absolutely disgusting comments, indeed. RGloucester — ☎ 17:22, 2 June 2015 (UTC)

Actually, the view of the community was not clear. It was a very slight majority that included people who clearly didn't understand what your proposed noticeboard would be for. When proposals fail to gain consensus, especially by narrow margins, it's okay to look at them, check out what people didn't like about them, change them, and try again. We're not violating the will of the people by asking, "Well if you don't want strawberry ice cream, how about this vanilla?" They didn't say "No ice cream!" They said "No strawberry!" Darkfrog24 (talk) 00:26, 3 June 2015 (UTC)

• Where is all this need for a style noticeboard coming from? Is there some evidence that the Help Desk is failing to adequately answer such questions? Because I'm not seeing it myself. SpinningSpark 15:10, 30 May 2015 (UTC)

Um, did you not read any of the above discussion? The need for people to know where to go to ask style questions as they pertain to WP editing has been made clear. So has the fact that Help Desk people themselves say "We don't do this".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:01, 2 June 2015 (UTC)

• Give it up: Honestly, this is a losing battle in so many ways. You are perched in your Ivory Tower and I (your average editor) am out fighting in the trenches. This is the type of article I encounter every day while you are discussing your tedious 'in or out': [12] (B.V.S.Ravi). I didn't even bother to place a clean up tag; my main concern is a BLP / unsourced. I am just laughing at you now! Worrying about style on Wikipedia is like bailing out the flood with a teaspoon. Take on the Gender Gap or something. Sheesh! Fylbecatulous talk 01:26, 31 May 2015 (UTC)

Fylbecatulous, I gather that you don't think things like punctuation and sentence structure are important, but the people asking for help with those issues do. The creation of a style help system would not stop you from fixing articles in ways that interest you more. An article can be properly sourced and properly written at the same time.

To answer the only legitimate question that's been asked, @Spinningspark: the evidence of demand for style help is all the people who show up at WT:MoS asking for style help (which they are technically not supposed to do, hence action #1 on this proposal). What we can infer is that they don't think the Help Desk is the place to go. For myself, I'd say that the Help Desk isn't addressing these needs well. According to Mandruss, in the rare cases when the Help Desk gets a style question, the people there try to answer it even if they don't know the answer. According to my own experience, the Help Desk deals almost exclusively with technical issues, with the nuts and bolts of how to get Wikipedia to do something. The person who hangs out at the Help Desk to answer questions is likely to be knowledgeable about those things but only a few will also be knowledgeable about style matters and Wikipedia's rules on style matters. If I hung out at the Help Desk, I'd see twenty questions that I didn't know how to answer for every one that I did, if not more. Having one dedicated page or some equivalent solution would make it easier for the people who know how to punctuate an appositive to answer questions about punctuating appositives. Darkfrog24 (talk) 17:35, 1 June 2015 (UTC)

Fylbecatulous, that's not a sensible response. It's not very clear that you assume any good faith at all about anyone who often edits at MOS, and you make it crystal clear that you believe they do not work on writing article content, sourcing improvement, or anti-POV-pushing efforts, and are aren't otherwise doing anything important. That's pretty insulting, and easily disproven by simply looking at what else they edit. You're entitled to whatever fantasy you like, I suppose. That doesn't really have anything to do with the question, which is "Since people obviously want somewhere to ask style questions as they pertain to editing Wikipedia, where should they ask them?" The obvious answer to this question, as it would be for any similar question about where to ask how to interpret and apply any other guildeline, is "on the guideline's talk page". This whole thread is pretty moot, since no one needs VPPRO's "permission" to do that or to tell people they're allowed to do that. So, can we please now zip it and get back to editing, without any further finger-pointing and invective?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:01, 2 June 2015 (UTC)

I have striken my last comment. I agree it is over the top and entirely unnecessary to have continued on in the manner I did. I have to sleep at night as do you all, so I apologise for raising the blood pressures of the editors at MoS. I also agree that you are dedicated to your tasks. Fylbecatulous talk 02:29, 2 June 2015 (UTC)

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

Incorrect information

Dear All at Wiki:

Mightn it not be a prudent policy that before a posting is made where factual data might be dubitable, especially in light of changes that the passage of time might bring about, that that posting made available to the 'editing' public prior to that data being posted? Case in point: I opened the page on Nikeri, a town in Suriname, South America. It says there are tensions between Nikeri and neighboring country Guyana. The wiki approved article goes on to say in parenthesis that there has been sporadic fighting between the two neighboring states. There has never been any physical fighting nor talk (intentions) of fighting or any gesture of any disagreement that can be misconstrued as such in the course of the modern histories of the two South American countries.

P. Singh, Guyana

ref: resident of border Guyana-Suriname last 60 years. — Preceding unsigned comment added by Prakash singh ny (talk • contribs) 17:05, 30 May 2015

What you are proposing sounds like pending changes, which we use to allow preview of edits on pages that have been subject to disruption. However, I can't find any mention on Nikeri anywhere so I'm not sure what actual article it is you are talking about. Beeblebrox (talk) 17:19, 30 May 2015 (UTC)

P. Singh appears to be talking about Nickerie District.-gadfium 23:23, 30 May 2015 (UTC)

The sporadic fighting referred to in that article presumably is about the incidents of 1969; as the article says, they were in the south of the country, not in Nickerie District, but this provides background for the scarcity of border crossings. There was an arbitration in 2007 which may have resolved this, but the article's content predates this. See Borders of Suriname#Western border.-gadfium 23:35, 30 May 2015 (UTC)

Dear P. Singh: Wikipedia is the encyclopedia anyone can edit. We rely on volunteers to improve our content. If you can, try to fix the problem yourself. We invite you to create an account too which give you a bunch of extra features. Jason Quinn (talk) 16:39, 8 June 2015 (UTC)

More interactivity

My concern is born out of the fact that I am authoring the Dutch Language wikibook, but it may well be of larger interest. I have left similar massages on both meta and mediawiki, but they seem to get ignored. Wikibooks itself is worse: people seem to be so singularly interested in authoring their own book that there is little discourse between them. Learning a language by just reading a written text is a terrible way to acquire language. So, writing a wikibook easily defaults into writing a grammar that occasionally will be consulted by the odd reader at best. In an electronic age that just won't do and is not necessary either. Computers can very well engage learners in a far more interactive way. One good way is sound files. Fortunately uploading sound files has become less cumbersome and bureaucratic at common than it used to be, but putting them on a page is still overly cumbersome. The smallest button I can put on a page seems to be:

[[file:nl-dit.ogg|noicon|20px]]"dit" which yields

• "dit"

With an unnecessary line feed that screws up all tables. In fact collapsible wikitables for some reason only take a smallish number of these links and then things get out of whack, like in the collapsible table called Vocabulary on the right of this page.

Sound files have been treated as a stepchild far too long, I think. Pretty much all Dutch words have a sound file despite of that being the case.

But using sound files is only one possibility of increasing interactivity. I now find myself making practice sets for external websites like Quizlet of Memrise and send our readers there to practice their vocabulary because the wiki system has nothing comparable to offer. For example Dutch past tenses need to be memorized, so I created this set. But why do I have to send our readers / learners away from the wiki system for that? Wouldn't it be more sensible to start thinking of how to make it more interactive? Granted authoring language books is not what most people do here, but I'm sure there are other potential uses of more interactive software. The wiki system has already transformed the concept of an encyclopedia to a much enhanced level, but it could move much beyond that.

Jcwf (talk) 19:57, 1 June 2015 (UTC)

Looks to me like what you want is more appropriate for Wikiversity than for Wikibooks. Ntsimp (talk) 22:43, 1 June 2015 (UTC)

I am really at a loss why you say that. There are many language books at Wikibooks ranging from German, French to Zulu or Punjabi. And no you do not need to go to a university to learn a language. In most countries learning languages starts long before that and continues long after. The US is perhaps -a rather sad- exception to that. Besides whether what I want is hosted at Wikibooks or Wikiversity is rather irrelevant for the point I made, because Wikiversity will run into the same lack of interactivity in the wikisoftware. But yes the poor interactivity of current wiki software is certainly a handicap for whatever is taught at Wikiversity.

Jcwf (talk) 00:46, 2 June 2015 (UTC)

Jcwf, I didn't suggest Wikiversity because of the subject matter of language, but because of the approach you desire. Since you're dissatisfied with what a textbook can offer, but textbooks are what Wikibooks does, it's not the right project for what you want to do. It may well be that Wikiversity can't technically handle this yet, but at least it would be a more appropriate location than Wikibooks. Ntsimp (talk) 17:28, 4 June 2015 (UTC)

I know nothing about Wikiversity and Wikibooks, but from the titles, this is what I would expect:

• Wikibooks sounds like I'd find books, maybe on-demand printing of material that is non interactive and not primarily oriented toward instruction.
• Wikiversity sounds like I'd find an educational institution, i.e., oriented primarily toward instruction and possibly interactive.

For this reason, it seems like you should look toward wikiversity not wikibooks. The title makes it sound like adult tertiary education, I would fully expect to find secondary school courses like history, biology, algebra and geometry. Primary school topics like penmanship and basic arithmetic would seem a bit less likely because of the name 'wikiversity', but I still think I'd be more likely to look for these things at wikiversity than at wikibooks. YBG (talk) 06:22, 2 June 2015 (UTC)

Well, your expectations are wrong. There is a lot more language text books at wikibooks than at wikiversity. The only one of any real importance is one in Breton. The wikiversity info for Portuguese and German e.g. refer to the wikibook version.

But as I said this is also totally irrelevant to my question and concern of interactivity. Because neither Wikiversity nor Wikibooks nor any other site in the wimimedia universe has that. Jcwf (talk) 06:50, 2 June 2015 (UTC)

Fair enough. My comment was about what I would expect, not about what actually exists. And your point about irrelevance is well taken; I had not thoroughly digested all of your previous reply. You are right in saying that lack of interactivity is not project-specific, but rather just as true at WP as at WV or WB. About all I can come up with is demonstrated over at my talk page. But if you are looking for others to join with you in advocating for more interactivity, it seems to me you'd find more support over at wikiversity than you found at wikibooks. Interactivity provides more benefit to courseware designers than to book authors or encyclopedia contributors. And that interactivity should be helpful in all topic areas, not just in language learning, so the relative lack of language materials at WV shouldn't deter you from trying over there. But even in the best imaginable outcome, it would probably take a long time for significant interactive features to get implemented. Best wishes! YBG (talk) 08:04, 2 June 2015 (UTC)

Have you checked out Template:Listen and template:multi-listen start? Rmhermen (talk) 16:18, 2 June 2015 (UTC)

Yes, Rmhermen, I have. In dismay. They remind me of this old and cruel joke about the GDR priding itself on having biggest transitors and computer chips... Sorry to get sassy, but they are perfect example of how outdated, quaint and obsolete wikimedia software really is. Both of those templates are GINORMOUS. If you have a hunderd words on a page that you want the reader to be able to hear they are totally, absolutely useless.

Actually they are bigger than my ginormous statement. Far bigger, bulkier an unwieldier. Real dinosaurs. Jcwf (talk) 19:56, 2 June 2015 (UTC)

How 'bout {{audio}} then? Isn't that exactly what you need? And if it's still too unwieldy, is there anything preventing you from modifying that template slightly so it only contains the parts needed for your purposes?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 5, 2015; 14:44 (UTC)

• @Ntsimp:If you look above you'll see a possible solution - little javascript apps that can be embedded in an article, now in use at Spanish wikipedia. Something like this might be what you need? Oiyarbepsy (talk) 20:03, 2 June 2015 (UTC)
• Two suggestions for you: Please add this to m:Community Tech project ideas. Also, look at the number eins (one) at wikivoyage:German phrasebook#Numbers, to see if that sort of idea might work for you. (It was mostly lifted from Wiktionary, and I don't know if it works in every browser. You'll get the best results from clicking on the pseudophoneticization, not the speaker icon.) Whatamidoing (WMF) (talk) 13:59, 3 June 2015 (UTC)
  • No!No!No! That abducts people to some black screen away from the written text that I am trying to get them to read. UTTERLY USELESS.

Jcwf (talk) 23:10, 9 June 2015 (UTC)