Last modified: 2014-09-08 11:02:35 UTC
I propose to ***automatically*** create an Edit Summary from the content of a "diff" process. In other words, if someone changes a page only slightly(*), this small change itself is proposed to be automatically inserted into the Edit Summary (*) changes less than a certain threshold. Example: if a changed string pattern x...xx. (...) ..xx...x is shorter than 80 contiguous characters, the whole changed string is placed into Edit Summary. I expect this changes as not being too complicated; it's similar to Eric's Edit Section enhancement (if a section is edited, currently the section header is copied into teh Edit SUmmary). My proposal need to override this, as it is even more specific, but can be probably combined (put Edit Section header conactenated with x...x..xx...x changed string into edit summary).
The only thing that makes this slightly more complex than that is that it would require the diff to be calculated for every edit [and preview?] submitted (or more-or-less every: if the edit has been given a summary already, it needn't be auto-summarised). This means a significant (I don't know how big, but in statistical terms "significant") slow-down of each applicable preview/save while the diff is computed (and the result measured against a threshold, but that's trivial in comparison). Also note that the section edit thing gets entered *before the user has changed anything*, so it's not really the same proposition.
(In reply to comment #1) > The only thing that makes this slightly more complex than that is that it would > require the diff to be calculated for every edit [and preview?] submitted (or > more-or-less every: if the edit has been given a summary already, it needn't be > auto-summarised). Yes, of course you are right. I forgot "if user has not entered a Summary, then {auto-create edit summary}" > This means a significant (I don't know how big, but in > statistical terms "significant") slow-down of each applicable preview/save while > the diff is computed (and the result measured against a threshold, but that's > trivial in comparison). > > Also note that the section edit thing gets entered *before the user has changed > anything*, so it's not really the same proposition. Yes, but this is also not solved in the current version: if you create a new section, still the old section heading is automatically pasted into the Edit Summary (instead of the newly created one..... however, when applying my proposal, it would detect this discrepancy) In summary: thank you for your valuable feedback, I liked that. The processing load issue must not be forgotten. Tom
on the other hand this may SAVE cpu because with an edit reason inserted there will be less reason for people to diff the edit when they see it on thier watchlist.
(In reply to comment #2) > Yes, but this is also not solved in the current version: if you create a new > section, still the old section heading is automatically pasted into the Edit > Summary (instead of the newly created one..... however, when applying my > proposal, it would detect this discrepancy) That's an interesting point; it does beg the question though, of under what circumstances the software would over-ride the summary text: if I go to edit a section, the software grabs the heading and puts it in the summary box, surrounded by /*...*/. I can edit this how I like (potentially messing up the convenient arrow link it gives in change lists), or I can leave it be. So what if I edit a section headed "foo", and submit the change with the summary "/* foo */ added new section bar" or "/* foo */ changed heading to bar" - should the software silently change the summary to "/* bar */ ...", because that was the section I actually ended up working on? Perhaps that would be left alone because I'd changed the summary from its default, which the software would presumably have to "remember" somehow. But what about a case where I edit a ==top heading==, but the text I change turns out to be inside a ===lower heading=== - should the software silently change my summary to say "/* lower heading */"? Would it do so on preview, changing it back to "/* top heading */" if necessary? And what about if I change the heading, but don't change the summary - I guess it needs to grab the new heading. It would probably work, but "we" would have to think quite carefully about how it was to behave in different circumstances.
(In reply to comment #4) > (In reply to comment #2) > > That's an interesting point; it does beg the question though, of under what > circumstances the software would over-ride the summary text: I mean: my proposal would simply ***ADD*** the diff-ed text (if less a threshold) to the existing "section heading auto-summary texts" So, a fixed text (the current section heading, if present) PLUS some parts of the changed strings. Wouldn't this solve all our (common) "problems" in a fine, nice and neat way ? By the way, thank you all again for your really valuable and still encouraging comments. Very often, when I contribute here, the proposals are smashed down in a fraction of a second (without seeing a least one positive aspect), This usually irritates me extremely. It's good to learn now, that open-minded developers like you are around here....
(In reply to comment #5) > So, a fixed text (the current section heading, if present) PLUS some parts of > the changed strings. In comment 2, you suggested that your diff-based code could *over-ride* the "/* heading name */" which is inserted as soon as you go to edit a section. I was just trying, in my rambling way, to think through how well this would work. In the case of *changing* the heading, it would be fairly easy: the same test could be applied as the "first time round". But for the case of adding a heading, or editting entirely within a sub-heading, it's not so obvious: the software can't actually "see" sections, only look for text that resembles headings. Which actually leads to a more serious problem than in my last comment: a diff won't tell you that all the changes are under one sub-heading; nor will it easily reveal the difference between adding one new section and adding two. And given that it may be inserting this "corrected" heading name *after the user has clicked save*, having it do too much "guessing" is just going to cause more confusion than help, IMHO. That's not to say your proposal in general is "bad" - something to generate things like "+ I agree - ~~~~" when the user is too lazy to copy-and-paste could be useful (depending, as I say, on what it does to server load). But I don't think it can realistically solve the flaws in the existing section-edit summaries.
Probably not feasible. Marking LATER if someone wants to make a more solid proposal on how to do it and when to use it.
see also http://bugzilla.wikimedia.org/show_bug.cgi?id=2437 "Automatic edit summaries when none entered"
(In reply to comment #1) > The only thing that makes this slightly more complex than that is that it would > require the diff to be calculated for every edit [and preview?] submitted (or > more-or-less every: if the edit has been given a summary already, it needn't be > auto-summarised). This means a significant (I don't know how big, but in > statistical terms "significant") slow-down of each applicable preview/save while > the diff is computed (and the result measured against a threshold, but that's > trivial in comparison). Yes, it requires one diff calculation. But think how many people ask for that diff if there is no edit summary otherwise. I don't know if diff pages are only calculated once and remembered, or calculated on the fly each time someone views one, but it could be a tremendous server load *savings* if you prevent lots of people needing to view the same diffs in the first place. (In reply to comment #8) > see also http://bugzilla.wikimedia.org/show_bug.cgi?id=2437 > "Automatic edit summaries when none entered" The only difference seems to be that my version (2437) puts an edit summary for *any* size edit, but only if the user doesn't enter one themselves.
> (In reply to comment #1) > Yes, it requires one diff calculation. But think how many people ask for that .... Dear Omegatron, can you edit soemthing ? As a proof of concept ?? I would be very interested in integrating this into my EnotifWiki. Please let me know. Wikinaut Tom
> > Yes, it requires one diff calculation. But think how many people ask for that > .... > > Dear Omegatron, > > can you edit soemthing ? As a proof of concept ?? > I would be very interested in integrating this into my EnotifWiki. s/edit/program/
(In reply to comment #10) > can you edit soemthing ? As a proof of concept ?? > I would be very interested in integrating this into my EnotifWiki. > > Please let me know. > Wikinaut Tom What do you mean?
*** Bug 2437 has been marked as a duplicate of this bug. ***
See also bug 1687 (warn), bug 4630 (force).
It looks like this has been implemented, albeit in a pretty limited fashion. Where is the documentation for this feature?
http://en.wikipedia.org/wiki/Wikipedia:Automatic_edit_summaries
(In reply to comment #16) > http://en.wikipedia.org/wiki/Wikipedia:Automatic_edit_summaries Was this written to fulfill a specific bug request, or just kind of fulfilled them incidentally?
I'm taking the LATER off this; it's probably actually fairly feasible.
Brion, was this implemented?
*** Bug 9375 has been marked as a duplicate of this bug. ***
