Should an edit to any wiki post bump the entire topic?

Oh, I believe you. I have edited wiki articles before. But wikipedia is not forum software, and there are significant differences:

  • Wiki pages and discussion Talk are neatly separated and normal users are not confronted with ongoing discussions when they navigate to the landing page (no ‘topic pollution’)
  • Wikpedia is encyclopedia software, and all content needs to be fact-checked, and thus a way more formal workflow is a requirement
  • Therefore it takes time to become a good editor, and a lot of rules / etiquette to consider. Also, and as a result (I don’t know numbers) the ratio readers vs. editors, has way more readers, I suspect

On our forum we have a bunch of use cases where wiki posts + regular posts are useful, but only if wiki edits are noticable:

Basic requirement:

  • Our forum landing page is displaying of Humane Technology discussion topics, and not interspersed with a lot of meta / ‘ongoing work’ topics

Wiki use cases:

  1. We have an Awareness Program, where we prepare theme and campaign Markdown documents

    • Themes/campaigns start as forum topic for general discussion (non-technical users), where first (or N-th) post is a wiki post with the document proposal
    • When discussed / refined the document is brought to Github (picked up by static site generator) and maintained by more tech-savvy users
    • There will be many such proposals. Wiki post and discussion are closely related and not meta discussions.
    • After wiki post is brought to github, it becomes less relevant, though updates may still be synchronized
  2. We have topics such as “List of cognitive biases that apply to social media” that start with a wiki post that gives an overview, followed by discussions on them

    • These discussions are not meta discussions again, and we’d prefer to keep them together with the list at the top
    • If a bias is added in the wiki post, it may need to be bumped so it can trigger renewed discussion
    • Of course the workaround here could be that the editor adds and additional post “I added bias XYZ to the wiki post”
  3. We have discussions where someone may post “I am doing research on this subject, and have collected this list of resources. I made it a wiki post, and please add your entries that I may have missed”

    • This avoids polluting the thread with any number of URL’s interspersed with continuation of the discussion, or requiring the researcher to create a new topic and crosslinking: read this in the context of that discussion

Long story, but I think the feature request that solves the issue I have is not that high impact, and makes sense:

  • If you delete or split a topic an entry is made to the topic thread “Deleted post …” and “Split topic …”, which causes a bump of the topic AFAIK
  • You can do the same with a wiki post edit: “User @janedoe created a new revision of wiki post 1
    -Whether or not these entries are created could be configurable at wiki level, and default behaviour can be specified at Settings admin.

Indeed, very simple and logical.

If you want this enforced by law, create a category for strict wikis, and mark them all auto-close in the category settings, so they can only ever have a single post by definition. Then you’d have the exact behavior you want.

Linking groups of topics together is completely normal and expected. Jamming a bunch of stuff into a single topic is rarely the way to go.

Except that you have to explain that to every user: “Don’t forget to create a post after your wiki edit, or no one will see the edit you made”.

With auto-closed wikis for every N campaigns we’d have 2N topics, and have to explain every user how to set that up properly.

This does not address use case 3).

Having auto-entries like “User X Edited wiki Y” seems just as simple and logical to me.


You are very used to how wikis have worked for all these years, so this all look to be the logical things to do. But it is not so obvious and easy UX-wise as the ‘Make wiki post…’ makes it seem to be.

The discourse forum does this a lot, though, where you have e.g. plugin topics, where the first post is the documentation, followed by (very) long discussions. Only in your case it is only admins that edit the first posts, and it needs not be a wiki.

3 Likes

Why would there be any other expectation? If, right now, you go back and edit the second post you made in this topic — which you easily could — why would you expect anyone to be notified of that?

There is no “please notify a bunch of people that I just made an edit to an old post” provision anywhere in Discourse, at any time. Or any other discussion software that I can think of.

But it is not just an old post. It is a wiki post, and marked as Wiki, because it has longer-lasting importance.

And in a wiki post you give others editing rights to add more important information to it over time.

1 Like

I think that you are making an incorrect assumption about wiki posts being more important. I haven’t seen anything from the Discourse team that suggests wiki posts are any more important than any other post. Maybe you are attributing your own ideas about what a wiki post should be?

As far as I remember, the differentiating feature of a wiki post has only ever been that it can be edited by more than one user. I also checked several topics on wiki posts and didn’t find any attribution of greater importance for wiki posts, e.g. in the following topics:

Thank you, @Remah,

Yes, and I don’t want to be seen as overly stubborn in pushing my arguments to make changes to the current feature.

But besides seeing limitations to the usefulness with current design, I also look with the eye of a product owner. The Discourse team have build up very strong convictions over the years on what constitutes forum functionality and how it should be used. And - being undisputed experts in this field - they are only right to have these, and push back to stuff they see as not adding value.

However, there is also a risk in being so deeply involved in the subject matter. And that is overlooking how outsiders, newbies perceive the functionality. The term ‘Wiki’ has a well-established meaning, and ‘wiki posts’ are different in that they are a wiki mixed-in with a discussion forum. As implemented, it has become an intertwined concept that requires extra steps that make it work (locking the topic, creating the Talk thread, etc), and even then one cannot get the Wiki-only view. By using the term ‘wiki’ you raise expectations.

The UX issues are very real. The extra pomp and ceremony to make all this work, are not necessary.

As what is logical functionality within a discussion forum, I have to note that Discourse team is stretching that definition to the maximum extent on their own forum. Besides discussion forum it is used for Product documentation and Help manuals, Issue management, Release notes, Module repository (plugins, themes, etc.) and - on every forum instance - even Page and Asset management [1].

This ‘dogfooding’ is no problem (I am a fan of dogfooding a product). As an admin I can live very well with that, but it is worthwhile to evaluate how not to force these ‘special uses’ on the end-users.


[1] I am refering here to topics that become the FAQ page and “Assets for the site design” in Site Moderators category, and to which our admin Samuel Klein (a 3 term Wikimedia Foundation of Trustees member, btw) remarked (and I agree):

2 Likes

I remember thinking that Discourse shouldn’t use the word “wiki” for posts. But, when I actually researched the issue, it didn’t take me long to realize that my understanding of what constitutes a wiki is based on specific implementations rather than the meaning of the word itself.

That’s why I think that what you are also arguing for a set of your own assumptions or a specific vision of how a wiki should operate rather than what wiki actually means.

The “well-established meaning” of “wiki” (noun) is pretty much the same as Discourse’s use of the term “wiki post” because it includes both collaborative editing and use of a web browser. The qualification that is only a “wiki post”, and not an wiki article or wiki page, appears to fits its current use in Discourse.

A wiki is a website on which users collaboratively modify content and structure directly from the web browser.
from Wiki - Wikipedia

As a noun, wiki means “a website that allows anyone to add, delete or revise content by using a web browser.”
from What Does "Wiki" Mean? - Everything After Z by Dictionary.com

A website or database developed collaboratively by a community of users, allowing any user to add and edit content.
from https://en.oxforddictionaries.com/definition/wiki

Thanks again. But in your reasoning you forget the “Why?”. Why would you collectively collaborate on editing a piece of content? —> To create valuable documentation for long-term reference (by a wider audience).

And on Discourse you can only achieve this, by performing a bunch of additional very forum-specific actions. It is squeezing a wiki into a discussion tool, creating a mix of 2 types of application.

Also note that, while your definition is accurate for what a wiki originally meant (collaberately editing via the browser), for the vast majority of internet users a wiki means ‘Information pages to read’ (it is comparable to brands that lose their brand protection, because the name gets universal meaning, like ‘Jeep’).

2 Likes

It’s fine to keep pushing for changes :grinning: - I’ve seen rejected suggestions later accepted when the issue has been reframed. But your current approach based on what wiki might mean won’t get my support and doesn’t appear to have swayed the Discourse team either.

That’s why I’ve focused on the definitions and explaining some difficulties with your framing of the issue. I’ve tried to show that:

  • Discourse wiki posts have one key characteristic: they are able to be edited by more than one user.
  • Discourse use of the term “wiki” fits within the “well-established” meaning.
  • Discourse doesn’t make any judgement about the value or importance of wiki posts as compared with other posts.

That’s also why I didn’t forget the “Why?” Because it’s just not important for the definition of wiki posts.

Essentially, I’m saying that you should step back and ignore that it is called a “wiki post”. Just imagine if it were only called a “collaborative post” then you probably wouldn’t be trying to make Discourse like other implementations of wiki or wiki-like features.

Where the “Why?” becomes important is telling me why a post has been edited. This is crux of the issue @codinghorror describes where there is no provision to create a notification when an old post is edited:

A system generated description can tell me who (user), what (post changed), where (topic & post) and when (time) a change was made but misses the most important question: “Why?”

Meaning is essential to good discourse. So where an editor wants to notify me of a change then they should be prepared to do some work to give me meaning and tell my why. The best means to do this is likely to be by creating a new post (in the same topic) to explain why the change has been made.

Why don’t I want to be notified of changes to old posts and don’t want such topics bumped? Because even if I’m told which post and which user edited it, I still have to review the edits to see what information has changed. It’s about as useless as showing me new Terms & Condition which many websites expect me to read without telling me exactly what has changed and why it has changed.

1 Like

Thank you for taking the time to write this elaborate response. Appreciated, @Remah.

Leaving previous posts above for what they are (we are having difference of opinion of what would be intuitive behavior, and that is okay), but there is now a confusion in terminology: I am not refering to ‘notifications’, but ‘bumping the topic’.

I don’t need to have a bunch of people be notified when a wiki post gets updated with a new revision, but I need the topic to bump to the top of the topic list, so others can find the edit.

And in Discourse there is such provision when:

  • Old posts are deleted
  • Old posts are split to new or existing topic

So why not have the same for wiki posts having new revisions become available (not talking about arbitrary old post edits… they may go unnoticed just fine)?

2 Likes

I think that’s much clearer and more concise.

Sorry, I included notifications because some people have requested these. I probably should have left them out.

My real world issue is that I’ve created many wiki posts in a How-To category on another website. These are normally used when people have a task they need to complete or a problem they need resolved. There’s no real discussion so everyone doesn’t need to see them on Latest. Plus many minor corrections (spelling, grammar, formatting, change to disclaimer) don’t warrant a bump on Latest. So I definitely want to keep the current default and don’t want them bumped automatically.

I have also had old revisions of the wiki posts deleted to reduce the noise.

2 Likes

That’s part of the problem here, you’re pushing aggressively for something you see as an improvement, when good solutions to this scenario already exist. It’s perfectly reasonable to separate wiki posts from their discussion, and doing so achieves the overall outcome. A separate discussion topic is a well recognised pattern and is effectively all Wikipedia do with their Discuss tab. If you disagree it’s also perfectly reasonable to suggest that the teams goals for their software, and your own needs don’t align, and that maybe Discourse isn’t for you.

Discourse is primarily a tool for discussion and one oft overlooked part of that is remembering where someone last read to. It’s so useful because readers can always rely on the simple assumption that any newness is occuring at or after the thing you last read. Creating the potential scenario that a topic may resurface due to activity at either end totally defeats that.

2 Likes

Thank you. I apologize if my posts were seen as aggressively pushing! That was absolutely not my intention, just clarifying what I perceived as unintuitive, and thinking I needed to explain better. I rest my case.

3 Likes

I also have an issue that wiki post edits do not get attention, so I found this discussion. I also got complaints from users that their contributions to wiki post do not get attention.

I read this thread and have closed all wiki topics, so that thay only have initial post. But even in that case, edit of the only post does not bump topic.

These are all wiki post on my forum - the first two were edited in last day, one have only one post, the other had two replies (which I deleted before closing it). None of them were bumped and shown on latest view.

Does editing last post really bump topic? It does not seem to or maybe closing the topic prevents this.

2 Likes

Sorry for bumping this, but I really have an issue as Wiki post edits do not get bumped. This make Wiki posts almost useless, as users do not notice new content.

Even if they are the only post in topic and also in the case that the topic is closed.

If you close it there are actions on the topic after the first post.

Topics are only bumped if the first post is the last action. Closing it either adds an action, or is a special case. I would need to test to be sure.

OK, but then hint from @codinghorror to close the topic to prevent additional replies to first post makes it useless.

I would really like that Wiki posts get noticed, as we want to use them as summary topics. But if they never get bumped, they will just be forgotten and never noticed by new users.

1 Like

Maybe a plugin could add a new type of action which would be added to a topic when a wiki post is edited, bumping it, but also allowing comments through regular replies.

I think wiki edits and bumps should be better handled in core. If @codinghorror suggestion that closed wiki topic would work, it would be great but it does not. :frowning:

Edit: I have found the way to make it work: you have to close the topic and then remove all posts after initial post (including note about closed topic - this is what I was missing)

2 Likes