For several years the reply to “How do I ensure a wiki post is bumped when it’s edited?” was to close the topic to prevent replies and delete all replies below the wiki. Then edits on the wiki post were edits on the last post and edits on the last post meant that the topic was bumped.
Now edits on the last post no longer cause a bump in the topic list. So how does everyone track edits on wikis now?
I know you can watch topics to receive notifications about wiki edits. But for me it’s not the same. I cannot set a single topic to be watched by all users by default. But they would all see when the topic was bumped. Even visitors can see that a topic is bumped while you need to log in to see your notifications.
Also I think the bug report that those notifications aren’t reliable is still open Sporadic Wiki Post notifications and there was another report recently which also mentioned that notifications do not always work Subsequent Wiki Edits by Same User Don’t Trigger Notifications. So notifications and watching don’t seem like a replacement for bumping wikis after an edit for me.
If I had a great idea, I would have created a feature request or replied to one of the many existing ones.
I’d take bumping back. But I don’t think it’s helpful to ask for a feature that was removed.
I understand that it can be annoying for small typos. But I guess there were reasons why you decided to remove bumping on all edits, instead of, for example, preventing it on small changes, similar to how small edits aren’t tracked within the editing grace period.
So I just try to find workarounds for the side effects of that change.
We encourage users to edit their posts to add new information instead of replying again. But who will notice the new information if that no longer bumps the topic?
Anything based on notifications won’t help for visitors. To receive notifications, you need to be logged in. To see a topic at the top of latest, this wasn’t necessary.
So I guess I need a reply or, better, a small action post announcing the fact that there was an edit. I know staff can bump a topic, but that doesn’t help on edits by users. So maybe I need a bump option for regular users.
Create reply when editing wiki would also fix the issue for wiki edits. But on wikis that are edited often, this could mean lots of replies that are only helpful as long as they are the last post. No one is interested in the 50 posts that are notifications of wiki edits 2 years ago.
So I don’t think this is a feature request. I don’t have a solution. I have a problem because the solution I had was removed.
The use case that came first to my mind was the FAQ in a forum I use. It’s a topic kept without replies exactly for the purpose that it’s bumped when someone edits it.
This had numerous advantages for us.
First of all, many members noticed when the topic was being edited. I therefore never worried that a user with bad intentions could cause lasting disruption there. Even if someone reached TL1 and tried to add spam there, that would have been removed by the next person visiting the forum.
I was also able to add new information without having to find someone to review it first. I could trust that several community members would do this anyway when they saw the update. Probably faster than the person I would have asked for review would have seen it at all. In addition, I had not only one review from one user but from several. The responsibility was spread across many more people. Everyone helped improve the answer to the question.
I was also able to encourage new members to improve the wording. Users who are less technically savvy often find it difficult to understand overly technical explanations. It helps if, once they have understood it, they improve the wording so that the next person might understand it better. Of course, new users tend to have more difficulty with the correct formatting. But that wasn’t a problem because the community could correct it afterwards as soon as they noticed it.
The FAQs are pinned in the forum. I thought it was great that the date of the last edit was shown right next to it in the activity column. That way, the topic never looked outdated, but everyone could see that it was constantly being updated. Now the activity date won’t update anymore,
Within the past days I noticed wiki edits came to my mind first, because we had to find solutions for that before and I found all those topics from other users having the same problem. But actually the problem also exists for other meaningful edits where users add valuable information later. Of course those are not necessarily added to the last post. But I think that this is the most likely case. Discourse even forces users to edit their last post instead of replying several times in a row. I wonder how I’d feel on a forum I joined where the software tells me to edit my post instead of replying and if I did, no one noticed. It would feel like nobody cared. I guess it’s not a place where I wanted to stay.
In this forum meaningful edits for example happen when users are adding output from the serial monitor or pictures later.
Conversation example
new user: Hey I have problem X
member: Hey we can help you better after you shared images of X
new user: Can’t take images right now, will do that later when my child is in bed.
and then they put the pictures into that post later
I am worried we might miss these edits without the topic being bumped.
Getting back to your questions: while no one needs to know when a typo was fixed everyone might be interested in valuable updates. Visitors can easily tell that the wiki is actively maintained. Members can review changes on wikis and notice edits providing updated information.
For wiki posts, signaling to the community as a whole that a post had recently been edited is helpful for two reasons:
It helps distribute the responsibility of reviewing changes, to ensure their accuracy.
it helps show that they are up to date
For conversations, given that Discourse discourages multiple replies, people need a way to see that a significant edit was made instead.
I think you’re right that bumps had been a solution to both of these needs.
We will need to think about how best to address them, given the removal of the bump on edit behavior.
For the conversation one, I think the answer may be to soften the discouragement of multiple replies. I think there are cases where multiple replies makes more sense than edits, and we can adjust the wording and logic of when the nudge appears to help users make the right decision.
For the wiki one, I think it needs a bit more discussion, but I’ll share some hot takes. I think instead of discouraging replies on topics, we should encourage them, and design things diff with that in mind. If they were allowed and encouraged, I think I may shift expectations to say “if you make a significant edit, drop a reply on the topic briefly describing the changes and why you made them”. That’d bump the topic and make it even more transparent. We’ve talked about how replies should be displayed on wiki and documentation topics, so maybe that’d deserve another look.
Another thing I could imagine doing is having some shared notification stream for edits to wikis and documentation. For example, a chat channel that gets a message posted to it automatically when there are edits made. The group that actively manages it could see those there together, and discuss in a thread of needed. Not sure how hard that’d be to wire up today with existing tools. (There’s some possible overlap with this idea and this other discussion: How automated reports could help keeping Meta tidy)
I actually like that the wiki topic doesn’t have replies because whenever I click the topic, I am taken to the first and only post. While knowing there was an edit is relevant for noticing it, I don’t need to read about that over and over.
I know there is a category setting for taking me to the first post when all posts are read, but I wouldn’t want all topics in that category to do that.
Any chat-based solution won’t work on forums where chat is disabled
Yeah, I understand that. This is the kind of thing I was hinting at here:
There’s plenty to unpack there, but it could be something like hiding replies by default, for example. It’s a bigger conversation, for sure.
Fair enough. It could be enabled in a very targeted way for this use case, though. For example, we make limited use of chat on meta ourselves for things like this today already, but they aren’t widely visible and the general community participation still happens almost exclusively in forum discussions.
It’s hard to pinpoint the rationale to a single thing. We observed a handful of things that led to us deciding to remove the “bump on edit last post” behavior.
In the case of minor edits, it’s unnecessary noise, as you mentioned.
But even in the case of major edits, we observed it’s also difficult to explain and often unwanted. We saw people often reach for the “reset bump date” feature when they hold that power after a major edit to a documentation topic, for example. Especially when multiple topics were being edited, but even for single topic edits. We even had people flag posts telling us to do this when we hadn’t bothered to do it ourselves.
But “reset bump date” isn’t too discoverable. People would ask how to do that, signaling that they really didn’t want to bump things but hadn’t figured out how to prevent it, and that likely many who hadn’t bothered to ask faced the same problem.
Another observation was people incorrectly assuming others would see their major edits. They’d create a stub post and edit it as they worked on it. They’re confidence that others would be following along was boosted by the bump. But in reality, many who followed along with the topic didn’t bother to check because the topic still doesn’t show up as unread after edits. So an extra reply to explicitly call out revisions and ask for review or feedback in these scenarios was often necessary anyway, but wasn’t happening.
I’m pretty confident that things will eventually be easier to understand without this functionality, but we’ll need to address a couple of these cases where people had come to depend on it.
This is quite interesting. I would have thought a major edit of a doc would be just the thing to warrant a bump in Latest to get some extra eyes on the new info/new feature and propel it back into the forefront of ‘current’ content. (Though I was also judicious with the Reset Bump Date feature as well when the edits weren’t enough to warrant bothering everyone with. But it was nice to have the option)
Yes, having the topic title flash back up as black rather than grey would have been a nice touch. Personally, I liked having them bumped and would read them to see what had been edited (it was also good for catching edit spam too )
I thought I’d give this a go here to see how it feels, and I must say it feels rather naughty. I think the concept of editing the post to add my ‘extra thoughts’ is so ingrained that trying this new way of ‘new reply each time’ almost borders on sacrilege.
I’m going to work on it and see if it gets any more comfortable.
I think, on a more practical level, the extra pings (+emails) may also be a downside. The reading experience for others might be a bit degraded as well when you hit a spurt of two or three posts from the same user. That would normally be an example of where a mod would merge them.
I do think there’s lots of room to fuss about the details here. Like, if you have extra thoughts to add 5 minutes later, you might still want to edit. If you have them a day later, another post feels better. I think the difference has to do with whether you assume others have read your post yet or not, or are still actively engaging in the conversation. It’s nuance all around.
@Moin, this is turning into more of a “feedback about a recent change” topic. What do you think? Should we embrace that and update the title as such? Or fork out the more general discussion into a new topic and leave this behind as something more tightly scoped to how we suggest handling wiki edits going forward?
But it was nice to have the option)
It felt a little like farting in public.