Page MenuHomePhabricator

Correcting edit summaries
Closed, DeclinedPublic

Description

Allow editing of edit summaries in some circumstances, for example if the edit is both your own edit and last edit, and the edit happens recently.

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Miscellaneous#Technical_user_right_to_edit_summaries
This proposal received 43 support votes, and was ranked #19 out of 107 proposals.


Original 2008 description:

I propose to implement a mechanism to correct edit summaries (1) if it is your own edit (2) and if it is the last edit (3) during a short time span (e.g. 1 - 12 hours).

One possible way to do this would be a link on history pages, e.g. "(rollback | undo | fix summary)". A new page would then allow to fix the summary.

Such a function would allow to fix accidents such as empty summaries, switched summaries (when you have many tabs open), and half-completed raw summaries. Currently, minor or fake edits are required to provide a correct summary.

Under the proposed restrictions (own, last, recent), there is probably no potential for abuse (e.g. any following edit would make the previous summary permanent). This would allow to simply overwrite the edit summary field without the need for a summary history or log.

This might have to be restricted to registered users as theoretically an anonymous user with reassigned IP would be able to change summaries not belonging to him.

There is a current [2008] Village Pump proposal (https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_30#Being_able_to_edit_your_edit_summaries) with currently only positive responses.

There is a also somewhat related closed bug T12105: Allow editing of edit summaries after the fact which did not discuss reasonable restrictions or implementation details. The current proposal addresses previous objections such as increased user interface, system, or code complexity.

Details

Reference
bz13937
Related Gerrit Patches:

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:10 PM
bzimport added a project: MediaWiki-Page-Diffs.
bzimport set Reference to bz13937.
bzimport added a subscriber: Unknown Object (MLST).
Cacycle created this task.May 3 2008, 7:11 PM
brion added a comment.May 7 2008, 12:56 AM

We've generally blanket-rejected these requests in the past.

Might not be a bad idea to be able to handle the "oops" factor gracefully, though.

thedukeofwaltham wrote:

What do you mean?

And, for the record, I do not like the sound of "blanket-rejected". It indicates a lack of willingness to examine the specific proposal on its merits. The strictest limit, one hour, would allow for all the benefits and would completely exclude any possibility of abuse (RfAs and RfArs have been cited mostly); I could even say that some misunderstandings might be avoided by editors changing a potentially offensive summary immediately afterwards, regretting their quick temper.

The proposed mechanism has been implemented in most online forum systems (such as phpBB) postings and has proven its usefulness and safety for years.

dev wrote:

Just an FYI, I've actually been working on an extension that'd allow this to happen, it needs a bit of a cleanup, and I need some sleep, so I'll post it online sometime soon.

dev wrote:

Patch to introduce PageHistoryTool hook

(In reply to comment #4)

Just an FYI, I've actually been working on an extension that'd allow this to
happen, it needs a bit of a cleanup, and I need some sleep, so I'll post it
online sometime soon.

Current code is online at http://dev.nigelj.com/mw/ it still needs a little bit of fixing, but it's nearly there.

Note, it requires the patch attached to work (n.b. changelog entry and hooks.txt edit removed in order to apply cleanly).

attachment PageHistoryTool-hook.patch ignored as obsolete

dev wrote:

Correct patch

Oops sorry folks, the last patch added an extra hook arguement that is by no way needed, here is the correct one.

attachment PageHistoryTool-hook.patch ignored as obsolete

Huji added a comment.Jul 7 2008, 1:52 PM

Nigel, I think a better (more generic) name should be used for the hook. Other than that, I find the idea useful.

dev wrote:

(In reply to comment #7)

Nigel, I think a better (more generic) name should be used for the hook. Other
than that, I find the idea useful.

Yeah, I agree whole heartedly.

Naming it SpecialFixsummary would be a better choice (which I've now done locally).

dev wrote:

Rebased patch w/ hooks.txt documentation

I've rebased the patch, just need to finish updating the extension etc, hopefully do that this weekend.

attachment mediawiki-pagehistorytool.patch ignored as obsolete

ayg wrote:

The added hook seems relatively reasonable, independent of the merit of the request that this bug actually makes. Use tabs, though, not spaces. And you're missing documentation for the PageHistory object (first parameter passed) in hooks.txt.

I think the basic idea is worth considering, but an hour is far too long. Five minutes should be a maximum. Anything more would be too confusing, in my opinion.

Keywords: patch, need-review

dev wrote:

Rebased patch (r39564 w/ updated hooks.txt documentation and tabulation instead of spaces

(In reply to comment #10)

The added hook seems relatively reasonable, independent of the merit of the
request that this bug actually makes. Use tabs, though, not spaces. And
you're missing documentation for the PageHistory object (first parameter
passed) in hooks.txt.

Done in this update

(In reply to comment #11)

I think the basic idea is worth considering, but an hour is far too long. Five
minutes should be a maximum. Anything more would be too confusing, in my
opinion.

I agree, I plan in my next update of the extension to allow it to be customized.

Unfortunately I got distracted with other more important issues this weekend hopefully I'll be back onto this, this week.

(For reference, this hook allows the extension to hook in next to Rollback etc)

Attached:

ayg wrote:

Looking over the code, I think that a more comprehensive hook to replace the current PageHistoryLineEnding hook (while still keeping that for backward compatibility) would be a good idea. Currently we collapse everything into a string before we pass it to the hook, which is stupid. Instead, we should ditch the $s variable, and have the ending be something like this:

$ret = null;
if( !wfRunHooks( 'EndPageHistoryLine', $this, $row, $next, &$arr, &$ret ) ) {
return $ret;
}
return '<li>' . implode( ' ', $arr ) . "</li>\n";

This still has some issues:

  • Do we guarantee what numeric index various array elements have, or what? There are like ten or twenty different items going into this line, which makes for a really complicated single hook.
  • Imploding on spaces doesn't help with things like $tools that should really be passed as arrays themselves.

I don't think adding one extra hook for every widget on the line we want to be able to modify is a good idea. Is there any way to elegantly and simply expose *all* of this info to hooks?

Issues raised in comment 14 need to be addressed.

nolan.j.white wrote:

*** Bug 20511 has been marked as a duplicate of this bug. ***

TheDJ added a comment.Jan 10 2010, 4:32 PM

Created attachment 6944
Empty diff table alignment in Firefox

Attached:

TheDJ added a comment.Jan 10 2010, 4:37 PM

sorry, image was for anther bug.

sumanah wrote:

Changing keywords since Aryeh did review the patch.

This very clearly isn't just "related" to bug 10105, but depends on it; this is merely modifying the default rights set for the functionality requested in bug 10105, so discussion should remain there.

Note that https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement provides similar functionality without the dependency on bug 10105

Other reasons for allowing changing an edit summary:

  1. Not all content models support dummy edit. for example it's not possible to do a edit without changing the page's rendering in Wikibase. (which I think it's the most important reason)
  2. If others views a list of selected edits, for example using a tag filter, dummy
  3. Dummy edit is only a (bad) hack as it doesn't directly resolve the problem.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 11 2015, 8:35 PM
Matiia added a subscriber: Matiia.Nov 25 2015, 12:26 AM
Huji removed a subscriber: Huji.Nov 26 2015, 4:33 PM
-jem- added a subscriber: -jem-.Dec 14 2015, 7:46 PM
AS added a subscriber: AS.Jan 2 2016, 11:00 PM
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptJan 21 2016, 2:53 PM
DannyH updated the task description. (Show Details)Feb 5 2016, 11:51 PM
Bugreporter renamed this task from Correcting edit summaries (if own, last, & recent) to Correcting edit summaries.Feb 13 2016, 10:45 AM
Bugreporter updated the task description. (Show Details)
Ltrlg added a subscriber: Ltrlg.Mar 26 2016, 8:24 AM
Tacsipacsi updated the task description. (Show Details)Jun 8 2016, 10:41 AM
Oliv0 added a subscriber: Oliv0.Jun 8 2016, 4:32 PM

Change 296630 had a related patch set uploaded (by Sethakill):
[WIP] Allow users to change edit summary

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

Sethakill added a subscriber: Sethakill.
Quiddity updated the task description. (Show Details)Aug 21 2016, 7:13 PM
Quiddity closed this task as Declined.Sep 2 2016, 10:18 PM
Quiddity added a subscriber: Quiddity.

There are 2 main difficulties with this task:

  1. The user-interface. -- We don't want to add more default elements, especially ones that would rarely be used (relatively-speaking), to the already cluttered and info-dense tracking changes pages (history/usercontribs/recentchanges/watchlist/etc), all of which would need to have this consistently. We could potentially get around this, by just creating a Special:UpdateEditSummary page, and either linking to it somewhere on the tracking changes pages, or just leaving it out and considering it as a semi-hidden power-user feature.
  1. The tracking of changes. -- We would need to be able to see the original version of an edit summary. We would need to be able to see any subsequent versions, if more than one change was made. This information would need to be in the logs at the very least, and probably need to be included in the various tracking changes pages, in order to avoid user-confusion, and to provide transparency. It would definitely need to be integrated with all the usual moderation tools (revdeletion, oversight etc). As various comments in the Wishlist survey noted, this would basically be creating a mini-history-within-the-history.

Whilst (1) is potentially easily (albeit imperfectly) solvable, implementing all the requirements for (2) would take many months of effort from a few developers, given the numerous core code changes and database changes that would be required. It would also further complicate the tracking changes pages and logs from an editor perspective.
For these reasons, we're declining this feature-request.

He7d3r rescinded a token.Sep 4 2016, 11:20 AM
He7d3r awarded a token.