In T284921#7363881, @Pchelolo wrote:

The problems with this features affect only those who have activated it, did I understand that correctly?

Yes and no. Right now ALL logged-in users get uncached page views because of features like this one. The ultimate goal here is to allow cached access for ALL logged-in users. If you live in a part of the world with good internet connection and good connectivity with our primary data centers, performance is not a huge problem for you personally and you will not see a huge difference. But for all the people with less connectivity having cached responses will be a dramatic improvement.

Removing this particular feature will not yet allow us to serve cached responses to all logged-in users - it's not the last blocker, nor it is the hardest one. With this one 0.4% of users will start sharing the cache, the load will go slightly down, performance for you will improve a little bit. Nothing fascinating will happen. But all these are not the reasons for this change. The reason is that it's a stepping stone on the path to the big prize - enabling CDN-cached access for all logged in users. It will not happen instantly after we drop this particular feature, but we need to drop or completely reengineer it, sooner or later, if we want more than half of the world to enjoy performance similar to what the people with good internet connection have.

In T284921#7363813, @Aklapper wrote:

@Chaddy: There is a server side where things are hosted. There is also a client side where things are shown in your web browser. These are two different things.

Okay, even if there are some performance issues, let us decide ourselves if we want to live with these issues. The problems with this features affect only those who have activated it, did I understand that correctly?

In T284921#7362796, @Aklapper wrote:

In T284921#7362790, @Chaddy wrote:

As I understand the text in the box above this feature does not cause big problems.

No. The task description above says "severely degrades performance" and "cache fragmentation".

In T284921#7360996, @daniel wrote:

In T284921#7360597, @Chaddy wrote:

The option to auto-number headings is very useful. I stronly oppose any plans to remove this feature. If you want to remove it, ask the communities locally but don't decide this covertly on Phabricator.

We asked on Meta via Tech News. I realize that this is not obvious to everyone, but it's the best channel I know to get information to all the different communities in their local language. I don't know how to talk to 900 communities in 100 languages directly. Do you have a suggestion?

Can you describe how you use the section headings, and what makes them particularly useful to you? If there is sufficient demand, it's possible to re-implement this using a different mechanism, as discussed above. So far, you seem to be the only one who feels strongly they need this.

In T284917#7361034, @daniel wrote:

In T284917#7360584, @Chaddy wrote:

Only a few people read the tech news. It was not properly announced in the projects. And of course no one could object this when no one knew of this. You're taking the easy way out...

I'd think that local editors who read Tech News would bring it up with their communities if they though it was relevant, and would let know here (or on the relevant talk page) if there were concerns or objections. At least, that's what I would have done when I was a Wikipedia admin. How else could we communicate changes to all the projects in all the languages, with different communication channels and practices? Do you have an idea?

The option to auto-number headings is very useful. I stronly oppose any plans to remove this feature. If you want to remove it, ask the communities locally but don't decide this covertly on Phabricator.

In T284917#7360520, @JJMC89 wrote:

Why do you change such things without consultation of the communites?

See the top of the task description. It was announced, and no objections were raised in the linked consultation.

Strong oppose to this change. Please reactivate this option. Why do you change such things without consultation of the communites? Normally we need a voting for such changes.

In T218511#6049602, @Joeyconnick wrote:

Happening a lot in the last few days, including right now, on en.wikipedia.org

For weeks I had no problems. But today again the error occured. So unfortunately it is NOT fixed! Maybe a new update destroyed the older fix?

The problems occurs almost every time I reload my watchlist. Often entrys are bold I already have seen, even edits I did myself. Also sometimes entrys are not bold although I never have seen them. Furthermore in article histories sometimes diffs are marked as unseen although I already have seen them. Something is really broken here. And it is not a new problem, it occurs since several months! But a short time ago it has become worse. Please fix it asap!

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!

In T188798#4071294, @stjn wrote:

In T188798#4071291, @Chaddy wrote:

I don't see any consensus here for reduction to 500 characters...

There wasn’t any consensus for increase to 1000 characters to begin with...

In T188798#4071270, @gerritbot wrote:

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

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

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.