Any suggestion how it should handle the case of the edit summary already being the maximum size (or close to maximum size)?

Also, what would be the desired behavior when multiple sections are added in the same edit?

The simplest enhancement would be to simply look for the equivalent of clicking "New section" on a talk page, and make it work the same way that does. i.e. the diff for the edit just shows additional text being appended to the bottom of the page, *and* the beginning string of that text is recognized as a section header: A series of === followed by text followed by a series of the same number of ===. In the rare case that a section header exceeds the summary limit, just truncate it. I tested on my talk page and found that I could exceed the maximum in the box for entering the section header in the "new section" interface, and indeed it was truncated. Practically speaking, I have never seen a section header so long that it maxed out the summary limit.
https://en.wikipedia.org/w/index.php?title=User_talk:Wbm1058&offset=20151117033000&action=history

When multiple sections are added the summary should use the first one added.

Now if you want to support recognizing new sections created inside the middle of a page, say a subsection 3.1 added to a page that already has a section 4, that might be trickier, but I think still doable with the right regex for recognizing new sections. But just a "new section" at the bottom would be my first priority.

Actually, on second thought, if text is edited in more than one section at the same level, then it's no longer a "section edit" but a full article edit, and there should be no section link in the edit summary. But if a new section is appended at the end which includes sub-sections of that section, then the edit summary should link to the new section added, not one of its subs.

The endorsement comment at https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Editing#Generate_automatic_summary_.2F.2A_blah_.2A.2F_when_I_manually_add_a_section_heading_when_editing makes a good point: "Having the wrong section indicated is worse than having no section indicated at all." See this diff: https://en.wikipedia.org/w/index.php?title=User_talk%3AWbm1058&type=revision&diff=691137594&oldid=691061620 I edited my talk page clicking "edit source" at the "Virginia Tech Project Invite" section, then my only addition was the "New section test" section. My exit summary should be →‎New section test , not →‎Virginia Tech Project Invite ... this is arguably a BUG, not just an enhancement request. I didn't actually change anything in the Virginia Tech Project Invite section at all!

Thanks for the clarification @Wbm1058. Your last example does seem like an especially bad outcome as anyone following the section link will be confused. My estimation is that this would be relatively easy for anyone familiar with the editing and parsing code. However, those are some of the oldest and cruftiest parts of the MediaWiki codebase, so most people would be reluctant to mess with it. We would also need to make sure that the change didn't have an adverse effect on save performance (running complicated regexs on large articles can be slow). It does seem like it would be a nice improvement to have, though.

In my ~18 year career as a programmer, I specialized in fixing old and crufty code. Very little of my work was greenfields-type development. I know the shiny-new stuff like Visual Editor is more fun to work on for most, but y'all need to have people on staff who have a talent for wading into cruft and fixing it without breaking things. And hopefully actually enjoy that kind of work. Personally, I think all developers should cut their teeth by demonstrating that they can do this type of task. You learn things by working on other people's code. I'd only let developers work in a greenfield after they demonstrated their abilities in the cruft. Note that here, I've taken over two bots and have them operating successfully without much downtime or drama. /soapbox

@Wbm1058: I don't disagree. I'm just trying to set realistic expectations :)

Another nice to have enhancement related to this. If I edit a section, and change the section title, then change the title accordingly in the edit summary, e.g.:
https://en.wikipedia.org/w/index.php?title=List_of_minor_planets_named_after_places&diff=prev&oldid=693821412

Thanks Ricordisamoa, for linking T67989. Well this is interesting. Maybe this javascript can be leveraged to complete this task?
https://de.wikipedia.org/wiki/Benutzer:Perhelion/sectionSummary
https://de.wikipedia.org/wiki/Benutzer:Perhelion/sectionSummary.js

In T22307#1891350, @Wbm1058 wrote:

Maybe this javascript can be leveraged to complete this task?

Then it wouldn't be reusable for Pywikibot; also clients written in PHP, Java, Ruby would have to reimplement it. How about the server side?

I've been asked to look at this task for a quick assessment of difficulty.

At a guess, to do this quickly and poorly (e.g. with an extra button to trigger the fill-in) this could be done in a day or less, though at considerable cost in terms of adding UX complexity to an area that already performs very poorly in testing, and a poor performance impact (every keystroke would need to be monitored for potential action), with poorly-defined outcomes in situations like long section titles or multiple sections added and would only help users of Javascript browsers on the desktop Web site, mucking things up for bots, apps, people on old browsers or slow connections, and mobile users. As such, I'd probably veto an attempt to do this in this manner, as the benefit would be significantly out-weighed by the cost for all our users.

It is difficult to see how one could do this "right" with the wikitext editor's edit form as it currently.

• Adding it automatically server-side after the user clicks save without user prompting would be very poor form, and goes against our user expectation models.

• Adding it automatically server-side after the user clicks save and then prompting the user with an interstitial to confirm their assent would be disruptive and unwelcome (generally, anything that gets in the way of users saving is not great and has to be over-whelmingly useful to merit inclusion), and wouldn't help the bots use case.

• Adding it automatically client-side before the user clicks save, with a little prompt to the user to cancel it could be neat. Not sure how it'd work, and it suffers from the JS-only and performance problems I mentioned above of a hacky solution. Potentially this could have a server-side alternative option, but it'd at best be human-interactive, which still doesn't serve bots.

• Having a client-side prompt which pops-in as you write, letting you insert (or remove) such details could be neat, and could include other prompts similar to a number of community gadgets to prompt people with common change summary reasons. This'd be (a) hard to get right and (b) as always, doesn't serve the bot use case, but probably could be quite compelling.

In short, I don't know. Good ideas welcome.

@Jdforrester-WMF: Thanks for the detailed assessment!

You don't need to overthink this. Nobody is asking for an extra button.

"Adding it automatically server-side after the user clicks save without user prompting would be very poor form, and goes against our user expectation models." Why?

So I click "edit section" on the last section of a talk page, the section is titled Need reliable sources to confirm birth date

In the edit window I add the text at the bottom of that section:
== We should update the photo ==
The picture in the infobox is ten years old. Can someone find a newer picture and update that?

The default edit summary... before I typed any of the above... is:
/* Need reliable sources to confirm birth date */

To which I add:
/* Need reliable sources to confirm birth date */ The infobox picture is old

and then click "save". Now, many novice (and even some experienced) editors don't fully understand how section-links in edit summaries work.

Are you saying that a reasonable editor would *expect* that edit summary to be left unaltered, and would be surprised and shocked to see it changed to:

/* We should update the photo */ The infobox picture is old

without explicit notification of this change, and obtaining their explicit consent?

That they intentionally want to mislead their fellow editors into believing that they only commented on the need for reliable sources to confirm the birth date?
That they intentionally want to confuse their fellow editors?
That they are not expecting the server-side to automatically fix the default section, as a matter of convenience, saving them the trouble of doing it themselves?
That they would not be annoyed by your "are you sure" prompt to confirm the correct section link? A. Why of course. Wasn't my intention obvious?

I personally would support a client-side version, as I've already written a script to this (some time ago).
As community developer I'm interested in working on this task and I would slim down "my version" for a more general usage.

I mean a @prompt could maybe a good idea for a default pre filled section title on some pages like: https://commons.wikimedia.org/wiki/Commons:Graphic_Lab/Illustration_workshop (on German WP are more, it seems now in the English WP this feature get removed all over) But this is near another task.

The Wikimedia-Hackathon-2016 starts tomorrow and this task is featured at T119703. We want to use T130776: Wikimedia Hackathon 2016 Opening Session to promote these projects and help recruiting volunteers to work for them.

If this task is ripe for hackathon work, please follow these instructions. If it is not ready, remove it from T119703 in order to avoid volunteers' frustration. Thank you!

In T22307#2049003, @Jdforrester-WMF wrote:

Adding it automatically server-side after the user clicks save without user prompting would be very poor form, and goes against our user expectation models.

I think this would be acceptable and only a bit iffy. We auto-generate some edit summaries, if none is provided, without asking the user (e.g. when a new page is created, or when a page is blanked). I'm not sure if people generally consider the /* blah */ part of "their" edit summary, anyway.

Thanks for that, matmarex. You said it more succinctly and much better than I did. Right, the Mediawiki software should not consider the /* blah */ to be part of the user's edit summary at all. Rather, it is a Wiki-section-link (using a different syntax than the usual [ [ #blah ] ]) to the single section that the user edited. This should not even be directly under user control. If the user edited more than one section at the same heading-level, then the software should remove the /* blah */ or change it to the next higher level section that includes all sections which were edited. If the user edited just one section (which may or may not include sub-sections) and the /* blah */ is not there, then the software should add it. If the /* blah */ points to the wrong section, then the software should fix it. That's the ideal complete solution, but any partial enhancement that just addressed a subset of all the editing scenarios would be an improvement.

I see that this was not one of the "lucky eight" that got worked on at the 2016 Hackathon. Seems to me like something that could only be knocked off in a weekend by someone already at least somewhat familiar with the code responsible for this. Anyone else would need more time to get up to speed, or a mentor who was more familiar with the code who could give some broad guidance on what needed to be done and how to go about it.

Change 281470 had a related patch set uploaded (by Bartosz Dziewoński):
Generate automatic summary /* Section */ when a section heading is added manually

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

@matmarex Hey, I'm wondering if you could give a status update on this task. Is the previous patch still ready&waiting for review, or does it need further work first? Ty!

@matmarex if the task still needs more work, and an Outreachy intern's help( Dec 6 to March 6 ) would benefit, please let us know and we'll feature this task.

Applications are open until Oct-17.

@Quiddity @Sumit The patch here is mostly complete, except for the items listed in the commit message. I don't think it would work as an Outreachy task. :(

I looked at this again during the 2017 hackathon and updated the patch. The feature is now implemented and seems to work fine, but I've ran into some CI troubles. But hopefully this will actually move forward soon!

Change 356140 had a related patch set uploaded (by Thiemo Mättig (WMDE); owner: Thiemo Mättig (WMDE)):
[mediawiki/extensions/Wikibase@master] Add test for EntityHandler::getAutosummary

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

Change 356140 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add test for EntityHandler::getAutosummary

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

Got asked about this by @Wbm1058 at WCNA 2018 again. Tried to help it along, but I got stuck on the change. Don't really know enough about this area of the code to quickly diagnose what was still wrong with it. Assistance would be appreciated.

I agree with the concerns @Jdforrester-WMF brought up: having it done server-side after the page saves would definitely go against my expectations. If it ends up implemented this way, it should have a very clear opt-out mechanism (or perhaps even be opt-in). Also, perhaps it should be opted out by default for those who already have the "Prompt me when entering a blank edit summary" box checked (not sure if there's really any correlation there, though).

More specifically, there are many ambiguous cases. Let's say I added a subsection to an existing talk section (not a particularly common task, but sometimes it's useful). Would the edit summary update to the name of the subsection? I might want to choose what subsection level the edit summary appears.

In T22307#2177745, @Wbm1058 wrote:

This should not even be directly under user control.

I don't think this narrow issue is the venue to discuss such a broad change; I think such a change would merit an entirely separate ticket. Having the section link be independent from the rest of the edit summary would diverge signficantly from the current implementation. In doing so, you would be taking away editor's freedom in how their edit summary formats, with either the justification that "it's what the user wants" or "it's better for the wiki if edit summaries target the correct section"; I'm not sure if these are sufficient justifications. Furthermore, this is especially problematic when issues like T69068 remain; the automatically generated edit summary would be incorrect in those cases.

OK, so every time I try to move a page over a redirect the software breaks in with 'The destination page " " already exists. Do you want to delete it to make way for the move? (Check the edit history.)' How dare it do this AGAINST MY EXPECTATIONS! Just move the page and stop running interference.

But, if you can get away with doing that, what is the big deal with popping up a preview of the summary and making the editor click SAVE a second time. Oh the horror.

And if the editor INSISTS on changing the auto-generated summary from == Requested move 17 May 2019 == to == Go to hell == just let them do that, because you love to enable trolling your good-faith contributors.

@Wbm1058: Even if you may have reasons to be annoyed, there is no reason to be confrontational or sarcastic. Please see https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette for communication expectations. Thanks!

In T22307#5184121, @E_to_the_Pi_times_i wrote:

[H]aving it done server-side after the page saves would definitely go against my expectations. If it ends up implemented this way, it should have a very clear opt-out mechanism (or perhaps even be opt-in).

I think you read too much into my comment. I have no problem with this being implemented, I would just prefer it to be visible within the interface and not done behind my back; the examples you give of having extra UI components to review when you take actions are actually favorable to my preference for clarity.

Change 281470 abandoned by Bartosz Dziewoński:
Generate automatic summary /* Section */ when a section heading is added manually

Reason:
I am not currently planning to work on this again. Sorry.

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

I am not currently planning to work on this again. Sorry.

@matmarex: Does that mean that you should be removed as task assignee? Asking to avoid cookie-licking.