- Edit Task
- Edit Related Tasks...
- Create Subtask
- Edit Parent Tasks
- Edit Subtasks
- Merge Duplicates In
- Close As Duplicate
- Edit Related Objects...
- Edit Commits
- Edit Mocks
- Edit Revisions
- Mute Notifications
- Protect as security issue
- Award Token
- Flag For Later
It would be nice for normal users to be able to change the text of an edit summary after it's saved. Obvious uses:
- giving proper attribution for text imported from other sources
- correcting typos (eg redlinks)
- retracting offensive remarks
- improving poor or unintentionally misleading summaries
Downsides? There would be some loss of traceability, if one user accuses another of having said something offensive in an edit summary, which is now not apparent. Perhaps all changes could be written to an admin-viewable log in case of disputes.
Sorry if it's been suggested before, I did look.
Related Objects Search...Sethakill T15937 Correcting edit summaries Declined None T12105 Allow editing of edit summaries after the fact
- Mentioned In
- T188798: Change the limit of the edit summary to 500 characters on all Wikimedia wikis
T15937: Correcting edit summaries
Event Timelinebzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:47 PM bzimport added a project: MediaWiki-Page-Diffs. bzimport set Reference to bz10105. bzimport added a subscriber: Unknown Object (MLST). bzimport created this task.Jun 2 2007, 2:35 AM bzimport added a comment.Jun 30 2007, 7:53 AM Comment Actions
From what I can see, this would provide a few issues, such as we would need to keep a history of the history, which seems unnecessary. Either that or restrict changing to sysops or original user only, and have a link next saying (changed X times). But this would cause a few history issues.bzimport added a comment.Jun 30 2007, 7:21 PM Comment Actions
What 'issues'? It's just an edit summary. What's the worst thing that could possibly happen if a rogue user changed their edit summary after the fact, and that change wasn't widely visible? Is that worst case scenario so bad that it's worth denying all the best-case scenarios from happening?
[Trivial alternative simple solution: New edit summary is prepended to old edit summary, thusly:
Fixed typos and created a new section, deleted three refs. [was: Created a new section, killed stupid refs]
]bzimport added a comment.Jun 30 2007, 8:15 PM Comment Actions
Perhaps a new log type could be created for editing the edit summary? For example, when User:Joe changes his edit summary, the following log entry is added:
[ date ] User:Joe changes edit summary from 'old summary' to 'new summary' on article 'Foo'.
This would avoid having to keep a history of the history, but still provide traceability.bzimport added a comment.Jun 30 2007, 10:11 PM Comment Actions
What *real* usage is there for changing edit summaries after the fact? The edit summary is never guaranteed to be accurate, as with any of the other properties, such as "minor edit" - if you want to know exactly what was changed, you view a diff of the edit.
This seems to me to add needless complexity, especially in terms of UI complexity, for the sake of appeasing pedantry. Strongly inclined to WONTFIX unless a solid rationale is presented.bzimport added a comment.Jul 1 2007, 2:55 AM Comment Actions
I agree with Rob. The issues this might possibly fix are too minor to merit the added complexity. In the case of seriously problematic edit summaries, of course, the edit can simply be deleted or oversighted. Minor typos can be ignored, and other "changes" can be submitted as null edits, or the user can request that an admin delete the edit and allow him to resubmit it with a better summary.jayvdb added a comment.Nov 14 2014, 2:17 AM Comment Actions