C’est pourquoi vous les laissez postuler. Si nécessaire, l’accès peut être révoqué. Quant à la confiance ? Eh bien, cela dépend de la communauté. 
Qu’est-ce qui leur permet de postuler ? Il n’est pas nécessaire de penser selon les anciennes catégories. Tout le monde devrait être égal. Si quelqu’un remarque une erreur dans le texte et décide de la corriger, devrait-il soumettre une candidature ? Je ne connais pas cet utilisateur, je ne veux pas lui donner accès à tout le contenu. Et pourquoi ? Si la modération habituelle résout tous les problèmes de qualité du contenu. De plus, avec la modification du contenu à l’aide de markdown, l’utilisateur aura des difficultés par rapport à l’éditeur visuel habituel, il est facile de faire une erreur. Personne ne peut garantir que les utilisateurs ne feront pas d’erreurs.
Cela devrait être comme un github. N’importe qui peut suggérer des changements, mais tout le monde n’a pas un accès complet.
Si quelqu’un remarque une erreur, il peut envoyer un message au groupe qui maintient la base de données. Cela réduit le besoin de modérer fortement une base de connaissances. Si quelqu’un souhaite devenir un mainteneur actif, il le peut ; sinon, il soumet le changement au groupe qui maintient le wiki.
D’après mon expérience, personne ne signalera d’erreur. Trop d’actions pour un utilisateur normal. Il est assez facile de corriger ou d’ajouter du contenu. L’utilisateur ne veut pas rejoindre des groupes ou devenir modérateur, il veut juste corriger ou ajouter du contenu. Il veut le faire une fois. Procédez à partir de cette logique. Tous les utilisateurs ne veulent pas être des membres actifs de la communauté. Mais ils peuvent contribuer. J’ai déjà mentionné GitHub comme exemple.
1 « J'aime »
Alors c’est un problème communautaire avec ladite communauté. Il est très facile d’ajouter un bouton/lien pour qu’un « utilisateur normal » soumette une modification proposée audit article/sujet, avec un bouton/lien secondaire si ledit utilisateur normal souhaite rejoindre une équipe de mainteneurs.
L’objectif ici est que s’il y a un problème avec des personnes corrompant votre base de connaissances et que vous ne voulez pas avoir à utiliser une modération lourde ; avoir un groupe de mainteneurs qui peuvent apporter des modifications a du sens. Dans un monde parfait, on n’aurait pas à se soucier des personnes peu scrupuleuses créant des problèmes inutiles. 
Pour le moment, une notification de modification est envoyée au propriétaire du sujet ainsi qu’à toute personne qui suit le wiki lorsqu’il y a une modification, je pense donc qu’il est raisonnablement facile de suivre les changements en fonction de la façon dont vous avez configuré vos notifications.
Cependant, personnellement, je ne suis pas contre l’idée que les modifications soient envoyées à la file d’attente de révision/une sorte de file d’attente de révision de groupe avant d’être publiées. Je ne sais pas combien de travail cela demanderait à construire ?
7 « J'aime »
Merci de votre compréhension. Je crée une communauté technique et personne ne souhaite que les utilisateurs écrivent accidentellement des absurdités. La chose la plus importante qui caractérise toute base de connaissances est l’exactitude des informations. C’est la base de tout. Sinon, il est inutile de le faire. Une modération appropriée de la base de connaissances est tout aussi importante que le contenu lui-même.
En fait, vous recherchez des modifications partagées. Parce qu’à moins de connaître l’éditeur à l’avance et de faire de la pré-modération, lorsque les wikis fonctionnent avec de la post-modération, vous aurez un peu de mal à y parvenir :
2 « J'aime »
Non. C’est complètement différent
En quoi est-ce différent ? Vous ne voulez pas autoriser la modification libre, car vous ne faites pas confiance à un visiteur aléatoire pour savoir et pouvoir. C’est pourquoi vous voulez utiliser des droits d’édition de facto limités via la pré-modération. Vous avez des exigences de qualité et de connaissance,
Vous appelez cela un wiki avec approbation par le personnel. Et pourtant, c’est une édition partagée pour un groupe — et pour cela, vous avez déjà des outils et des paramètres.
Vous avez déformé mes propos. Je veux que tout le monde puisse modifier la base de connaissances, y compris les utilisateurs réguliers et occasionnels. Pour ce faire, il doit y avoir une fonctionnalité composée d’une seule fonction : accepter ou rejeter les modifications. C’est suffisant.
1 « J'aime »
Sur le plan pratique, quel serait l’état de la file d’attente s’il y avait plus d’une modification en attente ? Pour le moment, une modification est enregistrée à temps et le wiki est prêt pour que la personne suivante puisse apporter une modification (et si deux personnes essaient de modifier en même temps, vous obtenez un message « x est en train d’écrire » et quelques avertissements lors de l’enregistrement, je pense). Le wiki devrait-il être verrouillé jusqu’à ce que la seule approbation soit acceptée/rejetée ?
5 « J'aime »
Ce n’est pas vrai. C’est vous qui avez écrit cela.
Vous n’aimez pas la réponse parce que vous avez décidé qu’elle devait passer par le wiki. C’est une situation totalement différente de la déformation.
Parce qu’il s’agit d’une méta-discussion sur les wikis, je suis plutôt contre une modération plus stricte car il existe déjà des outils appropriés. Si un wiki ne respecte pas les règles générales, il devrait changer, si possible. Le wiki n’est après tout qu’un autre sujet. Mais un wiki n’a pas besoin d’outils de modération plus stricts que les autres sujets.
Et l’idée des wikis n’est pas limitée aux droits d’édition. Ce devrait être une foire d’empoigne, mais sans combat à la façon du Far West, donc un contrôle de base doit être présent. Et il l’est déjà.
1 « J'aime »
Je pense que vous pourriez mal comprendre. Il soutient en effet la modération de publication « Free-4-All ».
La simple vérité est que Discourse Meta prend en charge les deux méthodes et chaque communauté doit décider de la méthode qui fonctionne le mieux. Qu’il s’agisse de corrections de modération a posteriori ou d’un processus de soumission d’approbation préventive utilisant les droits de groupe et les options de sécurité de catégorie pour les catégories dédiées de base de connaissances wiki.
L’une ou l’autre méthode fonctionne bien et, comme le permet la personnalisation ouverte de Discourse Meta, elle est réalisable.
2 « J'aime »
la base de connaissances et les discussions ouvertes sont des choses complètement différentes. Dans la base de connaissances, l’exactitude des informations est primordiale, et vous pouvez écrire n’importe quoi dans les discussions.
Essentiellement, il faudrait une forme de branchement de version derrière cela, et des fusions, etc. L’alternative est, comme vous le dites, le verrouillage, ce qui n’est vraiment pas préférable.
Serait-il plutôt possible de soumettre la version modifiée en tant que MP à l’auteur, et que l’auteur soit celui qui peut fusionner ou rejeter la modification ? Le processus pourrait être le suivant :
- Je modifie le wiki
- Je clique sur soumettre
- Le propriétaire reçoit un MP de la nouvelle version du wiki
- Le propriétaire peut accepter la nouvelle version – cela remplacerait l’original par la version dans le MP
Le propriétaire peut également répondre à la soumission dans le MP et suggérer des modifications ou la rejeter complètement. L’utilisateur peut toujours modifier sa soumission en modifiant le MP – cela reste une « branche » et n’est « fusionné » que lorsque l’auteur original l’accepte. Lorsqu’il est accepté, le MP est archivé (peut-être aussi converti d’une manière ou d’une autre dans un format plus transparent ?)
1 « J'aime »
J’ai remarqué que les utilisateurs d’invision demandent également aux développeurs d’ajouter une fonctionnalité similaire depuis 2015. Cette douleur n’est donc pas seulement pour les utilisateurs de discourse
https://invisioncommunity.com/forums/topic/423493-wiki-like-editing-is-useless-at-this-moment/?tab=comments
Relance sur celui-ci. @SystemZ Je pense que c’est une fonctionnalité importante pour offrir plus de support à cette configuration hybride de type communauté/wiki. Je suis également heureux de contribuer au code pour faire avancer quelque chose.
1 « J'aime »
J’utilise Discourse comme base pour une communauté d’apprentissage des langues. Nous avons une section d’articles à laquelle les gens peuvent contribuer, cependant, même les apprenants de langues intermédiaires peuvent parfois être trop confiants dans leur évaluation de leurs compétences et finir par partager de la désinformation.
Une fonctionnalité comme celle-ci serait incroyable pour nous permettre de démocratiser la modification du contenu wiki sur notre site tout en nous assurant de garder nos informations exactes. De plus, cela empêche une mauvaise utilisation possible de la fonction d’édition.
Si j’étais une personne riche avec une maison de campagne, j’enverrais des pots-de-vin à Discourse pour qu’ils implémentent cela. Malheureusement, je ne suis qu’une personne au hasard dans un endroit au hasard. 
2 « J'aime »
Je pense aussi que ce serait une bonne fonctionnalité. Nous avons migré notre documentation de Docusaurus vers Discourse et là, nous utilisions git pour le contrôle de version et les approbations. Maintenant, nous ne voulons pas que tout le monde puisse modifier le premier message. Mais pour l’approbation, nous, les modérateurs, voulons examiner les modifications apportées par les rédacteurs (groupe personnalisé).
Pour le moment, je fais simplement confiance aux rédacteurs pour publier leurs modifications tout en vérifiant les notifications de « modification » que je reçois de ce sujet plus tard.
1 « J'aime »