This ticket represents requirements for the initial approach we take to editing specific comments as well as the work involved with implementing it.
Requirements
⚠️This list is still evolving
The following requirements. should be implemented for use by contributors to all Wikipedia talk pages on desktop web
- Contributors will only be able to see the edit affordance on comments they have written
- Technically, contributors will only be able to see the edit affordance next to comments signed with the username they are logged in with
- Contributors will not see an indication that a specific comment has been edited on the talk page (e.g. there will be no "edited" indication as there is on Slack for example)
- Contributors should not be able to edit their signature, regardless of the edit mode (source or visual) they are using.
Open questions
- How should notifications behave when a contributor @ mentions someone new while editing their comment. See this comment for context: T246245#5976962
- Should edited comments have a dedicated change tag associated with them? See T273611 via @Patriccck.
Done
- The "Open questions" above have been answered
- The "Requirements" above have been implemented
On-wiki mentions:
- Akoopal at nl.wiki: https://w.wiki/S6Q
- https://w.wiki/uWk
- @Klein (https://w.wiki/3sQ$): "...I want to be able to edit my last comment because of a typo or another minor change and for that basically I have to scroll up to the top, press edit for the whole section, scroll back to the bottom again... In long conversations it gets really tiring."
- User:LittleGun, "I would like to be able to edit individual replies, rather tan [sic] a whole section." | source
- mw:Topic:Wvwd06jr8wr6iux5
- Topic:Wvx2piv3cl4aecof
- @MichaelMaggs on en.wiki
Related ObjectsStatus Subtype Assigned Task Open None T245225 Implement editing specific comments Open None T242562 Develop a technical approach for editing a specific comment Resolved ppelberg T245220 Comment parser should report range of comment and signature separately Open None T273611 Add tags "Own comment edit" and "Foreign comment edit" when editing comments
- Mentioned In
- T338534: Generate a design that accommodates multiple comment- and topic-level actions
T243249: New discussion v1.0: conduct usability testing
T258743: Change what symbol is prepended to pings on ar.wiki
T249861: Make it possible to customize the default signature format per wiki
T246245: Reply v2.0: Create annotated tickets for posting on-wiki
T245221: Replies v2.0: Engineering
T245220: Comment parser should report range of comment and signature separately
T244498: Replies v2.0: determine what additional instrumentation is needed
T245222: Implement opt-in/out of watching talk page in Replying workflow
T235593: Replies v2.0: create mockups - Mentioned Here
- T273611: Add tags "Own comment edit" and "Foreign comment edit" when editing comments
T245221: Replies v2.0: Engineering
T246245: Reply v2.0: Create annotated tickets for posting on-wiki
T242562: Develop a technical approach for editing a specific comment
T240640: [Feedback] Not supporting adding multiple signatures in a comment
T245220: Comment parser should report range of comment and signature separately
Event Timeline
Comment ActionsLast week, over chat and during Thursday's 13-February standup, we made the below decisions as it relates to the initial approach we will take for the workflow for editing specific comments on talk pages.
The below have also been added as requirements to the task description.
What rules should inform how and where the edit comment affordance is displayed on the talk page?
- Contributors will only be able to see the edit affordance on comments they have written
- Technically, contributors will only be able to see the edit affordance next to comments signed with the username they are logged in with
What will indicate a comment has been edited?
- Contributors will not see an indication that a specific comment has been edited on the talk page (e.g. there be no "edited" indication as there is on Slack for example)
- Thinking: if we were to implement a feature like this right now, it would only work reliably on comments edited using DiscussionTools, not those using full page editing. In an effort to help contributors stay focused on what they are trying to accomplish, without needing to think unnecessarily about the internals of the system, we think the implications of the action they are taking – in this case, editing a comment – should be as consistent as possible between the Replying and full page workflows.
Should a person's signature be editable when editing their comment?
Meta
- The user experiences of the "compose" and "edit" comment workflows should be as consistent as possible
- Thinking: consistency will help people form a clearer understanding and more realistic expectations of what the workflow can and cannot do. We worry mixing the two will lead to confusion.
Rich text mode
- Signature should not be editable [1]
- Thinking: We are assuming contributors using the rich text input (more likely to be Junior Contributors) will not expect to be able to affect their comment's metadata considering: 1) this information is not exposed in the "compose" part of the experience and 2) this information is not exposed in the editing workflow on similar sites (e.g. Github [2] and Gitlab [3])
Source mode
- Signature should not be editable [1]
- Thinking: Exposing the signature could lead contributors to become confused about how auto-signing works and when it is triggered leading to confusion and potentially, frustration.
- This functionality will require some enhancements to the parser which are being worked in this task: T245220
Comment ActionsI'm copying a comment from a subtask, about signatures not being editable:
In T245220#5900718, @Alsee wrote:
This seems like a poor idea. If you cut the editable range short, they can't append after the signature. We don't usually do that for quick spelling/grammar/link fixes, but major or late changes will often get an appended second signature and possibly a note of what major change was made. Also any attempt to identify the start of the signature will be a guess, and guesses which are wrong will produce very odd behavior for the affected users.
I looked up our internal discussion from 13 February and we actually considered this, but decided that "supporting that use case would be more complex, as we'd have to let people insert content after the signature". (I'm not really convinced if that's true, I'd have to think about it more.)
Also, comments like this (with multiple signatures) can exist on pages if they were added using the normal wikitext editor, and we already support replying to them (T240640). When we implement editing, editing such a comment will open the edit box with the signature in the middle, and no signature at the end, which would be pretty confusing (although, admittedly, comments like that are somewhat rare).
Comment ActionsMy proposal for handling signatures while editing:
- In source mode, the signature(s) should be visible and editable as normal
- In visual mode, the signature(s) should be visible, but treated as a focusable node (basically, you can't edit inside of it)
But we have a parser that detects signatures, and we should be able to use the signature ranges it reports (T245220) to also parse signatures in our visual mode
In both modes, if the user removes every signature from the existing comment, add a new signature
- Removing the signature is never a good idea, and probably indicates the user is confused or did it accidentally, but we can't really prevent it…
- We must ensure there is a signature, otherwise it would become impossible to edit/reply-to this comment using our tool, because it would no longer be detected as a comment
- (Maybe investigate if we actually can prevent the user from removing the signature(s), that would probably be better if it is possible)
Comment Actions@matmarex I think you should reconsider how you're conceptualizing the product. We're not building a discussion system, we're building a convenience-tool for wikipages. Consider your points here:
- We must ensure there is a signature (because reason)
- Maybe investigate if we actually can prevent the user from removing the signature(s)
The rationale for the constraint is irrelevant. Constraints-based reasoning does not hold for this product unless you're planning to enforce those constraints in full page edit mode as well.
Comment Actions@Alsee I don't see how the behavior of full-page editing is relevant here. We are not changing how it works.
We're building a tool to post or edit comments. If you need to do something other than posting or editing a single comment, you should use the full-page editing interface. I thought that was obvious, but perhaps it was not.
Making it possible to remove a signature in a comment would mean corrupting pages, and we're committed to not causing page corruption.
Comment Actions@matmarex first note that I'm not actually taking any position here on how the product should work in this case. I'm talking about how we reason about the design. Discussion Tools is a parallel option for posting and editing comments. Any rationale for how Discussion Tools will work should be based on what makes sense for the product given that attempted constraints do not actually hold.
Making it possible to remove a signature
It is possible. Given that it is possible, does it make sense for the new tool to lack that ability? Maybe, but not based on an "it should not be possible" rationale. Any deliberate limitation or constraint in the product should be considered in terms of "Would the product be better if we force users to go full-page-edit to do that?"
Comment ActionsDevelopment update: 17-March
@Alsee + @matmarex, considering I don't have anything to add to y'alls conversation at this moment, I'm going to sidestep what you have been discussing to share the following update:
For the time being, we are going to pause development on the new workflow for editing single comments on talk pages.
More details here: T242562#5977993
ppelberg updated the task description. (Show Details)Jan 16 2021, 12:40 AM2021-01-16 00:40:15 (UTC+0)Comment ActionsI just noticed this task. On the one hand, I agree that the tool should not allow removing the signature—yes, removal is always possible using full page editing, but if the tool doesn’t allow it, the chances of accidentally removing the signature are much lower. On the other hand, just stripping it from the end and putting back on save isn’t going to work:
- There may be a signature in the middle. That can’t be stripped, how would you handle it?
- Even if the signature is at the end, it may not be preceded by the current content of discussiontools-signature-prefix (either because the message changed in the meanwhile, or because the user originally typed the tildes manually—e.g. I usually type – ~~~~, where the space is U+00A0 NO-BREAK SPACE, not U+0020 SPACE as in the message). Just stripping and putting back will change the prefix from U+2013 U+00A0 to U+2013 U+00A0 U+0020, i.e. there will be two spaces (and because one of them is a non-breaking one, actually two spaces will appear). If you strip just the signature itself but not the prefix, it’s quite likely that someone appending a new sentence to their comment will not leave an extra space at the end, just like they’re not supposed to do this when posting a new comment.
- Also you should consider that a signature is not a static thing. The timestamp part is almost certainly different from (older than) the timestamp ~~~~~ would generate at the time pre-save transform happens during saving the edit. Which is actually something the user may want to take advantage of (e.g. if they update their comment just after publishing it, they might want to update the timestamp as well), but probably most of the time wants to avoid.
ppelberg moved this task from Backlog to New Features on the DiscussionTools board.Aug 11 2021, 4:31 AM2021-08-11 04:31:42 (UTC+0)Comment ActionsRegarding the whole signature discussion... I believe the importance of the timestamp must be stressed. If one comment changes, there's no logical sense to keep the old timestamp. Keeping that in mind, maybe the signature should be removed automatically altogether and re-introduced in the new version of the comment every time an edit happens.
Comment ActionsThere is sense; it depends on to what extent the comment was edited. If one completely rewrites their comment, then yes, it makes no sense to keep the old timestamp. However, if one just fixes a typo without changing the meaning in a comment that got several replies in the meantime, changing the timestamp would cause a lot of confusion without avoiding any. Consider changing this:
I’d lyke to ask second opinions on this topic. —Alice 12:00, 3 June 2022 (UTC)
I support the idea. —Bob 12:10, 3 June 2022 (UTC)
I think it needs some adjustments, lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC)
into this:
I’d like to ask second opinions on this topic. —Alice 03:00, 4 June 2022 (UTC)
I support the idea. —Bob 12:10, 3 June 2022 (UTC)
I think it needs some adjustments, lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC)
Why did Bob and Charlie reply to a comment that has not yet been written at that time?
Or even:
I’d like to ask second opinions on this topic. —Alice 12:00, 3 June 2022 (UTC)
I suport the idea. —Bob 12:10, 3 June 2022 (UTC)
I second Bob. —Charlie 12:12, 3 June 2022 (UTC)
into
Or even:
I’d like to ask second opinions on this topic. —Alice 12:00, 3 June 2022 (UTC)
I support the idea. —Bob 12:15, 3 June 2022 (UTC)
I second Bob. —Charlie 12:12, 3 June 2022 (UTC)
What did Charlie second? There’s no comment written by Bob from before Charlie’s comment. Not even the indentation helps, as Charlie decided to technically reply to Alice’s comment.
Also, when substantial changes are made, it’s common not to change the timestamp, but simply strike through the old text and add the new. This way, it’s clear that the comment was substantially changed afterwards, but it’s also clear which comments were written after it was first published.
Comment ActionsIn regard to typo fixing personally I can see changing the timestamp as being equal to "this comment was edited". Generally speaking, I'm not too fond of heavy notices that tell that so a "time confusion" would be a subtle enough clue that comment editing had happened. Indentation would preserve the logical flow of the conversation.
BUT I didn't consider multiple/complex indentation situations. Those would suffer from my suggestion (even though I can't really think of many times when my discussion/context confusion has been resolved by looking at timestamps.) Having said that though, the strike through method scares me as it leans too much on the "heavy notices" method. Being pedantic in nature, I have a bad (?) habit of re-reading my comments multiple times and, most often than not, doing multiple micro-edits in a row to comments to fix typos, punctuation, make context clearer, etc. The idea of spamming all the participants with emails about my multiple edits was already scary enough and something that continuously plagues me (I so wish silent edits were an option for these cases). Making it so every little correction I make is marked with an ever growing row of stricken through timestamps is terrorizing.
This comment is just a mockup. It can't hurt you. — Klein 14:54, 3 June 2022 (UTC) Klein 14:56 3 June 2022 (UTC) Klein 15:00, 3 June 2022 (UTC) Klein 15:05, 3 June 2022 (UTC)
Ever since erasers were created people have tried a lot to make them leave as little mark as possible on the page. The whole point of erasers is to erase mistakes. You would think that the virtual space, free as it is from physical constraints, would be free of the ink residue that erasers can't fully clear in real pages. However, for reasons I understand, the exact opposite has generally happened. Fearing abuse or having complex situation in which you actually want your edit to be noticed, edits are generally heavy marked for easy noticing. A good balance should be chosen between those 2 concepts. In wiki we already have page history and page versions comparison. This should be an incentive to make edit history less pronounced as a thing, generally speaking.
Comment ActionsSorry, I wasn’t clear enough about the strikethrough. Not signatures are often struck through, but the substantially changed parts themselves, for example from
The typography-related parts should be removed, they duplicate the [[Lorem ipsum]] article. —Alice 12:00, 3 June 2022 (UTC)
I agree. —Bob 12:10, 3 June 2022 (UTC)
to
The typography-related parts should be removed, they duplicate the [[Lorem ipsum]] article. —Alice 12:00, 3 June 2022 (UTC)
I agree. Actually, if we remove everything related to typography, almost nothing remains, so this article should be redirected to [[Lorem ipsum]] instead. —Bob 12:10, 3 June 2022 (UTC)
Comment Actions
In T245225#7979283, @Tacsipacsi wrote:
Sorry, I wasn’t clear enough about the strikethrough. Not signatures are often struck through, but the substantially changed parts themselves...
That would be one of those cases when you actually want to draw attention to the change. The way I see it is that that case leans more towards "user desired text formatting to make content easier to digest" than "autoformatting that should be supplied as a default function by the tool". Just adding a strikethrough button beside the bold and italic ones in the text formatting options maybe can suffice for those cases. Or if we really think they're prominent enough, we can add that as an alternative ingrained function of the tool but I wouldn't like it if it was normative. As said, personally I'd hate getting reminded of my errors and mistakes and actually accentuating them more each time I try to edit/fix them.
Comment ActionsA lot of comments. There is something to say for changing the signature, for leaving the signature and even for adding a new signature, but it is all depending on the circumstances. I would trust the people editing to do the right thing, if in doubt, you can always check the history.
But, the tool should add the support for this. I would suggest that if you edit the comment, to just make the signature already in, to be part of the text, and add a checkbox (default off) to add a new signature to the comment. That will enable the user to do whatever is most appropriate.
Comment Actions
In T245225#7981322, @Tacsipacsi wrote:
...although adding a strikethrough button to the toolbar would be nice indeed...
Now that I see it carefully, strikethrough formatting is already possible in VE, and subsequently in replies, although you need one extra click to access that as a formatting option (together with some other ones). So maybe no changes are needed in that aspect?
>>! In T245225#7981322, @Tacsipacsi wrote:
...in many cases changing the timestamp would cause more confusion than what it’d avoid.
It would cause extra confusion on multi-leveled threads, I agree.
In T245225#7982277, @Akoopal wrote:
... I would suggest that if you edit the comment, to just make the signature already in, to be part of the text, and add a checkbox (default off) to add a new signature to the comment. That will enable the user to do whatever is most appropriate.
Maybe, inspired by what Tacsipacsi said above, the default state can be determined by the size of the comment change? Let's say, if it is less than 50%, you get a default off because most likely you were fixing typos and if it is more than that, you get a default on because you've made enough substantial changes to the comment to consider it a rewritten one. We can play with the percentage number as needed.
Comment ActionsLetting users decide whether the signature should be updated is a good idea, but I’m not sure if dynamic default value is also a good idea, for the same reason that differentiates minor edits (no substantial changes) and small edits (few changed characters). Consider the following non-minor (substantial) change:
I support option 1 2 for reasons explained in several sentences here. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. ~~~~
(the user made a typo, but the typo fix constitutes a substantial change), and the following minor (non-substantial) one:
I supoort support opion option 2 forr easons for reasons explaine d explained in severa l several sentencew sentences here. ~~~~
(the user typed faster than they actually can, but the ton of typos doesn’t change the meaning of the text).
Comment ActionsMy thoughts:
Signatures
If you are using DiscussionTools, signatures should not be editable or removable. Signatures are central to DiscussionTools working in the first place. If you're using the tool, you shouldn't have the ability to ruin the data structure and make replying harder or impossible for others who are using the tool.
Edits and timestamps
Here's how I think this should work:
- Timestamp should be replaced after an edit is made.
- A second automatic edit should be made after the reply is edited that adds a link(s) to the revision(s) of the edit(s) that was made to the reply. For example:
lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC) Edited
And if there are multiple edits, DiscussionTools would parse the "Edits" text and make a single button that would show a dialog to all of the edits.
Normal text:
lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC) Edit 3
Parsed text with "Edited" being a button:
lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC)
Comment ActionsI see the point that breaking a signature breaks the tool. But I don't
think it will be a big problem myself.
As an alternative, I would then propose to have a switch to either keep the
signature, add a signature (and then the old sig should be visible so you
can add text after it, explaining the edit), or replace the signature. That
way there is still the needed flexibility.
Regards,
André
Comment ActionsI see various rationales above essentially wanting to force or prohibit certain results. The community explicitly wanted to keep Wikitext pages, and asked for improvements making it quicker and easier to do what we already do. I think that concept resolves many questions about how these talk-tools should work.
If a user makes a typo fix, or even a sequence of ten edits typo-fixing, that should not mangle the date. It also should not spam ten history-links for the ten edits. Trivial fixes should be unobtrusive.
If someone significantly changes the meaning of their comment, especially if there have been replies to their comment, it is a community-based expectation that they are responsible to indicate their change. There shouldn't be any need for special handling special support when editing a comment - we should be able to use strike-through and italics and other formatting when writing the comment in the first place.
Sometimes we leave the original signature-timestamp in place, sometimes we delete it and generate a new signature-timestamp, and sometimes we keep the original signature-timestamp followed by an edit-explanation followed by new signature-timestamp. You just need a checkbox or something controlling whether a new signature-timestamp gets appended. When this box is checked, it just needs to be very visually clear what it's going to do.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T245225 Implement editing specific comments | |||
| Open | None | T242562 Develop a technical approach for editing a specific comment | |||
| Resolved | ppelberg | T245220 Comment parser should report range of comment and signature separately | |||
| Open | None | T273611 Add tags "Own comment edit" and "Foreign comment edit" when editing comments |
- Mentioned In
- T338534: Generate a design that accommodates multiple comment- and topic-level actions
T243249: New discussion v1.0: conduct usability testing
T258743: Change what symbol is prepended to pings on ar.wiki
T249861: Make it possible to customize the default signature format per wiki
T246245: Reply v2.0: Create annotated tickets for posting on-wiki
T245221: Replies v2.0: Engineering
T245220: Comment parser should report range of comment and signature separately
T244498: Replies v2.0: determine what additional instrumentation is needed
T245222: Implement opt-in/out of watching talk page in Replying workflow
T235593: Replies v2.0: create mockups - Mentioned Here
- T273611: Add tags "Own comment edit" and "Foreign comment edit" when editing comments
T245221: Replies v2.0: Engineering
T246245: Reply v2.0: Create annotated tickets for posting on-wiki
T242562: Develop a technical approach for editing a specific comment
T240640: [Feedback] Not supporting adding multiple signatures in a comment
T245220: Comment parser should report range of comment and signature separately
Event Timeline
Last week, over chat and during Thursday's 13-February standup, we made the below decisions as it relates to the initial approach we will take for the workflow for editing specific comments on talk pages.
The below have also been added as requirements to the task description.
What rules should inform how and where the edit comment affordance is displayed on the talk page?
- Contributors will only be able to see the edit affordance on comments they have written
- Technically, contributors will only be able to see the edit affordance next to comments signed with the username they are logged in with
What will indicate a comment has been edited?
- Contributors will not see an indication that a specific comment has been edited on the talk page (e.g. there be no "edited" indication as there is on Slack for example)
- Thinking: if we were to implement a feature like this right now, it would only work reliably on comments edited using DiscussionTools, not those using full page editing. In an effort to help contributors stay focused on what they are trying to accomplish, without needing to think unnecessarily about the internals of the system, we think the implications of the action they are taking – in this case, editing a comment – should be as consistent as possible between the Replying and full page workflows.
Should a person's signature be editable when editing their comment?
Meta
- The user experiences of the "compose" and "edit" comment workflows should be as consistent as possible
- Thinking: consistency will help people form a clearer understanding and more realistic expectations of what the workflow can and cannot do. We worry mixing the two will lead to confusion.
Rich text mode
- Signature should not be editable [1]
- Thinking: We are assuming contributors using the rich text input (more likely to be Junior Contributors) will not expect to be able to affect their comment's metadata considering: 1) this information is not exposed in the "compose" part of the experience and 2) this information is not exposed in the editing workflow on similar sites (e.g. Github [2] and Gitlab [3])
Source mode
- Signature should not be editable [1]
- Thinking: Exposing the signature could lead contributors to become confused about how auto-signing works and when it is triggered leading to confusion and potentially, frustration.
- This functionality will require some enhancements to the parser which are being worked in this task: T245220
I'm copying a comment from a subtask, about signatures not being editable:
In T245220#5900718, @Alsee wrote:This seems like a poor idea. If you cut the editable range short, they can't append after the signature. We don't usually do that for quick spelling/grammar/link fixes, but major or late changes will often get an appended second signature and possibly a note of what major change was made. Also any attempt to identify the start of the signature will be a guess, and guesses which are wrong will produce very odd behavior for the affected users.
I looked up our internal discussion from 13 February and we actually considered this, but decided that "supporting that use case would be more complex, as we'd have to let people insert content after the signature". (I'm not really convinced if that's true, I'd have to think about it more.)
Also, comments like this (with multiple signatures) can exist on pages if they were added using the normal wikitext editor, and we already support replying to them (T240640). When we implement editing, editing such a comment will open the edit box with the signature in the middle, and no signature at the end, which would be pretty confusing (although, admittedly, comments like that are somewhat rare).
My proposal for handling signatures while editing:
- In source mode, the signature(s) should be visible and editable as normal
- In visual mode, the signature(s) should be visible, but treated as a focusable node (basically, you can't edit inside of it)
- Removing the signature is never a good idea, and probably indicates the user is confused or did it accidentally, but we can't really prevent it…
- We must ensure there is a signature, otherwise it would become impossible to edit/reply-to this comment using our tool, because it would no longer be detected as a comment
- (Maybe investigate if we actually can prevent the user from removing the signature(s), that would probably be better if it is possible)
@matmarex I think you should reconsider how you're conceptualizing the product. We're not building a discussion system, we're building a convenience-tool for wikipages. Consider your points here:
- We must ensure there is a signature (because reason)
- Maybe investigate if we actually can prevent the user from removing the signature(s)
The rationale for the constraint is irrelevant. Constraints-based reasoning does not hold for this product unless you're planning to enforce those constraints in full page edit mode as well.
@Alsee I don't see how the behavior of full-page editing is relevant here. We are not changing how it works.
We're building a tool to post or edit comments. If you need to do something other than posting or editing a single comment, you should use the full-page editing interface. I thought that was obvious, but perhaps it was not.
Making it possible to remove a signature in a comment would mean corrupting pages, and we're committed to not causing page corruption.
@matmarex first note that I'm not actually taking any position here on how the product should work in this case. I'm talking about how we reason about the design. Discussion Tools is a parallel option for posting and editing comments. Any rationale for how Discussion Tools will work should be based on what makes sense for the product given that attempted constraints do not actually hold.
Making it possible to remove a signature
It is possible. Given that it is possible, does it make sense for the new tool to lack that ability? Maybe, but not based on an "it should not be possible" rationale. Any deliberate limitation or constraint in the product should be considered in terms of "Would the product be better if we force users to go full-page-edit to do that?"
Development update: 17-March
@Alsee + @matmarex, considering I don't have anything to add to y'alls conversation at this moment, I'm going to sidestep what you have been discussing to share the following update:
For the time being, we are going to pause development on the new workflow for editing single comments on talk pages.
More details here: T242562#5977993
I just noticed this task. On the one hand, I agree that the tool should not allow removing the signature—yes, removal is always possible using full page editing, but if the tool doesn’t allow it, the chances of accidentally removing the signature are much lower. On the other hand, just stripping it from the end and putting back on save isn’t going to work:
- There may be a signature in the middle. That can’t be stripped, how would you handle it?
- Even if the signature is at the end, it may not be preceded by the current content of discussiontools-signature-prefix (either because the message changed in the meanwhile, or because the user originally typed the tildes manually—e.g. I usually type – ~~~~, where the space is U+00A0 NO-BREAK SPACE, not U+0020 SPACE as in the message). Just stripping and putting back will change the prefix from U+2013 U+00A0 to U+2013 U+00A0 U+0020, i.e. there will be two spaces (and because one of them is a non-breaking one, actually two spaces will appear). If you strip just the signature itself but not the prefix, it’s quite likely that someone appending a new sentence to their comment will not leave an extra space at the end, just like they’re not supposed to do this when posting a new comment.
- Also you should consider that a signature is not a static thing. The timestamp part is almost certainly different from (older than) the timestamp ~~~~~ would generate at the time pre-save transform happens during saving the edit. Which is actually something the user may want to take advantage of (e.g. if they update their comment just after publishing it, they might want to update the timestamp as well), but probably most of the time wants to avoid.
Regarding the whole signature discussion... I believe the importance of the timestamp must be stressed. If one comment changes, there's no logical sense to keep the old timestamp. Keeping that in mind, maybe the signature should be removed automatically altogether and re-introduced in the new version of the comment every time an edit happens.
There is sense; it depends on to what extent the comment was edited. If one completely rewrites their comment, then yes, it makes no sense to keep the old timestamp. However, if one just fixes a typo without changing the meaning in a comment that got several replies in the meantime, changing the timestamp would cause a lot of confusion without avoiding any. Consider changing this:
I’d lyke to ask second opinions on this topic. —Alice 12:00, 3 June 2022 (UTC)
I support the idea. —Bob 12:10, 3 June 2022 (UTC)
I think it needs some adjustments, lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC)
into this:
I’d like to ask second opinions on this topic. —Alice 03:00, 4 June 2022 (UTC)
I support the idea. —Bob 12:10, 3 June 2022 (UTC)
I think it needs some adjustments, lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC)
Why did Bob and Charlie reply to a comment that has not yet been written at that time?
Or even:
I’d like to ask second opinions on this topic. —Alice 12:00, 3 June 2022 (UTC)
I suport the idea. —Bob 12:10, 3 June 2022 (UTC)
I second Bob. —Charlie 12:12, 3 June 2022 (UTC)
into
Or even:
I’d like to ask second opinions on this topic. —Alice 12:00, 3 June 2022 (UTC)
I support the idea. —Bob 12:15, 3 June 2022 (UTC)
I second Bob. —Charlie 12:12, 3 June 2022 (UTC)
What did Charlie second? There’s no comment written by Bob from before Charlie’s comment. Not even the indentation helps, as Charlie decided to technically reply to Alice’s comment.
Also, when substantial changes are made, it’s common not to change the timestamp, but simply strike through the old text and add the new. This way, it’s clear that the comment was substantially changed afterwards, but it’s also clear which comments were written after it was first published.
In regard to typo fixing personally I can see changing the timestamp as being equal to "this comment was edited". Generally speaking, I'm not too fond of heavy notices that tell that so a "time confusion" would be a subtle enough clue that comment editing had happened. Indentation would preserve the logical flow of the conversation.
BUT I didn't consider multiple/complex indentation situations. Those would suffer from my suggestion (even though I can't really think of many times when my discussion/context confusion has been resolved by looking at timestamps.) Having said that though, the strike through method scares me as it leans too much on the "heavy notices" method. Being pedantic in nature, I have a bad (?) habit of re-reading my comments multiple times and, most often than not, doing multiple micro-edits in a row to comments to fix typos, punctuation, make context clearer, etc. The idea of spamming all the participants with emails about my multiple edits was already scary enough and something that continuously plagues me (I so wish silent edits were an option for these cases). Making it so every little correction I make is marked with an ever growing row of stricken through timestamps is terrorizing.
This comment is just a mockup. It can't hurt you. —
Klein 14:54, 3 June 2022 (UTC)Klein 14:56 3 June 2022 (UTC)Klein 15:00, 3 June 2022 (UTC)Klein 15:05, 3 June 2022 (UTC)
Ever since erasers were created people have tried a lot to make them leave as little mark as possible on the page. The whole point of erasers is to erase mistakes. You would think that the virtual space, free as it is from physical constraints, would be free of the ink residue that erasers can't fully clear in real pages. However, for reasons I understand, the exact opposite has generally happened. Fearing abuse or having complex situation in which you actually want your edit to be noticed, edits are generally heavy marked for easy noticing. A good balance should be chosen between those 2 concepts. In wiki we already have page history and page versions comparison. This should be an incentive to make edit history less pronounced as a thing, generally speaking.
Sorry, I wasn’t clear enough about the strikethrough. Not signatures are often struck through, but the substantially changed parts themselves, for example from
The typography-related parts should be removed, they duplicate the [[Lorem ipsum]] article. —Alice 12:00, 3 June 2022 (UTC)
I agree. —Bob 12:10, 3 June 2022 (UTC)
to
The typography-related parts should be removed, they duplicate the [[Lorem ipsum]] article. —Alice 12:00, 3 June 2022 (UTC)
I agree.Actually, if we remove everything related to typography, almost nothing remains, so this article should be redirected to [[Lorem ipsum]] instead. —Bob 12:10, 3 June 2022 (UTC)
In T245225#7979283, @Tacsipacsi wrote:Sorry, I wasn’t clear enough about the strikethrough. Not signatures are often struck through, but the substantially changed parts themselves...
That would be one of those cases when you actually want to draw attention to the change. The way I see it is that that case leans more towards "user desired text formatting to make content easier to digest" than "autoformatting that should be supplied as a default function by the tool". Just adding a strikethrough button beside the bold and italic ones in the text formatting options maybe can suffice for those cases. Or if we really think they're prominent enough, we can add that as an alternative ingrained function of the tool but I wouldn't like it if it was normative. As said, personally I'd hate getting reminded of my errors and mistakes and actually accentuating them more each time I try to edit/fix them.
A lot of comments. There is something to say for changing the signature, for leaving the signature and even for adding a new signature, but it is all depending on the circumstances. I would trust the people editing to do the right thing, if in doubt, you can always check the history.
But, the tool should add the support for this. I would suggest that if you edit the comment, to just make the signature already in, to be part of the text, and add a checkbox (default off) to add a new signature to the comment. That will enable the user to do whatever is most appropriate.
In T245225#7981322, @Tacsipacsi wrote:...although adding a strikethrough button to the toolbar would be nice indeed...
Now that I see it carefully, strikethrough formatting is already possible in VE, and subsequently in replies, although you need one extra click to access that as a formatting option (together with some other ones). So maybe no changes are needed in that aspect?
>>! In T245225#7981322, @Tacsipacsi wrote:
...in many cases changing the timestamp would cause more confusion than what it’d avoid.
It would cause extra confusion on multi-leveled threads, I agree.
In T245225#7982277, @Akoopal wrote:... I would suggest that if you edit the comment, to just make the signature already in, to be part of the text, and add a checkbox (default off) to add a new signature to the comment. That will enable the user to do whatever is most appropriate.
Maybe, inspired by what Tacsipacsi said above, the default state can be determined by the size of the comment change? Let's say, if it is less than 50%, you get a default off because most likely you were fixing typos and if it is more than that, you get a default on because you've made enough substantial changes to the comment to consider it a rewritten one. We can play with the percentage number as needed.
Letting users decide whether the signature should be updated is a good idea, but I’m not sure if dynamic default value is also a good idea, for the same reason that differentiates minor edits (no substantial changes) and small edits (few changed characters). Consider the following non-minor (substantial) change:
I support option
12 for reasons explained in several sentences here. Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet. ~~~~
(the user made a typo, but the typo fix constitutes a substantial change), and the following minor (non-substantial) one:
I
supoortsupportopionoption 2forr easonsfor reasonsexplaine dexplained insevera lseveralsentencewsentences here. ~~~~
(the user typed faster than they actually can, but the ton of typos doesn’t change the meaning of the text).
My thoughts:
Signatures
If you are using DiscussionTools, signatures should not be editable or removable. Signatures are central to DiscussionTools working in the first place. If you're using the tool, you shouldn't have the ability to ruin the data structure and make replying harder or impossible for others who are using the tool.
Edits and timestamps
Here's how I think this should work:
- Timestamp should be replaced after an edit is made.
- A second automatic edit should be made after the reply is edited that adds a link(s) to the revision(s) of the edit(s) that was made to the reply. For example:
lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC) Edited
And if there are multiple edits, DiscussionTools would parse the "Edits" text and make a single button that would show a dialog to all of the edits.
Normal text:
lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC) Edit 3
Parsed text with "Edited" being a button:
lorem ipsum dolor sit amet. —Charlie 12:12, 3 June 2022 (UTC)
Comment ActionsI see the point that breaking a signature breaks the tool. But I don't
think it will be a big problem myself.As an alternative, I would then propose to have a switch to either keep the
signature, add a signature (and then the old sig should be visible so you
can add text after it, explaining the edit), or replace the signature. That
way there is still the needed flexibility.Regards,
André
Comment ActionsI see various rationales above essentially wanting to force or prohibit certain results. The community explicitly wanted to keep Wikitext pages, and asked for improvements making it quicker and easier to do what we already do. I think that concept resolves many questions about how these talk-tools should work.
If a user makes a typo fix, or even a sequence of ten edits typo-fixing, that should not mangle the date. It also should not spam ten history-links for the ten edits. Trivial fixes should be unobtrusive.
If someone significantly changes the meaning of their comment, especially if there have been replies to their comment, it is a community-based expectation that they are responsible to indicate their change. There shouldn't be any need for special handling special support when editing a comment - we should be able to use strike-through and italics and other formatting when writing the comment in the first place.
Sometimes we leave the original signature-timestamp in place, sometimes we delete it and generate a new signature-timestamp, and sometimes we keep the original signature-timestamp followed by an edit-explanation followed by new signature-timestamp. You just need a checkbox or something controlling whether a new signature-timestamp gets appended. When this box is checked, it just needs to be very visually clear what it's going to do.
)){kind=link}