Nieuwe manier om bewerkingen op wiki-posts bij te houden?

Ondersteuning
1

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.

3 likes
2

Dit klinkt als een functieaanvraag. Hoe wilt u dat Discourse op wiki-bewerkingen wordt geattendeerd?

Wiki’s zijn al speciaal, dus misschien hebben we een nieuwe site-instelling nodig om meldingen van wiki-bewerkingen in te schakelen en een gebruikersvoorkeur over wanneer deze moeten worden gemeld.

3

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.

1 like
4

Ik hou van het idee van een kleine actiepost bij het bewerken. Maar ben het ermee eens dat dit rommel zal veroorzaken. Misschien kunnen ze verborgen worden achter een link om ze te verbergen/tonen?

Wanneer jij en je leden wiki’s bewerken, voeg je dan een notitie toe om de reden van de bewerking uit te leggen? Dat zou in de kleine actiepost kunnen.

5

Can we get a little deeper into defining the problem?

To begin with, who needs to know when a given wiki post is edited? What do you expect them to do when they see that a wiki post was edited?

1 like
6

Alle gebruikers die geïnteresseerd zijn in dat onderwerp. En ze willen graag nieuwe informatie lezen.

Dat was de belangrijkste reden waarom ik alle wiki’s op mijn forum heb verwijderd.

7

[quote=“mcwumbly, post:5, topic:383582”]
Kunnen we dieper ingaan op de definitie van het probleem?

Om te beginnen, wie moet weten wanneer een bepaalde wiki-post is bewerkt? Wat verwacht u dat ze doen als ze zien dat een wiki-post is bewerkt?
[/quote]De use case die het eerst in me opkwam, was de FAQ op een forum dat ik gebruik. Het is een onderwerp dat zonder reacties wordt gehouden, juist om de reden dat het omhoog komt wanneer iemand het bewerkt.
Dit had tal van voordelen voor ons.
Allereerst merkten veel leden op wanneer het onderwerp werd bewerkt. Ik maakte me er dus nooit zorgen over dat een gebruiker met slechte bedoelingen blijvende schade kon aanrichten. Zelfs als iemand TL1 bereikte en daar spam probeerde toe te voegen, zou dat zijn verwijderd door de volgende persoon die het forum bezocht.

Ik kon ook nieuwe informatie toevoegen zonder dat ik iemand hoefde te vinden om het eerst te beoordelen. Ik kon erop vertrouwen dat verschillende communityleden dit sowieso zouden doen wanneer ze de update zagen. Waarschijnlijk sneller dan de persoon die ik om beoordeling zou hebben gevraagd, het überhaupt zou hebben gezien. Bovendien had ik niet slechts één beoordeling van één gebruiker, maar van verschillende. De verantwoordelijkheid werd over veel meer mensen verspreid. Iedereen hielp mee de antwoorden op de vragen te verbeteren.

Ik kon ook nieuwe leden aanmoedigen om de formulering te verbeteren. Gebruikers die minder technisch onderlegd zijn, vinden het vaak moeilijk om te technische uitleg te begrijpen. Het helpt als ze, zodra ze het hebben begrepen, de formulering verbeteren, zodat de volgende persoon het beter kan begrijpen. Natuurlijk hebben nieuwe gebruikers de neiging meer moeite te hebben met de juiste opmaak. Maar dat was geen probleem, omdat de community het achteraf kon corrigeren zodra ze het merkten.

De FAQ’s zijn vastgezet op het forum. Ik vond het geweldig dat de datum van de laatste bewerking direct ernaast in de activiteitskolom werd weergegeven. Zo zag het onderwerp er nooit verouderd uit, maar iedereen kon zien dat het voortdurend werd bijgewerkt. Nu wordt de activiteitsdatum niet meer bijgewerkt.

In de afgelopen dagen kwamen wiki-bewerkingen me als eerste te binnen, omdat we daarvoor oplossingen moesten vinden en ik al die onderwerpen van andere gebruikers met hetzelfde probleem vond. Maar eigenlijk bestaat het probleem ook voor andere zinvolle bewerkingen waarbij gebruikers later waardevolle informatie toevoegen. Natuurlijk worden die niet noodzakelijkerwijs aan het laatste bericht toegevoegd. Maar ik denk dat dit het meest waarschijnlijke geval is. Discourse dwingt gebruikers zelfs om hun laatste bericht te bewerken in plaats van meerdere keren achter elkaar te reageren. Ik vraag me af hoe ik me zou voelen op een forum waar ik lid van ben, waar de software me vertelt mijn bericht te bewerken in plaats van te reageren, en als ik dat deed, niemand het merkte. Het zou voelen alsof niemand het gaf. Ik denk niet dat het een plek was waar ik wilde blijven.
Op dit forum gebeuren zinvolle bewerkingen bijvoorbeeld wanneer gebruikers later de output van de seriële monitor of foto’s toevoegen.

Gespreksvoorbeeld

nieuwe gebruiker: Hé, ik heb probleem X
lid: Hé, we kunnen je beter helpen nadat je afbeeldingen van X hebt gedeeld
nieuwe gebruiker: Kan nu geen afbeeldingen maken, zal dat later doen als mijn kind op bed ligt.

en dan stoppen ze later de afbeeldingen in dat bericht

Ik ben bang dat we deze bewerkingen zullen missen zonder dat het onderwerp wordt gebumpt.

Terugkomend op uw vragen: hoewel niemand hoeft te weten wanneer een typefout is gecorrigeerd, kan iedereen geïnteresseerd zijn in waardevolle updates. Bezoekers kunnen gemakkelijk zien dat de wiki actief wordt onderhouden. Leden kunnen wijzigingen in wiki’s beoordelen en bewerkingen opmerken die bijgewerkte informatie bieden.

1 like
8

OK, gotcha. Here’s what I’m understanding:

  • 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)

1 like
9

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 :worried:

1 like
10

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.

11

Uit nieuwsgierigheid, wat is de reden achter deze wijziging?

Als het voornamelijk is om typfouten/onbeduidende bewerkingen te voorkomen die een onderwerp omhoog duwen, kan het dan alleen worden beperkt om die af te handelen en het bestaande gedrag intact te laten?

1 like
12

Het is moeilijk om de redenatie tot één enkel ding te herleiden. We hebben een paar dingen waargenomen die ertoe leidden dat we besloten het gedrag van het “verhogen van de laatste post bij bewerking” te verwijderen.

In het geval van kleine bewerkingen is het onnodige ruis, zoals je al aangaf.

Maar zelfs in het geval van grote bewerkingen hebben we waargenomen dat het ook moeilijk uit te leggen is en vaak ongewenst is. We zagen dat mensen vaak naar de functie “verhogingsdatum resetten” grepen wanneer ze die mogelijkheid hadden na een grote bewerking van bijvoorbeeld een documentatieonderwerp. Vooral wanneer meerdere onderwerpen werden bewerkt, maar zelfs voor bewerkingen van één onderwerp. We hadden zelfs mensen die posts markeerden en ons vroegen dit te doen, terwijl wij er zelf geen moeite voor deden.

Maar “verhogingsdatum resetten” is niet erg vindbaar. Mensen vroegen hoe ze dat moesten doen, wat aangaf dat ze dingen eigenlijk niet wilden verhogen, maar er niet achter waren gekomen hoe ze dat konden voorkomen, en dat waarschijnlijk velen die zich niet de moeite hadden genomen om te vragen hetzelfde probleem hadden.

Een andere observatie was dat mensen onterecht aannamen dat anderen hun grote bewerkingen zouden zien. Ze maakten een stub post en bewerkten deze terwijl ze eraan werkten. Hun vertrouwen dat anderen zouden volgen, werd versterkt door de verhoging. Maar in werkelijkheid hebben velen die het onderwerp volgden niet de moeite genomen om te controleren omdat het onderwerp na bewerkingen nog steeds niet als ongelezen wordt weergegeven. Dus een extra antwoord om expliciet revisies te benoemen en om feedback of beoordeling te vragen in deze scenario’s was sowieso vaak nodig, maar gebeurde niet.

Ik ben er vrij zeker van dat de zaken uiteindelijk gemakkelijker te begrijpen zullen zijn zonder deze functionaliteit, maar we zullen een paar van deze gevallen moeten aanpakken waarbij mensen erop waren gaan vertrouwen.

13

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. :slight_smile: 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 :slight_smile:)

I’ll keep my eyes peeled to see what’s coming. :eyes: :slight_smile:

1 like
14

I thought I’d give this a go here to see how it feels, and I must say it feels rather naughty. :slight_smile: 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. :slight_smile:

I’m going to work on it and see if it gets any more comfortable. :+1:

1 like
15

Ik denk, op een praktischer niveau, dat de extra meldingen (+e-mails) ook een nadeel kunnen zijn. De leeservaring voor anderen kan ook wat verslechteren als je een reeks van twee of drie berichten van dezelfde gebruiker krijgt. Dat zou normaal gesproken een voorbeeld zijn waarbij een moderator ze zou samenvoegen.

1 like
16

In a good way though, right?

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?

2 likes
17

Honestly? :baymax_no: It felt a little like farting in public.

But it’s early days yet. I may come to embrace it. :slight_smile:

1 like
18

Another change on the way here:

1 like