Follow-up Comment #7, sr #111305 (group administration): [comment #6 comment #6:] > On Tue, Aug 26, 2025 at 03:29:52PM -0400, Keith Marshall wrote: >> >> That said, my own [https://savannah.gnu.org/bugs/index.php?60927#comment13 >> comment #13], on that same https://savannah.gnu.org/bugs/?60927 ticket >> mentioned in [comment #0 my original submission], illustrates a further >> issue, >> which a ticket editing capability could mitigate: that particular comment >> includes a less than obvious typo, (U+2009 where I intended U+200B). I'd >> love >> to be able to fix that, but without a ticket editing capability, I cannot >> do >> so. > > How do people fix such things on mailing lists? They post a follow-up. I think we should be able to agree on this much: experience has taught us that mailing lists are a _really_ poor conduit for reporting bugs, or similar issues. Primarily, they fail because they offer no robust mechanism for recording and tracking progress, resulting in issues falling through the cracks, being forgotten, and remaining unresolved indefinitely. However, they also suffer from degradation of reporting and tracking quality, simply by virtue of those follow-up posts, which are inevitably required to correct errors in earlier posts. Such errors lead to confusion, and the consequent follow-up posts compound this; not only do they add clutter to the discussion thread, with a consequent degradation in cohesion of the discussion, but there is a danger of corrections being overlooked, and issue resolution being pursued on the basis of false premises.
Every other tracker system, on which I have had occasion to post, has allowed
post-submission editing, to correct submission; IMO, such editing leads
to a _significantly_ better quality of information within the tracker
content.
>> Perhaps less relevant on savannah, but FWIW, the most common reason for
>> using
>> this capability SourceForge, and on OSDN.net, was to correct the markup of
>> code samples, posted by user who didn't bother to acquaint themselves with
>> the
>> appropriate markup conventions; I would encounter this in original ticket
>> submissions, just as often as in follow up comments; the usual effect was
>> that
>> the code samples became unreadable, because elements of the code, which the
>> users were trying to illustrate, would be interpreted as markup.
>> Fortunately,
>> correction was possible, because an editing capability was available to the
>> original posters of malformed content, and to authorised project members.
>
> Enabling changes would result in two kinds of potential confusions,
>
> * The actual author of the post may differ from the original poster.
So what? Even if the correction is applied by someone other than the original
author, any improvement in quality of information is surely a win. I would
suggest that the edited post should remain attributed to its original author;
if edited by another, that can be recorded as a supplementary annotation,
(either supplied automatically, or manually, at the discretion of the editor,
within the body of the amended submission).
> * The user can't rely on the accessibility of any fixed comment.
Sorry, but I don't understand your concern here.
> If we implement editing, I think we should work out some features
> to mitigate them, e.g. limit editing to one time, with the original
> post being easily available.
I agree that recording of editing history, for individual posts, with the
ability to observe changes made, if practicable, would be worthwhile; however,
IMO limiting the _number_ of edits allowed is a _really bad_ idea.
I would suggest that what _should_ be restricted is _who_ is permitted to edit
content:
* Any user could be permitted to modify content which they, themselves, have
authored, (possibly subject to administrative blocking, in the event of
malfeasance).
* Any technician, manager, or administrator for the particular tracker, should
be allowed to modify _any_ tracker content; (presumably, you can trust those
to whom you have accorded such privileges, to act responsibly).
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/support/?111305>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
signature.asc
Description: PGP signature
