rene.kijewski wrote:

There are several ways to solve this problem:

• A whitelist for which namespaces never a warning is to be displayed (regardless of the [default] user settings).
• A blacklist.
• A fully configurable list of namespaces. (But how to treat the existing user settings?)
• An option, if there should be no warning on talk pages.

I prefer the last one; it would be also easy to implement.

I prefer a configurable list in LocalSettings.php.
Talk pages are just one example where summaries are not always needed. User pages also require no summary (in most cases). Or think of village-pump-like pages in the project namespace where people sign their posts.
An array should be sufficient, something that can be changed in LocalSettings.php (with $wgMissingsummary['0'] = true; or so).
I can't see why there would be a problem with existing user settings. Users would still be able to enable missingsummary, but it would be only displayed on namespaces defined as eligible for missingsummary (and I think this is a good thing, as most people who enable this function don't want to be warned on (for example) talk pages).

rene.kijewski wrote:

I prefer a configurable list in LocalSettings.php.

So you propose a blacklist and/or whitelist.

Or think of village-pump-like pages in the project namespace

Well, on the village pump one mostly always edits an existing section, or inserts a new one. If a user edits the page as a whole, a summary would be appropriate. Likely if one edits in another's user namespace. In your own NS you don't have to enter a summary by now.

I can't see why there would be a problem with existing user settings.

If you'd let the users decide on which namespaces they want to be warned, there would be a problem how to threat their existing settings; whether to treat it as all namespaces or a predetermined list of namespaces (e.g. all subject namespaces).

I propose a predefined list in DefaultSettings with a reasonable configuration (for example: summary is needed only in namespace 0) which can be overwritten in LocalSettings.

Well, on the village pump one mostly always edits an existing section, or inserts a new one.

Even if you have some kind of automatic summary (like through "edit a section"), you still get a warning. The summary is not compared to an empty string, but to the autosummary (see line 876 in includes/EditPage.php). So, you still have problems on the village-pump.

If you'd let the users decide on which namespaces they want to be warned [...]

I don't think it is necessary to allow the user to configure this option for each namespace. The sysadmin defines the namespaces for missingsummary in LocalSettings.php and the user decides whether he wishes to enable the option for those namespaces or not.

rene.kijewski wrote:

Even if you have some kind of automatic summary (like through "edit a
section"), you still get a warning.

I thought I read it is only tested not to be empty. I would even say it should be changed this way. Was it not that way of late *confused*.

But after all I think my idea could be a generic improsement, not only fitting the current needs of de.wp. But for short a whitelist/blacklist should be sufficient. Maybe a should open a new bug afterwards ...
Don't you wanna file a patch a developer could commit?

Testing against an empty string as opposed to the auto summary isn't helping what missingsummary tries to accomplish. After all, the aim is that the user fills out the summary, not that it gets filled out automatically. The user is supposed to give additional information, the reasons for his edit and his sources and while /* heading */ is useful, it doesn't replace a summary.

Don't you wanna file a patch a developer could commit?

I'm sorry, but the soonest moment for me to look into the code is in two weeks, after I finished my [[Abitur]] :)

rene.kijewski wrote:

Testing against an empty string as opposed to the auto summary isn't helping

Since there is <ref> the sources shouldn't be kept in the summary at all. What shall I write when I correct a comma? "Fixed interpunctuation", kinda exaggerated. I think it is of vital importance to keep editing simple. We should not overdo the whole summary-is-essential thing.

I'm sorry, but the soonest moment for me to look into the code is in two weeks,
after I finished my [[Abitur]] :)

Aber wehe dir, wenn du dann keinen Einser-Schnitt hast ;)

We should not overdo the whole summary-is-essential thing.

That's an argument against missingsummary and it is correct (I abstained in the dewiki poll because of that). However, it doesn't have anything to do with editing a section vs. editing the whole page. If you wish to force summaries, you wish to force them in both cases.

rene.kijewski wrote:

new variable '$wgForceEditSummaryFor'

Introduces a new global variable '$wgForceEditSummaryFor' which may contain an array of the namespaces where a blank summary should be suppressed.
If it stores an empty array (default), all a blank summary should be suppressed on all namespaces.
E.g. $wgForceEditSummaryFor[] = NS_MAIN; in LocalSettings.php enforces a summary only in the article namespace.

Attached:

Patch still applies (very minor conflict on the global lines)

But the resultant code is horrible

From a usability viewpoint, missingsummary is horrible. A rewrite in Javascript would be much better.