Along the same lines as #134, I'd like to have a way to preview comments before submitting them and/or to edit comments after submitting them.
Fix formatting (especially Markdown). This function should be available in a preview.
Fix wording (for example, sentences I noticed are ambigious). This would be a reason for editing because sometimes you notice only a bit later that something isn't as easy to understand as you initially thought. I'm aware that you can always add another comment to clarify, but for many cases, this seems overkill, so the clarification doesn't happen.
Adding a part of program output that you omitted when submitting the comment (maybe because you thought it's not relevant). Adding this output to the comment is much more concise than repeating the previously listed output together with the previously omitted output.
So in my opinion neither of preview or edit is a substitute for the other. For Markdown fixes, you'd want a preview, for text changes you'd want editing. That said, editing is the more
universal of the two features, so if you implement only one I'd prefer edit over preview.
A simple idea here - next to the Comment button a checkbox[x] Preview before postingcould work. If checked (default) it goes to an intermediary screen previewing the comment, with options [Edit] that returns to the initial screen with comment body in, and [Post] that makes it live. If the idea of the comments is to have them concise and valuable, a slow-down in between helps.
Editing after posting would probably require keeping track of the changes so the meaning thread doesn't get lost. Notifications go out with the posted comment immediately and others may start writing own responses. Altering or deleting the initial post in the meantime could lead to confusing threads for an observer later. Probably best to keep it simple.
Editing is definitely not planned, because your comments get emailed out to subscribers right away, and you can't take that back. A preview checkbox sounds smart, though.
I think most ticket systems nowadays support editing comments. If I know that, I know that the version I got mailed may be different from the version in the web interface. So I click the link in the email to read the current version of the comment in the web interface. I assume most people will know this, too. (By the way, my understanding from your comments is that you can reply directly to the ticket system email to add a comment to the ticket. I didn't know that, although I'm not extremely surprised either. :-) )
If the idea is that you can rely on the comment being the current one in the email and reply in your email client, I understand the reservations about editing comments. On the other hand, I'm not sure if replying directly to comment emails is a good idea to begin with. This might mess up the Markdown rendering in the web interface unless the email sender was extremely careful to make sure that they wrote valid Markdown, including keeping the Markdown in any quoted parts correct. Therefore, replying on the web may be preferable anyway because you can check the Markdown formatting (once you have the preview ;-) ).
Whatever the user interface for posting comments becomes I think it should be consistent with posting of ticket descriptions.
It seems like you can edit posted issues. This causes some regulatory issues in with regard to many European countries' hate speech laws: any administrator of such a site is liable for all content posted there, even if he or she is not the host or operator. Conversely, hosts are not responsible. However, e-mail conversations are exempt, and thus logs of mailing lists should also be.
It would be really nice to have an option to disable all editing of content and have it work like
listsbut with a HTML form to send e-mail, to achieve the legal fiction of it being a nice front-end around a mailing list. Otherwise, users from my country and many others would be prohibited from using the issue tracking service to its full extent, having instead to rely on lists for both discussion and issue tracking. In particular, messages from anonymous users couldn't be permitted, as it's possible to craft messages which, while illegal, are not readily detectable as such - there is a significant regulatory uncertainty in the field.
Here is an English translation of the relevant Swedish law:
Leave the law and its implications to me, there's no need to be a backseat lawyer.
Closing this ticket because comment previews have been implemented.
Certainly you cannot be familiar with all the law in the world? There have been numerous cases in which people have been found guilty of administering Facebook groups, so it seems like it would hold for issue trackers as well. This is a matter of great concern for me as I do not want to be fined or imprisoned for running an issue tracker.
(I'm not saying you, being an American, are at any risk, I'm saying many European users (e.g. all Swedish users) of the platform who administer their own issue trackers are, whether they host the site or not)
It is your responsibility to conduct yourself with respect to the laws to which you are subject. If this means not editing tickets, then don't edit tickets. It is SourceHut's responsibility to conduct itself according to the laws to which it is subject, and editing tickets is fine. In any case, tickets are emailed to you, so the original record exists regardless.
No, having the mere ability to edit tickets makes it a BBS (illegal), whereas not having the ability makes it a mailing list (legal). You need to have a way to disable the editing feature altogether and make it a mailing list, or you are liable.