This will extend to many other topic state changes: pin, archive, banner, unlist, and so forth. Any message you used to see in yellow will be in this newer, muted style.
I was thinking, along the way we might want to add an option to show category changes and title edits in the same way, inline in the topic.
This is, strictly speaking, duplicating the edit history that already exists in the first post of the topic. It would just make category changes and title edits much more visible and public.
Is this useful as a default? Could get a bit noisy if the OP decides to edit their title five times, on the other hand, seeing topics get recategorized makes it clearer when and why “gardening” is going on, etc.
Definitely in favour of muting all staff messages.
As for the OP edits, I’m quite reluctant. My experience with GitHub is that they log too much. I feel like an idiot whenever I’ve chosen the wrong label, milestone or what-have-you for an issue, which GitHub will be all too happy to put on my “public record” as if it was important information pertaining to the discussion at hand.
That, in turn, means that in order to make such a feature less disruptive, you’d need to take into account a bunch of corner cases:
No change-note should be created within the 5 minute edit grace period.
In a series of changes of the same type, only the latest should show (e.g. I change category to feature, then to spec, then back to feature again. Wouldn’t want all of those logged; just the final change).
For long logs, you’ll want to add truncated/untruncated options, like for inc/outg links.
Where should OP edits be displayed? Always under the topic post, or spread chronologically throughout the topic like the other Staff messages? (the latter seems more correct and visible, but could quickly lead to noise)
I think edit history is enough. It’s important that changes are recorded, to avoid “backtracking” or malicious editing (on an old forum, I once saw a prolific and useful poster edit all of their thousands of posts to whitespace after a dramatic flounce. There was nothing the admins could do), but I don’t think it;s worth notifying the topic at large.
We rate limit everything by policy, so there’s no way a user could edit a ton of their posts in the same day with Discourse. They could rage-edit (x) per day…
I think I’m on the side with @erlend_sh, I’m not sure a typical participant cares that the category/title were changed.
As a participant, why would I care if this topic was moved from Feature to Bug or to UX? I wouldn’t. Why would I care that the title was made more/less descriptive, or a typo was corrected in the title? I wouldn’t.
The biggest part that I would care about, is the original post. If that significantly got altered, then I care, as it could alter my response and any future responses. But again, not sure I see that as worth showing an indicator.
It would be nice to see if there are metrics for how often a title/category is changed on a relatively active site.
These all make sense. Today, they are distracting, especially banner and pin. Unlist, eh… we use that a lot at Sitepoint and it is occasionally nice that it is very noticeable so the user sees it.
I’ve always felt their presence was a bit too strong in most cases anyway, so I look forward to them being a bit more muted.
Although I think it make the most sense to just leave it open to plugin territory, I will say that this could be useful as long as it’s opt-in every time. Many wikis do the opposite: they let you opt out by checking a “this is a minor edit” box.
So if I felt like my category change had some significance, I could check the “Important edit” box, which would trigger a change-notice.
As a “regular” here, I’ve never changed a category, and I’ve only edited a title once, to correct a typo where a couple of letters were transposed. I don’t care about that showing up in the edit history if someone wants to bother to look, but I personally would not make a correction like that if a notification of it was going to stuck right in the topic.
eh. I still probably don’t care. The reason it was moved a year after was probably a new category was created and makes more sense now. The user himself couldn’t do it a year from now, as the edit window default is 3 months (I think, maybe 6 months).
So that leaves TL 3 and Staff, both of which I trust.
