Require staff approval for wiki edits in selected categories

AI-generated summary

The discussion centers on a feature request to implement staff or group approval for wiki edits in specific categories, allowing community members to contribute while maintaining content quality. SystemZ initiates the thread, explaining the need to allow TL0-TL2 users to edit guides in a wiki mode, but requiring staff approval for changes to prevent uncontrolled modifications. pfaffman initially suggests that staff can edit without wiki mode, but SystemZ clarifies that the goal is to empower the broader community with a pre-publish review process.

Several users express strong support for this functionality. balboah, markersocial, and galligan agree, comparing the desired workflow to Stack Overflow or GitHub, where users can suggest changes that require approval from trusted members (e.g., TL3+ or OP). volanar emphasizes the importance of this feature for protecting knowledge bases from vandalism or errors, suggesting a “Suggest Changes” button similar to Wikipedia. volanar notes that this reduces moderator burden and improves content accuracy.

Conversely, Jagster and Heliosurge offer alternative perspectives. Heliosurge suggests using Group permissions to restrict editing to approved members, while Jagster argues that Discourse is primarily a discussion platform, not a dedicated wiki like MediaWiki, and that pre-moderation might hinder the natural flow of community contribution. Jagster and volanar debate whether this constitutes “shared editing” or true wiki freedom, with volanar insisting that accuracy in knowledge bases requires strict moderation unlike open discussions.

Technical considerations are raised by JammyDodger and Tris20, who discuss potential implementation challenges such as handling concurrent edits, locking mechanisms, and version branching. Tris20 proposes a PM-based approval workflow as a workaround. The thread concludes with mrmowji sharing their experience moving documentation to Discourse and missing Git-style approvals, and jord8on suggesting manual workarounds or plugins. Moin links to a related “Suggested Edits” feature request, indicating this is a known community need.

I would like to see something to keep some category’s topic edits under control.

In my community we have todo/guide category with staff “seal of approval”.
We want to make all topic in this category wiki mode for community to be able to update guides but then we don’t have under control what changes are being made.

Option in category settings to require staff or selected group approval would be much appreciated :slight_smile:

9 Likes

Staff (and tl4) can edit it without making it a wiki.

By community I meant all users other than TL4.
I have no problem with TL4 users (in our case it’s 0,35% of all users) but I want to give ability to contribute for rest of users (TL0, TL1, TL2) but with staff approval for each change that they submit.

1 Like

Oh. Sorry. I somehow missed that bit. There’s a lot I don’t know, but I think that’s going to be pretty hard to do.

It’s a feature request category so I think it’s proper category for that :wink:
Besides, there is already review queue and post flagging, I think it can be mixed and changed somehow to offer this functionality.

Maybe I can contribute this feature via PR if some of more knowing of Discourse internals tip me at which parts of code I should look at (I’m not a rails regular).

3 Likes

This is something I’d like as well. Kind of like stackoverflow I suppose.

Would be sweet to let TL1 be part of it but they might not always write the right thing, then you don’t know how long it takes before someone reviews the change

2 Likes

+1 Would be great to have some sort of approval system so that lesser trusted users can still contribute to wikis.

A scenario like:
TL1+ can contribute, TL3+ or OP can approve changes. If the editing is done by the OP, then require no approval.

2 Likes

+1 this kind of feature would be great!

1 Like

Now any user with the necessary level of trust can edit a wiki post. But not all changes are useful. There are unscrupulous users or competitors who can ruin hundreds of posts and it takes a lot of time to restore them. On this forum they wrote about similar stories.

To reduce the burden on moderators and content creators, I suggest adding the functionality of rejecting/approving changes by moderators to the wiki post.
When editing a wiki post, use the “Suggest Changes” button or a similar name instead of the “edit wiki” button. Thus, any user can make changes, and the creator of the post or moderator will have full control over the content :muscle:.
You can also add mass approval/rejection of changes, as well as always encourage changes for a specific user (good for large communities).

3 Likes

There is a similar Contribute > Feature request

3 Likes

Well, editing wars (and just bad behaving) are a real thing in the wiki-world. Wikis are a bit a rare case still nowadays in (Discourse-)forums, but that situation is changing — earlier it was close to impossible option to choose and use.

But we don’t give totally free hands to majority to edit first posts, and no matter how we want call a topic that situation doesn’t change. Or of course it changes because of nature of wikis, but the trust issue doesn’t change.

Because TL4 is a choise of admin, not giving just automatically based on given likes (sure, there is a couple other metrics as we all know :wink: ) there is no reason limit TL4 rights. But TL3s and lower are different situation.

Perhaps we need possibility to force approving. There is just one minor issue in such forum-wide limitation: all wiki-topics aren’t so heat. Majority of topics are not and when a forum suffers widers such acting there is deeper issues. But forum-wide limitations increase workload of moderators and with topics, where is no overcooking, no one want to see unnecessary work. Plus limitations limit will of users to write — that is wanted situation every now and then, though.

But what we need in pre-ideal world is an option to force approving per topics, and even with a timer.

1 Like

I think there are many such queries to be found. Because this is one of the two key functions in the wiki, there may not be any other functions. Without this feature, the wiki cannot be controlled

1 Like

In wikipedia, it is normal practice to accept or reject changes from unverified users. On the contrary, the load on moderators decreases, the quality of content increases significantly

Yes it is but Wikipedia, or MediaWiki as platform, is purpose made solution for wikis, but with very limited ability for discussion (I would say it is more lower than just very limited). Discourse is purpose made platform for discussion, but with very limited tools for wikis.

We need tools to handle wikis bit better. But otherwise we just can’t compare what MediaWiki and Discourse are or are not. For real wikis I would use MediaWiki right away and trying to use Discourse for discussion,

2 Likes

Discourse is primarily a universal knowledge-based community platform. You are behind the times. Universal

1 Like

No it is not :wink: It is brilliant for discussion. As a social media platform, not so much. As a blogging platform, a lot is needed. For podcasting — nope, not a chance. E-commerce, no. LMS, other no. As a wiki — well, what was the topic now :wink:

Quite few things are universal. And that is really good that way. Everyone should do where they are the best. Like MediaWiki beeing a wiki-platform, and Discourse offering a forum.

4 Likes

Have you considered setting Groups up? You could have ppl required to apply to a group to have Create/Reply security access. Everyone can view but only group members of that wiki category would be able to edit. At least if I understand category security regarding wiki edits. Then only approved members can adjust wiki info.

There is also a Customization > Theme component iirc that may or not work iirc called require post edit reason.

1 Like

I have to disagree. Discourse is designed to be used how you choose; it is not restricted to simply a knowledge base as that is just one type of use scenario. You may want to brush up on learning Discourse features of potential use.

The point is that absolutely any user can contribute to the creation of knowledge base content. Any community is committed to this. But moderation is necessary in all cases. Can you trust every user you grant access to? I’m not sure about that. Lack of control can lead to sad consequences. One user can thoroughly rattle your nerves. Control is always necessary, even for verified users.

Even if the user is a good guy, he may be wrong. Moderation will help to fix it quickly and accurately :slightly_smiling_face: