This very clearly isn't just "related" to bug 10105, but depends on it; this is merely modifying the default rights set for the functionality requested in bug 10105, so discussion should remain there.

Note that https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement provides similar functionality without the dependency on bug 10105

Other reasons for allowing changing an edit summary:

1. Not all content models support dummy edit. for example it's not possible to do a edit without changing the page's rendering in Wikibase. (which I think it's the most important reason)
2. If others views a list of selected edits, for example using a tag filter, dummy
3. Dummy edit is only a (bad) hack as it doesn't directly resolve the problem.

Change 296630 had a related patch set uploaded (by Sethakill):
[WIP] Allow users to change edit summary

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

There are 2 main difficulties with this task:

1. The user-interface. -- We don't want to add more default elements, especially ones that would rarely be used (relatively-speaking), to the already cluttered and info-dense tracking changes pages (history/usercontribs/recentchanges/watchlist/etc), all of which would need to have this consistently. We could potentially get around this, by just creating a Special:UpdateEditSummary page, and either linking to it somewhere on the tracking changes pages, or just leaving it out and considering it as a semi-hidden power-user feature.

2. The tracking of changes. -- We would need to be able to see the original version of an edit summary. We would need to be able to see any subsequent versions, if more than one change was made. This information would need to be in the logs at the very least, and probably need to be included in the various tracking changes pages, in order to avoid user-confusion, and to provide transparency. It would definitely need to be integrated with all the usual moderation tools (revdeletion, oversight etc). As various comments in the Wishlist survey noted, this would basically be creating a mini-history-within-the-history.

Whilst (1) is potentially easily (albeit imperfectly) solvable, implementing all the requirements for (2) would take many months of effort from a few developers, given the numerous core code changes and database changes that would be required. It would also further complicate the tracking changes pages and logs from an editor perspective.
For these reasons, we're declining this feature-request.

I understand that it would be epic project, and that developers are busy with important things. But, I think it's at least worth reopening as a function request, to be completed as and when (there is no deadline). https://en.wikipedia.org/wiki/Wikipedia:There_is_no_deadline

With the advent of AI technology, I think this is worth revisiting in 2025 in a way that wasn't conceivable in 2016. AI is very good at sifting through text. That gives AI a possible role in sorting out the mess that's the Wikipedia database:

1. An AI bot can generate edit summaries for users who are too lazy to use them
2. An AI bot could go through page histories and add missing edit summaries. There would be a huge backlog, but clearing it is achievable.
3. Longer-term speculation, but MediaWiki needs something better than the current watchlist. One thing that might be useful is metadata tags added to any edits that feed into an algorithm.

Restrict changes to trusted users (e.g. admins, bots run by trusted individuals).

A database log could be kept of any changes to the edit summary. Call it "edit summary change log."

What do you think @Quiddity ?

In T15937#10487825, @Bugreporter2 wrote:

What do you think @Quiddity ?

Officially, I don't think anything has changed regarding either of the 2 main difficulties I briefly described above in T15937#2606108 - Especially the amount of new code-complexity this would require creating - for a relatively minimal benefit.

Personally, I think your new idea #1 might be an interesting feature for some people (but it doesn't seem related to correcting edit summaries; I believe it's more about the initial creation of edit summaries, given that manual-review is almost certainly desired by each end-user).
I would be opposed to the new idea #2 of using an AI to generate edit summaries for old-edits that didn't originally have one, for a variety of reasons, including: Manual-review requirements (to avoid inaccurate hallucinations that generative text engines are prone to), and as people might have left empty summaries on purpose for en:WP:BEANS reasons in some cases.
I'm not sure if new idea #3 is directly related to correcting edit summaries, or if it would be better covered by the Special:Tags system (from a technical perspective).

For this task, I believe it ought to be classified as Low priority, but I won't change it back myself.

I agree with Quiddity and I think these ideas are better placed as separate tickets (i think they have merit in some ways, though low in priority).

I personally don't see the usefulness of correcting edit summaries. I always look at this from the perspective of.. "out of all the thousands of things that we could possibly do and spend time on, would doing this have a large impact on building an encyclopedia (or any other type of wiki for that matter) or the community doing that building" and in that frame, I just don't see the impact.

What i see are a few people that feel a need to make things 'correct'. It's like saying "i like a clean house, so we should build clean houses" but we are not in the business of building clean houses, it's not our purpose. We just need it to be clean enough for most people to function. So for me priority is like bottom of the barrel honestly.

Here's an idea brought up at WP:VPI:

First, call this feature "annotating" the edit summary. Provide an [Annotate edit summary] button that would (1) create a dummy edit whose edit summary included the desired annotation, and (2) simultaneously added an <Annotated> tag to the original edit. Such annotation should be restricted to the original editor. If it was further restricted to the current edit, linking from original edit to its annotation (or vice-versa) would be as simple as clicking the next edit (or previous edit) hyperlinks. If it were not restricted to the current edit, the annotation-to-edit link could be provided by a link in the text of the annotation, but the more needed edit-to-annotation would be more difficult.

We have a similar problem now with reverted edits. The revert’s edit summary points back to the original edit, but from the original edit all you can see is the "reverted" tag, you cannot easily navigate to the revert to see who performed it and when. This could be overcome by having a special search that searched for edits whose summary pointed to the original edit. This same feature could be used both for edits that have been reverted and those whose edit summary had been annotated.

Though not by much, this might be easier to implement than the original idea.

In T15937#11048341, @aliu wrote:

Here's an idea brought up at WP:VPI:

First, call this feature "annotating" the edit summary. Provide an [Annotate edit summary] button that would (1) create a dummy edit whose edit summary included the desired annotation, and (2) simultaneously added an <Annotated> tag to the original edit. Such annotation should be restricted to the original editor. If it was further restricted to the current edit, linking from original edit to its annotation (or vice-versa) would be as simple as clicking the next edit (or previous edit) hyperlinks. If it were not restricted to the current edit, the annotation-to-edit link could be provided by a link in the text of the annotation, but the more needed edit-to-annotation would be more difficult.

We have a similar problem now with reverted edits. The revert’s edit summary points back to the original edit, but from the original edit all you can see is the "reverted" tag, you cannot easily navigate to the revert to see who performed it and when. This could be overcome by having a special search that searched for edits whose summary pointed to the original edit. This same feature could be used both for edits that have been reverted and those whose edit summary had been annotated.

Though not by much, this might be easier to implement than the original idea.

I think that would be more confusing than anything else.

It's just built-in support for dummy edits.

See also: https://meta.wikimedia.org/wiki/Community_Wishlist/W451

Change #296630 abandoned by Hashar:

[mediawiki/core@master] [WIP] Allow users to change edit summary

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

Change #296630 restored by Thcipriani:

[mediawiki/core@master] [WIP] Allow users to change edit summary

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

Using AI to generate summaries for 25+ years of Wikipedia edits would use lot of computing power

So first (1) we should develop it to be run via either calling LLM provider directly or via an agent server not hosted in Wikimedia production; (2) be used with an opt-in basis (e.g. as a gadget).

Developing "changable edit summaries" does not depends on that.