Edit summary prefill poll

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

This poll is closed. The winning option is: Add it in, no user preference

Because the poll was very close, I will nevertheless consider making it a pref, once we have re-organized user preferences a little so that this doesn't become too annoying.—Eloquence 21:11, 22 Mar 2004 (UTC)

For a few days, an unannounced feature from the development branch of the code was active on Wikipedia which would automatically fill the "summary" box with the section title, see w:Wikipedia:Edit_summary#Section_title_as_automatic_edit_summary.

The greatest poll ever[edit]

When e.g. editing this section, the text "The greatest poll ever" would be entered into the summary box as a default. When you tab into the box, that text should be highlighted so you can overwrite it.

Apparently a few people have objected on IRC on that feature, and User:Brion VIBBER has taken it out temporarily. Arguments for and against are collected below, and you are encouraged to vote on whether you want this feature to go back in or not.

Deadline for the poll will be March 22, 20:00 UTC.

Arguments against the feature:

  • Some people will now become lazy and not type any summary
    • If people don't want to write a summary, that's their decision. We can't force them to. However, my experience is that this has not been done in practice. My subjective impression is that people now are more aware that the summary needs to be filled, and will be more likely to write something there when it is empty. I have observed this behavior in myself. I have also seen lots of modified default summaries. This could be backed up by empirical research if necessary.—Eloquence
  • "Recent changes" and the edit histories will be flooded with almost meaningless information. Hand-written summaries will easily be overlooked.--El 14:21, 20 Mar 2004 (UTC)
    • I have not noticed that during the time the feature was used. Auto-summaries were instantly recognizable because of the ((..)) (which I'm not particularly fond of, but any syntax that makes them stand out from normal summaries will do).—Eloquence 16:45, 20 Mar 2004 (UTC)
      • Auto-summaries in brackets still annoy me. If the software can discern between auto-summaries and human-written summaries it could as well offer me the option not to show auto-summaries at all, which would have to be set on the preferences page. So I'd be completely satisfied with the two complementary options "Don't generate auto-summaries." and "Don't show auto-summaries."--El 20:53, 20 Mar 2004 (UTC)
        • We can't reliably check for auto vs. human once the edit has been saved, unless we use a unique markup or alter the table structure to store the summary in a separate field. That would be a major change because it affects all article histories for all articles ever written, therefore I am against it.—Eloquence 00:20, 21 Mar 2004 (UTC)
          • The check can be done (and is done if I understand it correctly) before the edit is saved, i.e. only unchanged auto-summaries are enclosed in brackets. I want the software to show me only those summaries that don't start with '(' and don't end with ')'. Of course every user can write such a summary, but in reality almost no one does. And it doesn't harm if these summaries are not shown to me, because they must be unimportant anyway if they are enclosed in brackets.--El 11:29, 21 Mar 2004 (UTC)
  • If the summary field is changed and then preview is clicked, the changes are wiped out and replaced with the (section heading). I consider this a fixable bug, through. --ssd
    • This bug was fixed an hour after the feature went live. You must have tested an earlier version.—Eloquence 00:18, 21 Mar 2004 (UTC)

Arguments for the new feature:

  • It results in usually useful summaries or "summary stubs"
  • We get summaries especially for minor edits, where there previously were none

Possible solutions (votes for multiple options allowed):

Add it in, no user preference[edit]

  1. —Eloquence 23:54, 19 Mar 2004 (UTC) So far none of the arguments for the need of a user preference has convinced me. There are already enough prefs as it is -- too many prefs = bad usability.
  2. Brion VIBBER 00:06, 20 Mar 2004 (UTC) Definitely should not be a user preference. We have too many, and will be streamlining prefs soon.
  3. — Jor (Darkelf) 00:08, 20 Mar 2004 (UTC) A default edit summary is better than none. Agreed with Eoloquence and Brion on the prefs bit.
  4. Angela. I think it's useful, and it's easy enough for those who want to type their own summary to overwrite it.
  5. Dpbsmith 01:59, 20 Mar 2004 (UTC) I thought it was neat and was pleased to see it. (Don't have any strong objections to making it a user preference, but in my experience that's usually a cop-out and wasted effort). Just implement it as is, no preference. If we find that we are getting lots of edits with no other summary then it can be removed. If we find that we are getting lots of complaints by people who don't like the effort of replacing the text, then it can be made a user preference.
  6. Anthere
  7. Patrick 03:30, 20 Mar 2004 (UTC) - Very useful, when one adds details after the section title one has a quite informative summary with a minimum of effort.
  8. DanDrake 04:42, 20 Mar 2004 (UTC) The idea of appending a colon or something to indicate that more is expected is also good.
  9. Vincent Ramos I'm getting rather fed up with editors who seldom indicate what they've done. This option seems very important to me.
  10. Beatnick Add it but in the form "Section title : "
  11. Kowey 14:21, 20 Mar 2004 (UTC) : simple, effective
  12. Schusch 15:29, 20 Mar 2004 (UTC): If I don't like it in a special case, I still can delete the text - if one doesn't use the summary, his or her behavior won't change wether this feature is there or not
  13. Theresa knott 16:10, 20 Mar 2004 (UTC)
  14. Philip Marlowe 19:22, 20 Mar 2004 (UTC) It's grrrreat!
  15. James F. (talk) 22:35, 20 Mar 2004 (UTC)
  16. Andrsvoss 13:47, 21 Mar 2004 (UTC)
  17. Willy 20:27, 21 Mar 2004 (UTC)
  18. Rudolf 1922 08:02, 22 Mar 2004 (UTC)
  19. \Mikez 08:10, 22 Mar 2004 (UTC) (I liked it during the test...)

Add it in, but allow user preference[edit]

Note: In this case, it may still take weeks for this feature to go back in, as an additional user preference is a substantial change that can be only made during a full upgrade.

  1. Dori | Talk 04:21, 20 Mar 2004 (UTC)
  2. Tim Starling 05:43, 20 Mar 2004 (UTC) there's no such thing as too many user preferences, although poor categorisation is possible (and currently rife)
  3. Alibaba 06:49, 20 Mar 2004 (UTC)
  4. Baldhur 10:17, 20 Mar 2004 (UTC)
  5. Shaihulud 13:54, 20 Mar 2004 (UTC)
  6. 14:18, 20 Mar 2004 (UTC)
  7. Looxix 18:19, 20 Mar 2004 (UTC)

Add it in, without a user preference at first, but allow user preference later[edit]

This will allow us to keep using the feature immediately, but the nay-sayers will be able to switch it off after the next upgrade).

  1. —Eloquence 23:54, 19 Mar 2004 (UTC) If people insist on it.
  2. Fennec 00:04, 20 Mar 2004 (UTC)
  3. Jwrosenzweig 00:28, 20 Mar 2004 (UTC)
  4. Angela. Allow preferences, but turn this on by default.
  5. Elf. Ditto. Format as "Subject: ". And only if we can take just the first 25 chars or 4 words or something--e.g., if I were editing this section, my default summary would be "Add it in, without a user preference at first, but allow user preference later" which would not only discourage me from adding anything else but many like this would just absolutely blow away any reasonable visual scan of summaries on pages such as recent changes.
  6. Arwel 01:57, 20 Mar 2004 (UTC). Allow it as a user preference, but turn it on by default -- I first noticed this on cy, where I was pleased people were putting useful summaries in the description at last!
  7. Vardion. No particular objection to it, but personally, I'd rather not use it.
  8. Alibaba 06:49, 20 Mar 2004 (UTC)
  9. Jay If the user is allowed to overwrite the default summary, he may as well be allowed to set or unset the feature using preferences. Its both the same. But if the user chooses to switch off the feature, we wouldn't be able to trace that user's behaviour wrt. that feature. Hence no user prefs. facility now, only later.
  10. Greudin 09:32, 20 Mar 2004 (UTC)
  11. Tessarakt 09:48, 20 Mar 2004 (UTC)
  12. Pontauxchats 12:39, 20 Mar 2004 (UTC)
  13. Flups 14:12, 20 Mar 2004 (UTC)
  14. Sverdrup (talk) 21:16, 20 Mar 2004 (UTC)
  15. Ruhrjung 21:21, 20 Mar 2004 (UTC)
  16. James F. (talk) 22:38, 20 Mar 2004 (UTC)
  17. Hemmer 10:06, 21 Mar 2004 (UTC)

Keep current behavior (no default summary)[edit]

  1. Brion VIBBER 00:06, 20 Mar 2004 (UTC)
  2. It was useful for raising consciousness about the summary line existing in the first place. That said, I've had to manually erase it every time. -- Cimon Avaro on a pogo stick 00:31, 20 Mar 2004 (UTC)
  3. Elian - I think it makes people lazy and we would end up with a history full of absolutely useless summary lines. An empty field says: "fill me". if there is already text in, this incentive is removed.
  4. RoseParks I don't see a use for the paragraph name alone in the edit summary. If the author is supposed to add to it, this will be unclear.
  5. Eclecticology 03:32, 20 Mar 2004 (UTC) I prefer edit summaries that describe what I'm doing.
  6. Dori | Talk 04:22, 20 Mar 2004 (UTC)
  7. Tim Starling 05:43, 20 Mar 2004 (UTC)
  8. El 14:22, 20 Mar 2004 (UTC), but see alternate plans below
  9. Timwi 16:47, 20 Mar 2004 (UTC)
  10. How does this benefit anyone? If I see (References) in the history, what does that mean? Did someone add a link? Did they fix a typo? Did they add five new sections underneath it? Did they delete the content and fill it with "RADICALBENDERISGREAT!!!1!"? It's no better than the existing behavior, but it does become misleading because it looks more "legitimate." It would be harder to scan for vandals. RadicalBender 17:08, 20 Mar 2004 (UTC)
    • A human-written summary looks like this: (foo), an auto-summary looks like this: ((foo)). Maybe there are ways to make it clearer that the edit summary was generated automatically. However, I found it quite ironic that you typed the text "Keep current behavior" in the summary field for your vote, which would have been inserted automatically if this feature was enabled.—Eloquence 17:18, 20 Mar 2004 (UTC)
      • I grant you, in this particular instance, you are correct, it would have (basically) been the same thing I typed in. However, that doesn't help the hundreds of thousands of articles that are not polls. :) Irregardless, I still maintain that just listing the section (or some variant) in the summary as a change provides little to no benefit, but can cause a number of potential problems. RadicalBender 20:37, 20 Mar 2004 (UTC)
        • See my response to El below -- in the short time the feature was active it already has helped me on many articles, exactly because I now know where people are making an edit in a 40K article who would have previously not written anything about it.—Eloquence 23:46, 20 Mar 2004 (UTC)
  11. Fantasy 21:19, 21 Mar 2004 (UTC) (You can add an extra field saving/showing the title of the edit-section)

Alternate plans[edit]

How about if no summary is entered, only then is the title of the section stored as the summary? Possibly with a "[bot]" prefix - Fagan

I often want to add to the default summary. That would no longer be possible.—Eloquence 02:26, 20 Mar 2004 (UTC)

Put the section name in the summary field, followed by a colon, making it clear that there's an expectation to fill in more. moink

I'd prefer too with a colon rather than brackets Alibaba 06:49, 20 Mar 2004 (UTC)
Yes, that sounds like a good suggestion. I asked for feedback on the Village pump regarding the formatting.—Eloquence 02:26, 20 Mar 2004 (UTC)
Like GetWiki's "note changes here"? [1] You'll just end up with a lot of colons with nothing after them. -- Tim Starling 05:43, 20 Mar 2004 (UTC)
We can strip the trailing colon if the user enters nothing.—Eloquence 16:43, 20 Mar 2004 (UTC)
Then I type something like "remove superfluous :", and your code would strip the ":", redering my summary meaningless. — Timwi 16:48, 20 Mar 2004 (UTC)
Not at all - we can determine if the user has changed the summary field from the default before we do the stripping.—Eloquence

How about to always put the section name (if there is no section, another word) to the summary, but don't put it in the summary field. The result could be e.g. (typo, wikified (Geography, Weblinks)). In this case Geography and Weblinks are the section names, typo and wikified are filled in by the editor. --Andre ( 11:32, 20 Mar 2004 (UTC))

I like this suggestion. Although I'd say prepend it. Dori | Talk 16:11, 20 Mar 2004 (UTC)
Sometimes sections have nothing to do with what you are editing, especially on talk pages, where people often forget to create sections for new threads. It would be annoying to not be able to get rid of such misleading summaries.—Eloquence 16:44, 20 Mar 2004 (UTC)
I see your point about not being able to change what goes in the summary, however, someone wouldn't get that text unless they were specifically editing that section. Dori | Talk 22:27, 21 Mar 2004 (UTC)

See also this archived discussion of a more elaborate solution (involving multiple choices of autosummary based on context and/or preferences) - IMSoP 03:50, 20 Mar 2004 (UTC)

I like version 0 on http://rwec.co.uk/~ron/dropdown_test. One of the strings could be the section heading. If a string is selected and Javascript is active, the string can be automatically copied to the summary field and then be edited by the user if necessary.--El 14:22, 20 Mar 2004 (UTC)

kowey's 3 case approach[edit]

How about this 3-case behaviour:

  1. you don't type anything - the section automatically gets filled in (Fagan's idea)
  2. you type something - your text appears verbatim (the old behaviour)
  3. you type something with "::" or other syntax - the :: autoexpands to the section name

Simple, no? Typing :: in the summary will be like typing ~~~~ for your sig -- Kowey 00:35, 21 Mar 2004 (UTC)

Yeah, and ~~~~ is one of the worst design decisions in the history of Wikipedia. Seriously. It's not like there's an obvious alternative to it, but that's the first thing we have to teach newbies because it cannot be learned from looking at what other people are doing. I am absolutely against any such solution.—Eloquence 01:04, 21 Mar 2004 (UTC)
Dang... and there I was thinking I had found a tidy solution to please everybody. To be honest, I kind of like the 4 tilde thing: efficient in use and simple to explain. Maybe this is somewhat screwy thinking, but I also think it makes for a useful rite, something neat little trick for old wikipedians to share with newbies; makes the newbies feel like they're in on some grand wiki secret/culture/community etc :-) Kowey 01:10, 21 Mar 2004 (UTC)
That may be true to some extent, but as we add more and more of these little tricks, the rite begins to resemble a Klingon pain stick ritual.—Eloquence 01:32, 21 Mar 2004 (UTC)

Here's a fourth alternative.... how about the summary starts blank, but a button triggers javascript to fill it in with the section heading? (I would have to read/edit this page backwards.) (And I'm a fairly new user and found ~~~~ fairly quickly. Is that the only problem with it?) --Ssd 03:53, 27 Mar 2004 (UTC)

make it dependant on OS (or not)[edit]

Naturally, people using Unix or Unix-like systems won't get the autoselect of the prefilled edit summary box (presumably so it doesn't clobber stuff that's in the primary X buffer), but then this makes it very difficult to remove the prefilled summary (have to backspace over it). If it's going to stay (no pref), can there be at least a preference to make its behaviour somehow dependant on OS? I don't want to have to backspace over everything just in case I have something in a buffer that I don't want to lose... The easy way would just be to make it a preference, period ;) Dysprosia 04:42, 25 Mar 2004 (UTC)

I use netscape under unix, and I don't seem to have these problems. Ctrl-A Ctrl-k does quite fine for clearing the edit summary. Similarly, I can easily double-click, tripple-click, or even drag-highlight the summary box and then hit backspace to clear it, exactly as I would in windows. What browser do you use that any of these are difficult?
On the flip side, I wonder if I'd rather have the summary blank, with a javascript button next to it to prefill it on press instead. --Ssd 03:46, 27 Mar 2004 (UTC)
It didn't autohighlight for Moz, but I think this mightn't be such a wide case as I one thought, as it works for Fb right now, but the copy of Moz I was using on another computer may have been a bit old. Need to do some more testing, it seems... But thanks for the ^K tip! Didn't know about that one! Dysprosia 04:06, 27 Mar 2004 (UTC)
emacs keys. --Ssd 06:24, 28 Mar 2004 (UTC)
No wonder I didn't know - I use vi ;) Dysprosia 08:06, 28 Mar 2004 (UTC)

Some example summaries[edit]

Let's look at some of the human-written summaries in the history of this page:

# (cur) (last) . . 16:10, 20 Mar 2004 . . Theresa knott (voting)
# (cur) (last) . . 15:29, 20 Mar 2004 . . Schusch (Edit summary prefill poll)
# (cur) (last) . . 14:22, 20 Mar 2004 . . El (Edit summary prefill poll)
# (cur) (last) . . 14:21, 20 Mar 2004 . . El (Edit summary prefill poll)
# (cur) (last) . . M 14:21, 20 Mar 2004 . . Kowey
# (cur) (last) . . 14:18, 20 Mar 2004 . .
# (cur) (last) . . 14:12, 20 Mar 2004 . . Flups
# (cur) (last) . . 13:54, 20 Mar 2004 . . Shaihulud
# (cur) (last) . . M 13:17, 20 Mar 2004 . . Patrick
# (cur) (last) . . 12:39, 20 Mar 2004 . . Pontauxchats (my vote)
# (cur) (last) . . 11:05, 20 Mar 2004 . . Vincent Ramos (A voté)
# (cur) (last) . . M 10:17, 20 Mar 2004 . . Baldhur (vote)
# (cur) (last) . . 09:48, 20 Mar 2004 . . Tessarakt
# (cur) (last) . . 07:16, 20 Mar 2004 . . Jay (add with user prefs later)
# (cur) (last) . . 06:49, 20 Mar 2004 . . Alibaba
# (cur) (last) . . 04:42, 20 Mar 2004 . . DanDrake
# (cur) (last) . . 04:41, 20 Mar 2004 . . DanDrake (yes)
# (cur) (last) . . 04:22, 20 Mar 2004 . . Dori (voting for another options as well)
# (cur) (last) . . 04:21, 20 Mar 2004 . . Dori (voting)
# (cur) (last) . . 03:32, 20 Mar 2004 . . Eclecticology (participating)
# (cur) (last) . . 03:30, 20 Mar 2004 . . Patrick (add in)
# (cur) (last) . . 02:57, 20 Mar 2004 . . Anthere
# (cur) (last) . . 02:40, 20 Mar 2004 . . (voting)
# (cur) (last) . . 02:26, 20 Mar 2004 . . Eloquence

I think this single example alone thoroughly debunks the theory that humans write much better summaries when they don't get a default.

Many people wrote nothing. Only very few people described exactly what they were voting for. Most wrote something like "vote" or "yes". Had auto-summaries been enabled, everyone who used section editing would have gotten a very precise default description, e.g. "(Add it in, no user preference)" or "Add it in, no user preference:" in the proposal discussed above, after which they could write "yes", or "comment".

It puzzles me how anyone can seriously make the argument that our summaries will get worse when it's obvious from all real evidence that our summaries are very bad right now, and that in the vast majority of cases, providing a default summary would make the description much more accurate and useful. Yes, there will be a few cases where people forget to write something when they should have had. These few cases are far outweighed by the huge number of cases where the summary becomes improved.—Eloquence 17:41, 20 Mar 2004 (UTC)

Voting pages like this one are quite different from article pages. When users edit a section of this page, they most likely vote for the option given in the section heading. What else can they do? In articles, they can fix typos, add links, write nonsense and the like. What would be the benefit of knowing where exactly they did it? This is zero-information. Knowing which section was edited is only useful to some degree when the user makes textual changes he is too lazy to summarise in his own words. If you want to have meaningful summaries in all cases (not only when the user edits only one section) the simplest solution would be to force him to write a summary by not accepting edits with an empty summary field. Several standard summaries could be offered in this case (like on [2]).--El 20:53, 20 Mar 2004 (UTC)
Zero information?! There is plenty of information that can be gathered from such a summary. For example, when I have a page on my watchlist, and I note that someone made a change to ((External links)) or ((References)), in many cases I won't care about it. However, when someone makes a change to ((CIA role in the coup)) to Augusto Pinochet, that is much more interesting, especially when it's non-minor. On many articles I know exactly what I have done and care only about specific sections. Someone may responsible for keeping the "Deaths" on the day pages up-to-date, so he or she can ignore all other section changes on these pages. (I noticed quite a few ((Deaths)) or ((Events)) minor edits on the day pages while this feature was active; most of them would not have had any summary without it.) Just read the comments above -- someone wrote that for the first time, edit summaries became useful on the wiki he works on (cy). Is he dealing with "zero information" and just doesn't realize it? No, I think that this claim is clearly wrong, and easily disproven.
Yes, auto-summaries may be useful in some cases, as I have said, but in other cases they are not. Let the users decide if they want to see them. I am sure, not all users work like you. I have e.g. only about 150 pages on my watchlist and I want to monitor all changes regardless of the section they affect. So I don't need the additional information and I have the impression that it increases the information flood.--El 11:29, 21 Mar 2004 (UTC)
It seems to me that the more we talk about these summaries, the more useful they become. Here's another scenario which I just experienced: Say you want to find out when someone made a particular addition to an article. That happens fairly often. Now you can look at the history and hope that the person has written an adequate summary. There's no other way to search the history - your only other option is to do a diff-by-diff comparison. With auto-summaries, you can much narrow down your search because you can instantly rule out edits to sections which do not include the change you are interested in.
Auto-summaries may help, but they don't help much. Mandatory summaries would be a much better solution for this problem.--El 16:28, 21 Mar 2004 (UTC)
As the summaries on this page alone demonstrate, they wouldn't. And look who just forgot writing a summary ...—Eloquence 16:57, 21 Mar 2004 (UTC)
That's because the software didn't remind me. :-) --El 17:42, 21 Mar 2004 (UTC)
As for making their visibility optional, that seems to me like making the summaries themselves optional. "They only clutter the recent changes list - if I want to see what someone has done I'll look at a diff!" I see no difference between auto-summaries and human-written summaries here, after all, auto-summaries are manually approved by humans before they are saved.—Eloquence 13:25, 21 Mar 2004 (UTC)
I can also think of radical possibilities in the opposite direction, i.e. one can include a whole bunch of automatically generated information in the summary, some of which are even more useful than the section heading. The summary would then read like: "edited section 'bla', deleted 123 bytes, added 321 bytes, deleted 4 internal links, added 2 internal links, added 6 F-words ...". Now I wonder, as you want to have one of these possibilities, why not all? We have to find the happy medium. There are three qualitatively different options: 1. no summaries at all 2. human-written summaries 3. human-written + auto-summaries. In my opinion, it is most reasonable to set human-written summaries as the default and enable the users to choose additional auto-generated information, if they want them.--El 16:28, 21 Mar 2004 (UTC)
Actually, such machine-generated auto-summaries make sense, if they can sensibly be integrated into the RC UI. That would be doable if the RC page was within a table, where we could add an additional information column, with little icons representing the nature of the change, e.g. "+++" lots of text added. It would also be nice to be able to dynamically expand a diff from RC, without loading a separate page. Within the current summary format, too much unstructured information makes the history and RC page hard to read. The section prefill does not cross that threshold, however, especially because - unlike these machine-generated changes - it can be edited, shortened and adapted before the edit is saved.—Eloquence 16:57, 21 Mar 2004 (UTC)
As for your suggestion to make edit summaries mandatory, wiki is all about ease of editing. A mandatory summary is a significant impediment and can be frustrating. Things that don't need to be summarized (although it's nice if they are) include: 1) user page edits, 2) user-to-user conversations, 3) many "minor" edits, 4) many talk page edits, 5) new article creation, 6) sandbox edits .. We can't realistically check for all these possibilities. Furthermore, when people are frustrated by something, they have a tendency to go away, or to enter nonsense. First time visitors will simply write "asidfjaosidf" because they do not know what the summary is for! Or worse, they will deliberately abuse it after having been annoyed by us with a message box.
Summaries should be mandatory only for article pages and that's easy to check. I don't know if all minor edits should have to be summarised, because if they have to, many users will probably mark their edits as minor if they can thus avoid thinking about a proper summary. Summaries like "asidfjaosidf" would be useful too, because they would alert me that something may be wrong with this edit. No serious person would write such a summary.--El 11:29, 21 Mar 2004 (UTC)
Is this an article page? How do you check for that? Do you want to set it on a per-wiki basis? Look, this idea isn't going to fly. It would only end up being bothersome and annoying.—Eloquence 16:58, 21 Mar 2004 (UTC)
Yes. Namespace=0. Yes. And it's not bothersome to write summaries, it's bothersome to wade through "recent changes" without meaningful summaries.--El 17:42, 21 Mar 2004 (UTC)
The joy of Wikipedia comes from quickly getting results, and many of us got hooked on it for exactly that reason. Anonymous users are supposed to get a positive first-time editing experience, not one where they are attacked by some alertbox that tells them that they can't proceed without entering something into some field which they don't understand the purpose of yet. No, mandatory summariers have been suggested again and again, but rejected again and again for these reasons. As for the dropdown auto-summaries, they are a nice addition to the section edit auto-summaries, but everything that adds to the complexity of the edit screen user interface needs to be carefully considered and tried for a few weeks before it can be used; otherwise we risk frustrating people who have become used to a certain editing routine. The section auto-summaries do not significantly impede such routines.
I do not insist on mandatory summaries. I only wanted to say that mandatory summaries would be better than auto-summaries. The third alternative is to keep the current behaviour and add the dropdown menu. That would already be an improvement and certainly better than auto-summaries.--El 11:29, 21 Mar 2004 (UTC)
Hardly, because you can no longer edit the auto-summary text, and because it complicates the user interface unnecessarily. With multiple options in the same dropdown, it is also not possible to combine, say, "spelling" with "(some example summaries)".—Eloquence 13:25, 21 Mar 2004 (UTC)
That depends on whether or not the user has JavaScript enabled. If it is enabled, the text of the selected option can automatically be copied to the text field and then edited by the user. It could also be appended to an existing text in this field, so that combinations become possible. If JavaScript is not enabled, it is still possible to combine a message the user writes in the text field with the text of an option he selects in the dropdown menu.--El 16:28, 21 Mar 2004 (UTC)
Another thing: The more people use these auto-summaries, the more they will understand the usefulness of good sectioning of articles and talk pages. For example, if the feature was active, I would now have added a new subsection "Automatic summaries vs. mandatory human summaries".—Eloquence 23:45, 20 Mar 2004 (UTC)

Darn, I missed this poll![edit]

Somehow I missed this poll over the last 3(?) days. And, I just discovered the new feature and I don't think I really like it -- I'm not sure how useful the info is as an edit summary. However, I'm not arguing that we revisit the decision. I usually check the polls every couple of days, but I guess I missed a day over the weekend. I'll see if there is a better pplace to raise this. but I just wanted to mention it here. BCorr ¤ Брайен 22:44, 22 Mar 2004 (UTC)

this feature is just plain stupid. the information it provides is good for nothing, and it disencourages newbies to write anything useful in the summary. also three days for a poll is much too short - i do not remember reading anything about this nonsense on the german wikipedia. D 01:48, 25 Mar 2004 (UTC)

  • I just want to agree with Fantasy, who wrote in his vote summary above "add an extra field keeping the section that was edited". I think this is a useful change, but the information should be kept separate in the db as much as possible... whether or not the 'section title' text is also prefilled into the comments section, and how it is displayed in the edit history, are interface design choices that are minor compared to the improvement of tracking this information. Sj
    • Separately, I think the default should be no prefill, and that people who figure out how to tweak their advanced prefs should be allowed to request a prefill. Then the edit-summary display software can decide how to display the set of {section edited, edit summary submitted}. Sj 19:26, 26 Mar 2004 (UTC)
    • you are right, this information is indeed useful to keep and should stay separate from the summary, but i strongly disagree on that it is more or less unimportant whether the summary is preset in the GUI or not. a summary written by a human (or even the absence of it) tells me much more about an article than a section header, so although i do not like the thought of a mandatory summary field very much, i think users should be encouraged to write such summaries instead of making them seemingly unnecessary. -- D 12:42, 26 Mar 2004 (UTC)