だから、彼らに適用させるのです。必要であれば、アクセスを取り消すことができます。信頼については？それはコミュニティ次第です。
適用を許可する理由は何でしょうか。古いカテゴリで考える必要はありません。誰もが平等であるべきです。誰かがテキストのエラーに気づき、それを修正することにした場合、申請を提出すべきでしょうか？私はこのユーザーを知りませんし、すべてのコンテンツへのアクセス権を与えたくありません。なぜなら、通常のモデレーションでコンテンツの品質に関するすべての問題が解決するからです。さらに、マークダウンを使用してコンテンツを変更する場合、通常のビジュアルエディタと比較してユーザーは困難を抱えることになり、間違いを犯しやすくなります。ユーザーが間違いを犯せないことを保証する人はいません。
これはGitHubのようなものであるべきです。誰でも変更を提案できますが、全員がフルアクセスできるわけではありません。
エラーに気づいた人は、データベースを管理しているグループにメッセージを送ることができます。これにより、ナレッジベースのモデレーションを大幅に行う必要がなくなります。積極的にメンテナーになりたい人はなることができ、そうでない場合はウィキを管理しているグループに変更を提出します。
私の経験では、誰もエラーを報告しません。通常のユーザーにはアクションが多すぎます。コンテンツを修正したり追加したりするのは簡単です。ユーザーはグループに参加したりモデレーターになったりしたくありません。ただコンテンツを修正したり追加したりしたいだけです。一度だけそれをしたいのです。このロジックから進めてください。すべてのユーザーがコミュニティの積極的なメンバーになりたいわけではありません。しかし、彼らは貢献できます。すでに例としてgithubを挙げました。
「いいね！」 1
それなら、それはそのコミュニティの問題です。通常のユーザーがその投稿/トピックの変更を提案するためのボタン/リンクを追加するのは非常に簡単です。また、通常のユーザーがメンテーナーチームに参加したい場合は、2番目のボタン/リンクもあります。
ここでのポイントは、知識ベースを破損する人々がいて、重いモデレーションを使用する必要がない場合です。変更を行うことができるメンテーナーのグループがあれば理にかなっています。完璧な世界では、不正な人々が無駄な問題を引き起こすことを心配する必要はありません。
現在、編集があった場合、トピックオーナーおよびウィキをウォッチしている全員に編集通知が送信されるため、通知の設定方法によっては変更を追跡するのは比較的容易だと思います。
ただし、個人的には、編集をレビューキューまたは何らかのグループレビューキューに送信してから公開するというアイデアに反対ではありません。それが構築にどれだけの作業を要するかは分かりませんが。
「いいね！」 7
ご理解いただきありがとうございます。技術コミュニティを作成しているのですが、ユーザーが誤ってナンセンスなことを書くのを誰も望んでいません。ナレッジベースを特徴づける最も重要なことは、情報の正確さです。それがすべての基礎です。そうでなければ、それを行う意味はありません。ナレッジベースの適切なモデレーションは、コンテンツ自体と同じくらい重要です。
実際には、共有編集を探しているということになります。なぜなら、編集者を知っていて事前モデレーションを行わない限り、ウィキが事後モデレーションで機能する場合、これを達成するのは少し大変だからです。
「いいね！」 2
いいえ。これは全く異なります。
どのように違うのですか？ランダムな訪問者が知識や能力を持っていると信頼していないため、自由な編集を許可したくないのです。だからこそ、事前審査による事実上の編集権限の制限を使用したいのです。品質と知識に関する要求があります。
あなたはそれをスタッフによる承認付きのウィキと呼んでいます。それにもかかわらず、それはグループによる共有編集であり、そのためのツールと設定はすでにあります。
私の言葉を歪曲しました。一般ユーザーとカジュアルユーザーの両方を含む、誰もがナレッジベースを編集できるようにしたいのです。そのためには、変更を受け入れるか拒否するかという1つの機能からなる機能が必要です。それで十分です。
「いいね！」 1
実用的な観点から、複数の編集が待機している場合、キューの状態はどうなりますか？現在、編集はその場で保存され、次の人が編集できるようになります（同時に2人が編集しようとすると、「xが入力中です」という表示や、保存時の警告が表示されると思います）。承認が受け入れられるか拒否されるまで、ウィキはロックされる必要がありますか？
「いいね！」 5
それは真実ではありません。あなたが書いたことです。
答えが気に入らないのは、それがウィキを通らなければならないと決めたからです。それは歪曲とは全く異なる状況です。
これはウィキのメタディスカッションなので、すでに適切なツールがあるので、私はより厳しい事前モデレーションにはどちらかというと反対です。ウィキが一般的なルールに従わないのであれば、可能であれば変更されるべきです。結局のところ、ウィキは単なる別のトピックです。しかし、ウィキは他のトピックよりも厳しいモデレーションツールを必要としません。
そして、ウィキのアイデアは編集権限を制限することではありません。それは自由放任であるべきですが、西部劇のような争いはなく、基本的な管理は必要です。そしてそれはすでにあります。
「いいね！」 1
誤解されているかもしれませんが、彼は確かに「Free-4-All」の投稿モデレーションをサポートしています。
単純な真実は、Discourse Metaは両方の方法をサポートしており、各コミュニティが最適な方法を決定する必要があります。それは、後から考えたモデレーションの修正であっても、専用のWikiナレッジベースカテゴリのグループ権限カテゴリセキュリティオプションを使用した事前の承認提出プロセスであっても構いません。
どちらの方法でも問題なく機能し、Discourse Metaのオープンカスタマイズに従って実行可能です。
「いいね！」 2
ナレッジベースとオープンディスカッションは全く異なるものです。ナレッジベースでは情報の正確性が最優先され、ディスカッションでは何でも書くことができます。
これには基本的に、バージョン分岐とマージなどが必要になるでしょう。代替案は、おっしゃるようにロックすることですが、それは実際には望ましくありません。
代わりに、編集されたバージョンを著者にプライベートメッセージ（PM）として送信し、著者が編集をマージまたは拒否できるようにすることは可能でしょうか？プロセスは次のようになります。
- Wikiを編集します。
- 送信をクリックします。
- 所有者は、Wikiの新しいバージョンのPMを受け取ります。
- 所有者は新しいバージョンを受け入れることができます。これにより、元のバージョンがPM内のバージョンに置き換えられます。
所有者は、PMで提出に返信して、変更を提案したり、完全に拒否したりすることもできます。ユーザーは、PMを編集して提出をさらに変更できます。これは「ブランチ」として残り、「マージ」されるのは、元の著者が受け入れた場合のみです。受け入れられると、PMはアーカイブされます（おそらく、より透明な形式に変換されることもありますか？）。
「いいね！」 1
invisionユーザーも2015年から同様の機能追加を開発者に依頼していることに気づきました。したがって、この問題はdiscourseユーザーだけのものではありません。
https://invisioncommunity.com/forums/topic/423493-wiki-like-editing-is-useless-at-this-moment/?tab=comments
これについて再度投稿します。@SystemZ このハイブリッドコミュニティ/wikiのようなセットアップをよりサポートするための重要な機能だと思います。また、何かを完成させるためのコードに貢献することも喜んで行います。
「いいね！」 1
私は言語学習コミュニティの基盤としてDiscourseを使用しています。記事セクションがあり、皆が貢献できますが、中級レベルの学習者でさえ、自分のスキルを過信して誤った情報を共有してしまうことがあります。
このような機能があれば、サイト上のウィキコンテンツの編集を民主化しつつ、情報の正確性を確保できるため、信じられないほど役立ちます。また、編集機能の悪用を防ぐこともできます。
もし私が裕福な人で夏の家に住んでいたら、Discourseにこの機能を実装するように賄賂を送っていたでしょう。残念ながら、私はどこにでもいるただの一般人です。
「いいね！」 2
私もそれが良い機能だと思います。ドキュサウルスからDiscourseにドキュメントを移行しましたが、そこではバージョン管理と承認にgitを使用していました。現在、誰でも最初の投稿を編集できるようにしたくありません。しかし、承認のために、モデレーターである私たちは、ライター（カスタムグループ）が行う編集を確認したいと考えています。
現時点では、ライターが変更を公開することを単に信頼し、後でそのトピックから受け取る「編集」通知を確認しています。
「いいね！」 1