The current implementation is somewhat of awful. The long size should be depending on what (and maybe how) is something inserted. The edit summary is, in general, a short notice what was done. Some people c&p they fully edit text in there what should definitely never the goal of this feature. Or also classic Uploads got the full file-page as the summary.
E.q. useful for:

• T100231
• T155496
• rTSVN2615

There is a discussion about this at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Turn_off_extended_edit_summaries . It seems that there is a perception that this had been only discussed and decided with the German Wikipedia community, but was rolled out on other projects too. Is that accurate? If not, it may be useful to edit the task description to correct that impression (it currently says "Needs to be further discussed with: German Community" only).

In T6714#4016706, @Tbayer wrote:

There is a discussion about this at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Turn_off_extended_edit_summaries . It seems that there is a perception that this had been only discussed and decided with the German Wikipedia community, but was rolled out on other projects too. Is that accurate? If not, it may be useful to edit the task description to correct that impression (it currently says "Needs to be further discussed with: German Community" only).

Hi @Tbayer, I removed the misleading part of the description, so that only the original description stays. Also it would be great if the team/people who worked on this task could add more details.

I am all for increasing edit summary length for people who are not writing in Latin alphabet, but I don’t get how this was even chosen to be resolved in this way (1000 characters in edit summary for every community) without a large discussion about what communities consider edit summaries to be.

Now, because of wishes of particular community of German Wikipedia [retracted], we are stuck with a summary which is as large as some of articles. This was not properly discussed outside of German Wikipedia and it is frankly astonishing how much unnecessary software bloat their users get to push to global code. Now all communities are stuck with monstrous edit summaries as they were stuck before with RevisionSlider, all because of the wishes of one community. [retracted]

The initiatives like this tell other communities that it’s time to severely stop any involvement of Wikimedia Germany in software changes of Wikimedia movement, because in the end all they care about are minor wishes of a particular community (13 people have caused this, thirteen people). I am sorry, but this is getting completely out of control. [retracted]

UPD: Stroke out misleading parts of my comment because of comment of Lea_WMDE. The general point still stands: this was not discussed properly and it is too major of a change to do without any previous discussion with communities of Wikimedia movement.

In T6714#4016970, @stjn wrote:

I am all for increasing edit summary length for people who are not writing in Latin alphabet, but I don’t get how this was even chosen to be resolved in this way (1000 characters in edit summary for every community) without a large discussion about what communities consider edit summaries to be.

Now, because of wishes of particular community of German Wikipedia, we are stuck with a summary which is as large as some of articles. This was not properly discussed outside of German Wikipedia and it is frankly astonishing how much unnecessary software bloat their users get to push to global code. Now all communities are stuck with monstrous edit summaries as they were stuck before with RevisionSlider, all because of the wishes of one community.

The initiatives like this tell other communities that it’s time to severely stop any involvement of Wikimedia Germany in software changes of Wikimedia movement, because in the end all they care about are minor wishes of a particular community (13 people have caused this, thirteen people). I am sorry, but this is getting completely out of control.

Please check your facts. https://meta.wikimedia.org/wiki/Community_Tech/Edit_summary_length_for_non-Latin_languages "This project was the #2 request on the 2016 Community Wishlist Survey."

In T6714#4016978, @Legoktm wrote:

Please check your facts. https://meta.wikimedia.org/wiki/Community_Tech/Edit_summary_length_for_non-Latin_languages "This project was the #2 request on the 2016 Community Wishlist Survey."

This wasn’t about increasing limit of 255 symbols everywhere to 1000, this was about increasing limit of 255 bytes for non-Latin languages to 255 symbols. I think that checking the facts is needed for those that made a change to use 1000 characters in every wiki, not for those that (justifiably) wanted bigger summaries when using non-ASCII symbols (and I voted on that proposal, too, but it wasn’t about this change).

@stjn I'm sorry for the outdated and misleading information in the ticket, which we now removed. However, we have never worked on this request, and we are certainly not the reason why the extension of the edit summary length was worked on (independent of whether this would be useful or not). This was a wish from our 2013 survey, and we have never started a broad discussion, neither in de-wiki, let alone in all other wikis, since there was never a concrete plan from our side to work on it.

In T6714#4016978, @Legoktm wrote:

Please check your facts. https://meta.wikimedia.org/wiki/Community_Tech/Edit_summary_length_for_non-Latin_languages "This project was the #2 request on the 2016 Community Wishlist Survey."

I would also like to point out that up to November 28, 2017 there was no talk in that task to even attempt to increase edit summary length for everyone to 1000 Unicode characters. Seems like WMF deployers understood what the task was about (increasing a limit for non-Latin communities) and then went to completely another direction on their own (without any community backing on this, since even they understood that Community Wishlist was about something else).

The only reasonable solution at this point is to revert the change that was not discussed (1000 Unicode characters instead of 255 as it was before) and impose client-side and API limits that would return the status quo ASAP.

https://commons.wikimedia.org/w/index.php?title=Commons:Bots/Requests/JeffGBot_3&diff=prev&oldid=290010988

Was this what was envisioned when increasing the edit summary length?

Really?

In T6714#4017816, @AlexisJazz wrote:

https://commons.wikimedia.org/w/index.php?title=Commons:Bots/Requests/JeffGBot_3&diff=prev&oldid=290010988

Was this what was envisioned when increasing the edit summary length?

Really?

Asking in good faith: What's wrong with that example? It seems to me that an editor is trying to explain what they're doing and why they're doing it.

https://ru.wikipedia.org/w/index.php?title=Служебная:Журналы&offset=&limit=500&type=upload&user=&page=&subtype=

I am sorry, but now I am convinced that Wikimedia developers made the most disruptive change of the entire timespan of our movement. Our entire logs like these became completely unreadable because there is no more incentive from the MediaWiki to cut the autogenerated summaries a bit. We have to guess when is there going to be any reasoning for pushing this through. The same seems to happen on Commons and in other projects.

In T6714#4019106, @Niharika wrote:

Asking in good faith: What's wrong with that example? It seems to me that an editor is trying to explain what they're doing and why they're doing it.

The fact that the editor managed to fit his entire 833-characters long comment into a summary field. Which is not for that. At this point people can write their entire blogs in that thing.

In my opinion, this needs to be reverted as soon as possible, as there is no frontend adjustement for this change whatsoever.

I doubt what is currently happening was intended by anyone. While I love increasing the storage to a thousand bytes or more, this shouldn't be directly passed to users. There has to be some reasonable character (not byte) limit (300 maybe), but 1000 is absolutely crossing the line.

What should be done are tweaks with auto generated summaries (IPv6 reverts…) that are making the use of the summary really hard in some cases. I think this data should be stored in a machine readable, localizable json object or something like this (This is supported by the database right now!) Furthermore, there need to be UI tweaks for possible longer summaries (T6717, show/hide links or something like this). If this isn't done, page history and logs become way too cluttered with whole essays of text for productive use.

As I read various stuff related to this, including @brion's / Community Tech's RFC page, it seems the underlying database and backend change to 1000 bytes has happened previously, and that the March event was actually just removing a user interface level limitation to the status quo length (250 bytes or whatever it was). If that is so, then there is existing front end code to limit what editors are allowed to input in this field that can be deployed with a limit in line with community wishes regardless of what the backend technically allows. And in front end code it should be much easier to make this limit based on characters and not bytes, to ease the burden on the non-Latin communities.

And guidelines for edit summary usage should really be set by the community at each project, within the technical limitations of what the backend can handle, but not be tied to whatever is preferable from a technical perspective. 1000 bytes is an upper limit, not a mandated minimum.

But I guess this front end limit might not currently be configurable, at least not on a per-project basis?

In any case, rolling back the db and backend changes now seems insane (the changes are good, the side effects are what's objected to), so I would urge exploring what can be done on the front end to address all constituencies' concerns.

But I guess this front end limit might not currently be configurable, at least not on a per-project basis?

It would not be a great idea to vary per project. At a minimum, wikis would then interfere with each other when some revision is exported and imported to another wiki with lower limit.

In T6714#4020625, @Nemo_bis wrote:

It would not be a great idea to vary per project. At a minimum, wikis would then interfere with each other when some revision is exported and imported to another wiki with lower limit.

Not if the limit is on input to the edit summary: so long as the backend can store, and the frontend display, the data then there is no problem.

Community Tech's current proposal (being discussed at ENWP's Village Pump) is to set the edit summary input on all desktop and mobile web editing interfaces to 500 characters. We will make this change to all wikis.

@TBolliger That sounds like a very good first approach; but I would urge you to keep in mind the possibility, longer term, to make this configurable per project. The discussion on enwp is crystallising a lot of factors applicable to that local project, but needs will differ across projects and making it configurable will allow local consensus to determine the appropriate limit for that specific project's needs. When or whether that is implemented, just having that as part of the requirements will shape the implementation of the short term solution: for example in terms of truncate/disclose functionality for revision history views to deal with revisions imported from a project with larger local limits.

In T6714#4025634, @TBolliger wrote:

Community Tech's current proposal (being discussed at ENWP's Village Pump) is to set the edit summary input on all desktop and mobile web editing interfaces to 500 characters. We will make this change to all wikis.

The rationale for this is still not clear. The change should’ve never happened in this way, the fact that a couple or more of English-speaking editors support upping the limit a bit should not be a deciding factor in whether decisions like this can happen or not. And no, Community Tech should’ve not decided this in the first place without a community discussion, otherwise its name is pretty misleading if you can make changes without any community backing.

Returning to limit of 255 characters should be only option, then decide on cases where there are some problems with it. Not ‘make a change no one wanted and backtrack a bit so you can make undiscussed changes like this in future’.

In T6714#4026145, @Xover wrote:

@TBolliger That sounds like a very good first approach; but I would urge you to keep in mind the possibility, longer term, to make this configurable per project. The discussion on enwp is crystallising a lot of factors applicable to that local project, but needs will differ across projects and making it configurable will allow local consensus to determine the appropriate limit for that specific project's needs. When or whether that is implemented, just having that as part of the requirements will shape the implementation of the short term solution: for example in terms of truncate/disclose functionality for revision history views to deal with revisions imported from a project with larger local limits.

You can configure this limit per project right now. By (ab)using Common.js.

There are a million reasons why this is a terrible idea, but if a project wants to reduce the limit right now for most users, it's possible.

OK, it looks like the initial dust has at least partially settled.

>>! In T6714#4025634, @TBolliger wrote:

Community Tech's current proposal (being discussed at ENWP's Village Pump) is to set the edit summary input on all desktop and mobile web editing interfaces to 500 characters. We will make this change to all wikis.

I think that would be extremely unwise (and rushed) at this point. Please don't rush and keep in mind that the English wikipedia is not the center of the world. I strongly recommend to ask for a wider community input: keep in mind that the wikis most affected with the short summary problems were those writing in non-latin languages. So touch all the communities via means like Tech News and ask for advice on more neutral grounds like Meta.

I am open to support sensible proposals like cutting the length of automatic edit summaries or truncating the display of longer summaries. But I am strongly opposed to rushing with the cutting the (new) length of the summary itself until the positives and negatives can be realistically considered.

Yes, the dust seems to have settled and there is no clear consensus on the ENWP village pump. We will leave the summary and text inputs as-is (1,000 characters) unless there is a very strong and clear demand to do so.

We're going to gather a little more data about how the summaries have been used since March 1.

In T6714#4032654, @TBolliger wrote:

We will leave the summary and text inputs as-is (1,000 characters) unless there is a very strong and clear demand to do so.

I am sorry, what? Didn’t there have to be a very strong and clear demand to up the character limit in the first place?

The decision-making process in Wikimedia movement is broken as fuck. Sorry for obscenities, but after 3 days of hearing non-answers out of WMF team that did this all by themselves this is the least I can say in this situation. Seems like there is no accountability and there is no consensus-seeking at the WMF level anymore. If only every one of us could storm into their respective community and push anything they like without any retaliation from the community at-large.

@stjn — I'm sorry that you're frustrated with this change. Extending this on non-Latin languages was the #2 wish on the 2016 Community Wishlist and status updates were posted on our project page and Phabricator tasks.

The WMF is attempting to have a constructive discussion about next steps but the discussion has waned.

I am stating the second time that I am fully aware that extending the edit summary limit in terms of bytes was a needed change, and I even voted on that proposal. What no one from WMF side seems to understand, it seems, is that that proposal was not about changing from 255 bytes to 1000 characters, and there is no consensus there for that change. It was, as was stated there and as was understood even in some notes from Community Tech team there, about changing the edit summary limit from 255 bytes to 255 characters. Nothing else.

I don’t understand why this is so hard to understand, and I don’t know why there is such a need to defend this unwanted change through this method in particular, when it is not what that proposal was about (as we can clearly see from its text and from Community Tech’s notes) and to state that it was about 255→1000 change is a clear misrepresentation of wishes of respective non-Latin communities (which no one bothered to ask on this, to be completely fair, so far we’ve seen only feedback from English Wikipedia, and some people there maybe want some higher limit too, but it is not their prerogative to decide this).

I agree with @stjn. This change has nothing to do with the community wishlist proposal (which isn't consensus anyway). Non-latin languages have their problems solved already if we move to 255 characters instead of bytes.

Furthermore, the Village pump discussion is actually distorting the community opinion quite much, as it provides 255 and 1000 as only alternatives. If you actually read the reasons provided by the people opposing a revert, many state something around 500 characters as a good, sufficient compromise. Others state summary problems with IPv6 that clearly aren't a problem anymore with more than 400 characters. I don't see a basis to let stay with 1000 considering this, but go to 500 characters as was proposed just yesterday (??) by @TBolliger.

I see no reason not to implement the 500 character compromise.

There was definitely a gap in non-technical documentation on this ticket, the Wishlist project page, and elsewhere. A Wishlist product manager should have kept them more up-to-date, but did not. That's our bad. I'm going to update all the applicable pages now.

Given that this change has released, I think the best discussion we can have is around "what effect are extended edit summaries having on wiki" and "what, if anything, should we do to respond to the change. Reverting this change will have adverse side effects (technical and likely social) a I'd like to avoid any unnecessary whiplash. As a product manager, I think reverting will do more harm than good and we should not make any changes until we are sure they will benefit the majority of users.

English Wikipedia's Village Pump discussion has slowed to a crawl, it now seems the original RFC was a knee-jerk reaction. I will post in the discussion to see if the lack of comments reflects a silent agreement for our proposal of 500 characters, or if people have stopped caring and the 1,000 character limit is acceptable. We also need to check on other wikis of other languages, I'll post on Meta looking for help.

As for T6717 and other suggestions on how to visually truncate/handle long summaries — I think these are best handled as gadgets or user scripts.

Change 417593 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/core@master] [WIP] Display-side truncation of edit summaries with expand button

https://gerrit.wikimedia.org/r/417593

See this on how some very long summaries make logs , diffs and history page less usable.

Edit summary should be a short summary of edits, not the whole story of life. Somebody already wrote a 1000 characters long vandal summary on the Finnish Wikipedia, that only contained "j" letter and it had no any spaces, so it broke the interface design and we had to revdelete the summary. 500 characters should be more than enough.

@Stryn: How is that anecdote related to this task? I can also type a 255 characters long vandal summary that only contains the letter "m" and the very same problem happens. Feel free to file a separate task about layout breakage as this feels unrelated to the topic of this very task.

In T6714#4056428, @Aklapper wrote:

@Stryn: How is that anecdote related to this task? I can also type a 255 characters long vandal summary that only contains the letter "m" and the very same problem happens. Feel free to file a separate task about layout breakage as this feels unrelated to the topic of this very task.

Yeah, this is more about the need to do something like this in the global CSS rather than about long summaries.

Yeah, this is more about the need to do something like this in the global CSS rather than about long summaries.

This too to include the case with watchlist where items grouping is set to "on".

Change 417593 abandoned by Tim Starling:
[WIP] Display-side truncation of edit summaries with expand button

https://gerrit.wikimedia.org/r/417593

I want to join those who claim that the problem with IPv6 reverts is persisting. And I honestly do not understand why this thing should not be attacked broadly. IPv6 reverts are an example for the fact that ~250 characters are sometimes too little space, not the one oddity to an otherwise perfect limit, when Latin script languages is the point of reference.

Is there anything left to do here?