That is why you let them apply. If needed access can be revoked. As for trust? Well that depends on the community. 
What let them apply? No need to think in the old categories. Everyone should be equal. If someone notices an error in the text and decides to fix it, should they submit an apply? I do not know this user, I do not want to give him access to all the content. And why? If the usual moderation solves all the problems with the quality of content. Moreover, with the change of content using markdown, the user will have difficulties compared to the usual visual editor, it is easy to make a mistake. No one can guarantee that users can not make mistakes.
It should be like a github. Anyone can suggest changes, but not everyone has full access.
If someone notices an error then they can message the group that maintains the database. This reduces the need to heavily moderate a knowledge base. If someone wants to become an active maintainer they can; if nor they submit the change to the group that maintains the wiki.
In my experience, no one will report an error. Too many actions for a normal user. It’s easy enough to fix or add content. The user does not want to join groups or become a moderator, he just wants to fix or add content. He wants to do it once. Proceed from this logic. Not all users want to be active members of the community. But they can contribute. I have already mentioned github as an example
1 Like
Then that is a community issue with said community. It is very easy to add a button/link for a “normal user” to submit a proposed change to said post/topic with having a 2ndary button/link if said normal user would like to join a team of maintainers.
The point here is if there is an issue with ppl corrupting your knowledge base and do not want to have to use heavy moderation; having a group of maintainers whom can make changes makes sense. In a perfect world one would not need to be concerned with unscrupulous ppl making unnecessary problems. 
At the moment, an edit notification is sent out to the topic-owner as well as anyone watching the wiki whenever there’s an edit, so I think it’s reasonably easy to keep track of changes depending on how you have your notifications set up.
Though, personally, I’m not against the idea of having the edits sent to the review queue/some kind of group review queue prior to going live. I don’t know how much work that would take to build though?
7 Likes
Thanks for understanding. I’m creating a technical community, and no one wants users to accidentally write some nonsense. The most important thing that characterizes any knowledge base is the accuracy of information. This is the basis of everything. Otherwise, it’s pointless to do it. Proper moderation of the knowledge base is just as important as the content itself
Actually you are looking for shared edits then. Because unless you know beforehand editor and doing pre-moderation, when wikis works with post-moderation, you are going to get a bit hard time to achieve this:
2 Likes
No. This is completely different
How is it different? You don’t want allow free editing, because you don’t trust a random visitor know and can. That’s why you want use de facto limited editing rights via pre-moderation. You have demands of quality and knowledge,
You call it wiki with approval by staff. And yet it is shared edit for a group — and for that you have tools and settings already.
You have distorted my words. I want everyone to be able to edit the knowledge base, including both regular and casual users. To do this, there must be a functional consisting of one function: accept or reject changes. That’s enough
1 Like
On a practical note, how would the queue state be if there were more than one edit waiting? At the moment, an edit is saved at the time and the wiki is ready for the next person to then make an edit (and if two people are trying to edit at the same time you get some ‘x is typing’ and some warnings on save, I think). Would the wiki have to be locked until the one approval is accepted/rejected?
5 Likes
That’s not true. You wrote that.
You don’t like the answer because you have decided it must go thru wiki. That is totally different situation than distorting.
Because this a meta-discussion of wikis, I’m kind of against harder pre-mderation because there is suitable tools already. If a wiki doesn’t follow general rules then that should change, if possible. Wiki is just another topic after all. But a wiki doesn’t need harder moderation tools than another topics.
And idea of wikis is not limited editing rights. It should be free-for-all, but without fight a la wild west, so basic control must be. And is already.
1 Like
I think you might misunderstand. He does indeed support the Free-4-All post moderation.
The simple truth Discourse Meta does support both nethodes and each community must decide which method works best. Be it after thought moderation fixes or a pre emptive approval submission process using group rights category security options for dedicated wiki knowledge base categories.
Either method works fine and as per Discourse Meta’s open customization is doable.
2 Likes
the knowledge base and open discussions are completely different things. In the knowledge base, the accuracy of information is in the first place, and you can write anything in discussions
Essentially there would have to be some form of version branching behind this, and merges etc. The alternative is as you say with locking which is really not preferrable.
Would instead it be possible to submit the edited version as a PM to the author, and the author is the one who can merge or reject the edit? Process could be like:
- I edit the wiki
- I click submit
- Owner gets a pm of the newer version of the wiki
- Owner can accept the new version – this would replace the original with the version in the PM
Owner can also reply to the submission in the PM and suggest modifications or reject it comepletely. User can still modify their submission by editing the PM – this remains as a “branch” and is only “merged” when the original author accepts it. When accepted the pm is archived(maybe also convered somehow into a more transparent format?)
1 Like
I noticed that invision users have also been asking developers to add similar functionality since 2015. So this pain is not only for discourse users
Bump on this one. @SystemZ I think this is an important feature to give more support for that hybrid community/wiki sort of setup. Also happy to contribute to code to get something across the line.
1 Like
I’m using Discourse as the basis for a language-learning community. We have an articles section folks can contribute to, however, even intermediate language learners can sometimes be overly confident in their assessment of their skills and end up sharing misinformation.
A feature like this would be incredible to allow us to democratize editing wiki content on our site while making sure we keep our information accurate. Also, it prevents possible misuse of the edit feature.
If I was some rich person with a summer home I’d be sending Discourse bribes to implement this. Sadly I am just some random person in some random place. 
1 Like