Last modified: 2014-09-08 11:02:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3307, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1307 - Auto-Edit Summary: if few changes ("smaller" than a threshold) have been made, automatically create an Edit Summary from diff results
Auto-Edit Summary: if few changes ("smaller" than a threshold) have been made...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Lowest enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 2437 9375 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-10 23:48 UTC by T. Gries
Modified: 2014-09-08 11:02 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description T. Gries 2005-01-10 23:48:51 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).
Comment 1 Rowan Collins [IMSoP] 2005-01-11 00:01:04 UTC
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.
Comment 2 T. Gries 2005-01-11 00:08:42 UTC
(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
Comment 3 peter green 2005-01-11 00:16:20 UTC
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.

Comment 4 Rowan Collins [IMSoP] 2005-01-11 01:15:07 UTC
(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.
Comment 5 T. Gries 2005-01-11 02:11:37 UTC
(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....
Comment 6 Rowan Collins [IMSoP] 2005-01-11 16:39:11 UTC
(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.
Comment 7 Brion Vibber 2005-01-29 07:14:03 UTC
Probably not feasible. Marking LATER if someone wants to make a more solid proposal on how to do it and when to use it.
Comment 8 T. Gries 2005-06-22 20:38:13 UTC
see also http://bugzilla.wikimedia.org/show_bug.cgi?id=2437
"Automatic edit summaries when none entered"
Comment 9 Omegatron 2005-06-22 20:51:38 UTC
(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.
Comment 10 T. Gries 2005-06-22 21:14:18 UTC
> (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

Comment 11 T. Gries 2005-06-22 21:22:25 UTC
> > 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/
Comment 12 Omegatron 2005-08-06 02:23:56 UTC
(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?
Comment 13 Zigger 2006-01-16 04:41:42 UTC
*** Bug 2437 has been marked as a duplicate of this bug. ***
Comment 14 Zigger 2006-01-16 04:43:13 UTC
See also bug 1687 (warn), bug 4630 (force).
Comment 15 Omegatron 2006-12-27 20:03:05 UTC
It looks like this has been implemented, albeit in a pretty limited fashion. 
Where is the documentation for this feature?
Comment 17 Omegatron 2007-01-02 01:58:03 UTC
(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?
Comment 18 Brion Vibber 2011-11-29 20:51:29 UTC
I'm taking the LATER off this; it's probably actually fairly feasible.
Comment 19 matanya 2012-07-26 12:46:38 UTC
Brion, was this implemented?
Comment 20 Jesús Martínez Novo (Ciencia Al Poder) 2014-06-29 18:46:49 UTC
*** Bug 9375 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links