| MGChecker | |
| Mar 2 2018, 11:50 PM |
| F14671153: Screen Shot 2018-03-07 at 5.15.20 PM.png | |
| Mar 8 2018, 1:43 AM |
As outlined by many user in the parent task, the current situation isn't working out at all. This should be reverted until there was a proper discussion what we actually want to do with the database upgrades provided and until the UI is actually capable of dealing with this change without disrupting logs, historys and diffs.
We want to set the limit to 500 characters for all Wikimedia wikis. This should not change the database in any way.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | Feature | None | T6718 Linker::formatComment() should be changed to support lists | ||
| Resolved | TheDJ | T6714 Epic: Increasing the length of the edit summary | |||
| Resolved | Niharika | T188798 Change the limit of the edit summary to 500 characters on all Wikimedia wikis |
I don't imagine anyone would have updated their bots to make use of the extended edit summary in the span of a week.
They haven't, but many of the bots were never coded to truncate at 255 characters, so now they are using more than that, e.g. AnomieBOT. The long bot summaries I've noticed thus far have all looked helpful and not problematic.
The edit filter logged 104 edits with summaries over 500 characters on March 7 (UTC), and many of those edits didn't actually go through because they were disallowed by another filter. Just curious what the discrepancy could be?
Good question. There could be several things, I imagine. I didn't filter the edits by rc_type so all types of edits are counted.
And I think all edits were counted even if they got suppressed afterwards - probably something AbuseFIlter won't count?
There could also be something funky with how comment_id works. I joined recentchanges and comment tables on that field.
Yeah that must be it. The edit filter doesn't track all logged actions. For our purposes I think it makes sense to include everything. I tried running some queries for all logged actions in recentchanges, and the numbers were a thousand or so fewer, likely because some things got deleted since you ran the queries. That being said, our numbers here don't include those to deleted pages, but the percentages probably aren't off by much.
@kaldari — what is the right way to split this work into different tickets? Or can it be tackled in just one ticket?
My preference is to leave the limit as it is, and to collapse or truncate edit summaries in the change list UI. There's no reason to limit the size on the diff page.
Hey Tim, I'm curious what your thoughts are on this. While I think everyone agrees that the summaries need to be truncated in the UI, the current community consensus (on English Wikipedia at least) seems to support reducing the maximum to 500 characters. Personally, I haven't seen any compelling use cases for summaries longer than 500 characters. Most of them so far are just from folks who copy and paste their entire edits into the summary. For reference, this comment is exactly 499 characters.
I think 500 is too long for change lists, I think it should be more like 150. When you require the same length for storage and display, you have to make awkward trade-offs. Edit summaries on Wikipedia are usually much shorter than 500 characters, whereas commit messages in MW git are very often longer than 500 characters. I don't think MediaWiki is fundamentally more complicated than a Wikipedia article, I think Wikipedians are just accustomed to not explaining what they are doing, due to UI decisions by developers.
Proof-of-concept display-side truncation uploaded at https://gerrit.wikimedia.org/r/#/c/417593/
To get a bit more philosophical, my theory is that improving and encouraging communication of the rationale for an edit will help to avoid conflict and anger.
There are other use cases, like linking to pages with long titles or URLs.
If you look at long edit summaries (>200 bytes), they mostly seem pretty harmless:
Should we not have more of that sort of thing?
For a complex edit that changes a number of things in the article, a meaningful, informative point-by-point summary explaining the rationale for each change could easile take 1000 characters or more. But there are plenty UI obstacles to that beyond field length:
OTOH if you decide to allow long summaries it's not hard to nudge users towards making them more useful. For example, the field could automatically truncate at 200 characters on a long copy/paste and offer to add the rest with an extra click.
In any case, experimenting with the English Wikipedia is never a good idea IMO. Make the max length configurable, set it on enwiki to whatever they are asking for, find a small wiki that's interested in playing around with long edit summaries, go back to enwiki once the UI is polished.
I totally agree that we should allow long edit summaries, but none of the examples you cite are longer than 255 characters. If we look at recent edit summaries that are longer than 500 characters, we have: cut and paste of article text, SEO spamming, and excessive wall-of-text arguments. Unlike Gerrit, Wikipedia has talk pages, which are probably the best place to engage in lengthy discussions, explanations, and arguments. That said, I do think that 255 is too short, and that we should truncate aggressively in the UI (with links or hover for full text).
I'll mention one more thing, that the community has been rather vocal about. People also have to patrol edit summaries (just like content), for vandalism. By hiding parts of the edit summary, it will become possible to hide for instance privacy violations and egregious language in the part of the editsummary that is hidden by default, without admins or vandalisme patrollers to notice it quickly.
And yes, people do that, they did it in AFTv5 and they will do it here.
That's not any different from patrolling content though, you need to click through for that as well. Or is this about some patrol gadgets showing the diff but not the summary (on the assumption that it is visible in recent changes anyway) / not being able to handle long summaries?
We as a community should move away from the ‘holier-than-thou’ relationship of English Wikipedia with WMF. If you would not do changes that might prove bad in English Wikipedia, don’t do them in other communities as well. If current trade-off is 500 characters (although I’d prefer the return to status quo), it should be applied everywhere.
Yes, and this is why solutions implementing hiding lengthy summaries in front-end are bad. Edit summaries are not that big of the deal as diffs, so more people would be less interested in them and thus more possibility of less people noticing bad parts of the summary if they are hidden (the more you force people to click on something, the less they do it).
The wishes of the vocal users of the English Wikipedia frequently do not represent what other communities want or find useful.
Or, in at least some cases, what the majority of the English Wikipedia community want or find useful...
Even if that is maybe the case sometimes, in this particular instance we have to remember that no one wanted this change in this way. No community desired this, so it would be disingenuous to throw bones at the community of English Wikipedia and not to fix a self-created problem everywhere. And, on the larger point, it’s not like WMF frequently discusses new extensions and features in other communities as thoroughly as they do in English Wikipedia, so you can’t say that others 100% want something or find everything useful.
Actually I did update AnomieBOT to take advantage of the longer limit a few days after the change was deployed to enwiki. If I hadn't, that diff's summary would have looked more like this one.
I note that making the length arbitrarily different on different wikis could cause problems for imports and for cross-wiki tools and scripts. Since necessary attribution might be in an edit summary we probably shouldn't truncate it to the local wiki's shorter length on import. And consistency would likely be better for tools and scripts, even though we could expose the local limit via the API so they could adapt.
set it on enwiki to whatever they are asking for
I note "they" aren't asking for any one thing. Requests include setting it back to 255 bytes, setting it to 255 characters, setting it to 255 bytes/characters but not counting various parts of the summary, setting it to 400–500 characters, and keeping it at 1000 characters despite the others wanting it lowered.
I also note that most asks, including the current title of this task, are only asking for the frontend limit to be lowered. They're not asking for the limit on edits via the API to be lowered to the same value, or edits made by people who use a user script to adjust the limit applied by the frontend JavaScript or <input> maxlength attribute.
I was interested in that sentence, since despite enwiki's WP:CONEXCEPT exiting certain people still demand that they should have been consulted about any change they don't immediately like.
But then you went on to clarify that you meant something quite different.
That's obviously wrong, many people wanted longer summaries even for ASCII text. It's not even true that IPv6 addresses were the only reason people asked for a longer summary for ASCII text.
(EDIT: I see I got confused below and thought I was commenting on T6714 rather than T188798. The point remains, however.)
Several comments on this very task make that request, including T6714#90316, T6714#90326, T6714#90336, T6714#1460029, and T6714#3289236.
The description of this task from May 2015 until 11 days ago specifically asked for at least 1024 bytes. That number came from the German Wikipedia Community Wishlist, and I note German doesn't use very many non-ASCII characters (i.e. ä, ö, ü, and ß counting as two bytes each was probably not a major factor in that number).
And see also other tasks such as T6712, T6715, T13550, T39356, T99944, and T148296 that make or include similar requests for longer summaries.
And, on the larger point, it’s not like WMF frequently discusses new extensions and features in other communities as thoroughly as they do in English Wikipedia,
That's an unfortunate side effect of English being the only language shared by all staff, and Wikipedia being by far the biggest project.
But, in fact, some features are discussed in depth with some communities. Enough for Deskana to know for a fact that other communities do, indeed, strongly support some features than the vocal enwiki users strongly oppose.
I've read through this entire ticket and all on-wiki discussions that I could find. There's not going to be a solution that makes everybody absolutely happy, but we can try to determine a reasonable compromise.
As Community Wishlist PM, I feel confident in making the decision to follow through with the current title of this task and to change the limit of the edit summary to 500 characters on all Wikimedia wikis on the 2010 wikitext editor, VisualEditor, 2017 wikitext editor, and mobile editor. The Community Tech team will take this into our current sprint, which starts today, and will post on Village Pumps Technical before the release occurs.
As Brad mentioned, the most straightforward way to do this across the board is changing the constant in includes/CommentStore.php:
const COMMENT_CHARACTER_LIMIT = 1000;
We should also take a look at Tim's patch for improving the UI: https://gerrit.wikimedia.org/r/#/c/417593/, although we probably want to track that in T6714 rather than here.
That would be a far more far-reaching change than what the current task description states, it would also make impossible to provide a longer comment via the API. Also makes it impossible to have different limits per wiki (even if it's not a Wikimedia wiki), and might break export/import that involves revisions made while the limit was higher. Adding a new configuration setting which is used in JS and form submit checks is more effort but that's the decent way to fix this IMO.
Why exactly should we create loopholes for avoiding the limit? The problems with export/import and current edits can be solved regardless of this, but making the change only on front-end would be pretty irresponsible and supportive of stuffing beans up the summary.
As a developer, I would rather have just one limit to deal with rather than two, whether it's 500 or 1000. (As an editor, I have wanted comments longer than 255 bytes/characters for a long time, I would have liked it if we stuck to 1000 but 500 will be fine too, the longest edit comment I needed to write since we enabled the longer ones still fits in that.)
Edits that were already saved with the longer comment should not be a problem. Comment formatting code doesn't care about the length (it just formats whatever it got from the database), and the worst thing that could happen to imported edits will be the comment getting truncated to the new limit (you'd run into the same thing when importing edits from a wiki with extended comments, whether 500 or 1000 characters, to a wiki with legacy 255-byte comments, it's not scary).
There's potential for losing attribution at the end of the original edit's summary if it gets truncated on import.
For importing from a newer version of MediaWiki into an older one, you take your chances with things working. The one-time shortening after only having been enabled for a short time seems low-risk, although I'm still slightly tempted to add code so importing bypasses unnecessary truncation. But wikis having arbitrary different summary lengths on an ongoing basis, as would be the case with a configuration variable, starts to be a bit much IMO.
If this is a big concern, then allowing cross-wiki imports to bypass the limit sounds reasonable. Imports are already special. (We probably shouldn't allow it for imports from XML, as a simple mistake could create an insanely long comment.)
But wikis having arbitrary different summary lengths on an ongoing basis, as would be the case with a configuration variable, starts to be a bit much IMO.
Fair enough.
Instead of trying to enumerate everything, you could just say "Change the limit of edit summaries and other comments to 500 codepoints".
On the other hand if it's not a configuration variable non-Wikimedia wikis are forced to use whatever gets decided (in practice) on the English Wikipedia, too. Something that can become the subject of community debates shouldn't be a class constant, that's just bad engineering practice.
I have thought myself that it could be configurable in the past (T185948#3946663), but on second thought it might not be a great idea with the increasing "crosswikiness". We'll implement that, and then someone will notice an edit from Wikidata with a longer summary than allowed on a given wiki in their watchlist, or an Echo notification for a ping with a longer summary on another wiki, and then they'll be angry about it and we'll be implementing edit summary truncation in a dozen new places. If we managed to get everyone to agree on 500, let's not open that can of worms.
That's a fair argument for keeping it consistent on the Wikimedia wikis (although AIUI 500 is way too long for recent changes and UI truncation is needed anyway), but not for hardcoding it. The few cross-wikifarm uses we have (InstantCommons, import) are not really problematic IMO.
No, it's bad engineering practice to blindly add configuration variables for anything anyone wants to configure. Good engineering practice is to weigh all factors, which in this case leads me to decide that a consistent limit is better for cross-wiki interactions and outweighs the complaints I've seen.
Personally I see even this task as appeasement of the complainers whose reasons came down to "OMG people might write longer summaries", which will probably encourage similar "I don't immediately like it, so you must revert" complaining about technical changes in the future, but I'm not going to try to block it.
I want the limit to be kept at 1000 characters. There is no reason to reduce it again. Sure, you can do crap if you want, but vandals and trolls always find ways to get us on our nerves.
If you want to detailly describe what you have changed or especially why you have reverted an edit, the more space you have the better it is. We are used to shorten our edit summaries to a minimum due to the very low 255 limit over the last years. So maybe some people can't imagine that there could really be a need for longer edit summaries.
I also think it is much more useful to have the detailed edit summary linked directly to the edit and not put on the discussion page or somewhere else (as some users suggested).
At least in German Wikipedia, there only where a few people that criticised the new 1000 limit. It is not the idea behind democracy that a loud but small minority gets it's will over the silent majority. So please keep the 1000 characters limit!
There’s a difference between ‘I don’t immediately like it, so you must revert’ and ‘you didn’t discuss it properly, so this was unnecessary’. And no matter how many comments on Phabricator you will provide, this wasn’t discussed properly in the matter of Community Tech request that was a primary goal of this decision.
There’s a talk page for that. Maybe we should make posting on talk pages directly from the edit less tedious instead of deciding that, since it is currently tedious, users should write entire essays in the comments if they wish so.
Current arguments of supporters of this change boil down to this. People sometimes don’t like using doors for whichever reason and opt to try to fit through the pet door, which is the size of a dog. Instead of trying to think for which reasons they don’t use the normal door, we decide to make pet door fit humans. And so, pet door loses its entire meaning.
(sorry for multiple edits)
The most recent Community Tech wishlist proposal was not the only factor behind this change, nor was it the primary goal. Deny it all you like, but longer comments have been requested for years, long before the Wishlist.
The reason I worked on this was actually T161671: the revision database table is very wide, and since it's also very tall on some wikis it's getting to the point where it's making needed database schema changes excessively difficult. We can significantly narrow it by extracting the rev_comment and rev_user_text fields into other tables, so that became one of the projects I've been working on lately. That work continues, BTW.
But since extracting comments to a separate table provided a golden opportunity to also resolve T6715, I included that in the scope of the work. And since doing that unblocked T6714, I added that in too since it kept coming up as a request.
The limit of 1000 was a semi-arbitrary recommendation that I went with based on the years of existing requests. I don't really care much about the actual value, but I am disappointed at the change whiplash due to complaints from people who're upset because they weren't newly consulted about it specifically.
Change 421193 had a related patch set uploaded (by Niharika29; owner: Niharika29):
[mediawiki/core@master] This patch reduces the edit summary length to 500 characters
That's not right, stjn... https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-72cpf7aoefgwkhx/
Change 421193 merged by jenkins-bot:
[mediawiki/core@master] This patch reduces the edit summary length to 500 characters
Change 422560 had a related patch set uploaded (by MaxSem; owner: Niharika29):
[mediawiki/core@wmf/1.31.0-wmf.27] This patch reduces the edit summary length to 500 characters
Change 422561 had a related patch set uploaded (by MaxSem; owner: Niharika29):
[mediawiki/core@wmf/1.31.0-wmf.26] This patch reduces the edit summary length to 500 characters
Change 422560 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.27] This patch reduces the edit summary length to 500 characters
Change 422561 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.26] This patch reduces the edit summary length to 500 characters
Now, obviously the patch has gone live and the edit summary is now limited to 500 characters. I do not agree with this! Only a few people wanted this reduction. Please undo this patch!
@Chaddy: See https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes instead. Thanks.
I agree with you, but at this stage I think moving on would be a more productive use of our time.
You could always start another RFC on-wiki demanding that the change from 1000 to 500 characters be reverted ;)
/me runs and hides