Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Turn off extended edit summaries

Today the edit summary limit was extended from 250ish to 1000. Apparently this was a request from dewiki on the Community Wishlist. See phab:T6714 for one of the many phab requests about it. This is a prime example of the potential problems with this. It will do nothing more than cause massive disruption in the histories of numerous pages. For that reason I'm putting this to the community.

Should enwiki request that the old edit summary limit be put back on this project? --Majora (talk) 23:51, 1 March 2018 (UTC)

Survey

• Support as proposer --Majora (talk) 23:51, 1 March 2018 (UTC)
• Support. Yes, please turn it off. --SmokeyJoe (talk) 23:55, 1 March 2018 (UTC) Maybe not turn it off, but make it adjustable by the user.
• Support somebody must not have thought this change through. Lepricavark (talk) 23:59, 1 March 2018 (UTC)
• Support per...do I really need this part? But I'll add a comment in Discussion. ―Mandruss ☎ 00:08, 2 March 2018 (UTC)
• Support but it would be nice if the limit applied only to characters that actually display in watchlists, rather than the source of the edit summary. When you're adding extra text to an auto-generated summary that includes pipes, you can run out of space pretty fast. Whether that's technically feasible I wouldn't know. --Trovatore (talk) 00:27, 2 March 2018 (UTC)
• Support 1000 is too much; if the limit is tuneable I wouldn't be opposed to something around the 400-500 range due to IPv6-related concerns. power~enwiki (π, ν) 00:48, 2 March 2018 (UTC)

  @Power~enwiki: The proposal above that you're supporting is to reduce it back to 255 characters, so your vote should actually be "oppose". -- intgr [talk] 10:24, 2 March 2018 (UTC)

• Support: You don't need 1,000 characters for an edit summary. 255 is sufficient. — MRD2014 ^Talk 01:37, 2 March 2018 (UTC)
• Support: The old limit was sufficient. It was also useful. Very occasionally the situation seems to require a summary longer than the normal 5 or 6 words. On these occasions the limit prevented me from using an over-long summary by "forcing" me to pare it down to something appropriately concise. If there is still a need to say more I should be using the summary to point to a talk page discussion. Summaries should be concise and not bloat the history/watchlist entries. -- Begoon 02:45, 2 March 2018 (UTC)

Noting I'd also be happy with Legoktm's solution. -- Begoon 09:33, 2 March 2018 (UTC)

• Support Don't solve something that was never a problem.--v/r - TP 02:46, 2 March 2018 (UTC)
• Support TonyBallioni (talk) 02:48, 2 March 2018 (UTC)
• Support If you can't say it in 255 characters you should be pointing to a talk page. However, sometimes the preloaded stuff doesn't leave you enough space. Britmax (talk) 12:02, 2 March 2018 (UTC)
• I prefer edit summaries longer than 255 character being available; often with section edits, a lot of space is taken up by the section heading, and when reverting edits from IPv6 editors, a lot of space is taken up by the boilerplate text. (I appreciate some suggest deleting this text to make room; I prefer keeping the standard text as an aid to those who are accustomed to it, and adding a brief summary afterwards.) A lower limit than 1000 would probably be suitable, though. isaacl (talk) 03:19, 2 March 2018 (UTC)
• Oppose. Between unicode characters and IPv6 it's clearly a net improvement. The diffs provided indicate that the auto-summaries need tweaking to not include the full length of what was written. Something like "cut at the end of the first sentence" would solve this easily. FACE WITH TEARS OF JOY ^[u+1F602] 03:49, 2 March 2018 (UTC)
  • These aren't autosummaries. That's the problem. Some people are used to copying their entire comment into the edit summary on the assumption that it gets cut off. TonyBallioni (talk) 03:54, 2 March 2018 (UTC)
    • Ah gotcha, understood. Still: I think a few examples from before people were aware of the new behavior are not a big deal. People adapt when their environment changes :) FACE WITH TEARS OF JOY ^[u+1F602] 03:58, 2 March 2018 (UTC)
      • A "few" in the span of a few hours being turned on will turn into a massive mess as time goes on. These are, for all intents and purposes, permanent in page histories. While temporary, they also completely disrupt watchlists. This is nonsensical. I can understand that the Germans wanted this, you can have some crazy long sentences in German, but we didn't ask for this. We didn't ask for a 1,000 byte limit. --Majora (talk) 04:01, 2 March 2018 (UTC)
        • This is *NOT* a request just from the German community. If you look at phab:T6714 it goes all the way back to 2006! Even English Wikipedians wanted (and still want this). Legoktm (talk) 04:08, 2 March 2018 (UTC)
        • (ec) This has nothing to do with Germans, really...plenty of folks have commented on these tasks over quite a few years (including some enwiki users). Issues with poor display on watchlists and so forth can be cleaned up as time goes on (like a "expand full summary ->" link?). Nothing is perfect the first time, and I think the underlying change will ultimately be beneficial to folks. FACE WITH TEARS OF JOY ^[u+1F602] 04:12, 2 March 2018 (UTC)
• Support We're barraged with text everywhere else, this is one place to the point writing is enforced. -- GreenC 03:51, 2 March 2018 (UTC)
• Oppose There are plenty of places where the old limit was entirely problematic. Protection logs getting trimmed, rollbacks having broken links, and so on. Maybe we need a better way of displaying these, but lets not throw the baby out with the bathwater here. Legoktm (talk) 03:53, 2 March 2018 (UTC)

• I'd agree with you for log entries and the like. Is there a way to adjust a setting locally so we can limit user generated edit summaries specifically? Killiondude (talk) 03:58, 2 March 2018 (UTC)

  No, that's not really a setting. It's still a problem when you undo an IPv6 user's (or someone with a longer username) edit and want to leave a rationale after it though. I put a proposal in the discussion section about how we could do truncation without losing the benefits of this change which I hope is a workable compromise. Legoktm (talk) 04:06, 2 March 2018 (UTC)

• Oppose in favour of Legoktm/😂's proposal (see below), which is to truncate the display and add a clickable "..." (or similar) to reveal the rest of the summary. For this see phab:T6717. I don't know how long this would take to implement, but it's only JavaScript, so it can't be that hard. Worse comes to worse we can implement something ourselves here, but my bet is other Latin wikis will want the same. I wouldn't stress over it. A solution will be found. — MusikAnimal ^talk 04:27, 2 March 2018 (UTC)
• Oppose cutting the limit back down - my god I'm glad that when reverting an IP edit, the entire span isn't taken up any more with monster-IPv6 user name + link to said monster-IPv6 talk page! Having a higher character limit is entirely welcome from my point of view. Implementing some dynamic truncation with option to reveal more content, as discussed below, might be a good option though. --Elmidae (talk · contribs) 06:58, 2 March 2018 (UTC)
• Oppose cutting back to 255 per Legoktm, Elmidae et al. 1000 may be beyond reasonable needs, I prefer a reasonable number plus section name or username/talk page automatically generated content etc. Old length was often too short to put in a useful comment on top of the automatic stuff. A warning should come up when exceeding 255 characters and additional text could go on a highlighted background, or one could click to extend the summary box by say 255 characters at a time, yellow highlighting the first time, then orange, then red.· · · Peter (Southwood) ^(talk): 08:40, 2 March 2018 (UTC)
• Oppose Long edit summaries can be truncated, per the above suggestion. Need to do something with IPv6 addresses as they may cause problems with being able to write a full comment. !dave 08:56, 2 March 2018 (UTC)
• Oppose per above. Benefits clearly outweigh the drawbacks. Broken links in rollback summaries or log entries are confusing even to experienced users. -FASTILY 09:20, 2 March 2018 (UTC)
• Oppose 255 characters is not enough for a summary when reverting a long IPv6 address edit. It doesn't need to be 1000 chars either though, maybe somethig in between. -- intgr [talk] 10:24, 2 March 2018 (UTC)
• Oppose. Firstly, the opening statement in this RfC has obviously incorrect statements in it. This is not the result of "a request from dewiki", it was the #2 item from the 2016 Community Wishlist, and in fact had many users from the English Wikipedia voting in support of it. Secondly, the opening statement fails to actually describe the damage that is being caused by these longer edit summaries, other than that page histories can now be longer due to the longer edit summaries, which is merely different and is not actually damaging. Continued change aversion serves nobody. Let's wait and see how it works out, rather than rushing to turn the new things off simply because they're new. --Deskana (talk) 10:54, 2 March 2018 (UTC)
  • Comment: this was maybe the intent of developers, but it has no relation to #2 item from the 2016 Community Wishlist. We asked for 255 Cyrillic and other non-Latin symbols to be treated as 255 ASCII symbols, we got 7x increase in edit summary length. stjn^[ru] 11:14, 2 March 2018 (UTC)
• Oppose — Although, 1,000 characters may be more than one wants, 255 characters are in no shape or form enough. Also, per rationale provided by Deskana (talk · contribs) and 😂 (talk · contribs). No prejudice towards making the limit a bit reasonable — to say, 500-600 characters — though.
  Regards, SshibumXZ (Talk) (Contributions). 11:09, 2 March 2018 (UTC)
• Oppose. I occasionally have to deal with copyright violations from multiple URLs and I find 255 characters goes pretty quickly. I support Legotm's solution. I'd also try to change editor behavior, but that's hard. MER-C 11:23, 2 March 2018 (UTC)
• Oppose - looks like a useful change, having to shorten edit summaries to fit under the previous limit has been annoying on occasion. Thanks. Mike Peel (talk) 11:26, 2 March 2018 (UTC)
• Cut the baby and make it 300-400 per SshibumXZ. Not too disruptive, not too limiting for long section headers. ~ Amory (u • t • c) 11:30, 2 March 2018 (UTC)

  Just to add, it's not clear to me why this happened. The "#2 on the request list" argument pretty clearly supports our Russian friend here that the request was for 255 characters. I get that with some characters taking 3 bytes, a byte limit of 750-1000 was likely the easiest solution, but it does seem to be counter to what was actually proposed and supported. ~ Amory (u • t • c) 15:37, 2 March 2018 (UTC)

• Oppose. There's a common pattern here. WMF does something that improves experience for a substantial part of the movement (in this case, non-Latin-character-using projects). Someone notices this has a marginal impact on their personal experience. That person goes "OMG THIS IS AWFUL WHY WAS I NOT CONSULTED" and starts some kind of demand for the WMF to undo what they've just done. Then there is an unproductive conversation about whether this change is a good or bad idea, usually started without reference to the WMF's rationale for doing something in the first place, and with an unrealistic insistence that the WMF only do things when they have crafted something that works in an ideal way for everyone who might possibly have an opinion on the matter. Looking at the cost-benefit, I am quite happy to have longer edit summaries and more cluttered edit histories here, if that means the Russian Wikipedia and others can have edit summaries at a reasonable length. But maybe we should also look at the cost-benefit of the number of RFCs we seem to have saying "WMF please undo whatever it is you've just done", as well... The Land (talk) 11:43, 2 March 2018 (UTC)

  No opinion on your general point, but it's not hard to see how this, multiplied many times, will be a serious disruption, far from a marginal impact on personal experience. You can tell folks not to do that until you're blue in the face and many will do it anyway, either because they are unaware of your guidance or because they don't care about silly old guidance. It's clear that something needs to change, the question under discussion is what. ―Mandruss ☎ 11:52, 2 March 2018 (UTC)

  @The Land: Improving experience of Russian Wikipedia and other communities was not intent of this change. This was a complete decision mystery from WMF, we and others were asking only for increasing 255 bytes to 255 symbols across the Wikimedia projects, what we got is the same 1000 characters out-of-nowhere as you do. We are frankly as surprised about this change as your community is. stjn^[ru] 11:55, 2 March 2018 (UTC)

  Well it's pretty clear that this is the WMF's chosen method of implementing that request. I'm not claiming it's a perfect implementation, but then, the reality is that the WMF does not have the tech resources to do everything perfectly. The Land (talk) 20:54, 2 March 2018 (UTC)

  There's very little mystery, the goal was to increase the edit summary length, very specifically to accommodate Russian and other non-latin langages, seemeta:Community Tech/Edit summary length for non-Latin languages in particular. Headbomb {t · c · p · b} 01:01, 3 March 2018 (UTC)

  The specific wording of the proposal is as follows: Should enwiki request that the old edit summary limit be put back on this project? This proposal is for our project and does not impact the Russian Wikipedia at all. Given that you only edit here very rarely, and apparently don't even have enough time to actually read the proposal before !voting, you should not be so dismissive of the opinions of those who are actively contributing to the encyclopedia. This change may not affect you, but it most certainly does affect us. Lepricavark (talk) 19:35, 2 March 2018 (UTC)

  lol, once you've been contributing to the Wikimedia movement for 14 years, then come back and tell me I don't understand Wikipedia! The Land (talk) 20:54, 2 March 2018 (UTC)

  I never said you don't understand Wikipedia. I said you didn't understand this proposal. But hey, you've been around longer than I have (with far fewer edits), so you must be right! Lepricavark (talk) 22:58, 2 March 2018 (UTC)

• Oppose. If there is an actual problem here (and I'm struggling to see one), then the way to solve it is to get consensus for a local guideline about edit summary length and educate people about it. Thryduulf (talk) 11:48, 2 March 2018 (UTC)
• Support Allowing scope to place long diatribes in edit summaries (whether displayed or not) will hasten the demise of the talk page. We do, however, need to shorten lengthy auto summaries like "Undid revision ***** by *****": Noyster (talk), 11:54, 2 March 2018 (UTC)
• Oppose per Thryduulf and The Land, but it would definitely be useful to have some way to truncate the display of long summaries. ​—DoRD (talk)​ 12:50, 2 March 2018 (UTC)
• Oppose I have no problem with the new edit summary length. If people are using it to be disruptive, then deal with that on its own. --Jayron32 13:28, 2 March 2018 (UTC)

  Do we not have enough disruption to deal with on its own without creating new opportunities for it? There are already alternative solutions on the table that do not. ―Mandruss ☎ 13:32, 2 March 2018 (UTC)

All communication is not disruptive. Edit summary space has eminently constructive uses. Bus stop (talk) 12:48, 10 March 2018 (UTC)

• Oppose clearly a net improvement for the community per The Land, Sadads (talk) 14:58, 2 March 2018 (UTC)
• Oppose clearly this is a net improvement. However, I very much support a 255 displayed-character "soft" truncation with a clickable [...] to expand to the full summary. Or any other reasonable limit to displayed character if 255 is deemed too much.Headbomb {t · c · p · b} 15:05, 2 March 2018 (UTC)
• support This is not an improvement and just invites people to write yet more things that they cannot redact or edit. And no I do not want my watchlist crammed with overlong rants. And as noted above. people already treat edit notes like tweets (some history pages look like my twitter feed with fake dialogue) and longer edit notes will only encourage that, and the edit warring that goes on underneath it. Dramatic changes like this to user experience should have a prior RfC in any case. Jytdog (talk) 15:27, 2 March 2018 (UTC)
  • As this day has gone on my watchlist has become an un-useable jumble of clutter. Jytdog (talk) 20:03, 2 March 2018 (UTC)
• Oppose There are often times I have to shorten or remove details in an edit summary just fit it in the limit. Would rather be able to explain things without being limited. I would be fine with a lower limit if the character limit was limited to only displayed characters, as often wikilinks(to ip/user+talk) can take up a significant portion when reverting. Other cases are when I want to link to a talk page discussion with section, but there isn't enough space to link it and give a detailed edit summary, and you are forced to just simply say see this linked discussion with short summary, or give more detailed summary and refer them to go to talk page, where they have to find discussion on their own there or in archives. If there seems to be a high level of abuse/disruptions, limiting it to extended confirmed users could be an option. WikiVirusC^(talk) 15:37, 2 March 2018 (UTC)
• Oppose grandstanding tends to be a bad look for people --Guerillero | Parlez Moi 15:54, 2 March 2018 (UTC)
• Support Overly long edit summaries clutter the history page, watchlist, and are unnecessary. If the argument is for IPv6 addresses, extend it to 300 characters. If you need more than that, use the talk page. Natureium (talk) 16:48, 2 March 2018 (UTC)
• Oppose – large edit summaries would likely indicate a bigger issue or problem being dealt with, something that should probably attract more attention. If I see a huge edit summary on my watchlist, I will likely pay more attention to that edit. This feature may also encourage editors to speak to each other more, right on the front lines where editing is taking place. Better communication leads to better results. A well-explained edit is less likely to be reverted. A big problem we are likely to face with this feature is spamming, and so there will be an inevitable increase in deletions of entries from edit histories. Hopefully we have enough people available with the right tools to handle the shift in problems that this feature will create. Not more or bigger problems, necessarily, but different ones. And of course, we will need new guidelines for edit summaries. Like not repeating huge summaries for multiple edits on the same page. Posting the explanation once should suffice. Huge edit summaries for mass edits over many pages should also be discouraged, with a preference for a pointer to a notice on a talk page, rather than such a notice being repeated over and over in watchlists. The biggest outcry will likely be from editors monitoring things via watchlists. It will be interesting to see how the community adapts this new feature into its culture, and I am confident that it will. Let's try this new feature out for awhile and see how it goes.     — The Transhumanist    17:09, 2 March 2018 (UTC)
• Oppose Longer edit summaries are useful. We should have a way to truncate. I also endorse Legoktm's comment: when there's a feature change, we should try not to just shout "turn it off!" but talk to the developers calmly about how the change affects us so it can be improved. A bit more "Yes, and..." and a bit less blow it up and start over. —Tom Morris (talk) 17:27, 2 March 2018 (UTC)
• Partial oppose: 1000 is overkill for legitimate usage. I'd recommend 512 with an option for truncation in the view, and that a filter be implemented for overly long edit summaries so that they may be monitored for abuse. ViperSnake151  Talk  17:31, 2 March 2018 (UTC)
• Oppose. Smallchief (talk) 17:35, 2 March 2018 (UTC)
• Support per Jytdog and Noyster - perhaps till 400 char but not more than that really Galobtter (pingó mió) 17:39, 2 March 2018 (UTC)
• Oppose, per Unicode, IPv6, etc. There should probably be a watchlist option to only show the first n characters, though. Support Lego's solution now that I've actually found it. --SarekOfVulcan (talk) 17:41, 2 March 2018 (UTC)
• Oppose does not matter. Alanscottwalker (talk) 17:49, 2 March 2018 (UTC)

What does this mean? Are you just voting without a reason to vote? — Preceding unsigned comment added by Natureium (talk • contribs)

Explanation: We call that a !!vote—pronounced not-not-vote—aka vote. ―Mandruss ☎ 19:13, 2 March 2018 (UTC)

Was I unclear, sorry -- the objections are silly (too much space! we don't want to read! I can't handle change! Other people will act bad!, I was not consulted! People play! etc.) and the expansion of space is fine. Alanscottwalker (talk) 19:18, 2 March 2018 (UTC)

No, objections include opening up abuse of watchlists, obfuscating issues that would normally be picked up, making admins and those who try to detect vandalism lives' more difficult. But hey. The Rambling Man (talk) 20:42, 2 March 2018 (UTC)

Come on, now. Apart from those trying to make a rhetorical, uhm, point, there has not even been a breakout of all these suppossed "problems" in this very discussion. Alanscottwalker (talk) 16:30, 3 March 2018 (UTC)

• Support - What plank actually thought this was a great idea ? ....., 250(ish) was absolutely fine ..... Bumping it up to 1000 means more dumbass edit summaries like mine[1] (Text copied from Jesus)(Diff), If you want to post longer comments then use the bloody talkpage, I'm all for change and improvement but this improves nothing (if anything it gives trolls/vandals more opportunity to clog up my entire watchlist!). –Davey2010^Talk 19:37, 2 March 2018 (UTC)(Added attribution at 22:32, 5 March 2018 (UTC))

I feel I should add I didn't abuse the feature for the fun of it - I abused it to show how easy it is for it too be abused, I don't in any way, shape or form condone anyone following suit and I would hope for this specific case my edit summary isn't revdelled, Thanks, –Davey2010^Talk 20:35, 2 March 2018 (UTC).

Davey2010, I've revdel'd your edit summary since it was copied without attribution and is thus a violation of policy. Primefac (talk) 18:47, 5 March 2018 (UTC) (please ping on reply)

• Support they are edit summaries, made specifically to include in a brief way the changes made. I’d be happy with a small increase, but as demonstrated this has major potential for abuse. In a rare occasion there’s not enough room, use the talk page to explain, where character usage is unlimited. Aiken D 19:43, 2 March 2018 (UTC)
• Oppose: It's preferable to be able to paste the full url of the source for a copyvio edit removal into my edit summary, but sometimes with the old limit I have run out of space, particularly when I want to remove from multiple sources in one edit. See for example today's work at 2017 Mumbai stampede, where it was possible to include full urls and get the work done quicker in fewer edits while still leaving a good audit trail. Running out of space means I have to perform more edits to do the same amount of work (which is slower and also clutters up watch-lists), or leave a cut-off url (which makes later review of what I did difficult to impossible). 500 characters is prolly enough for 3-4 urls though. — Diannaa 🍁 (talk) 19:47, 2 March 2018 (UTC)
• Support (a) if you can't _summarise_ your edit in 200 characters, something's wrong and (b) this is perfect for vandals to flood watchlists. Mine is already overwhelmed by people just trying it out. It's a joke and completely unnecessary. Just because Twitter doubled up, it doesn't mean we need this crap in our lives. REMOVE, allow me to demonstrate. Minor change. Another minor change. The Rambling Man (talk) 20:18, 2 March 2018 (UTC)

  Now then, hopefully no-one will block me, but the point is, now look at the edit history and try to work out what I did. This is a complete joke, a failure, a fad that needs checking. Perhaps those who are opposing this restriction in characters don't do a lot of work behind the scenes where quickly assimilating information from an edit summary is essential. Not to mention how easy it's going to be to destroy the ability to easily parse ones' watchlists. REMOVE. The Rambling Man (talk) 20:21, 2 March 2018 (UTC)

  Revdeled the second two as disruptive. Once was more than enough. --SarekOfVulcan (talk) 20:24, 2 March 2018 (UTC)

  That's bollocks. You're deliberately obfuscating the issue. We need to see what two or three edit summaries of this type look like back to back. But you've hidden it now. The Rambling Man (talk) 20:27, 2 March 2018 (UTC)

  If you want that iridiscent's talk history has enough of that Galobtter (pingó mió) 20:31, 2 March 2018 (UTC)

  Not at all, TRM. They have helpfully demonstrated the extra workload this will add for already-overworked admins. ―Mandruss ☎ 20:32, 2 March 2018 (UTC)

  It's not just admins, the rest of us who care about the integrity of Wikipedia are now concerned that we can't work out what the fuck people are doing. The Rambling Man (talk) 20:35, 2 March 2018 (UTC)

  That too. Don't worry, if this sticks it won't stick for long. Many of those !voting Oppose will be at the head of the line complaining about it, mark my words. ―Mandruss ☎ 20:37, 2 March 2018 (UTC)

• Support turning it off. Yes, there are some potential benefits; yes, they're hugely outweighed by the disruption watchlist-flooding will cause. ‑ Iridescent 20:23, 2 March 2018 (UTC)

  So, because you don't want people being abusive with the new edit summaries, you used it abusively. If you didn't want them to be used that way, maybe you shouldn't have. --Jayron32 20:26, 2 March 2018 (UTC)

  Um, to demonstrate the problem, which is perfectly reasonable. Bonkers. The Rambling Man (talk) 20:40, 2 March 2018 (UTC)

  (edit conflict)If you want to demonstrate the problem, do it in your own sandbox and link to it, not a major discussion venue. --SarekOfVulcan (talk) 20:44, 2 March 2018 (UTC)

  I think the point is that this disruption can and will be caused on ANY WIKIPEDIA PAGE that's not fully protected. Demonstrating it in a sandbox is great, but it misses the salient point, which you are working so hard to obfuscate. Noted. The Rambling Man (talk) 20:47, 2 March 2018 (UTC)

  WP:POINT+WP:IAR. ―Mandruss ☎ 20:43, 2 March 2018 (UTC)

  ... = WP:lulz. Kurtis ^(talk) 09:35, 9 March 2018 (UTC)

• Oppose - While I agree that 1000 is too many quite often 255 was not enough. A compromise at 500 would be useful. BTW as I see it the real problem is those editors who copy paste their post into the edit summary line. Perhaps they could learn to type something that is a brief description summing up what they posted. MarnetteD|Talk 20:35, 2 March 2018 (UTC)
• Support - Progress is great, and I think 1000, or even 10,000 character edit summaries might be OK, but only if their display is truncated by default. This should have been submitted to the community for discussion before being phabricated into our workflow. It has the potential to be quite disruptive unless implemented with finesse.- MrX 🖋 20:57, 2 March 2018 (UTC)
• Support It's a summary. It's supposed to be brief. Learn to be brief. PaleCloudedWhite (talk) 21:00, 2 March 2018 (UTC)
• Comment it's ironic that an admin has deemed two of my lengthy edit summaries to be so disruptive that they need to be rev-del'ed, and I was simply demonstrating the problem. So once the general population of vandals get to know this, how much time is going to be spent rev-del'ing such "disruptive" summaries? Although the principle I was demonstrating has been incorrectly obfuscated by this admin, it proves another very important point in favour of returning to shorter summaries. The Rambling Man (talk) 21:05, 2 March 2018 (UTC)

  Here is a great example of what this admin was trying to hide from you all. The Rambling Man (talk) 21:23, 2 March 2018 (UTC)

• Support Long summaries discourage talk page discussion and, thus, interferes with dispute resolution. All main forms of dispute resolution — Third Opinion, Dispute Resolution Noticeboard, and Formal Mediation — have a prerequisite that they will not accept a case which has not had substantial talk page discussion and that they will not consider edit summaries in determining whether that discussion has occurred. Long edit summaries will cause more cases to be declined. — TransporterMan (TALK) 21:27, 2 March 2018 (UTC)
  • I think MedCom does a fine enough job rejecting cases on its own anyway ;-) FACE WITH TEARS OF JOY ^[u+1F602] 21:54, 2 March 2018 (UTC)
• Oppose I think there's a real need for a longer edit summary field. That said, it is easy to imagine that problems can occur if people accidentally post a long edit summary. Can that be handled with an edit filter which would warn an editor that there edit summary exceeded say, 500 characters, and give them a chance to edit?--S Philbrick(Talk) 21:47, 2 March 2018 (UTC)
• Oppose I don't see the examples cited as disruptive. They are on an order or magnitude less problematic than walls of text I see on discussion pages. Cas Liber (talk · contribs) 23:41, 2 March 2018 (UTC)

But that's what talk pages are for. The edit summary is meant to be a quick summary of what change you made. Natureium (talk) 23:43, 2 March 2018 (UTC)

• Support 1000 is too much, even for IPv6 and things like that, noone needs more than 500 signs in any case. Furthermore, I don't think making the summaries much longer isn't what's needed here, but making the autogenerated parts of the summary machine-readable is. This solves the problem without causing this mess, and is a way better solution in general, as it is localizable as well. --MGChecker (talk) 00:02, 3 March 2018 (UTC)
• Oppose (tho I support legotm's suggestion) --Terra ^(talk) 00:15, 3 March 2018 (UTC)
• Support - it was a terrible idea in the first place, and has done nothing but harm from the beginning. --Orange Mike | Talk 00:42, 3 March 2018 (UTC)
• Oppose Nobody needs to use an edit summary at all, but any number of characters is an arbitrary limit. Why not err on the high side? — Malik Shabazz ^Talk/_Stalk 02:16, 3 March 2018 (UTC)
• Oppose. We'll get used to it soon enough. – Joe (talk) 03:00, 3 March 2018 (UTC)
• Oppose There is no evidence yet of real trouble. Remember admins can hide edit summaries if there are serious problems (eg this is now big enough for copyvio, and not just for outing and harrassment). We also have the option of edit filters if you want to get a handle on stupid things happening. Graeme Bartlett (talk) 03:19, 3 March 2018 (UTC)
• Oppose in light of alternative solutions, such as truncation. My main concern with lengthy edit summaries is that it might enable more editors to "discuss" things via the edit summary, which invites more edit warring behavior. However, I also think reverting all the way back to the previous limit is an oversimplified solution. More space in the edit summary in general is an improvement, especially considering how internal links and IPv6 addresses can sometimes clog it up. Mz7 (talk) 03:39, 3 March 2018 (UTC)
• Support 1000 is too many. ~Awilley (talk) 04:31, 3 March 2018 (UTC)
• Support 1000 is too many, and as someone else said: 'If you can't say it in 255 characters you should be pointing to a talk page'. Edit summaries are supposed to be just that: an edit summary. Turning edit summaries into yet another form of dialog is nonsense. In my experience, ES are hardly ever read anyway (due the number of clicks needed to get to them). Many less experienced users probably still don't even know what an ES is. Kudpung กุดผึ้ง (talk) 05:23, 3 March 2018 (UTC)
• Oppose per MarnetteD. Double sharp (talk) 05:42, 3 March 2018 (UTC)
• Oppose – The previous edit summaries limit was too restrictive, in my opinion. I do like the idea of having particularly long edit summaries auto-collapse, though. Master of Time (talk) 06:28, 3 March 2018 (UTC)
• Strong Oppose - Say, for example, one wants to link to this discussion in an edit summary. Wikipedia:Village pump (proposals)#Turn off extended edit summaries takes up 71 characters, but with piping it may only display as a few, e.g. "see here". This change is extremely beneficial both for those who like to provide links to specific policies and guidelines that are being implemented within their edits and due to the fact that section headings without shortcut(s) (or those with only obscure, unknown ones) can take up a lot of space. Sure, some will leave 1000 displayed character edit summaries, but the benefit outweighs what is a small downside. If people are being foolish with edit summaries, leave them a kind note; if people are abusing edit summaries, leave them a warning. I can envision even a 1000 displayed character edit summary that is purely descriptive of a large copyedit; in other words, something due within an edit summary that would not be necessary or appropriate for a talk page. — Godsy ^(TALK_CONT) 08:41, 3 March 2018 (UTC)
• Support 1000 characters is far too long- if you need that much detail on an edit/revert, then there's a talkpage for that (as others have highlighted). Maybe 1000 characters is needed in German where individual words are much longer, but here on English wiki it's ridiculously excessive. Joseph2302 (talk) 11:28, 3 March 2018 (UTC)
• Oppose 1000 is too long but 250 is too short. 500 would be nice. Or make it so only EC30/500 can use the full mount, nonEC and IPs have to stick with 250. L3X1 ◊distænt write◊ 12:28, 3 March 2018 (UTC)
• Support I do not see the need to replace the talkpage by an edit summary The Banner talk 13:04, 3 March 2018 (UTC)
• Oppose: 500 characters for experinced editors is enough, IP/newbies should be stuck with 250. KGirl ^{(Wanna chat?)} 15:46, 3 March 2018 (UTC)
• Oppose I sometimes want more than 250. Agree it was too short before. Doc James (talk · contribs · email) 16:25, 3 March 2018 (UTC)
• Support The community wishlist proposal was intended to benefit users of non-English languages who could only use about 30% of the available space because each of their text characters counted as 2-4 as compared to English. I do not remember the proposal being about a demand to make more text possible for English writing, or for writing in any language being longer than the equivalent amount of text and information as compared to English. The proposer highlighted what to me is obviously a major problem - the change has broken the status quo of English Wikipedia edit logs and this major disruptive change has happened without discussion. The solution is to put things back to the way they were before then start a conversation about the extent to which we should change the status quo. Many of the oppose votes here are out of order, because when anyone makes a major change to user experience in wiki and there is not community consensus for that, the start of the discussion is status quo, and not claiming to negotiate with the change as the new way and negotiating back to the established norm from that. WP:BRD applies here - the change was bold but challenged so now we revert and discuss from there. I agree that we need the ability to post links in the edit summary but exposing human readers to long URLs should never be allowed anyway. Expanding the edit summary for the sake of making humans read computer code in the edit summary is not a solution. Blue Rasberry (talk) 16:27, 3 March 2018 (UTC)

Actually, no. By policy software changes fall outside BRD. Alanscottwalker (talk) 16:53, 3 March 2018 (UTC)

@Alanscottwalker: Yes, in usual cases project wide software changes are not subject to BRD. I still claim that it applies in this case because WMF decisions beyond community review are valid when they make some attempt to acknowledge major problems which they would cause. The problematic outcome we are experiencing was never a consideration so reverting and talking it thought is more reasonable than alternatives. Obviously someone would have raised the issue if anyone imagined it; no one did. This problem is an oversight and not intentional. Also this action was supposed to benefit the community at the community's own request. The community has stake in the outcome of its own requests so enforcing this experimental new way of doing things is not an urgent indisputable need. Blue Rasberry (talk) 15:13, 4 March 2018 (UTC)

Urgent, what? It's clear the "community" went to the devs and said we do not like this arbitrary limit, so they, wholly within our policy, changed it to another arbitrary limit -- now, another part of the community is saying we like the old arbitrary limit and yet another part of the community is saying, the old arbitrary limit sucked, but there is and remains a limit. The arguments against the new limit all center around 'people act in bad faith' (which is generally not in fact, the case, and we, at any rate assume that it's not) or the peculiar case of the few who regularly pasted their entire comments instead of ever providing a summary (which, if that bothers the community, the community knows how to regulate, or practice will just change - or the community will just ignore it and go on) -- either way, as years of practice has seen (and common sense and human nature would expect), almost all people do not want to write more than they have to (which is a much greater controller than any arbitrary limit) -- as seen, if they write edits summaries, at all, they have either done a short summary or a very few have pasted what they already wrote. Alanscottwalker (talk) 16:00, 4 March 2018 (UTC)

The arguments against the new limit all center around 'people act in bad faith'... Simply not true. Poor judgment is not bad faith, and there is no WP:AGJ. ―Mandruss ☎ 16:04, 4 March 2018 (UTC)

So, we should now assume you have bad judgement, is your argument, or you oddly claim to know how to rescue people from their bad judgement. But no, the arguments are, people will abuse (bad faith) people will vandalize (bad faith) people can't control themselves (bad faith) -- they all center around bad faith - as for the people who can't improve their judgment to community standards, there have always been some, and the remedies for that have not changed, one iota. Alanscottwalker (talk) 16:15, 4 March 2018 (UTC)

So, we should now assume you have bad judgement, is your argument. Simply not true. You should not assume I have bad judgment, nor should you assume I have good judgment. Regardless, the AGF concept applies to how we regard each other individually; it does not mean that we have to apply a general "people are good" worldview in decisions like this. To whatever extent the Support arguments do consider that bad faith exists (far less than all, which is what you hyperbolically stated), I think we need to live in the environment that exists, not the environment that we wish existed. Anybody who says bad faith is too rare to factor into this decision needs to extract their head out of the sand. ―Mandruss ☎ 16:29, 4 March 2018 (UTC)

Get your head out of the sand of the imaginary world where you pretend to protect people from their bad judgment, (Wikipedia has a whole ethos on not doing that, called ROPE). No, there is actually no reason why half the people discussing here, should defer to your judgement. AGF is not a 'rule of social space' because it's imaginary, it's actually because people 'try to do the right thing' -- if people did not try to do the right thing, Wikipedia cannot exist. -- Alanscottwalker (talk) 16:49, 4 March 2018 (UTC)

• Support. Discussion is for talk pages; edit summaries need only contain a very brief summary of what the edit does. If other languages need more space, then limit this change to the wikis in those languages. Kablammo (talk) 17:11, 3 March 2018 (UTC)
• Support. Unlike projects with non-Latin writing, we have no need for so many characters in general; a 1000-Latin-character summary causes problems because of its length (it's 2/3 long enough for a WP:DYK article!), and it's virtually never necessary. I understand that there can be exceptions, but people like Doc James can use the gadget that expands the maximum length of the edit summary. Nyttend (talk) 20:27, 3 March 2018 (UTC)
• Support per this edit summary. Unless rules are developed to punish prevent abuse and only specific needs for overrun are allowed, longer edit summaries are bad for the project. Chris Troutman (talk) 21:56, 3 March 2018 (UTC)

• I don't think using an edit summary made by someone deliberately being WP:POINTy is good qualification for supporting the reinstatement of the very restrictive edit summary limit. Master of Time (talk) 23:26, 3 March 2018 (UTC)

I kinda disagree that is was POINTY behavior, as it was my own talk page, and rather than typing gibberish or unicode I wrote something constructive. For those who didn't click I wrote believes that rules should be written so that serial abusers who post hundreds of unicode characters and nonsense, and who specifically disrupt the histories, should receive sanctions ranging from receiving a personal limit of 250 characters to indefinite blocks for NOTHERE/CIR/trollish behavior. Another thing the I wish to note, if making it so EC30/500s get the 1000max is hard, make it so admins get access to the longer ES function, as Diaanna pointed out in the survey, URLs for copyright violations can be long themselves, and when you through multiple attack locations, you can run out of room quickly. In the TP use/abuse policies, clarify that communication is to take place on TP, not in the histories, and that NPA/CIVIL…. And Chris troutman, do I correctly interpret your above vote as "Until technical restrictions as to who gets to use long ES and/or polices are enacted, the edit summary length for the en.wiki should returned to its prior max of 250"? Thanks, L3X1 ◊distænt write◊ 22:02, 4 March 2018 (UTC)

@L3X1: Yes, that's it exactly. Chris Troutman (talk) 22:15, 4 March 2018 (UTC)

• Oppose. How about 500? Kevin (aka L235 · t · c) 00:05, 4 March 2018 (UTC)
• Support. Please turn this off. It's making a mess of watchlists and contribution histories. Frankly, it's annoying enough when people routinely used the full 255 limit. If there's a need to say more, "see talk" and a brief note there is better than filling up watchlists. SarahSV ^(talk) 00:12, 4 March 2018 (UTC)
  • Odd, I have thousands of pages on my watchlist and it looks absolutely fine. Master of Time (talk) 00:40, 4 March 2018 (UTC)
• Oppose (well partially anyway). I think it should be truncated a bit to 500 characters, as there's no way the full 1000 character summary is needed. But long summaries (such as undo of IPv6 users) will get chopped off if this is reverted completely. epicgenius (talk) 00:54, 4 March 2018 (UTC)
• Oppose because the higher limit is useful for things like copyvio cleanup and reverting Ipv6 editors. I tend to be wordy in edit summaries because I like to explain what I did and why and having that extra limit (which I very much doubt I'd ever reach) is good for me. With respect to editors who copy their entire edit into the edit summary field, I found this practice to be annoying even before the increased character limit, as in this case the edit summary isn't actually a summary of the edit. I also don't need to see the same text twice (once in the edit summary and again on the page). I do support truncating the display of edit summaries in watchlists, etc, as discussed below. Ca2james (talk) 04:28, 4 March 2018 (UTC)
• Oppose we should just be stricter about people misusing longer edit summaries eg. [2] [3] [4] [5] [6] [7] ·addshore· ^{talk to me!} 17:55, 4 March 2018 (UTC)
• Oppose/leaning conditional Support As a page mover, I often come around when the 240ish limit is not enough. I generally pipe the links in summary so it becomes readable/accessible later while being seen in page history, and watchlist. An example would be special:diff/827568706. On a few instances, I had to use edit summary "moved per consensus on talkpage", as the link (without being piped) was taking a lot of characters. If there could be a workaround that, then I would support it completely. —usernamekiran(talk) 18:11, 4 March 2018 (UTC)
• Support. By definition it is an edit summary. Surely those who call themselves "editors" should be able to summarize something in roughly 250 words. Readers can be directed to the talk page for longer explanations. [Which, I believe, is the function of talk pages]. Sunray (talk) 20:08, 4 March 2018 (UTC)
• Oppose Actually, it is bytes not unicode characters. A UTF-8 character may contain up to four bytes. I've frequently been frustrated by the short edit summary limit, especially when much of it is taken up by auto-generated text. Hawkeye7 (discuss) 20:23, 4 March 2018 (UTC)
• Support trimming it back to 255 or something like that. As noted above, long edit summaries enable editors to think that they have engaged in discussion when they have not. Robert McClenon (talk) 20:27, 4 March 2018 (UTC)
• Oppose, since there's a JS fix below. Enterprisey (talk!) 21:47, 4 March 2018 (UTC)
• Oppose a return to 255. I might support a limit of ~400 or 500, but 255 was often too short. --BrownHairedGirl (talk) • (contribs) 22:24, 4 March 2018 (UTC)
• Oppose. There are a variety of situations where the capability of having a longer edit summary is useful, and all the disruption seems to be coming from the small number of metapedian editors who've developed the habit of copying the entire content of their post to a discussion page into the edit summary. Once these editors become aware of the issue, I don't think the issues are likely to continue. – Uanfala (talk) 23:53, 4 March 2018 (UTC)
• Support—it's an edit summary, not an edit recapitulation. The unilateral, unsolicited change is a solution to a mispercieved problem. Including IVP6 twice in IP edit listings is the problem—solvable by a short place-holder link (an IP address summary). That is a task suitable to a simple algorithm. Condensing an edit summary is not easily done by Wikipedia software—it is a task for editors. If an editor can not summarize an edit enough enough for easy identification and justification, then perhaps the edit should be reconsidered. — Neonorange (talk) 00:21, 5 March 2018 (UTC)
• Oppose More space can be useful for many tasks, as it has been noted by several editors. If clutter is a problem, just truncate at 255 the display, with a link to show the full comment, as it has been suggested above.--cyclopia^speak! 00:27, 5 March 2018 (UTC)
• Support This will make histories and watch lists unmanageable. Even here Rambling Man’s demo long edit summary had to be revdeleted. Summarize and take the tl;dr stuff to the talk page. This would allow verbose edit summary arguments.Edison (talk) 03:02, 5 March 2018 (UTC)
• Support: This is the wrong way to solve the problem. The right way is to give the user 255 characters (characters, not bytes) to write a summary and then to have the software tack on any canned edit summaries such as Undid revision 000000000 by User:0000:0000:0000:0000:0000:0000:0000:000 (User talk:0000:0000:0000:0000:0000:0000:0000:000). 255 characters is plenty. Just stop using them up with IPV6 addresses and by having the` limit smaller for Unicode character. — Preceding unsigned comment added by Guy Macon (talk • contribs)
  • @Guy Macon: MediaWiki:Undo-summary already cuts back the user's contributions link and removes the talk page link for users with over 25 characters in their usernames. So it would be [[Special:Contributions/0000:0000:0000:0000:0000:0000:0000:0000]] instead of [[Special:Contributions/0000:0000:0000:0000:0000:0000:0000:0000|0000:0000:0000:0000:0000:0000:0000:0000]] ([[User talk:0000:0000:0000:0000:0000:0000:0000:0000|0000:0000:0000:0000:0000:0000:0000:0000|talk]]), which is much longer. Just wanted to point that out. epicgenius (talk) 18:02, 9 March 2018 (UTC)
• Oppose. I can see why the higher limit helps with some real cases, and it's silly for the English Wikipedia to campaign against a feature that affects every project (or try to be a special exception to that feature) just because of our own habits. rspεεr (talk) 08:06, 5 March 2018 (UTC)
• Strong oppose. I fail to see the problem here. Even on my small screen I have no problems reading longer edit summaries. See Uanfala's comment above as well.--Jasper Deng (talk) 10:57, 5 March 2018 (UTC)
• Oppose, the old limit has caused problems here (undo autosummaries that can't be annotated etc.) The new length results in new potential problems, but it is up to us as a community to make those rare (tell off people who use edit summaries to discuss instead of summarising the edit). Users can also be asked by technical means to use short edit summaries where possible. —Kusma (t·c) 12:01, 5 March 2018 (UTC)
• Oppose, per opposing rationales above. I also think it is a big improvement because it gives the opportunity to good-faith editors to express in detail their position, when needed. Sure, like many functions on Wikipedia, it can also be abused, but this is not a reason to disallow it. Disruption can be handled whenever it arises. I also think this feature will save editing time. From my own experience, I was caught many times trying to delete characters from my edit-summary to accommodate the previous shorter length requirements. That editing procedure took a long time sometimes. With the new length, this vetting will be a thing of the past and it will save time. Dr. K. 19:42, 5 March 2018 (UTC)
• Oppose. If you don't want to read a long edit summary, don't read it. --Tryptofish (talk) 21:13, 5 March 2018 (UTC)
• Weak support - Hate to be a party-pooper, but the new character limit is way too easy to abuse. It doesn't appear to have been implemented very well either. Maybe trim it down to 300 characters per edit summary. Kurtis ^(talk) 21:42, 5 March 2018 (UTC)

  Changed to oppose. Then arguments in favor of longer edit summaries have swayed me. Kurtis ^(talk) 09:45, 9 March 2018 (UTC)

• Oppose. On the whole, I think there are more positive aspects than negative aspects in extending the character limit from 250 to 1,000 characters. Regards, AzureCitizen (talk) 22:59, 5 March 2018 (UTC)
• Support. As with other undiscussed changes, revert to the former state and hold a proper discussion. If there's then a consensus to implement it, wait to do so until a method of hiding the more ridiculous results is also ready for implementation. Meanwhile, people can continue to replace the IPv6 addresses with "IPv6 editor", and use "please see talk" if they run out of space. Justlettersandnumbers (talk) 14:15, 6 March 2018 (UTC)
• Oppose Proposal has no basis. Saying problems like "these" doesn't make it a real problem. One more usage case, in addition to the above presented reasons would be bots; edit summaries by bots often include a descriptive edit summary, a release version number, a link to the bot OP's page and some have their unique edit ID, reverting it back to 250 will need to cut back on atleast some of the factors required to make a proper edit summary to assist people. --QEDK (後 🌸 桜) 17:41, 6 March 2018 (UTC)
• Exceptionally Strong Oppose. To be honest, I was unaware that this feature had launched, but I applaud the implementation of this long-overdue tweak. The previous limit was a frequent and needless limitation and holdover from a simpler era in our editorial processes. I'll be plain: I don't think the strong majority of edits require nearly so many characters. Indeed, I don't think the majority have ever needed as many as the 200 or so previously allowed. But for certain work in certain areas--including but not nearly limited to those where it is useful to retain details regarding reversions and to explain one's quasi-administrative actions in detail. For example, I volunteer as a pending changes reviewer, and I feel compelled when rejecting an edit on a protected page to provide an explanation which is clear and gives both the proposing/novice editor good information on why their edit was found problematic and gives the other local editors a clear notion of what is going on when they look at the revision history. That's a tall order before you even add inthe fact that you lose space identifying the edit as a pending changes reversion, and probably the party as well, before you get into the substance of the issue. That's just one of many cases that I can think of off the top of my head where one is likely to run up against the previous character limit, and I'm sure others have notions from their own idiosyncratic experiences that I wouldn't even think of.

Addressing some of the reasoning for rolling back this change, the concern I find most credible is that there's a lot of potential for abuse here. Well, that's true with regard to edit summaries in general, but this change does not substantially alter the equation with regard to those problems. We have plenty of administrative tools to restrain or block those who will fill the field with trolling, just as we did before. The same goes for those who cannot grasp that the purpose of the edit summary has not itself changed and constrain their comments accordingly. There might be an adjustment period, maybe even a need to tighten some policy language here and there, but I see no reason to assume that this will not be a massive net positive in the long run. I've also seen some editors make some more specious claims, like "they just want an increase here, because they saw it happen on Twitter". I would propose to anyone making an argument such as this that if you are ready to jump to an analysis of your fellow editors' !votes that assumes said editors are borderline idiots operating on a "monkey see, monkey do" level (rather than making a good faith assumption that said editors are speaking from their own idiosyncratic experiences working in disparate parts of the project) that this is a red flag that you may be prone to cognitive biases (my side bias and the availability heuristic in particular) that could be colouring your interpretation of this issue. All of that said, there may be a reasonable compromise here (500-750 is probably more than sufficient for even most complex edit summaries, afterall), but I strongly oppose a return to the old limit. Snow ^{let's rap} 21:25, 6 March 2018 (UTC)

• Oppose clearly see more positives than negatives.Pharaoh of the Wizards (talk) 03:11, 7 March 2018 (UTC)
• Oppose - More than once, I wanted to use an edit summary along the lines of rm [[:Category:Foo]] per [[Wikipedia:Categories for discussion/Log/20$$ $$$$ $$#Category:Foo]], or even rename [[:Category:Foo]] to [[Category:Bar]] per [[Wikipedia:Categories for discussion/Log/20$$ $$$$ $$#Category:Foo]] for long category names, but couldn't do so. עוד מישהו Od Mishehu 14:59, 7 March 2018 (UTC)
• Oppose—I just came across this official action whose edit summary was apparently truncated according to the old limit. The new limit of 1000 must have been arrived at in consideration of the impact on the system made by longer edit summaries, and so the longer limit should stand, although I see the likelihood of a compromise limit. Having the ES display adjustable according to individual preferences seems to be something that is easily implemented and is the answer to those who find longer displays distracting . Dhtwiki (talk) 23:22, 7 March 2018 (UTC)
• Oppose There have been a few times I have found the old limit restricting. See this as a net positive. AIRcorn (talk) 00:06, 8 March 2018 (UTC)
• Partial Oppose General consensus is that 1000 limit is too long and 250 is too short, so reverting back isn't ideal. I support alternate solutions discussed here.   —  Hei Liebrecht 18:52, 8 March 2018 (UTC)
• Oppose per above. Jjjjjjdddddd (talk) 15:42, 9 March 2018 (UTC)
• Oppose - Every once in a while I get cut off when I'm running a long link into an edit summary to footnote something that doesn't need a footnote in the piece (say, a nickname in the lead). This expansion of characters is no problem until it proves itself a problem. Carrite (talk) 21:31, 9 March 2018 (UTC)
• Oppose. Edit summaries serve more than one purpose. For many edit summaries there is more than enough space. But sometimes you want to explain your reasoning from the outset, rather than engage in the more tedious process of Talk page discussion. Edit summaries not only say what you've done but allow you to respond to anticipated objections. Let us not forget that "orangutans are skeptical of changes in their cages". The additional space allows one the opportunity to explain oneself. Yes, this additional space can be misused. Misuse of edit summaries should result in stern warnings and blocks. Bus stop (talk) 12:19, 10 March 2018 (UTC)

• Oppose - I'd rather have "too much" space than not enough space. The latter is objectively a problem when it arises. "Too much" space? I'm inclined to agree with the many users above who so delicately suggest that this is a made up "problem". Swarm ♠ 19:31, 10 March 2018 (UTC)
• Oppose, but I would not object to a limit of 500 bytes, or of 255 characters plus automatic stuff (section headers and undid notes). I have never understood people copying their replies into the edit summary, and the problem with them doing it under a 1000 byte limit is not the limit but the user (even if it was an acceptable practice before and the user is acting in good faith, they should adapt to better practices now). I would also support truncating the comment at some smaller limit (150 or 255 characters, for example) by default when viewed in watchlists. The biggest problem I see is vandals spamming 1000 byte comments – though I wonder how likely this is as I can't recall many 255 byte comments on vandalism edits (maybe LTAs would catch on and cause quite a mess). — Bilorv_(c)(talk) 07:37, 11 March 2018 (UTC)
• Oppose, it's harmless. Stifle's non-admin account (talk) 14:27, 12 March 2018 (UTC)
• Split the difference, make it 500. I tend to make big edits encompassing a number of changes, and I also like to explain my rationale, so I've appreciated the countdown of how many characters I have left, and I like having more. This is an example of an edit that I suspect some won't like, so I appreciated being able to explain in detail. After seeing the fun at Iridescent's talk page (and not being able to see many of the symbols, and having my usual problem not being able to make out most emojis at text size and not knowing how to blow them up), I agree that 1,000 is way too big because it will be misused. But I have found the old limit problematic. Yngvadottir (talk) 20:43, 12 March 2018 (UTC)
• Support – This really encourages lengthy debate via edit summaries, and discourages talk page threads; will inevitably lead to drama, and probably already contributes to weaker understanding between editors and lost productivity. At first I didn't want to comment because I was swayed by arguments saying that's just an issue of individual behaviour. But then I kept seeing plenty of examples in my routine watchlist, i.e. just now this one on German Empire. I am now convinced this tool is influencing behaviour, and therefore should be restrained to the usual 250-ish character field. If that's a problem for some languages, it's a debate for their own wikis to change their settings according to what works best for them, not for the English-language Wikipedia. — JFG ^talk 21:14, 12 March 2018 (UTC)
• Oppose The benefits of this are much greater than the downside. If a user abuses this function then discuss it with them, but don't let them ruin it for us all. Emir of Wikipedia (talk) 20:48, 13 March 2018 (UTC)
• Strong oppose Artificial restrictions from software are silly. Using a clickable [...]-to-expand button, as suggested by several people, would fix this. Personally, I'd get rid of the limitations entirely, and allow unlimited-length, automatically paginated edit summaries, but at a certain point the effort to implement that would get a bit silly, so 1000 bytes seems like a reasonable compromise ;) —{{u|Goldenshimmer}}｜✝️｜they/their｜😹｜T/C｜☮️｜John 15:12｜🍂 22:05, 13 March 2018 (UTC)
• Oppose As stated above, gets a bit short with IPV6. Icarosaurvus (talk) 18:18, 14 March 2018 (UTC)
• Support Summaries should be concise and lengthy explanations and discussions posted in Talk pages; we should not be encouraging extended discussions in such an extremely limited medium as edit summaries. However, I am extremely pessimistic that even if there were overwhelming support for this requested change - and there clearly isn't - that the developers would make the change given the long history of changes being made with little consultation, testing with editors, or responses to feedback. ElKevbo (talk) 03:45, 15 March 2018 (UTC)
• Oppose per Legoktm. Allowing longer edit summaries is an improvement. feminist (talk) 05:17, 15 March 2018 (UTC)
• Oppose, but... In some cases, it is very practical to have more than 250 characters to summarize one's edit. That being said, I do agree with the problems enumerated, but I reckon finding a middle ground (like 500-600 as people above have suggested) is reasonable, considering there must be other solutions to the issues below. In short, don't go back to 250, do reduce the limit to an in-between number as per concesus, and do open a new discussion to fix the problems related to this. Thank you. Double Plus Ungood (talk) 14:39, 15 March 2018 (UTC)
• Oppose Maybe 1000 is a bit long but I agree the previous 255 was a bit short. As others have said, one particular example would be reverting IPv6 edits where you get very little room to explain any changes. Also with long section headings where you're prefer to keep the heading. While it's true there are more avenues for abuse, misuse and poor use with longer edit summaries, it's not likely there aren't serious possible problems already hence why removing edit summaries isn't unheard of. For the problems, we just deal with them as we always do. So overall a net positive. I'm fine with clickable long summaries etc but think the longer summaries should stay until this is implemented. Nil Einne (talk) 20:02, 15 March 2018 (UTC)
• Comment Can we just put it to something like 500? 1000 is a bit big, but 255 was so small that undoing an IPV6 meant that almost the whole edit summary was taken up by just the links to the contributions and the talk page, a stopgap measure was made by removing the piping, but it made it ugly. With the 1000 character limit, it's easy to make disruptive summaries that stretch the page, and admins have better things to do than revision deleting those. Just imagine if we had this in the time of Grawp. *shudder* Gatemansgc (TɅ̊LK) 01:02, 18 March 2018 (UTC)
• Support but maybe a decrease to 400 characters (to allow putting the full edit summary for reverting a very long IP Address. Anchorvale (talk · contribs) 06:09, 19 March 2018 (UTC)

@Anchorvale: It seems as if you meant to !vote Oppose but... here, rather than Support but..., given the actual content of your comments. The way this RfC has been structured, a support !vote indicates backing for returning the limit to 255 characters, not support for the new limit. Though of course, like a lot of us, you're clearly amenable to a middle ground solution. Snow ^{let's rap} 19:25, 20 March 2018 (UTC)

• Support restoration of the old limit because, frankly, I'm getting tired of having my Watchlist look like a Talk page. And encouraging users to view the edit summary as a substitute for a Talk page posting is not a good thing. As for the long IP addresses taking up too much space in the edit summaries, those can be truncated/eliminated when adding your own edit summary. NewYorkActuary (talk) 16:00, 24 March 2018 (UTC)
• Support - While having a longer edit summary limit can be naturally be seen as an improvement and "why not?", it adds many more problems that outweigh any potential benefits (which really aren't much at all). Since the character limit was expanded, I've noticed a significant increase in editors using edit summaries to argue their points, tell other editors to "stop it" and "you have to do this", and as a perceived communication medium in place of following Wikipedia's dispute resolution policy and creating talk page discussions. Edit summaries need to be clear, to the point, and state exactly what you did in a few words and why - nothing else... and the problem here is that the increased limit has allowed users to begin explaining their edits instead of summarizing them. This consequence has inadvertently made the path for users to start edit warring easier to cross, as it's now become slightly more convenient to just revert the edit again and add statements to the edit summary that should be made on the talk page instead, and it doesn't force them to summarize their changes and follow up with them in a discussion as the lower character count (in a manner of speaking) did. I'd say that 90% of the edit summaries I see that are significantly over the old character limit are by editors that are in a current dispute with someone else. Most of them fail to collaborate and begin a discussion, and start edit warring as a result. ~Oshwah~^{(talk) (contribs)} 07:03, 25 March 2018 (UTC)
• Oppose; overkill and 1,000 is preferable to 255. Reducing the limit seems reasonable. Jc86035 (talk) 15:40, 25 March 2018 (UTC)
• Support It should be really summary; that's very brief and to the point. –Ammarpad (talk) 19:01, 25 March 2018 (UTC)
• Oppose - a 1,000 character field does not require that you use 1,000 characters, it merely affords that you can. It does not change how edit summaries are written, it allows them to be written, as prescribed. I welcome the change.--John Cline (talk) 13:44, 26 March 2018 (UTC)
• Oppose I'm finding the extra space quite useful. Courcelles (talk) 14:42, 28 March 2018 (UTC)
• Oppose First, we are not Twitter. And second, the former abbreviations used, etc., could be seen as an institutional manner by which we bite the noobs, er, newbies, er, see WP:BITE. Third, the longer limit doesn't bite, er, mean that all the characters that could be used need be used. Finally, not all summations can be made within 250 characters. So, in short, oppose per above. Javert2113 (talk) 23:26, 28 March 2018 (UTC)

• Well put! Jjjjjjdddddd (talk) 01:52, 29 March 2018 (UTC)

Identified problems

The whole discussion is conflating many, many potential issues, so I figured we should keep a list here of real and/or potential problems with the new limits:

1. People being nitwits / vandals abusing this feature to create edit summaries near the 1000 limit for no useful reason (vandalism or WP:POINTY)
2. People who used to rely on shortening of edit summaries when pasting their reply to a comment into the editsummary (a habit)
3. Automatic edit summaries like MediaWiki:Autosumm-replace and MediaWiki:Autosumm-new which add the entire wiki text content into the edit summary. This happens for new pages, file uploads and with people replacing the entire content of a page (technical issue?)
4. People might use edit summaries as the discussion platform instead of talk pages (especially for newbies, this is likely to be a problem I suspect) (a UX issue)
5. When edit summaries ARE long, they take up a lot of space in the views of the page history, logs and recentchanges/watchlist feeds. This makes it harder to look at multiple entries at the same time, potential making vandal fighting more cumbersome, but also just overflowing the pages with information. (a UX issue)

Each of these issues might have one or more potential solutions. Please keep discussion with regard to solutions etc, in the Discussion section. If you have identified additional problems, you may add them here. —TheDJ (talk • contribs) 10:02, 5 March 2018 (UTC)

Autosumm-replace and autosumm-new still truncate at 200 bytes minus the byte-length of the messages themselves. See testwiki:Special:Diff/349059 and testwiki:Special:Diff/349060 for examples. Uploads, on the other hand, do not do their own truncation and so reach the 1000-character limit. Anomie⚔ 13:19, 5 March 2018 (UTC)

A good example of the "people using long edit summaries instead of Talk" problem can be seen in the current edit war occurring at Columbia University. ElKevbo (talk) 22:07, 15 March 2018 (UTC)

OTOH, that assumes they wouldn't just use less verbose summaries if the limit were shorter. Anomie⚔ 11:22, 16 March 2018 (UTC)

Discussion

• For an example of what how potentially disruptive this could be, see Special:Diff/828335644. I'm not calling out the editor who made that post, since it's likely they didn't know about the change in limit, it was just what brought the issue to my attention. Primefac (talk) 23:53, 1 March 2018 (UTC)
• You can name me. I am somewhat embarrassed, but no, I had not idea. I like to copy my entire post into the clipboard, in case of edit conflict or browser crash, but I see there will now be a big problem. Until today, the edit summary was limited to two lines. --SmokeyJoe (talk) 23:57, 1 March 2018 (UTC)

  Wow! I used to do this as well, until an editor complained about it. –xeno^talk 18:53, 2 March 2018 (UTC)

• Bad solution, but status quo ante sucks almost as much. Take for example the case of an undo of an edit made by an IPv6 editor. You have to remove the talk page link to have much room at all, and often even that's not enough to explain your revert adequately. Ideal solution would be a length that is variable depending on what's already there, always allowing for x number of additional characters. Surely that's do-able? ―Mandruss ☎ 00:08, 2 March 2018 (UTC)
• I can see that this solution is going to be a problem at times, but I've been running into the too-short summary limit since we started seeing IPv6 addresses. By the time an automated summary links to both the IP address and the IP's talk page there isn't all that much room left over. Even just getting rid of the talk page link would be an improvement. Meters (talk) 00:17, 2 March 2018 (UTC)

  If you use tools like Twinkle for such things then the request can be made at WT:Twinkle or if you have a github account on their respective pages. If you are talking about the automatic "undo" summary then perhaps MediaWiki:Undo-summary is the change you are looking for? --Majora (talk) 00:22, 2 March 2018 (UTC)

  If one is more interested in the overall project than their own needs, they prefer site-wide solutions over single-user ones. (I don't use Twinkle for reverts.) ―Mandruss ☎ 00:37, 2 March 2018 (UTC)

  Changes to the tools people use and the site settings that dictate things would be site-wide. Now that I look at it more, it appears that the automated edit summary on undos was already changed to accommodate IPv6 address as well as long usernames. This change seems like a gross over correction. I'm of the opinion that it needs to go back to the drawing board and a more adequate solution needs to be worked out by the devs as to not hammer in a solution, globally, that could cause such problems like filling up histories and watchlists. --Majora (talk) 00:46, 2 March 2018 (UTC)

  For "undo" summaries I often just highlight and delete the "talk page link" portion if I need more room - occasionally I might just remove the whole "autogenerated" portion and replace with my own summary, but the need to do this has been very rare. -- Begoon 02:49, 2 March 2018 (UTC)

• Just as a note, there's various Phab tasks related to the change. phab:T185948 is probably the most specific task, and phab:T6714 and phab:T6715 are also relevant. --AntiCompositeNumber (talk) 00:41, 2 March 2018 (UTC)
• My edit summaries are annoying me everywhere I look. How about an edit summary checkbox "allow expanded summary", with its default state set in your preferences? --SmokeyJoe (talk) 00:48, 2 March 2018 (UTC)
  • Seems useful, so as to not break workflows of people like you who paste in their comments.. Galobtter (pingó mió) 07:23, 2 March 2018 (UTC)
    • There used to be such a feature, but then edit summaries were increased to 255 characters for all users. oknazevad (talk) 19:00, 2 March 2018 (UTC)
• The change probably cannot turned off in any meaningful sense. I would rather put something in WP:Edit summaries that people should tend toward shorter rather than longer summaries. SmokeyJoe (Headbomb does it too) probably shouldn't copy and paste entire messages into the edit summary box anymore but instead actually summarize his comment. --Izno (talk) 01:09, 2 March 2018 (UTC)

  I'm guessing that would have about as much effect as WP:SIGAPP - a Wikipedia policy. ―Mandruss ☎ 01:17, 2 March 2018 (UTC)

  I have seen SIGAPP required of persons (and blocks provided until compliance). --Izno (talk) 01:57, 2 March 2018 (UTC)

  Too rare to be significant. ―Mandruss ☎ 11:14, 2 March 2018 (UTC)

• A possible solution would be after a certain length, that a dialog box prompt you that it's considered longer than average. I doubt most of the editors who appear to be abusing this are aware of the issue. A prompt, in these cases, would cause editors to be aware of the situation, and thus would prevent long summaries in most cases. I also like the idea of manually having to check a box to allow an extended summary. That said it probably should just disappear all together. --Deathawk (talk) 02:24, 2 March 2018 (UTC)

Tracked in Phabricator
Task T6717

• We need to stop approaching every change with "ugh this is bad lets turn it off" and "clearly no one thought this through". This has been in the works for YEARS and is one of the most wanted requests from the global Wikimedia Community. Here's my proposal: Allow people to save the full length of edit summaries in the database. On places where vertical room is limited (history/watchlist/etc.), do truncation based on the visual length (not wikitext length), add a clickable "..." to the end that will do full expansion. That allows complex characters and fixes IPv6, etc, while hopefully preventing the problem of longer summaries. Legoktm (talk) 04:02, 2 March 2018 (UTC)

  Saying we should stop saying "no one thought this through" while simultaneously stating a potential fix that would have solved all of this before it started seems a tad ironic. --Majora (talk) 04:05, 2 March 2018 (UTC)

  I was referring to the rhetoric being used. Given the complexity required by this change I'm not surprised something got missed. And I wish people took a moment to think about how there might actually be a good rationale behind the change before immediately jumping on it for being bad. Legoktm (talk) 04:15, 2 March 2018 (UTC)

  I'm all for the truncated version. I also understand the rationale for doing it. I'm also still on the side of undoing the change until the fix you mentioned above is deployable at the same time for the reasons I started this RfC. --Majora (talk) 04:22, 2 March 2018 (UTC)

  • Support Truncating the display, with a clickable "..." to reveal the rest of it, I think is a fantastic idea. Then everyone wins :) Because it's true even on enwiki we do run into issues with the summary being too short, such as page protections and reverting IPv6. For the record, I'm not sure everyone is simply adverse to change, or questioning the merit of this feature. Rather, it was clear there could be problems with display like the example diff, and that it's possible the edit summary would become some new unwarranted venue for discussion, especially when edit warring. If the display is truncated, that'd be enough to discourage misuse, and we still get all the benefits. — MusikAnimal ^talk 04:18, 2 March 2018 (UTC)
  • I suggested this above (or similar) as well, so obviously support FACE WITH TEARS OF JOY ^[u+1F602] 11:14 pm, Today (UTC−5)
  • I'd support this, but I think the current rollout should be disabled until this can be fixed. It has too much potential for disruption (and not just with watchlists. The potential for fights when in content disputes are also a factor). I don't think the positives of the untruncated version outweigh the negatives at this time. TonyBallioni (talk) 04:17, 2 March 2018 (UTC)
  • Hmm, I think IPv6 thing could be more elegantly fixed with a limit to visual length or if not, then a limit of 400 characters or something should be enough, not sure we should encourage/allow over-long edit summaries, I could see them being annoying even if hidden. Any problems with summary length usually from links personally Galobtter (pingó mió) 07:08, 2 March 2018 (UTC)
    • I can't think of any genuine needs for edit summary visually longer than 255 chars or with a total length > 400 Galobtter (pingó mió) 07:11, 2 March 2018 (UTC)
    • I'm also wondering if long edit summaries will break any tools like huggle/stiki, or at-least not work well for them Galobtter (pingó mió) 07:11, 2 March 2018 (UTC)
    • I also support atleast temporarily disabling until this is fixed; also wondering if forcing short edit summaries may force people to the talk page atleast occassionally.. Galobtter (pingó mió) 07:19, 2 March 2018 (UTC)
  • FYI, Allow people to save the full length of edit summaries in the database is 65535 bytes. ;) Anomie⚔ 12:25, 2 March 2018 (UTC)

I have problems with this.

1. Some section names are long. This would clip the meaningful part of the edit summary, eg

/* Question about using your image in my article about bananas */ replied to Longtailedlemur and Chad

2. This could be confusing for new users. I would recommend to have this as an opt-in (or at least opt-out) feature.

3. People who abuse long edit summaries would abuse short edit summaries too.

4. This needs to use JavaScript, so it would need to be written as a gadget. Without checking whether the user is viewing a relevant page (such as recent changes or diff preview etc), my codes are included below.

Like this (truncates to 300px width, does not look well with diff previews)

// Shorten all edit summaries to 300px
$('.comment').prop('style','text-overflow: ellipsis;width:300px !important;overflow:hidden !important;display:block;white-space: nowrap;')

// Unshorten the edit summary when clicked
$('.comment').click(function(){
$(this).prop('style','width:auto;');
});

Or like this (truncates to n characters).

var n = 80;
$('.comment').each(function(i){
	var original = $(this).text();
	var shortText = original.length > n ? $.trim(original).substring(0, n).trim(this) + " [...]" : original
	$(this).text(shortText);
	$(this).click(function(){
		$(this).text(original);
	});
});

5. When expanded, is it necessary to collapse the edit summary back on a second click? That's something I did not write above.

--Gryllida (talk) 05:19, 2 March 2018 (UTC)

• I am not a member of English Wikipedia community, but since there is inherently more chance that they would listen to you than to other Wikimedia communities on this matter, I want to completely support this proposal (of reverting this change globally, to be completely sure) here. Seems like Russian Wikipedia community voted in 2016 on a good proposal to get our edit summaries up to your limit (since in Russian you could enter only 128 symbols in edit summary before), but it was turned into a complete travesty on global level. There was no consensus on 1000 symbol edit summaries, there is no consensus on 1000 symbol edit summaries, the fact that they did this is atrocious. Any hacks that are proposed here (hiding some parts of edit summary etc.) are just hacks to curb Wikimedia community opinion after not asking one (since Community Wishlist proposal was explicitly about non-Latin communities and their database-imposed limits to edit summary length). Saint Johann (ru) 10:53, 2 March 2018 (UTC)
• Question for Legoktm, MusikAnimal, and others supporting the proposed solution — at the risk of spilling the WP:BEANS, wouldn't such a solution be the perfect place for vandalism? Make an edit, have a longish edit summary, but just beyond the cutoff for "show more" you can insert whatever insults. I suppose the answer is that folks will have it unhidden by default, but seems like it could make for a lot of extra clicking when checking diffs. Fixed pings, I need my tea ~ Amory (u • t • c) 11:27, 2 March 2018 (UTC)

  Hidden vandalism is better than not hidden, right? ;) I'd hope most of it would get caught by patrollers, but yes a simple user script/gadget could make it always show the full edit summary for those who want to. I doubt we'll introduce a preference, too many of those as it is. — MusikAnimal ^talk 16:35, 2 March 2018 (UTC)

• @Majora: The phab ticket you mention in the suggestion (phab:T6714) was outdated (apologies for that). Although this was in the German-speaking 2013 survey, we have not been part in this change (be it good or bad). The reasoning behind the change seems to be explained here. Would it be possible to update the intro accordingly? Thanks, Lea Voget (WMDE) (talk) 12:49, 2 March 2018 (UTC)

  Please accept my apologies Lea Voget (WMDE). That was the phab ticket that I saw and the header stating that it was on the top 20 German Wikipedia wishlist along with a link to a dewiki thread caused me to jump to an incorrect conclusion. I do apologize for that and I have struck the part of the RfC that stated that it was a dewiki proposal. --Majora (talk) 21:17, 2 March 2018 (UTC)

• By all means invite people to debate via edit summaries rather than the talk page and fill up watchlists as a result of this "solution". But if the result is my having to read through pages of waffle because this has left room for about half a dozen changes to the page on a perfectly reasonable laptop screen I, for one, will be finding another way to spend my time. Britmax (talk) 14:42, 2 March 2018 (UTC)
• I cannot understand what the people who implemented this were thinking. Why in the world would they make such a dramatic change to the user experience and not get prior buy-in? Jytdog (talk) 15:49, 2 March 2018 (UTC)
• This RfC is not neutral, nor does it attempt to express the situation in an even manner. Leading with declarations such as, "It will do nothing more than cause massive disruption in the histories of numerous pages." is not exactly assuming good faith. :) I really think we can, and should, do better in framing the situation so that all participants can have a clear and equal understanding of the facts before asking for community feedback. I suggest the creator work with interested parties to provide more context for the reason for the change (with references to existing discussions) and try again. As it stands now I can't in good conscious participate in such one-sided propaganda. Ckoerner (talk) 16:36, 2 March 2018 (UTC)
  • Addendum, as I wrote this I think I understand what people mean when they say the RfC process is broken. It's not necessary broken (nor is it perfect) but the glib way in which they are written leads to an oppositional argument easier than a congenial discussion. Ckoerner (talk) 16:39, 2 March 2018 (UTC)
  • Maybe WMF should try to explain their decisions beforehand, especially the decision to stump through from the original standpoint of ‘non-Latin communities want the same length of edit summaries as other communities’ right to ‘1000 characters for everyone, let’s write essays in edit summaries’. I feel like decision-makers in individual communities have a lot more responsibility and accountability in their communities than Wikimedia Foundation has in entire movement. And it really shouldn’t be like this. I was made more accountable over changing one template through a discussion in my home project than entire team that made this change without any discussion was made accountable over this. Something is entirely wrong not in the way communities respond to non-discussed changes, but in the way WMF is being dishonest and not upfront to their communities (not only English one, I want everyone to remember that, English Wikipedia gets it easy relative to others). stjn^[ru] 17:45, 2 March 2018 (UTC)
    • I think part of the problem is that the WMF is outnumbered in the many voices of representation. It's entirely plausible that the folks who enacted this change were following the desires of a community - that of the folks who participated in the wishlist proposal. That group said please do this for us. The team went and did that work. Which I think is healthy and how most folks would like to operate. Now they turned it on, and part of another community, with some obvious overlap, is upset. This comes through in the tone and framing of the RfC and comments like one one succeeding yours. In this situation the folks from the WMF (obviously not the entire WMF as we are not monolithic as some might think) is stuck in a position of damned if we do, damned if we don't. I think there's an opportunity to learn how to make our relationship healthier - in both directions. My suggestion, if we continue the RfC process as a means to understand community consensus - particularly around software changes/updates/configs - is that said proposals should be drafted together, not as one side in opposition to the other. We're all on the same side. Ckoerner (talk) 21:06, 2 March 2018 (UTC)
      • @Ckoerner: the matter of the fact is, you can find my own vote in your link under #34. But the thing is, I am more than sure that both the proposer and the voters didn’t give the Foundation and its developers the opportunity to do whatever the hell they like by their vote. The people there wanted to have parity with English-speaking colleagues in the number of characters, no one was talking about increasing limit up to thousand characters.
        WMF even understood this as we see in ‘We don't want to encourage Latin languages to post 3x longer edit summaries, because edit summaries aren't intended to be a primary communication method’. But someone clicked along the way, someone thought it was good idea to seek consensus where there is none, and someone did this their own way instead of implementing wishes of communities that you are talking about. At this point it is pretty hypocritical to talk about the tone of discussion, because there was none prior.
        And the less discussions are happening, the less of the same side we are on. I want to believe in all the good work the Foundation does, but frankly WMF developers get to stump through with any changes they like without any hesitation or need to at least ask at some point in time. If we are on the same side, we both should act like we are on the same side. And the main responsibility for this is on the side of powerful, not on the side of weak (which, in this case, is the Wikimedia community). stjn^[ru] 21:29, 2 March 2018 (UTC)
        • I'm sorry my attempt to have a conversation with regards to how we can all improve is met with more finger pointing and stress than I care to engage with. I appreciate your feedback, but am ending my part in this conversation. Thank you. Ckoerner (talk) 23:10, 2 March 2018 (UTC)
          • Sorry my attempts to get information out of people who defend making change this way were perceived that way. Of course, you are in your own right to not respond to WMF-related criticism over this situation, but the fact is that someone should. stjn^[ru] 10:21, 3 March 2018 (UTC)
    • User:Ckoerner what is fucking broken is the way the WMF interacts with the editing communities. Jytdog (talk) 19:43, 2 March 2018 (UTC)

      WMF interacts with the editing communities? . Kablammo (talk) 00:46, 3 March 2018 (UTC)

      • @Jytdog: - cause getting irrationally angry and all up in someones face like that with swearing is gonna help. Seddon ^talk 22:45, 2 March 2018 (UTC)
        • Yes anger is irrational. So is relentless fuckwittery from the WMF. Are you aware that Ckoerner is their fucking liaison person? Their comment above is probably the most incompetent piece of liaisoning I have ever seen. wtf. really. Jytdog (talk) 22:55, 2 March 2018 (UTC)
          • Yikes. Yeah, that was quite a tone deaf response for a liaison. Lepricavark (talk) 23:02, 2 March 2018 (UTC)
            • My comments here are in my role as a volunteer. If anyone has an issue with my performance as a staff member you are welcome to bring it to the attention of my supervisor. I'm stepping away from this...well, not quite a conversation, to enjoy my weekend. I hope you enjoy yours as well. Ckoerner (talk) 23:10, 2 March 2018 (UTC)
            • @Lepricavark:Ckoerner made his post under his personal account, something that is perfectly reasonable and fine. So is calling for rational discussion and debate. What is not reasonable and fine is Jytdog's reaction. Our policies dictate that one remain respectful, even when one is upset. I would hope that you don't think that is behavior to be emulated. Keegan (talk) 23:18, 2 March 2018 (UTC)
              • Yes, it's fair point to point out that Ckoerner was posting under his personal account. As he has walked away from the discussion, I'll leave it at that. Lepricavark (talk) 23:32, 2 March 2018 (UTC)
                • I think WMF employees should be more aware that most people aren't going to see the distinction, and that it can cause frustrations with community members, but I also think that Legoktm's proposal to fix is a good one, and I understand Keegan's frustrations about how they are sometimes treated by the community (as one of the people most involved in implementing ACTRIAL from a community perspective, I am well aware that the WMF actually does want to do their best to help support the projects, and I appreciate that dealing with volunteers who think the worst of them can be frustrating and make them not even want to engage).
                  I think this was a bad idea to rollout in the current form on en.wiki, but I get why it was done, and I am grateful that we have people thinking about other language groups who also should have access to a free content encyclopedia in their language of choice. They should be treated with respect in all circumstances, even when there is disagreement with actions of the foundation. TonyBallioni (talk) 01:10, 3 March 2018 (UTC)
                  • As a prominent critic of the WMF's community engagement, and as someone currently angry about the WMF battling a Commons consensus to uninstall Flow, I have to say the hostility and profanity doesn't belong on this one. This started as an absolutely legitimate task to fix edit summaries for other languages. When the technical-limit of 255 bytes went away it was an unfortunate but understandable mistake to "generously" raise the limit to 1000. And most importantly, the WMF is clearly eager to fix this. Let's reserve the hostility for cases where the WMF isn't willing to work with us. Alsee (talk) 11:37, 5 March 2018 (UTC)
• What would be helpful is an option to subdivide the edit summary and have 200 bytes for the edit summary you are writing in addition to the generated edit summary that lists the section name (which really should not be too long). But with long IP names reverting edits by one long IP name to another long IP name can generate a lot of bytes. The ability to add up to 200 bytes to such a generated edit summary would occasionally be useful. ϢereSpielChequers 20:31, 2 March 2018 (UTC)
• Question: I've seen a couple of folks mention "this will be confusing for new users." Can you please elaborate? Why would allowing extra text in a box be confusing? If they're new, they're not used to the old limits, so what about the new limit is surprising? I'm genuinely curious. FACE WITH TEARS OF JOY ^[u+1F602] 05:39, 5 March 2018 (UTC)
• Copyright violation within the edit comment is a risk, such as possibly this edit's comment being taken from here (in this example the source may be out of copyright). Batternut (talk) 10:17, 7 March 2018 (UTC)
  • In that case the comment can be revdelled. Graeme Bartlett (talk) 11:01, 7 March 2018 (UTC)

Community Wishlist team response

Hi everyone — I’m Trevor, a product manager at the Wikimedia Foundation with the Wishlist team. I’ve just read up on this entire thread and have conferred with some colleagues about this change. I’d like to start off with an apology — we’re sorry this caught you by surprise and we’re sorry for the interruptions it’s causing. We knew that this has been a big problem for non-Latin languages. We should have communicated more about the trade-off for English.

We agree that edit summaries should be brief updates to inform others about what an edit contains. It’s not an appropriate place to rant, converse, or ramble. We want to help alleviate potential abuse. The current suggestions we find most promising are:

• Lego and 😂’s idea to truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click. This is very quick for us to build, test, and release.
• Truncate long summaries on Recent Changes, history, and other log pages with an ellipsis that does not expand. To view the full summary, the diff page must be viewed.
• Deathawk’s idea of displaying a warning when an edit summary is longer than average. This is a larger amount of work to support in all major editing tools and will take more time to build, test, and release.
• ViperSnake’s idea of setting up an edit filter to monitor summaries so we can all gain a better understanding of how these long summaries are actually used in the wild.
• Any others?

We propose truncating the summaries on history pages, etc. and exploring an edit filter to monitor the situation. We believe these will address the most common problems highlighted in the survey and discussion above. What do you think? — Trevor Bolliger, WMF Product Manager (t) 23:40, 2 March 2018 (UTC)

@TBolliger (WMF): I think there's a very strong consensus to truncate everywhere. There's somewhat of a debate between expandable or non-expandable, but if the information is stored, then it has to be accessible in someway, so expandable seems to make the most sense. No opinion on the edit filter, but that doesn't sound silly, so why not? Headbomb {t · c · p · b} 01:08, 3 March 2018 (UTC)

Hi Headbomb. Thanks for suggesting that expanding ellipsis is better. I agree. Do you want to test the expandable ellipsis JavaScript code I gave above? I believe if you put it in Special:MyPage/common.js then it would work. (I have also put it to User:Gryllida/js/truncateEditSummaryWithClickableEllipsis.js.) --Gryllida (talk) 01:22, 3 March 2018 (UTC)

@Gryllida: This is great, thanks for making this and sharing with us! When our team explores phab:T6717 next week we'll look into your script. I think the ellipsis could potentially be visually differentiated so it doesn't look like it's part of the summary. Also, on hover the cursor should be a clicky-hand so it's apparent an action occurs on click. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)

Added. --Gryllida (talk) 01:44, 5 March 2018 (UTC)

@Gryllida: Nice! — Trevor Bolliger, WMF Product Manager (t) 23:09, 5 March 2018 (UTC)

Hi Trevor Bolliger, WMF Product Manager. My opinions:

1. "truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click" COULD be opt-in: any interested contributor can enable this, and only for wikis which request this feature.

2. "Truncate long summaries on Recent Changes, history, and other log pages with an ellipsis that does not expand. To view the full summary, the diff page must be viewed." MUST be opt-in. A contributor making a long and legitimate edit summary probably wants it to be visible to others straight away.

3. You said, "Deathawk’s idea of displaying a warning when an edit summary is longer than average. This is a larger amount of work to support in all major editing tools". What are these major editing tools? Visual Editor already clips the edit summary to 255 characters anyway. (This is inconsistent, I would probably fix it?)

Codes for Wiki Editor, or users of no enhanced editing toolbars, with a threshold of 10 characters as this makes testing the code easier and quicker (you may adjust the threshold as needed):

Version 1: shows the warning as a text below the edit summary: [8]

Version 2: marks the counter in orange: [9]

Version 3: marks the counter in orange and draws an orange border around the edit summary box: [10]

Version 4: marks the counter in orange and draws an orange border around the edit summary box and shows a warning as a text below the edit summary: [11]

4. "setting up an edit filter to monitor summaries so we can all gain a better understanding of how these long summaries are actually used in the wild." this MIGHT be interesting. I do not find this terribly useful, but I do not mind this as long as it does not prevent the editor from saving the page. I would say such filters should vary per-wiki rather than being global.

--Gryllida (talk) 01:17, 3 March 2018 (UTC)

@Gryllida: Oh, correct. VisualEditor (and the 2017 Wikitext editor) already truncate at 250. In this case, we'd just need to change the behavior of the 2010 wikitext editor. On my first (Saturday morning) glance, I think I prefer version 1, but they could all be viable treatments. Another option would be like Twitter, where all characters after 140 (280?) are marked in red as a warning. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)

FYI, VE is still applying the old limit because the update for VE didn't make it into 1.31.0-wmf.23. It should be coming this week in 1.31.0-wmf.24; you should be able to test it now on the Beta Cluster. As for "highlighting in red like Twitter", might that confuse Twitter-using Wikipedians into thinking the summary can't be submitted? Anomie⚔ 05:29, 4 March 2018 (UTC)

@Anomie: Good catch, thank you. — Trevor Bolliger, WMF Product Manager (t) 23:09, 5 March 2018 (UTC)

I know this would be more complex, but I still support a solution that doesn't care about byte limits and such stuff. In my opinion, there should be a limit of characters, and not of bytes, in the summary, that could be at something like 400. This resembles the spirit of the summary more as it isn't alphabet dependent anymore (except for east-asian languages with their exterme information per symbol ratio), and links wouldn't take away summary space anymore, while still the summary a summary instead of half an essay. Trunctating in the frontend at around 250 characters would still be useful in this case. Furthermore, in the long-term the IPv6-revert-like problems should be solved in my opinion by not prepending this to the saved summary anymore. This information should be stored in machine readable format (so it can be localized as well). I think this proposal would provide a solution for most of the problems outlined here, while I can't find any downsides right now except for its complexity.

However, I want to point out my disagreement to Legoktms point of view about the nature of this change. There was never any discussion how the additional database space should be used after it was provided. What's happening now wasn't really planned by anyone, it just happened. And it it's neither really elegant nor prepared. --MGChecker (talk) 02:28, 3 March 2018 (UTC)

@TBolliger (WMF):, thanks for these suggestions. One of the major concerns expressed by those preferring a longer edit summary limit is that IPv6 addresses can take up much of the previous limit. Is it technically possible to exclude the username (or IP for anons) from the character limit? This would let us specify a reasonable but concise limit for the actual content. Shock Brigade Harvester Boris (talk) 04:13, 3 March 2018 (UTC)

If the truncation can be done on displayed characters, that shouldn't much of an issue. Headbomb {t · c · p · b} 04:39, 3 March 2018 (UTC)

Maybe, but I'm not convinced truncation is a solution. The important part of the edit summary may or may not be within the non-truncated portion. It would be better to prevent people from writing essay-length edit summaries (by removing the opportunity to do so) than to truncate them arbitrarily. But I understand that may not be possible. Shock Brigade Harvester Boris (talk) 05:04, 3 March 2018 (UTC)

@Shock Brigade Harvester Boris: We would have to spend some time to determine the best way to design and implement this idea, but it would be possible to exclude usernames (and potentially other links) from the the edit summary length. I think we can find a simpler solution as an alternative, though. I'm really curious to see what the results of the edit filter are to understand which types are surpassing the 255. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)

• No matter what angle we view this issue from, I think a filter to track long edit summary usage is helpful. I've created one at Special:AbuseFilter/904. — MusikAnimal ^talk 07:38, 3 March 2018 (UTC)
  • @MusikAnimal: Thank you! Let's keep an eye on it and perform some analysis on Monday. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)
  • Several editors have pointed out that long IP addresses can fill up much of the edit summary box, making it difficult to fit in anything else within a limited character field. My approach to this, when it occurs, is to manually delete the auto-generated bit of the summary, and replace it with something like "reverted previous IP edit/s", which is very readable and short enough to allow quite a lot of explanation afterwards, should that be necessary. PaleCloudedWhite (talk) 08:46, 3 March 2018 (UTC)
    • @PaleCloudedWhite: The revert and undo auto-generated messages are easily customizable via MediaWiki message. I think it'd be valid to have a separate discussion outside this RFC (there's already a lot going on here) if you wanted to propose such changes. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)

I don't understand what you're saying, as I haven't proposed any changes. I only said that my way of dealing with overly long auto-generated edit summaries is to manually remove them, and add my own instead. PaleCloudedWhite (talk) 18:15, 3 March 2018 (UTC)

@TBolliger (WMF): the thing is, are these suggestions permanent or temporary? You don’t say anything about this in your comment. If they are permanent, then sure there is no convenience at all in having some parts of edit summary cut off by default and not displayed until you click on it. But if they are temporary, then it doesn’t matter and we can put any bandaid to it. This is an important distinction, since we can’t discuss this without acknowledging first and foremost whether or not this 1000 characters long edit summary stays or not. stjn^[ru] 10:21, 3 March 2018 (UTC)

@TBolliger (WMF): It'd be better if edit summaries were capable of being expanded and viewed no matter what page you're on, rather than truncating them on some pages without the possibility of viewing the full summary. Viewing lots of edit summaries is a common action for administrators, checkusers, and oversighters, and having to load a diff page to view the full summaries will make that job considerably more tedious. There's quite a bit of mental overhead if you have to load an entirely new page to view the longer edit summary, especially if you need to see a lot of summaries. There's also the literal bandwidth overhead, since the longer edit summaries on those pages represents only a few kB of extra data, whereas loading the diff page is several orders of magnitude more than that; this is exacerbated if the truncation is performed on the client, since all the data would be transmitted anyway. I remain thoroughly unconvinced that the longer summaries can cause "massive disruption", but collapsing longer summaries seems to be a good improvement to the user experience regardless. --Deskana (talk) 20:03, 3 March 2018 (UTC)

• I'd support an expandable summary on all pages - but the diff page should probably show the full summary by default. ∰Bellezzasolo✡ Discuss 20:15, 3 March 2018 (UTC)

• Yeah, that makes sense. It could be collapsible everywhere with it expanded by default on the diff page and collapsed by default everywhere else, or maybe just not collapsible at all on the diff page but collapsible everywhere else. The former is probably a more consistent experience. I don't really know what I'd prefer. Either would be fine. --Deskana (talk) 20:29, 3 March 2018 (UTC)
• This change makes the code apply only outside of diff viewers. --Gryllida (talk) 03:43, 4 March 2018 (UTC)

• I'd prefer along with truncating, reducing the level to 6 or 700 for non admins, and 1000 for admins. Also, I'd suggest a policy implemented to the tune of Any editor who makes what would generally be accepted as an useless, POINTY, or otherwise excessively long ES regardless of content or length will be warned and if they continue, blocked for disruption. Exceptions are for those who have made 3 or less long ES, even if they are all gibberish {because not everyone will have discovered it, or known that policy was enacted, and through Good Faith may we wanting to test it out}, or for anyoen who copies and pastes their edit into the ES box, whether it is for a TP or any other page. While the practice of copy/pasting your edit into the dit summary box is discouraged and frowned upon, the ban of the practice would be impractical and despotic. Any non AC account typing MORE THAN 250b of gibberish to accompany a blank or so-so edit may be blocked per admins discretion for disruption. Howzaboudat? L3X1 ◊distænt write◊ 22:16, 4 March 2018 (UTC)

Also the word be spread regarding RD policy:

• users may request oversized summaries to be redacted on their UP and TPs,
• for normal articles and talk pages, they may be redacted at admin discretion IF there a plethora of them, ill intent is SUSPECTED (I know I know, but AGF is not a suicide pact), or they are mere gibberish/otherwise obviously unconstructive,
• same for the Wikispace, and on the userspaces of banned of blocked users.
• I do not recommend action to be taken against anyone who may have abused or otherwise experimented with the bug/feature, as some of it was very much POINTY, to illustrate a point to the WMF. The WMF, not being either a Living Person, not part of the en.wiki, is not protected under POINT. :)

TLDR If Iridescent wished to revdel all the huge ES on her page, she could. Basically re-iterating that RD3 and RD6 apply, because my read through of them doesn't convince me that they apply. L3X1 ◊distænt write◊ 22:26, 4 March 2018 (UTC)

I'd say that sanctions for these edit summaries fall under disrruptive editing, we don't need a new policy (perhaps just comment on DISRUPT that this includes edit summaries). POINT is about disrupting WP to make a point. It clearly doesn't matter that the recipient of the point is the WMF. ∰Bellezzasolo✡ Discuss 23:13, 4 March 2018 (UTC)

Trevor Bolliger, WMF Product Manager I'm not thrilled with the options you listed. The long summaries are even worse on diff screens because they're half-width and double-height. I think it's a bad idea to invite wall-of-text summaries in the first place. I'd strongly suggest trying to return to the original Wishlist task. Cap edit summaries at 255 (or maybe 300) characters, and count those characters in whatever way makes technical-sense while providing approximate equivalence for other languages. I don't know if that means "codepoints" or what, but I doubt they are going to nitpick the counting. Alsee (talk) 11:55, 5 March 2018 (UTC)

Community Wishlist Team proposed change

Hi all. The WMF’s Community Wishlist team just had a meeting to look over edits longer than 255 characters and to discuss next steps for this issue. Our team generally agrees with most of the discussions above and believes that 255 bytes is too short and 1,000 characters is too long. We want to land on a sane and agreeable number. We propose 500 characters (technically code points).

Our current plan is to leave the underlying database change in place (making changes to the database is possible, but requires much more time and work and affects all wikis) but change the ‘edit summary’ text input box in all supported editors (e.g. VisualEditor, wikitext editor, new wikitext editor, mobile editor) enforce the 500 character limit. Additionally, we want to help build a gadget or user JS/CSS script that visually truncates long edit summaries where they might clutter the interface. (Gryllida already has a script functioning.)

I’d like to thank TheDJ for summarizing this RFC into a list of problems. We think setting the edit summary limit to 500 characters and sharing an opt-in script to visually truncate longer summaries will address the problems raised.

What do you think? — Trevor Bolliger, WMF Product Manager (t) 23:43, 5 March 2018 (UTC)

That works for me. Sounds like a reasonable compromise for all sides. Now, if you'll excuse me, I'm going to go install that truncation script. Thanks Gryllida! --Majora (talk) 23:48, 5 March 2018 (UTC)

I've gone over the past ~200 edits where the edit summary is over 255 characters (using the edit filter log), and broken down usage into these categories:

• 38% - Constructive / overly verbose. These are well-intentioned summaries, but they might be just a bit too wordy. Some were only marginally over 255 characters.
• 28% - Old school practice of copy/pasting the content you're adding, along with users who add <ref>{{cite web... (etc.) in support of their edit, which is surprisingly common.
• 16% - Constructive summaries from bots, user scripts, and IPv6 reverts. For some of these, it might be good to update the code to truncate after a certain length.
• 15% - Communication where the talk page would be better, including edit warring.
• 2% - Constructively including URLs the summary, such as indicating where copyright violations came from.
• 1% - Outright, unambiguous abuse.

I like to think I have a fair judgment of determining good from bad edit summary usage, but it should be clear this data is strictly based on my own opinion. You of course can go through the logs yourself and draw your own conclusions.

Hope this helps! — MusikAnimal ^talk 23:56, 5 March 2018 (UTC)

@MusikAnimal: So, what is your opinion on what the limit should be? Jack who built the house (talk) 02:56, 6 March 2018 (UTC)

I think 500 as proposed would be a nice compromise. Eventually, I think it'd be better to implement the "collapse" feature, where full edit summaries are allowed, but hidden from view unless you click to expand them. — MusikAnimal ^talk 20:25, 6 March 2018 (UTC)

What about 512, because it's twice as many as 256? Natureium (talk) 20:51, 6 March 2018 (UTC)

511, more likely, but I'll add that it's probably more user friendly to have a "normal people" round number like 500 than a "computer internet tech people" round number like 511/512. ~ Amory (u • t • c) 21:02, 6 March 2018 (UTC)

Yeah, I think here with the proposed change to the frontend we're counting characters not bytes, so 512 wouldn't necessarily translate to anything meaningful in terms of storage. Also, I've just updated Special:AbuseFilter/904 to look for summaries with over 500 characters, so that we can see what we'd be preventing. — MusikAnimal ^talk 21:28, 6 March 2018 (UTC)

Seems reasonable. ~ Amory (u • t • c) 02:55, 6 March 2018 (UTC)

Update: There have only been a handful of people who responded to the Wishlist team proposal I posted on Monday (to set the limit to 500 characters) so I want to check in here to make our team's plans are clear: we will not change the edit summary length from 1,000 characters to any other amount unless there is a clear consensus to do so. The simplest (and our preferred) solution is to leave the edit summary length at 1,000 characters.

The larger survey above is split on opinions between 255 and 1,000 and the discussion here has considerably slowed since this feature released last week. The edit summary is currently set to 1,000 characters and data shows that only 0.33% of all edit summaries have been longer than the previous maximum of 255 characters (and only 0.05% are longer than 500 characters). We've also been keeping an eye on the Edit Filter log for long summaries (which is now only logging summaries over 500 characters) and we (unscientifically) find that most long summaries are actually constructive or are from cut and paste summaries. As many people above have pointed out, there are already policies (e.g. WP:POINT) against abusing any part of the wiki software to be a nuisance.

What do you think? — Trevor Bolliger, WMF Product Manager (t) 01:37, 8 March 2018 (UTC)

@TBolliger (WMF): "we will not change the edit summary length from 1,000 characters to any other amount unless there is a clear consensus to do so" Did you seek ENWP consensus to make the change in the first place? If not, and your policy is to seek consensus before changes, then why not revert to the status quo pending consensus? Blue Rasberry (talk) 01:58, 8 March 2018 (UTC)

We're addressing this discussion based on the current status, data gathered so far, and the information provided in the discussion and survey above. Yes, the planning and announcement of this change should have been more clear (that's on us.) There's support for keeping it at 1,000 characters and we want to avoid whiplash caused by rapidly and repetitively changing this number. — Trevor Bolliger, WMF Product Manager (t) 02:07, 8 March 2018 (UTC)

• Support changing to any smaller number. 500 is definitely better than 1000 (and seems supported by Trevor's stats above). Kaldari (talk) 02:26, 8 March 2018 (UTC)
• Support 500 is a good middle ground. More than 255 isn't necessary in english most of the time, but is occasionally for technical reasons (rollback on long IPs). 1000, is too long. — Insertcleverphrasehere ^{(or here)} 02:42, 8 March 2018 (UTC)
• Support and in the original !voting section I counted 17 editors – distributed between the "Support" and "Oppose" sides – who would prefer an intermediate figure, often specifically stating 500 or a range including 500. They shouldn't all have to come back again before you declare a "clear consensus". If you still don't implement a reduction from 1,000 you should certainly respond to the calls for shortening what is displayed: Noyster (talk), 09:36, 8 March 2018 (UTC)
• Support 500-or-less. The giant edit summaries are too much of a mess on the page, and I think it's counterproductive to invite people to make wall-of-text posts in summaries. Alsee (talk) 11:38, 8 March 2018 (UTC)
• Comment/Question @TBolliger (WMF): I've suggested elsewhere that one possible workable approach would be to leave the technical limit in the backend at 1000 characters (is it bytes or characters btw?) but to make the actual limit on input configurable per project. That would get the developers out of the decision process within that overall technical limit, and would let the community on enwp decide, using their usual processes, to have, for example, 500 characters; Wikidata could decide to have 100 characters; and ruwp and dewp decide to have 255 characters. All projects and numbers are here of course just examples picked out of thin air: the point is that each project could decide their own limits within the upper maximum bound given by the backend. This requires actual support in the software (Gadgets and Common.js hacks would be way to kludgy for this purpose), but would subsequently be handled by the local community without requiring expending developer resources. And, almost equally crucially, it would make the decision to adjust the limit after some time to gather practical experience a much more lightweight one. After, say, a year of running with 500 characters as the limit, enwp could decide that this was too much or too small and adjust their policy, without having to go by way of the developers or run a cross-project RfC to find a limit that suits ruwp and dewp (as random examples). As best I can tell, apart from initial implementation cost, this approach would be able to satisfy all interested parties. Is there some problem with this approach that I'm not seeing? --Xover (talk) 12:10, 8 March 2018 (UTC)
  • The limit is 1000 Unicode codepoints. Which roughly means 1000 characters, but for example combining characters count separately even though the base character plus any combining characters display as one "character". Also, BTW, would you be satisfied your lower limit for the frontend input did not apply to things like imported edits or edits via the API (or edits by people who use a gadget or user script to override the frontend limit)? BJorsch (WMF) (talk) 13:09, 8 March 2018 (UTC)
    • @BJorsch (WMF): Imported edits are not really a problem as best I can tell (they are an exception, and the ability to import revisions is limited to editors with particular bits). But this is (one reason) why there should be built-in support for this: imported edits with very long edit summaries probably needs progressive disclosure (click to view characters beoynd the configured per-project limit, or something like that). For the API, I think it boils down to whether it provides an easily exploitable way to avoid the configured limit. The solution doesn't have to be perfect, but it needs to be tight enough that only defined permitted exceptions (e.g. a particular Gadget is allowed to exceed the limit, and the decision is made when deciding whether to allow the Gadget) and people who circumvent it in such a way that they can be policed by the admin corps (lets say someone polices the edits that hit an edit filter and can crack down on people who maliciously or in bad faith avoid the limit). The way I read the discussions above, nobody thinks the sky will fall if there are the occasional exceptions; it's the length of the vast majority of edit summaries they are concerned about. Personally I have a vague preference for around 250 net characters (that is, when boilerplate, links, and IP adresses are not counted towards the limit), but don't really care all that much about the specific number. I'm mostly concerned with avoiding the needless drama this has caused, and seems set to cause in the future, and placing the decision about this issue where it belongs. Because I don't imagine the developers really care whether enwp allows 250 or 500 characters, but in the status quo they're forced to effectively be the ones that decide that number, with all the attendant grief from those who don't feel like they've been heard or that they've had a real say in the decision. I'm also quite sympathetic to Anomie's point below. --Xover (talk) 14:21, 8 March 2018 (UTC)
      • As a developer, I don't much care what the specific limit is, although with IPv6 255 characters has proven too small. I do care that imports don't have surprise truncation that might cut off important attribution. And I think it'd be useful if cross-wiki bots and scripts didn't have to worry about arbitrary differences in allowed comment length. I also note that omitting boilerplate and the targets of piped links from the count could run into the 65535-byte limit at the database level if someone is piping a lot of particularly long page names, and would mean that no one could edit or delete the boilerplate if it's applicable to their edit. BJorsch (WMF) (talk) 15:06, 8 March 2018 (UTC)
• Support. Sure. MER-C 12:46, 8 March 2018 (UTC)
• Oppose Leave it alone for a while and reevaluate once people have had a chance to get over their change aversion. Let's not reward the small fraction of people who immediately break out the torches and pitchforks any time anything changes here. Anomie⚔ 13:18, 8 March 2018 (UTC)
• Support this and solutions discussed --> here   —  Hei Liebrecht 18:34, 8 March 2018 (UTC)
• I can live with 500 bytes, thanks for being willing to compromise. ϢereSpielChequers 18:46, 8 March 2018 (UTC)
• Support: I think 1000 was far too high and 500 is much more sensible, though I like the idea provided by Guy Macon below too. EdChem (talk) 10:37, 9 March 2018 (UTC)
• Oppose. This is premature. Let's keep gathering data, see what problems actually occur, and think about the best solutions to them. Rushing to decrease the limit based on guesses about what problems might happen is a bad way to operate. (This comment is without prejudice to the change to collapse edit summaries, which I believe to be a good change, and is proceeding ahead regardless of whether this happens or not.) --Deskana (talk) 11:31, 9 March 2018 (UTC)
• Oppose Reiterating already at this stage but this seems to be one of those ideas people can get against with pitchforks and banners but with no real basis. I've only seen "seems too long", "doesn't look okay", "clutter" type of arguments and arguably those are some pretty unreasonble counters to an arguably good change (evidence as presented). --QEDK (後 🌸 桜) 19:30, 9 March 2018 (UTC)
• Support 500, per points by TheDJ in #Identified problems, and by MusikAnimal at the top of this section.   ~ Tom.Reding (talk ⋅dgaf)  21:47, 9 March 2018 (UTC)
• Support 500 as a nice compromise between too long and too short. MarnetteD|Talk 21:50, 9 March 2018 (UTC)
• Support500 L3X1 ◊distænt write◊ 12:43, 11 March 2018 (UTC)
• Support 500 jcc (tea and biscuits) 15:44, 11 March 2018 (UTC)
• Support 500 (as I mentioned in the previous section). Kevin (aka L235 · t · c) 05:55, 12 March 2018 (UTC)
• Oppose changing the limit again. Just hurry up with the truncation fix. I've seen practically none of the foretold abuse from IPs that I keep hearing about. Master of Time (talk) 06:23, 12 March 2018 (UTC)
• Support 500. Good compromise. Truncation also sounds good. Edison (talk) 20:16, 13 March 2018 (UTC)
• Support 500 - I think this is a good compromise as 1000 was very long to say the least. –Davey2010^Talk 21:09, 13 March 2018 (UTC)
• Support 500 or (ideally) less. Do we really need stuff like this? Shock Brigade Harvester Boris (talk) 23:33, 13 March 2018 (UTC)

Update, March 14: Thank you for the comments and sharing your feedback on edit summaries, it's been incredibly helpful! The WMF's Community Wishlist team will be changing the edit summary length to 500 characters in phab:T188798, and the change will release to all wikis in the coming weeks. — Trevor Bolliger, WMF Product Manager (t) 17:31, 14 March 2018 (UTC)

• Weak oppose I feel that this move would conflict with consensus as established in the initial survey above. While a number of us have urged an intermediate figure as a middle ground solution from the beginning of this thread, the significant majority of community members who have responded to this discussion have expressed only a clear consensus for keeping the figure at 1000 characters. Given that the assertion being made here (in favor of a roll-back, partial or otherwise) is that the WMF should be responsive to community consensus on this matter, it seems very peculiar to me that the parties urging for that responsiveness now want to toss out a clear consensus on the matter, and one that arises from a fairly mammoth community discussion.

I say all of this not withstanding the fact that I think an intermediate figure is the logical approach. I simply also feel that a follow up discussion is now mandated (one which is open and obvious and not hidden in a subthread that is not clearly labelled as a survey and which most of the respondents to this thread have clearly missed the existence of), since the approach being considered runs contrary to the approach endorsed by the vast majority of respondents above; only a handful of us added comments specifically endorsing a middle ground figure. It's possible that a majority would be stridently against any reduction and would prefer a 1,000 character limit combined with one of the technical solutions already proposed (such as expandable fields in the edit history), or that they would prefer a figure different from 500 (it's worth noting afterall, that the precise middle ground between 255 and 1000 is 627, not 500).

Of course, the WMF's product team is free to implement this reduction unilaterally, same as the original increase. But insofar as the opponents of the increase called for it to be scrapped because it was not attentive to community needs, those advocates should not be able to ignore the outcome of the very discussion that they called for and shuttle through their next most favorite outcome, even if that second choice clearly conflicts with an express consensus voiced above (which I would summarize as "keep the 1,000 character limit, implement simple technical fixes to mitigate abuse and wait and see if the concerns voiced are a lot of hand-wringing about issues that will ultimately not manifest"). Frankly, the rapid endorsement of this proposal by many who wanted no increase feels only slightly shy of gamesmanship; these parties asserted that the WMF must be responsive to community consensus as the underlying predicate assumption for the initial survey, but just as soon as they realized that they were massively out!voted within the community, suddenly the community consensus that resulted from that survey isn't so important... And not to sound like a broken record, but I do definitely support the middle ground solution; I just think it would be an abuse of process to host the discussion above and then reject the outcome without a clear community mandate. It is, in my opinion, a bad faith move to shift the weight you accord to community consensus based on how it aligns with one's preferred outcome.

@TBolliger (WMF): can I ask you for you stance on this? I really do feel for you and your team, who (for my money) have been more than adequately responsive the community on this matter. But if your objective here is to predicate the ultimate solution on community feedback, I think another discussion needs to be held to see if the community consensus established above can be changed to support for an intermediate figure, a proposal that the large majority of respondents above did not contemplate. Of course, that may not be your objective; you may just wish to find a reasonable solution to land on for the short term, and that's fine too, as far as this community member is concerned. A lot of community volunteers here simply have no full understanding of the degree of autonomy the WMF possesses (and requires as a practical matter) on such issues, and I think if you just want to resolve this issue as quickly as possible, that's fine. But if we (the parties who want a middle ground figure) want to be able to say, at the end of the day, that the 500-character limit is a result of community input, and to be taken seriously when we make that assertion, another discussion is clearly necessary. Apologies to all for the super long post, but I felt the nuance of the overlapping issues here required detail. Snow ^{let's rap} 02:01, 22 March 2018 (UTC)

• By my quick and unscientific count, the original survey has 36 supporting a return to 255 bytes/characters, another 5 who think 300-400 would be ok but no more, 16 who specifically asked for 500-600, 6 who opposed the RFC while saying 1000 was too long without naming a specific figure, and 62 who opposed the proposal without saying 1000 was too much. And I count 7 people supporting the "compromise" in this section who didn't comment in the original survey. I didn't attempt to rate the strength of arguments. Anomie⚔ 03:35, 22 March 2018 (UTC)

• Mind you, I very much predict that, even given those figures, if we started a new discussion with the question of what the limit should be, it's very likely that a majority will move towards a 400-600 range (with significant minorities sticking to their guns at 255 and 1000, respectively). But I'm not allowed to substitute my expectations of community consensus for an actual expression of one (especially in the shadow of a massive community endorsement of another solution which, by its own terms, precludes the speculated-but-as-yet-unproven consensus). Process is important. Snow ^{let's rap} 03:51, 22 March 2018 (UTC)

@Snow Rise: Thank you for your comments and for taking the time to share them with us. There's already been some whiplash with this discussion and I'd hate to change course yet again (especially seeing that this conversation has slowed to nearly a halt.) Now that the 1,000 character limit has been 'in the wild' for nearly one month, we're seeing that there's not a huge amount of folks abusing it — and the existing processes to address disruptive users are effective. We are on track to release the code to limit to 500 characters next week. When the new car smell wears off this new length, if the need for changes becomes apparent we will be happy to participate in discussions about how best to make edit summaries serve all users (while acknowledging the Community Tech team is also responsible for 10 Wishlist items this calendar year.) — Trevor Bolliger, WMF Product Manager (t) 18:27, 22 March 2018 (UTC)

Understood--thank you for taking the time to respond. I do have some lingering concerns that a very vocal minority here managed to leverage a partial rollback out of your team, despite the large majority of community members supporting the 1,000 character limit as perfectly acceptable, pending any concrete evidence of issues. My concern is a little magnified upon hearing that the majority's perspective (that the potential for abuse is over-anticipated by the minority and easily controlled by existing measures anyway) seems to have been born out so far, from the development team's perspective as well. But, all of that said, I can't but appreciate the position you and your team are in and the fact that you'd hardly wish to change course again--and at the end of the day, a 500 character limit is reasonable solution. So I'm pretty satisfied with the ultimate outcome, though I suspect there are going to be a lot of people who responded to the original survey who may be nonplussed. But that's more an issue for the local community than for your team. Again, thank you for taking the time to engage with us. Snow ^{let's rap} 19:32, 22 March 2018 (UTC)

There has been a bit of chaos, but I think everything has been reasonably handled and reasonably resolved. I concur with Snow's assessment that any new discussion would gravitate to a 400-600 range anyway. Per WP:NOTBUREAUCRACY, a prevailing informal agreement about consensus can substitute for a formal process. (Someone could challenge it, but I expect any proposal to raise or lower the number would fail.) I think 500 is a result we can all live with. There's also another important point - I don't think this is a case where anyone wants to even consider an EnWiki-specific value. That would drag down anyone who tried pushing for a new number.

And a thanks to Trevor Bolliger. No one ever forgets to complain, and it's too easy to forget to thank. Alsee (talk) 18:52, 23 March 2018 (UTC)

Proposed alternative solution

In my opinion, setting the limit to 1000 bytes is the wrong way to solve the problem. The right way is to:

• Give the user 255 characters (characters, not bytes) to write a summary.
• Have the software tack on any canned edit summaries such as "Undid revision 000000000 by User:0000:0000:0000:0000:0000:0000:0000:000 (User talk:0000:0000:0000:0000:0000:0000:0000:000)" up to some reasonable limit.
• Make one Unicode character count the same as one ASCII character when enforcing the 255-character limit.
• Count a wikilink or external link according to how many characters the reader of the edit summary sees. Thus [[WP:1AM|1AM]] and [https://en.wikipedia.org/wiki/User:Guy_Macon/One_against_many 1AM] would count as three and four characters (1AM and 1AM).

Professionally-written software should meet the needs of the user, not the convenience of the coder. --Guy Macon (talk) 06:29, 5 March 2018 (UTC)

• Support: as proposer. --Guy Macon (talk) 06:29, 5 March 2018 (UTC)
  • Comment I agree that "bytes" is the wrong way to measure Unicode strings. But "characters" is problematic — it's not clear exactly what "Unicode character" means, when you take things like combining characters into account. You could try to count graphemes maybe, but this is not necessarily trivial, and it doesn't take into account piped links. Ideally I would have the limit based on the actual amount of space the summary takes up, rather than a rule based directly on the source text. --Trovatore (talk) 07:04, 5 March 2018 (UTC)
    • If I read the ticket correctly, the limit is now a 1000 unicode codepoints, not a 1000 bytes. Still not the same as a 1000 characters, but indeed, figuring out what counts as a character is almost impossible. —TheDJ (talk • contribs) 09:01, 5 March 2018 (UTC)
      • You did read it correctly. I note there's also a database limit of 65535 bytes on the entire comment, which might come into play if we were to try to not count various things. Anomie⚔ 13:30, 5 March 2018 (UTC)
• Yes It would be great if Wiki markup for internal and external links would function within edit summaries: Noyster (talk), 08:07, 5 March 2018 (UTC)
  • Edit summaries are not wiki text though. They only support a very limited subset for a reason. Adding external links, would require us to start policing those external links (to potential dangerous locations) as we need to do for articles. I'm not sure if that is a good idea. —TheDJ (talk • contribs) 09:17, 5 March 2018 (UTC)
• Oppose. There are useful situations where one might want to override an automated summary, such as when said edit is by a suppressible username. This seems needlessly complicated to me.--Jasper Deng (talk) 11:00, 5 March 2018 (UTC)
  • Who said that you couldn't override an automated summary? Properly written software would of course allow that, giving you a total of 255 characters for your comment plus the modified automated summary. Only untouched automated summaries would not count against your 255-chaaracter limit. --Guy Macon (talk) 10:16, 9 March 2018 (UTC)
• Support/Comment I think larger space for stored information was long due, just some rules are needed to avoid long-displayed messages such as those of just regular English words. Internal and external links, tags (if that functionality was better integrated), user names, and ips can be displayed in a more compact format, so the limit should be set based on the approximate calculated display width, not characters, bytes or unicode codepoints. For example, allow only for 250 "m" symbols in width (which should take 250 bytes) or 250 emojis -if that was an ok summary, in practice it would be something like CJK characters (which will take 1000 bytes) -but with the above "tokens/special contructions", allow to push for larger amount of bytes as long as the display size is not too long. As a temporary measure, until that can be reliably implemented and agreed by the community, "hide" on display overflows on places like recentchanges, contributors list and watchlist. --jynus (talk) 15:00, 5 March 2018 (UTC)
• Oppose. Collapsing the summaries, as proposed above, is sufficient. This solution complicates things with little benefit. --Deskana (talk) 17:43, 5 March 2018 (UTC)
  • With all due respect, the "this solution complicates things" mentality is one of the main reasons we all go through life dealing with shitty software. You write the software once. It gets used thousands of times per day. Making the software meet the needs of the users is far more important than making the software easy to write. --Guy Macon (talk) 16:18, 7 March 2018 (UTC)
    • I wasn't talking about code complexity. You've explained your solution well, and I think it's easy to understand. I also think a fixed summary length is even easier to understand. Given that I believe there's no harm being caused by the longer summaries, I favour the easier to understand solution. --Deskana (talk) 16:54, 7 March 2018 (UTC)
• Support - this deals with the many issues relating to the need to lengthen the edit summary. In the case I described above, with a long category being deleted/renamed/merged per CFD discussion, the viewer doesn't actually need to see the link target - telling them "CFD" and linking them to the discussion is enough. עוד מישהו Od Mishehu 15:51, 7 March 2018 (UTC)
• Comment - This is a decent idea, but would require some time to implement and might end up being confusing to folks. Personally, I favor the simpler idea of just changing to 500 characters. Kaldari (talk) 02:21, 8 March 2018 (UTC)

• It would indeed require some time to implement, but if designed properly would be invisible to the user. The user would see an unlabeled number (don't get me started on not labeling things...) on the right indicating how many characters she has left. Instead of 1000 the number would be 255 -- and it would be 255 even if Wikipedia helpfully used up 122 of those characters with by prefilling the edit summary with "Undid revision 000000000 by User:0000:0000:0000:0000:0000:0000:0000:000 (User talk:0000:0000:0000:0000:0000:0000:0000:000)". Totally invisible unless someone is looking for it. --Guy Macon (talk) 10:11, 9 March 2018 (UTC)

• Oppose: Sometimes it is important to have an explanation for edits in the summary rather than going through the talk pages. Personally I would have said make it optional so that those who don't want it can opt out. The C of E God Save the Queen! (talk) 09:46, 25 March 2018 (UTC)

List of arguably useful long edit summaries

I think collapsing edit summaries in change lists is a good idea, and I started work on an implementation here. I think the discussion has focused too much on people being stupid and not enough on allowing people to be smart if they want to be. Here is a list of arguably useful edit summaries longer than 500 bytes. I say arguably because you can always say "that should have been on the talk page". The big difference between the talk page and the history is its visibility. I'd just like to put a good word in for people writing useful things in places that are visible. -- Tim Starling (talk) 10:22, 9 March 2018 (UTC)

• /* Veganism by country */ filled out citations; no HTTPS page for Independent.co.uk or Gallup; used archive.is in Reuters and Atlantic citations because Internet Archive's archive was automatically redirecting to a broken page despite saving (Reuters) and failing to go through (Atlantic), no clear reason why, so this will do; perhaps the Internet Archive will cooperate for someone else; no clue why the wikitext diffs look like that, but my guess is too many changes; also punctuation; if the quotes are excessive, despite being recommended, then just remove them rather than revert the edit
• Rving these edits - This article had major reworking done to it to deal with multiple issues and problems in article needed resolving as follows: Lead Rewritten; History deleted, some information moved to Lead; Presenters deleted - this information is not clear on what it means and seems unneccesary; Infobox amended - co-presenters moved to "Presenters" and one location put into HIDDEN TXT until 16th series begins broadcast; Spin-Off episode table amended - it was quite big than needed; Opening Titles, End of Series Special, and Starting Games deleted - these are unreferenced and two sections feature information that is excessive and unnotable; Multiple Issue template on Marketing - issues are what are stated
• Undid revision 828599997 by Stevo1000 (talk) it’s not out of place, if you look at articles about major European cities they all have a similar content. Just because it’s a featured article doesn’t mean it can’t be expanded, especially when Manchester is going through a construction boom. Please stop deleting it, instead you could help improving it. It’s your opinion to think it’s not necessary but Wikipedia isn’t a place ruled by your opinions. Please next time you decide to remove someone’s work, discuss it first.
• /* Official languages */ In Russian language the word "of" is represented by the genitive case, and subsequent case endings. in this case a masculine word takes on the vowel ending "a" in genitive case. this is a common mistake in Russian language even often being wrong in translates such as google translate. In the case of "Republic of Dagestan," Респу́блика Дагеста́н is incorrect and translates as "Republic Dagestan." To correct this we must change the word Dagestan into genitive case to represent the word "of", or in this instance Респу́блика Дагеста́нa
• Additional instances of text which were insufficiently paraphrased from the source material have been removed. Research paper and Refimprove maintenance templates added. These two templates make notice of the article's need to incorporate sources which are of a secondary or tertiary nature, in order to better provide context to the reader. The dense subject matter necessitated the second template, which addresses the need to limit direct usage of scientific journal entries as the only type of sourcing available for this article. Scientific journals may be excellent references for articles, but the readership of those publications are markedly different than those of Wikipedia, and this ought to be reflected in the sources used.
• Correcting links as per example of 884 Priamus. Replacing the direct citations for the inline data with links that actually point to the data rather than the related (but individually useless) journal articles, preserving links to said articles by moving them into the External Links section. There's less metadata in the latter case of course, but there should be more than enough information to preserve accessibility under any realistic sub-apocalyptic circumstance where Wikipedia itself still operates (and author names etc are present within the articles themselves), and the original metadata has been kept as HTML comments just in case. Also, as no (accessible) data could be found associated with the (in any case obsolete) WISE preliminary release (written here to 2dp), and the NEOWISE data only displays to 2dp (but has been written here to an excessive 3dp), the latter has been removed, but its citation tied to the former instead. Also adding km/mi conversion & updating size estimates [truncated at 1000 characters]
• Archiving closed XfDs (errors?): Wikipedia:Articles for deletion/Slavko Dedić career record Wikipedia:Articles for deletion/John M. Puente Wikipedia:Articles for deletion/Vincent LaCrocq Wikipedia:Articles for deletion/Panayiotis Diamadis Wikipedia:Articles for deletion/Jorge Alberto Rodríguez (2nd nomination) Wikipedia:Articles for deletion/David Cowan (journalist) Wikipedia:Articles for deletion/Grant Russell Wikipedia:Articles for deletion/Elmer Stewart Rhodes Wikipedia:Articles for deletion/Moderator of the Sutlej Reformed Church of Pakistan

All but the last one of those could/should be on the talk page rather than in an edit summary. Natureium (talk) 17:03, 9 March 2018 (UTC)

Actually, I disagree. Justifying one's edit directly is most useful in an edit summary; talk pages are useful for discussing prospective edits or working out disputes, but these edit summaries are all doing what edit summaries are supposed to: explaining why you are doing what you are doing. --Jayron32 17:12, 9 March 2018 (UTC)

Your idea of what should be in an edit summary is very subjective and in my opinion, a wrong opinion - the editor above me gives some insight why. --QEDK (後 🌸 桜) 19:28, 9 March 2018 (UTC)

You believe that editors should not explain what they are doing in an edit summary? If so, you're going to have to change the text of WP:ES, which states, and I quote "It is good practice to fill in the edit summary field...as this helps others to understand the intention of your edit" If you believe that the main purpose of an edit summary is something other than explaining your intentions, then I posit that you are the one with an idiosyncratic opinion. I have said nothing that is not long established policy. --Jayron32 19:32, 9 March 2018 (UTC)

But these long-winded edit summaries could have been made more brief and still stated what was changed in the edit. E.g. compare "I added a sentence and reference about the age of onset of this condition because there wasn't any information about that, and moved the section on diagnosis to be above the section on treatment to be consistent with the WP:MED guidelines" with "age of onset; organization per WP:MED". Natureium (talk) 19:39, 9 March 2018 (UTC)

@Jayron32: You've gotten me awfully wrong, I was merely concurring with what you said and replying to the OP. --QEDK (後 🌸 桜) 07:36, 10 March 2018 (UTC)

An other useful one, by AnomieBOT: (BOT) Close discussions for deleted/nonexistent files: [[:File:Tuperware.jpg]], [[:File:Kmchugh.jpg]], [[:File:Carchi Flag.png]], [[:File:Sucumbios Flag.png]], [[:File:Madaba map.JPG]], [[:File:Tena Flag.png]], [[:File:Azuay.gif]], [[:File:EsmeraldasPRVFlag.png]], [[:File:737px-StaffordshireSouthGraph.png]], [[:File:Manabi Flag.png]], [[:File:Satapliasaurus claw fossil.jpg]], [[:File:Pristine-logo2.jpg]], [[:File:TTCL Customer Care.jpg]], [[:File:El Oro.png]], [[:File:TumeloHomeLetterHead.jpg]], [[:File:Turpen.JPG]], [[:File:Napo Flag.png]], [[:File:Orellana Flag.png]], [[:File:Klein Asian Society At KleinISD.jpg]], [[:File:TTP-Logo.jpg]], [[:File:Tulcan Flag.png]], [[:File:Los Rios.png]], [[:File:Tt egyptPuzzl.jpg]] Errors? [[User:AnomieBOT/shutoff/IFDCloser]] עוד מישהו Od Mishehu 09:24, 11 March 2018 (UTC)

Proposed alternative solution #2

My proposed alternative - continue to limit edit summaries to 255 characters, but offer a button saying "my edit requires a long explanation". Upon clicking that button, a user could enter an explanation with no limits whatsoever, and Mediawiki would automatically post this long explanation on the corresponding talk page (including a link to the edit), and the edit summary in the history would read "see talk page" with a link to the section. This is a good way to keep edit summaries short most of the time, while ensuring that things that should be discussions happen in the open on talk pages instead of hidden in edit summaries. Oiyarbepsy (talk) 23:46, 22 March 2018 (UTC)

Observe MOS:FONTSIZE in infobox templates

For clarity, this is about infobox templates, not their transclusions. It will not address how editors use infobox templates in articles. Please limit the scope of discussion accordingly.

Some (or many, depending on your definition) infobox templates contain code that reduces font size for some text elements below the minimum recommended in the last paragraph at MOS:FONTSIZE—85% of the page default size. Unlike most MoS, this is an accessibility issue. At Template talk:Infobox scientist#Font size reduction violates accessibility MOS, I'm advised that explicit community consensus is required to deprecate this usage by the infobox templates.

If the conclusion at Wikipedia:Village pump (technical)/Archive 159#Infobox font size is correct, the default size for normal infobox text is 88% of the page default. Therefore any further reduction below 97% would fall below the 85% minimum (0.88 x 0.96 = 0.845). As {{small}} is a further reduction to 85% (74.8% of page default), and {{smaller}} is a further reduction to 90% (79.2% of page default), this would include deprecation of both of those templates in infobox templates. Finally, according to Template:Small, <small>...</small> is equivalent to {{small}}, so it would also be deprecated.

PROPOSAL

Per MOS:FONTSIZE and MOS:ACCESS, deprecate font size reductions by infobox templates to below 85% of the page default size, including the use of {{small}}, {{smaller}}, and <small>...</small>. This will also apply to all templates that are used primarily or exclusively in infobox transclusions, as they inherit the reduction to 88%.

ADVERTISED AT

Wikipedia talk:Manual of Style
Wikipedia talk:Manual of Style/Accessibility
Wikipedia talk:Manual of Style/Infoboxes
Wikipedia talk:WikiProject Accessibility
Wikipedia talk:WikiProject Templates

Survey: Observe MOS:FONTSIZE in infobox templates

• Support as proposer. Per the lead at MOS:ACCESS, WMF takes accessibility seriously, and the 85% recommended minimum indicated on that page has been in place for years. I see no reason to deviate. ―Mandruss ☎ 23:14, 16 March 2018 (UTC)
• Support as per above. --Emir of Wikipedia (talk) 23:29, 16 March 2018 (UTC)

  @Emir of Wikipedia: Please affirm or change your !vote after addition of the last sentence of PROPOSAL. ―Mandruss ☎ 23:47, 16 March 2018 (UTC)

  Still support, but I think that the templates mentioned originally are the main issue. --Emir of Wikipedia (talk) 23:49, 16 March 2018 (UTC)

• Support I have been manually modifying small in infoboxes for about nine months. Walter Görlitz (talk) 00:37, 17 March 2018 (UTC)
• Support As someone who struggles to read text that's less than 85% of normal page font size, I wholeheartedly support this. Although this discussion should be no more than a re-affirmation of a MOS guideline that is already well established. There should already be no impediment to the removal of styles in infoboxes that reduce the font size. --RexxS (talk) 00:47, 17 March 2018 (UTC)
• Support. There is no lack of space for normal sized fonts, and we should not use "smaller" fonts that are harder to read. I don't think even 85% is justifiable - the infobox text can just be set at 100%. — Carl (CBM · talk) 00:48, 17 March 2018 (UTC)
• Support mostly but {{small}} etc can be used in titles and in |above= without the size getting below 85%. So shouldn't be deprecated there Galobtter (pingó mió) 06:48, 17 March 2018 (UTC)

  Given the purpose of the proposal, I hope we can assume that per common sense, rather than turn the proposal into a legalistic string of hereto's and wherefore's. ―Mandruss ☎ 06:58, 17 March 2018 (UTC)

• Support no excuses for smalling the text. --Redrose64 🌹 (talk) 07:51, 17 March 2018 (UTC)
• Support. It's a no-brainer. Wikipedia takes accessibility seriously; if we are the free encyclopedia that anyone can edit, we should also be one that anyone can read. As noted in the discussion below by others, it's not a healthy habit to think that we need consensus to implement guidelines that already testify of consensus on the matter. – Finnusertop (talk ⋅ contribs) 13:57, 17 March 2018 (UTC)
• Support Clearly. Don't think we need a full-fledged discussion here, Wikipedia:JUSTDOIT. ~ Amory (u • t • c) 15:03, 17 March 2018 (UTC)
• Support. Accessibility is important and, as Mandruss says in the first comment here, I see no argument for doing anything differently in this case. —David Eppstein (talk) 01:33, 20 March 2018 (UTC)
• Support per nom. But wouldn't it be simpler to modify the software so that no text smaller than the minimum can be displayed, not just in infoboxes but throughout the project? Justlettersandnumbers (talk) 10:42, 20 March 2018 (UTC)
• Support and broaden as necessary - We have nav templates, notices, and other things that have this same problem. -- Netoholic @ 13:25, 20 March 2018 (UTC)
• Support per nom. I have just (belatedly) learned that |()=small and {{marriage}} have finally divorced, which is nice. Hopefully there are not very many templates that have similar parameters, and are commonly used in infoboxen. Politrukki (talk) 14:06, 21 March 2018 (UTC)
• Support - Finnusertops !vote particularly stands out for me: "if we are the free encyclopedia that anyone can edit, we should also be one that anyone can read." - The site as whole is useless if you can't read its content ...., Not sure if this is entirely related but for a good few years I've been removing the "<small></small>" from quite a few image captions .... It may look fancy but it defeats the purpose of the object (ie readability). –Davey2010^Talk 16:44, 27 March 2018 (UTC)
• Weak Oppose - I'm afraid I have to oppose this, and, indeed, be the first dissenting vote on this issue. I do not oppose the accessibility of Wikipedia at all, but I do oppose this proposal for several reasons, chief among which is the issue regarding denotation of acting offices and matters of that sort: insofar as those are concerned, there must be a immediately clear manner in which readers may realize that the officeholder, say, was only doing so on an acting basis, for which the current proposal, in my opinion, does not adequately provide, but the usage of {{small}} does. (For the record, bolding the "Acting" bit doesn't suffice, and simply leaving it with a line-break just doesn't mean anything, at least at first glance.) As a modification to said proposal, if the usage of {{small}} were not deprecated, I would agree with it altogether. I am willing to hear other comments on this issue, however. Javert2113 (talk) 22:50, 28 March 2018 (UTC)

  @Javert2113: I don't understand your objection. Can you give a real-life example? ―Mandruss ☎ 22:59, 28 March 2018 (UTC)

  Most certainly. Let's look at the page for Miss Hope Hicks. Now, as it currently stands, it's clearly in violation of WP:NOSTRIKE: the infobox notes, using {{small}}, that she served in her role on an acting basis from August 16 to September 12, 2017. As we all can agree, even for the sake of conjecture, that the information should be in the infobox, removing the use of {{small}} there leaves the reader, in my opinion, somewhat confused: removing {{small}} would more or less signal to the reader that the notice of Miss Hicks's tenure as acting Communications Director is just as important, if not more so, than her assumption of office on August 16th. Perhaps I'm laboring under the incorrect assumption that the former (and incorrect) prevailing style, that of denotation of acting basis with use of {{small}}, is best for readers to understand that, say, Duan Qirui never officially held the office of President of the Republic of China, and that his acting on an interim basis should not be confused with the office he held or a possible lack of authority. In short, what I mean to say is this: removing the use of {{small}} may confuse readers. But I'm probably wrong, and the use of {{small}} is something of a pain in infoboxes. I just worry that there's no real way to denoting acting officers other than {{small}}. Javert2113 (talk) 23:12, 28 March 2018 (UTC)

  @Javert2113: Sorry, I still don't understand. I have removed the {{small}} from the Hope Hicks infobox.[12] How is this now less effective at conveying what you want to convey? ―Mandruss ☎ 23:42, 28 March 2018 (UTC)

  @Mandruss: Quite all right. Let me be as clear as I can be (and thank you for the Hicks bit, though I was planning to do that soon, anyway): I fear some casual readers will be confused by this. That's all. And that's really my only objection. Once the initial shock wears off, I'm sure they'll be fine. Still, I worry all the same. Javert2113 (talk) 23:46, 28 March 2018 (UTC)

  Hmmm. Regardless, see the italicized notice at the top of this thread. We are out of scope and off topic. ―Mandruss ☎ 23:50, 28 March 2018 (UTC)

  True enough. One moment, let me change my vote. I now support this proposal. Javert2113 (talk) 23:54, 28 March 2018 (UTC)

Discussion: Observe MOS:FONTSIZE in infobox templates

With the use of AWB I have been using the find and replace for <small>, </small> and a regex expression for the templates. I have been using the edit summary ""Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections." MOS:ACCESS#Text/MOS:FONTSIZE" --Emir of Wikipedia (talk) 23:27, 16 March 2018 (UTC)

You're speaking of transclusions in articles, I presume. As stated this is not about that, but I appreciate your work in that area. ―Mandruss ☎ 23:29, 16 March 2018 (UTC)

I've found in the past that some WikiProjects have created infobox templates that produce text that is too small, often because they "have always done it that way". Usually, explaining the accessibility problem leads to those problems being fixed, and another group of people helping to make Wikipedia more accessible. If one of the reasons for this discussion is a reluctance of some WikiProjects to change their infoboxes, then it would be worth advertising the discussion at those WikiProjects (if not done already), so that they can have their say and see the other editors' opinions expressed here. --RexxS (talk) 01:15, 17 March 2018 (UTC)

@RexxS: I don't know which WikiProjects you're talking about, but anybody is welcome to advertise anywhere and update the list above. My sole reason for starting this is the advice I referred to above, and I was not entirely surprised to hear that a community consensus is required to get folks to observe a long-standing guideline. It's far from the first time we've been required to get consensus for a guideline, and then another consensus to enforce the guideline. It defies logic, but that's Wikipedia. ―Mandruss ☎ 01:19, 17 March 2018 (UTC)

You had bad advice then. A guideline carries all the weight of the community and an individual editor needs to demonstrate a very good reason why the MOS should not apply to their edits. Primefac has all his facts wrong in that discussion, although I see that Frietjes has fixed the problem for Template:Infobox scientist now. If it's any help to you, there's a way of determining the absolute value of the fraction that any piece of text has relative to normal page font size. If you use the 'inspect' function in a browser like Chrome, you can check the computed value of font-size for a given piece of text. In Monobook skin, normal page font size is 12.7px, and in Vector it is 14px. A quick calculation shows that any text with a computed font-size less than 10.8px in Monobook or 11.9px in Vector will breach MOS:FONTSIZE. --RexxS (talk) 01:49, 17 March 2018 (UTC)

No Chrome. browser like Chrome undefined. Firefox. Anyway, a clear consensus here should eliminate 97% of the problem without need for 'inspect'ing anything. ―Mandruss ☎ 02:09, 17 March 2018 (UTC)

"Browsers like Chrome": Chrome uses the Blink engine as does Opera. That was a fork of Webkit used in Safari, which in turn was a fork of KHTML, used by Konqueror. That may give you an idea of what I meant. All of the major modern browsers have the ability to inspect text on a webpage, For Firefox, right-click followed by 'Q' opens the inspector. You'll find that the ability to ascertain font-size in a given place is vital because you'll simply have folks telling you the text you're trying to fix is more than the 85% limit – as happened to you already. This discussion is irrelevant because nobody's contesting the consensus at MOS:FONTSIZE, but they will contest your ability to identify which text actually breaches it unless you can definitively show that they are mistaken. --RexxS (talk) 13:30, 17 March 2018 (UTC)

Just WP:BEBOLD and do it unilaterally, as I did here and here. --Redrose64 🌹 (talk) 07:50, 17 March 2018 (UTC)

• Just a quick comment on the “long standing guideline” argument... remember that guidelines reflect consensus, and that consensus can change over time. That means that we should periodically check to see WHETHER a given guideline still reflects consensus or not (and IF consensus has changed, amend the guideline accordingly).
  Not saying that the consensus regarding font size has changed. Just saying that it is never wrong to double check. Blueboar (talk) 12:20, 17 March 2018 (UTC)

  Accessibility is basically mandated by the WMF--so whether WP:Accessibility has a "guideline" tag on it rather than a "policy" tag is immaterial. --Izno (talk) 12:59, 17 March 2018 (UTC)

  I'm pretty sure that we shouldn't strawpoll each and every guideline once every few months just to see if consensus has changed. Instead, if someone thinks that consensus regarding some guideline has changed, they can propose amending it. If consensus has truly changed, their proposal should pass easily in absence of opposition. – Finnusertop (talk ⋅ contribs) 14:06, 17 March 2018 (UTC)

  Yes, that approach appeals to both logic and efficiency. Speaking of logic and efficiency, the larger and more important issue is that there is any significant disagreement among experienced editors, on such a foundational question, 17 years after inception. ―Mandruss ☎ 19:13, 17 March 2018 (UTC)

• There is another alternative to removal, which is to set CSS rules for where small (or one of its variants) when small is used inside an infobox. --Izno (talk) 12:55, 17 March 2018 (UTC)
• On a somewhat tangent, navbox and sidebar also sets a smaller font size, and so small should also be deprecated in those places. --Izno (talk) 12:57, 17 March 2018 (UTC)
  • It already is: "Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections." – MOS:FONTSIZE. --RexxS (talk) 13:30, 17 March 2018 (UTC)
    • Deprecated? Removed? Fixed as I suggested as an alternative? Take your pick. :^) --Izno (talk) 13:37, 17 March 2018 (UTC)

Proposal: Reduce scope of "open proxy" policy; soften colocationwebhost blocks; let people who have accounts use VPNs to edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

• Rejected
• There's not a cat in hell's chance, that this's gonna lead to any tangentially different outcome and thus, I'm closing the discussion, to prevent further wasteful expenditure of editorial resources.
• There's an unanimous concensus that whilst there lays a genuinely credible case of good faith VPN users being caught in the cobwebs, that is heavily outweighed by the potential of proxies as an avenue for outright abuse.
• Signed by ~ Winged Blades^Godric at 09:15, 26 March 2018 (UTC)

---

The "open proxy" policy is way too broad. Why are hardblocks (using templates like {{colocationwebhost}} and its cousins) almost always used for VPNs, instead of the softblocks given to other shared IPs? My proposal would change this:

1. The open proxy policy would be changed, so that softblocks are applied to offending IPs.
2. An adminbot would be created to change all openproxy, colocationwebhost, etc. hardblocks to softblocks (using the {{anonblock}} template).
3. After the adminbot was finished, the openproxy, colocationwebhost, etc. templates would be gradually deprecated over the course of 3 to 6 months, and then redirected to the anonblock template.

KMF (talk) 20:20, 18 March 2018 (UTC)

General discussion: open proxy soft-block proposal

• What does the encyclopedia win with this proposal? The Banner talk 21:50, 18 March 2018 (UTC)
• This proposal fails to recognise the tremendous amount of abuse we get from vandals, sockpuppets, spambots, paid editor farms, LTAs, outright nutters, and others who abuse VPNs and anonymising proxies. If you want to know why they're usually hardblocked, that's the reason. We have the IPBE policy for users who want to edit through hard blocks. Meanwhile, neither the blocking policy nor the open proxy policy prescribe either hard or soft blocks, nor should they. -- zzuuzz ^(talk) 08:25, 19 March 2018 (UTC)
• People are entitled to use proxies to protect their privacy, and Wikipedia is entitled to protect itself from abuse. Proxies generate a lot of abuse so, sorry, but no, you will have to use other websites. Johnuniq (talk) 08:44, 19 March 2018 (UTC)
• Oppose meta:No open proxies is a global policy. Our local policy may be more restrictive than it, but it cannot be more liberal than it. Requiring soft blocks instead of leaving it to admin discretion appears to go against Publicly available proxies (including paid proxies) may be blocked for any period at any time. which leaves the type of block to be used as open. We could require hardblocks, as this would be more restrictive than the global policy, but we cannot exclude them from being used.TonyBallioni (talk) 17:26, 19 March 2018 (UTC)
  • I don't think that logic holds up. It says they "may be blocked", but does not require this to be at admin discretion. The admins are subject to the community, and I do not see any language preventing the community from restricting the admins in this way. --Trovatore (talk) 17:46, 19 March 2018 (UTC)
    • Yes, the global policy grants this entirely to admin discretion as what to block. The local communities can make stricter requirements (i.e. not allowing soft blocks), but cannot require more lenient actions against open proxies. TonyBallioni (talk) 18:11, 19 March 2018 (UTC)
      • Can you point me to that language? I don't see it. --Trovatore (talk) 18:21, 19 March 2018 (UTC)
        Here's my point more explicitly: The language Tony is calling out says that proxies "may be blocked", but does not give any special grant of decision-making authority to admins. The ultimate decision maker, when not overruled by the Foundation, is the community. Admin authority flows from the community, not from the Foundation, and the community is free to restrict it.
        I suppose the Foundation could, if it chose, give a direct grant of authority to admins to make that call. But I do not see that it has done so here. --Trovatore (talk) 20:08, 19 March 2018 (UTC)
        • It's more an issue of scope. The NOP policy on Meta is a global policy established by the global community at the time. There are few global policies, but those that do exist tend to allow for local policies to be more restrictive but not less (best example of this are the CU/OS policies). The NOP policy is somewhat unique in that it informs but does not require action. I don't imagine anything would be done if a local community overrode the global policy in this case, since there is no specified authority for enforcing it. But it would make more sense to try to change the global policy if there are factors that make it outdated or less useful than when it was originally implemented, rather than individual projects making exemptions or new rules. -- Ajraddatz (talk) 20:15, 19 March 2018 (UTC)
          • I still don't see, though, where it gives any grant of decision-making authority to individual admins. That's actually my main concern here. A lot of admins have an exaggerated understanding of the decisional (as opposed to technical) aspect of their role, and I think that needs to be challenged when it comes up. --Trovatore (talk) 21:11, 19 March 2018 (UTC)
            • The global policy above explicitly states that open proxies may be blocked for any period of time without specifying what type of block. This is both an explicit and implicit grant of discretion to admins (and our local policy does the same). Explicit in that we can block them for as long as we want, on our own discretion, and implicit in that when admin action is authorized but the exact nature of it is left unclear, it is up to the individual admins on how to use it in line with other policies. Most en.wiki admins hard block open proxies to the point where it has become a de facto policy, but they are also free to soft block if there is good reason. TonyBallioni (talk) 21:15, 19 March 2018 (UTC)
              • Admin actions are subject to appeal to the community, so no, you cannot do it for as long as you want subject (only) to your own discretion. --Trovatore (talk) 21:20, 19 March 2018 (UTC) And again, you're conflating technical ability with decisional authority. --Trovatore (talk) 21:22, 19 March 2018 (UTC)
                • And the global community and the local community have empowered us to do so through the local and global policies. TonyBallioni (talk) 21:27, 19 March 2018 (UTC)
                  • We can override that by a decision of the local community. --Trovatore (talk) 21:30, 19 March 2018 (UTC)
          • (edit conflict) Yes, I think what you say makes sense. We have a local policy on this too (Wikipedia:Open proxies), but it is specifically based on the meta policy. It doesn't make sense IMO, for us to make a more lenient local policy on this than the existing global policy on meta. If there are to be changes, it would be best to happen on meta first, followed by a local RfC to change it (which I suspect would not be succesful if it were widely advertised. We specifically hard block IPs here that have already been global blocked because the en.wiki enforcement of the open proxy policy/our granting of IPBE is stricter than the global enforcement.) TonyBallioni (talk) 21:12, 19 March 2018 (UTC)
            • Well, that's a different argument. Before, you were claiming that the community was not empowered to choose a more lenient standard. I don't think that's true. --Trovatore (talk) 21:19, 19 March 2018 (UTC)
              • As Ajraddatz noted, we typically don't allow more lenient standards for global policies (the standard being the global CU/OS policy): the local community cannot adopt a more lenient standard than the global community (global policies are written by the community as well, not the WMF, though I am unclear on the exact origins of this one.) From a practical standpoint, there's a question of what would be done if our policy was more lenient, which I agree with ajr is likely nothing, but that doesn't mean that we should do something that arguably going to make us more lenient than the global policy on this. Additionally, like I said, there's a snowball's chance in hell of this actually passing if it were well advertised. En.wiki has one of the strongest enforcements of this, and I don't see that changing. Also, pinging @Slakr and SQL: two other local admins who are heavily involved with dealing with local open proxy blocks. TonyBallioni (talk) 21:26, 19 March 2018 (UTC)
                • I think you are wrong that the local community "cannot" allow a more lenient standard. Your first sentence says that "we typically" do not, which may well be true. But that is a different claim. You have not yet given any convincing argument why we "cannot". --Trovatore (talk) 21:30, 19 March 2018 (UTC)
                  • You are simply wrong on this point, and I see no reason to further engage in discussion. Local policy cannot override global policy. TonyBallioni (talk) 21:31, 19 March 2018 (UTC)
                    • You have not supported your claims. --Trovatore (talk) 21:32, 19 March 2018 (UTC)
                    • More specifically, even if we grant that the local community cannot override the "global community", the language you pointed to still does not empower local admins to impose blocks contrary to the wishes of the local community. --Trovatore (talk) 21:36, 19 March 2018 (UTC)
• Oppose Echoing the above by The Banner, what do we "gain"? zzuuzz and Johnuniq touch on important points about the sheer unending abuse these open proxies enable. I see very little benefit versus a lot of possible negatives if this were to be enacted - TNT^❤ 21:44, 19 March 2018 (UTC)
• Oppose based on my current understanding of the situation. IBPE has been liberalized via an RFC so that it should be available to "trusted users" who want to edit via VPN. That seems like an adequate accommodation for the good use cases. Opinion subject to revision if there's something I don't understand. --Trovatore (talk) 21:58, 19 March 2018 (UTC)
• As above, I see a lot of cost, and not a lot of benefit for the project. IPBE is available to editors that meet it's requirements. SQL^{Query me!} 22:02, 19 March 2018 (UTC)
  • I should disclose that I recently edited the IBPE policy to bring a couple of small pieces of language into line with the outcome of the RFC. It was last edited for that purpose last fall, but I think there were a couple of points missed, and I addressed them. I said what I was doing on the talk page, so I feel I was transparent about it, but for further transparency I'll mention it here too. --Trovatore (talk) 22:05, 19 March 2018 (UTC)
• Oppose - we have already liberalized the IPBE policy to allow good-faith editors to edit from proxies if they so wish. The amount of potential abuse coming from open proxies still outweighs the benefit of allowing unrestricted editing from them, though this might change in the future with better targetted blocking options. -- Ajraddatz (talk) 22:29, 19 March 2018 (UTC)
  • Unfortunately it seems that it is not clear that the policy now allows this. That was the outcome of the RFC, but it seems that there is resistance to implementing it. --Trovatore (talk) 23:49, 19 March 2018 (UTC)
• Strike earlier oppose. I was basing my opinion on the outcome of the RFC about IBPE. It appears that this is under dispute. I still don't really think this proposal is a good idea; liberalizing IBPE is much better. But it needs to actually get done. --Trovatore (talk) 23:49, 19 March 2018 (UTC)
• Oppose in general; strong oppose mass-converting open-proxy blocks to soft blocks. Both would allow unchecked mass-creation of sleepers and open Pandora's Box once more. Incidentally, the main reason for colo/webhost blocks is that cloud providers make it trivially easy to ip hop, within seconds, either for free or practically nothing, which makes them effectively free, wide-open proxies. In effect, these blocks make managing abuse actually practical and level the playing field. Support reasonable liberalizing of IPBE (e.g., manually-checked extended-confirmed threshhold and/or clear sporadic-but-positive edit history), as I feel it would be a good idea. In the past, I've readily given out IPBE to those affected by colo blocks as long as they're reasonably assumed to be a legit user (even without CU confirmation), because any accounts they attempt to create from there would have a clear audit trail back for blocking, while any abuse that happens is easily rectifiable. Essentially, false negatives on one's "abuse likelihood detector" are mostly fine when granting IPBE, because it's an equally manual process for both parties (i.e., requestor and grantor), while fixing a false negative (i.e., blocking an actually-abusive user who happens to gain IPBE nefariously and/or revoking the IPBE) eats a trivial amount of time compared to an abuser growing an account to an IPBE-worthy reputation. --slakr^\ talk / 17:03, 21 March 2018 (UTC)

  ... and you know, come to think of it, I might only consider it a "weak support" for IPBE liberalization in the current climate where countries are essentially weaponizing sock farms to influence the elections of other countries—that is, if the vast majority of intelligence agencies are to be believed, which I think we should. In the distant past Wikipedia hasn't been able to avoid that on the small scale as easily, but I do feel like now it's a good sign that Arbcom hasn't really seen much of it lately (if their case load is reflective of the fact) and that the WP:ACDS system + WP:PROT levels work(s) positively for this (and mind you, it really only has a chance to work if we're vigilant about knocking out proxies). That's not to say that those types of bad actors with that type of power and backing couldn't find avenues around these stops to implement their agenda, but as is the recurring case with security online: nothing's going to stop the truly determined, but the occasional reasonable hurdle can easily stop a stampede long enough for your normal defences to respond effectively. --slakr^\ talk / 17:33, 21 March 2018 (UTC)

• Oppose - This would cause a whole heap of issues but the million dollar question is "What do we gain?" ...... Hell and mayhem that's what, –Davey2010^Talk 22:30, 21 March 2018 (UTC)
• Very strongly oppose - the proposer has not suggested how or why this change will be of any benefit to the encyclopedia whatsoever, while there are numerous ways that this will be harmful. Ivanvector (^Talk/_Edits) 11:40, 22 March 2018 (UTC)
• Oppose per all the oppose arguments above. Anyonee who has worked at COIN, SPI, and countering paid editing knows why we need no changes to the current policy, apart from the fact that we have diminishing human resources to check these things. We should preferably be looking at somewhat relaxing the rules for CU instead. Kudpung กุดผึ้ง (talk) 11:45, 22 March 2018 (UTC)
• Oppose, and I considered putting a snow close on this. My position and my contemplated close-statement is: There is significant sympathy for the case of good faith VPN users, however there is effectively unanimous consensus that proxies are an unacceptable avenue for abuse. VPN users might find IBPE to be a helpful alternative. Questions regarding global policy appear to be moot. Alsee (talk) 19:59, 23 March 2018 (UTC)

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

Wikipedia_talk:Requests_for_permissions#Looking_for_consensus

Hi all, this is a notice that I have started a discussion about adding an addition rule to the guidelines for granting for Page Mover and Template Editor user rights. Please feel free to comment. Alex Shih (talk) 17:49, 21 March 2018 (UTC)

Proposal: Don't prompt Registered users for CAPTCHAs in userspace

I was at an edit-a-thon recently, and new (Registered) users were trying to create articles in their userspace sandbox pages on the English Wikipedia. The editing process was clogged up by the need to enter captchas, sometimes multiple times for one page save. Captchas are required on the English Wikipedia if a Registered - i.e. not Autoconfirmed or Confirmed - user is adding external links, as described on Wikipedia:User access levels).

It makes sense to have a captcha if a non-confirmed user adds an external link to an article in mainspace, but in the user's own subpages captchas are much less necessary, and are a significant turnoff. A typical scenario that I saw is that the user would draft an article in Word, including lots of URLs to their sources, then copy the article to their sandbox in order to reformat it in wikitext.

I logged an issue in Phabricator about this and was informed that this change is technically possible, but requires project-level community consensus. Thoughts?

Clayoquot (talk | contribs) 20:34, 21 March 2018 (UTC)

Captcha turned off in User:pages would relieve unnecessary strain - server and user fatigue.Deermouse (talk) 21:19, 21 March 2018 (UTC)

Seems worthy to me to try it. We can always revert back. Could probably also be applied to Draft namespace in that case I presume ? Similar target group. —TheDJ (talk • contribs) 00:02, 22 March 2018 (UTC)

• Linkspam in userspace is a big issue and opening this up will mean massive spam by bots. . Yes it is supposed to be no index but Google does not always follow that and every good SEO expert knows those links are valuable even in no index pages. New users at edithons should be instructed to request Confirmed PERM naming and linking the event leader as one of their first edits. Legacypac (talk) 00:11, 22 March 2018 (UTC)

• @Legacypac: If you have a source for your comment about Google using noindex pages to factor into their PageRank algorithm, please add this to the relevant articles. As a software engineer, I'm very surprised to hear this. TheDragonFire (talk) 08:47, 25 March 2018 (UTC)

'No Index' pages pass and collect PageRank [13] according to Matt Cutts. That makes a Wikipedia link from Draft or Userspace have value to an outside website. Legacypac (talk) 15:15, 25 March 2018 (UTC)

Do you think talking to the developers and getting rel="nofollow" tags added would help mitigate this issue? TheDragonFire (talk) 08:46, 26 March 2018 (UTC)

No SEO now tries to build a natural looking link profile that includes nofollow links. Legacypac (talk) 08:53, 26 March 2018 (UTC)

• Captchas are necessary to minimize abuse. The proper solution for the editathon problem would be to implement Wikipedia:Event coordinator proposal. See WT:Event coordinator proposal#CAPTCHAs. Johnuniq (talk) 00:13, 22 March 2018 (UTC)
• As Wikipedia grows, so does it's popularity with spammers. Every possible tool should be used to help prevent it, and that includes the Captcha. If we don't, the patrollers wont have the capacity to deal it - they are already under stress and strain and almost ready to give up patrolling entirely. There is no evidence that the Captcha creates server fatigue. Your Internet connection or your browser may be slow. What we also need experienced users participating in these discusions who are aware of the challenges we face to keep the Wikipedia clean. Kudpung กุดผึ้ง (talk)

Thanks everyone for your perspectives, and thanks Johnuniq for bringing this up at WT:Event coordinator proposal#CAPTCHAs. That would certainly help for editathons with event co-ordinators who are experienced Wikipedians. Presumably there are also some good-faith human users who run into this issue outside of editathons as well.

Another possible change we could make to significantly reduce CAPTCHA pain for our users would be to prompt for a CAPTCHA only once per editing session. Would that be acceptable from a spambot-deterrent perspective? Or even prompting at every 10 page saves would be an improvement over prompting at every single save. Clayoquot (talk | contribs) 03:53, 22 March 2018 (UTC)

@Clayoquot:, I don't think the once-per-user-session idea will be helpful, I'm sorry to say. CAPTCHA is not foolproof and once a bot got one CAPTCHA pass it would be able to go completely wild as long as it kept the session open. Eggishorn (talk) (contrib) 19:23, 22 March 2018 (UTC)

• Clayoquot makes a good point and I've seen this problem too.. It is quite ridiculous that good faith users at organised events should be penalised and obstructed when they are being trained and encouraged to add references. Wikipedia is the encyclopedia that anyone can edit and its interface should facilitate this. Making people wait four days before they can do this in the normal way is quite silly. Spammers can work around this easily but outreach events have a narrow window and timetable in which to persuade people that Wikipedia is workable and worth their time. Per WP:BITE, "nothing scares potentially valuable contributors away faster than hostility". Andrew D. (talk) 11:52, 25 March 2018 (UTC)

Net neutrality

The Senate is headed for a vote on a Congressional Review Act (CRA) resolution to overturn the FCC’s repeal of net neutrality, but we still need at least one more Republican vote to win. According to FightForTheFuture, pressure from local businesses in lawmakers’ own districts is perhaps the single most effective strategy for convincing hard-to-get lawmakers to buck partisan politics and side with the overwhelming majority of voters to speak out for the open Internet.

Could we perhaps link to https://www.businessesfornetneutrality.com/ in a banner at the top of all pages? --Gryllida (talk) 00:12, 25 March 2018 (UTC)

• Oppose power~enwiki (π, ν) 00:15, 25 March 2018 (UTC)
• No political action please. -- Ajraddatz (talk) 00:39, 25 March 2018 (UTC)
• I strongly support net neutrality and I even tend to rant about it from time to time, but I think it might be good for Wikipedia to be politically neutral. If Wikipedia takes a political stand on just about anything, a certain percentage of users, editors, admins, and etc. will be alienated. Bob Webster (talk) 02:08, 25 March 2018 (UTC)
• I don't think we can. Back when the FCC was going to vote, there was a suggestion to have WP have some similar message to get the word out. I know I supported it, but there's a very strong vocal dismissal of anything that appears to be politically motivated or similar call to action; I doubt that has dissipated since last fall. --Masem (t) 02:20, 25 March 2018 (UTC)
• There is no "we" here with a monolithic political viewpoint. So no. MB 05:04, 25 March 2018 (UTC)
• Oppose in strongest sense. -Wikipedia's neutrality is what we should strive for, it is wha makes Wikipedia great and unassailable.–Ammarpad (talk) 06:21, 25 March 2018 (UTC)
• Comment. It is my view that the Wikimedia Foundation, in consultation with it's communities, is obligated to take any and all action necessarily to protect it's communities' ability to progress towards their goals. This action may at times suffer from a paradox of neutrality (similar to the paradox of tolerance), and this conflict can only be resolved by carefully balancing the threat's effect on our goals and the action's effect on our goals. In the case of the 2012 Wikipedia blackout, a decision was made that the threat presented an overwhelming danger to our continued operation and severe action was taken. My view is there is no blanket prohibition on potentially political action, but that such action needs to be supported by an extensive risk assessment. If you believe that this particular issue deserves such treatment, you are welcome to make your case, however I suspect we have already exhausted our ability to express our view on net neutrality at this time. TheDragonFire (talk) 08:32, 25 March 2018 (UTC)
• Different support This organization knows nothing about free content, open licensing, etc. They need Wiki support, but advertising and named partnerships will neither help them or wiki because their strategic plan actually is ignorant of the basics of a free and open Internet. Instead of asking for the wiki side to do all the work, contact them and ask them for the following:
  • They produce educational inforgraphics, explanatory texts about net neutrality, and a suite of other educational resources. Tell them to apply open licenses to this content and post it to Commons.
  • They have in-house experts helping them design lobbying campaigns and recruit activists. Tell them that Wikipedia is the most consulted source of information for every topic in their field of expertise. Show them the traffic metrics and bring them into a conversation in which you have them compare Wikipedia's traffic with the audience they are reaching in other social media. They should understand that ~100% of activists, journalists, and anyone researching the basics of social issues will review the wiki articles as they orient themselves to the topic and bring themselves up to date. In their network they ought to be able to send someone to edit wiki, and maybe you can organize training and support for them on the wiki side.
  • They organize lots of in-person protests and events. Tell them to train their community organizers to upload good photosets to commons with proper cataloging and documentation.

A partnership with the Wikimedia community cannot be the wiki side giving everything without the other side even understanding the value and significance of it. I know this organization. I appreciate the conversation they are trying to have. I want to draw them and experts on the opposing side to present their best in Wiki's media collection. Blue Rasberry (talk) 11:58, 25 March 2018 (UTC)

• I would support this iff it can be shown that this is an existential threat to Wikipedia. I have yet to see that argument convincingly made. Tazerdadog (talk) 21:31, 25 March 2018 (UTC)
• Oppose we as a movement don't want net neutrality, see Wikipedia Zero. While that program's being winded down, I'm sure the WMF will come up at some point within the next year or so with some idea where it would serve our mission if net neutrality wasn't a thing. When you are the 5th largest website on the planet, net neutrality has the possibility to hurt rather than help. TonyBallioni (talk) 21:51, 25 March 2018 (UTC)
• Oppose We don't need no stinkin' Net Neutrality. GenQuest ^{"Talk to Me"} 22:16, 25 March 2018 (UTC)
• Oppose any activism on the part of Wikipedia, we need to strive to remain politically neutral, regardless of how much I might personally feel about this particular issue. — Insertcleverphrasehere ^{(or here)} 22:18, 25 March 2018 (UTC)
• Oppose: The Internet is not broken, and does not need to be "fixed" by giving the US government more control over the internet. The recently repealed Obama-era net neutrality rules adopted a vague but sweeping "general conduct" standard that gave the FCC the power to crack down on perceived bad behavior by internet providers without providing clear guidance about what would trigger enforcement. --Guy Macon (talk) 22:29, 25 March 2018 (UTC)
• Comment - this is all gibberish to me. Systemic bias or what? The US-based contributors might understand what is going on but I suspect most of the rest of the world, unless IT-savvy, do not. - Sitush (talk) 23:31, 25 March 2018 (UTC)

@Sitush: Your country India organized the biggest protest for net neutrality in the world at Free_Basics#Net_neutrality_criticism_in_India. It brought popular support and politicians speaking out. May be not everyone gets all the details but lots of people have opinions about colonization and can see neocolonialism regardless of IT skills. Blue Rasberry (talk) 23:52, 25 March 2018 (UTC)

Do what? India? I'm in the UK. - Sitush (talk) 23:53, 25 March 2018 (UTC)

Another sort of bias; assuming a country from a username. I get a variation of that a lot. Although I was raised by a family from London speaking the Queen's English (I learned the Americanisms in school), people keep assuming from my name that I am French. That being said, why should the United States Federal Communication Commission In Washington be allowed to have control over the Internet? Why not some government agency in Whitehall? Or Brussels? Or African Union#Headquarters#Addis Ababa? --Guy Macon (talk) 02:14, 26 March 2018 (UTC)

Oh, indeed, I have no idea why the US should control anything and generally would much rather that country stopped trying to represent the world/throw its weight about etc ... but I also have no real idea what this proposal is referencing. I know, vaguely, of the net neutrality paradigm but that is it. And, contrary to popular opinion among people who take me to ANI, I am not an idiot :) - Sitush (talk) 02:18, 26 March 2018 (UTC)

@Sitush: Sorry to presume if there is any reason to object. We have developed India-related articles for years and I imagined that your interest in the place made India your own. Blue Rasberry (talk) 02:29, 26 March 2018 (UTC)

• Oppose. Iazyges Consermonor Opus meum 15:50, 26 March 2018 (UTC)
• Oppose. Stop trying to involve wikipedia in politics. Natureium (talk) 16:18, 26 March 2018 (UTC)
• Oppose - WMF as a whole should not get involved with any of this ..... I personally feel NN should never have been thought of but it has and here we are (coming from a UK bloke) ... Point is we IMHO should not involve ourselves with this. –Davey2010^Talk 16:37, 27 March 2018 (UTC)
• Oppose - I don't volunteer to be part of a political movement, I volunteer to build an encyclopedia. Anything that is not directly related to that, I will always oppose. Dennis Brown - 2¢ 15:50, 28 March 2018 (UTC)
• Oppose - Please don't bring politics into this encyclopedia. Do it elsewhere. Not here. Javert2113 (talk) 22:53, 28 March 2018 (UTC)

Discover Russia. Alumni and Professors

Dear colleagues, please comment on CentralNotice banner proposal for Discover Russia. Alumni and Professors article writing contest. (9-23 April 2018, all IPs from Russia, WPs in ar-de-en-es-fr-ja-ru-zh). Thank you on behalf of Wikimedia Russia, --Frhdkazan (talk) 12:12, 25 March 2018 (UTC)

Death knell sounding for Signpost? Proposals required

Signpost, our English Wikipedia 'newspaper', began when the project was started by Michael Snow who continues to contribute to the English Wikipedia. The first issue was released on 10 January 2005. Begun as a weekly publication, in July 2016 the official schedule was changed to every two weeks, but by November the issues were already running late with the next issue appearing on 26 November and the following Signpost not being published until 22 December three weeks later.

Signpost appeared on 17 January 2017 with a lead article from editor-in-chief, Peter Forsyth, entitled Next steps for the Signpost. Forsyth's article, which explained some of the concerns surrounding the newspaper, received a significant number of comments from readers including one from Blue Rasberry who suggested that a grant may be worth considering:

If there were a rotating internship program at The Signpost for journalism students then from one perspective it seems controversial to pay for content, but from another perspective for years the international wiki community has major projects with major investment which are almost unknown for lack of journalism. (…)This is wiki's own newspaper of record and if it has problems then I wish we could explore options to support volunteers in maintaining it.

Aschmidt suggested that Signpost could be made a blog, or even a journal, with James Heilman, known for his work on the Medicine project responding with 'Sort of like the Wiki Journal of Medicine? It is a fair bit of work. But could be good.' Stating that other related projects are '...experiencing parallel attenuation (...) Better to have fewer issues with excellent content than to fake along for the sake of hitting a weekly deadline' , Carrite makes a poignant reflection.

From August 2017 that weekly deadline became monthly; now in its thirteenth year, the most recent issue was published on 20 February with a note that the next one would be due out on 27 February (a week later?). We now have 27 March. Kudpung กุดผึ้ง (talk) 02:46, 27 March 2018 (UTC)

An indpeendent competing effort, The Citation, appears to have died out as well. Wikipediocracy hasn't had any front-page articles since December. The bread-and-butter article topics of ARBCOM cases, RfAs, etc. occur a lot less frequently than in the past. And personally, I suspect the topics I would be interested in writing about would be viewed by somebody as inappropriate canvassing. power~enwiki (π, ν) 03:39, 27 March 2018 (UTC)

Perhaps, but if you look at RfCs and such, there are now so many — and some of dubious quality or necessity — that it seems honestly hard to keep up with, beyond the specific interests one chooses at WP:FRS. There are so many discussions happening at once, it's a lot to juggle. ~ Amory (u • t • c) 11:07, 27 March 2018 (UTC)

Could part of the issue be the continued success of more focused newletters (tech, admin, etc.)? ~ Amory (u • t • c) 11:02, 27 March 2018 (UTC)

There has obviously been a problem getting workers for a long time, but unfortunately there is also one with readership. The first "News and Notes" of this year has only had 1800-odd views, which doesn't seem a lot. I think the quality remains high - it's a pity more people don't read it. Johnbod (talk) 15:07, 27 March 2018 (UTC)

+450 views through the single-page presentation. Cabayi (talk) 15:28, 27 March 2018 (UTC)

At its bare bones the Signal could be reimagined as a Portal which aggregated the recent featured articles, staffing changes at the Foundation, highest page traffic etc. But that would lack the editorial commentary which is what makes Signpost worth reading, and the release cycle which makes splits it into issues rather than it just being a stream (trickle?). Cabayi (talk) 16:15, 27 March 2018 (UTC)

Possibly newsletters are partly to blame, but certainly not wholly; those newsletters only inform a fraction of the news and action that is (or used to be) reported in Signpost. There are people who work for and on behalf of Wikipedia who have never or rarely edited it and haven't a clue of what's going on and then claim that even major new developments have been carried out in secret. Signpost does have big messaging and mailing lists as well as social media, so it reaches a larger and much broader spectrum of people. Kudpung กุดผึ้ง (talk) 16:26, 27 March 2018 (UTC)

From a production perspective, I think the key issue is the degree of co-ordination and commitment required from multiple contributors. For a period of time I edited a project newsletter, and I found most submitters were motivated by deadlines. So personally I think setting target release dates is still desirable. Perhaps there can be regular issues and supplementary ones: regular columns like the traffic report would continue to be in all issues, but feature articles and op-eds would appear on a less frequent basis. isaacl (talk) 17:35, 27 March 2018 (UTC)

• Fund The Signpost with a WMF grant for a paid administrator I posted a proposal at meta:Grants:Project/bluerasberry/fund a Signpost publisher.

The WMF should not fund Wiki content creation and editorial control - everyone agrees on this. I do think that the WMF should fund the tedious tasks which no volunteer finds enjoyable, but which when completed, amplify volunteer engagement. For various reasons, including 1990s software, the need for secretarial documentation and maintenance of a calendar, and demand for adherence to community values which are excessively time intensive for the niche purpose of running a newspaper, being the publisher of The Signpost is a lot of work. We can get a volunteer chief editor, and writers, and all the roles which are "journalism", but managing the very strange back end of publishing in Mediawiki software is tedious beyond anyone's willingness to volunteer. The least expensive way to manage administration is with payment to someone who will stay out of editorial decisions but facilitate what editors and writers submit.

The reason why we should maintain The Signpost is because it has been uniquely responsible for being the communication channel for resolving community discussions which have allocated millions of US$dollars of WMF funds in ways that would not have happened without community engagement in the community newspaper. Here are some options in front of us:

1. Let The Signpost falter. If we do this, the WMF will invest US$millions in marketing research and strategic planning to come to conclusions which would have arisen spontaneously from volunteer engagement in The Signpost. The Signpost has already proven itself to be an amazing forum for reaching broad consensus in the English and international Wikimedia communities. It has some value and merits some amount of investment for this reason. It has already earned its funding by resolving problems which otherwise are unfathomably complicated, stressful, and high risk to resolve in any other way.
2. Pay US$300,000 to a software developer to make The Signpost easier to publish. These software changes would still be a pain and go obsolete in 3 years because that is how Mediawiki development goes. Editing a newspaper is unlike publishing The Signpost. There is a bottleneck of ability to publish The Signpost and also the administrative support necessary to communicate in the normal way that any contemporary newspaper would operate is not available, because Mediawiki is not set up for this. Lots of people say "just fix the software, do not pay someone to be publisher", but it is crazy hard and crazy expensive to improve software as opposed to just paying someone outright to do the boring parts.
3. Pay ~US$100 per issue to an individual for administering The Signpost. This solves the problem, is cheap, and the money can go to a Wikimedia chapter which needs to be developed. India and Bangladesh would be my first choices because those countries, for whatever reason, have a history of attracting journalists as Wikimedia editors. Also in those economies the money would go further, and the WMF already has plans to spend $1000s to recruit volunteers who will contribute labor that could be purchased outright for $100s. I know that the Wiki community places a taboo on buying labor, but for some tasks, paying someone outreach is a lot cheaper than funding the recruitment campaign that will identify and groom the volunteer who would do the task. Administering The Signpost is esoteric and provides no job training or relevance to actually doing journalism, and the fault is in Mediawiki and the Wiki community's overriding need to publish in Mediawiki.

I advocate for paying an individual to publish as the most practical, cheapest, and most likely path to success for getting The Signpost out. We have content submissions, excellent editorial oversight, and readership. It is annoying that the bottleneck is in administration of adapting weird obsolete software to journalism.

Anyone with ideas might also try to form a The Signpost user group - meta:Wikimedia user groups. This would establish a board to oversee The Signpost, appoint a chief editor, and protect the values of the publication. Blue Rasberry (talk) 21:14, 27 March 2018 (UTC)

One possible reason for the overall decline is that the Wikimedia blog is taking up some of what the Signpost used to do, particularly in terms of research reports and Wikipedia/WMF activities. Don't know how much energy this has bled off from the Signpost, but The ed17 and Jayen466 might have input there. I wonder if the Signpost could incorporate blog links to add to regular features such as the traffic report... I don't know. Montanabw^(talk) 21:23, 27 March 2018 (UTC)

The WMF blog is not run by the community, rather it's corporate communication. It is up to the community to decide whether it will have a voice of its own. That's what the fall of Signpost is all about in the end.--Aschmidt (talk) 21:49, 27 March 2018 (UTC)

• Replace it with something short, snappy, informative and weekly. The Administrators' newsletter could be a nucleus, obviously with a wider topic range and a spot for an opinion piece (limited as to word count). One featured picture is enough: Noyster (talk), 16:22, 28 March 2018 (UTC)

  Well, the Administrators' newsletter already exists, so we would not have to duplicate it, would we? – BTW, thanks for the hint, I didn't even know it even exists, I've just subscribed to it) – Another example for a brief format might be the French fr:Wikipédia:Wikimag. A showcase for a much more lively concept would be, of course, the German de:Wikipedia:Kurier which is, in fact, a multi-author blog that everyone who wants can contribute to. It has become a bit of a nuisance that the German-language Wikimedia chapters have come to use it as a channel for their corporate communication with the community, too, but by and large it still is run by Wikipedians from all projects and colours. Its main advantage over the old Signpost is that you can publish a post whenever it's suitable. There is no weekly, by-weekly, etc. format, and there is no staff that decides what comes in and what stays out. It's a community blog, not a journalists' project.--Aschmidt (talk) 22:57, 28 March 2018 (UTC)

Proposal: Create keyboard shortcut to display User Contributions of other editors

I propose the creation of a keyboard shortcut to enable quick display of another editor's 'User contributions' whilst on either their User Page or on their Talk page.

The combination of Alt+⇧ Shift+G is recommended.

A keyboard shortcut would be a useful alternative to mouse or touchpad movement, and potentially quicker than scrolling down to the 'Special:Contributions' link which (somewhat frustratingly) is buried half-way down the left side of the page within 'Tools'. I suspect it is amongst the most frequently clicked page tool, especially when checking for vandalism or assessing another user's edits. The related keystroke combination, (Alt+⇧ Shift+Y) already exists for displaying one's own contributions, but there is nothing available to quickly list the work of other editors when on their pages. This proposal would address that.

The feasibility of this recommendation has already been discussed at WP:VPT, and a test by Begoon confirms the practicality of enabling this function with the suggested key stroke combination, providing broad consensus to implement this small enhancement is obtained here first. Please indicate your support, or any opposition.

Survey

1. Support (as proposer). Nick Moyes (talk) 11:35, 28 March 2018 (UTC)
2. Support Another keyboard shortcut is always useful. The only concern (as always with issues involving contributions) is hounding users based on their contributions, but this only expedites access a few seconds faster than clicking the tools link, so this should not be a concern with this proposal. E to the Pi times i (talk | contribs) 22:59, 28 March 2018 (UTC)
3. Support No objections here. Just wish I knew how to use keyboard shortcuts. Why do I use Opera again? Javert2113 (talk) 23:15, 28 March 2018 (UTC)

RfC about the future of video summaries of diseases on Wikipedia

Started here Doc James (talk · contribs · email) 20:40, 28 March 2018 (UTC)

Make map frame element available

There is a re-verification of consensus and/or discussion about introducing map frame elements to English Wikipedia as we had requested last year taking place on the Village Pump (technical). —TheDJ (talk • contribs) 15:47, 29 March 2018 (UTC)