Discourse を使用した RFC ステータスの追跡

特徴
1

機能名

Discourse の状態

機能目標

Discourse を RFC ライクなフォーラムにする

機能説明

  1. コメント依頼（RFC）は、特にインターネットの主要な技術開発および標準設定機関であるインターネット技術タスクフォース（IETF）からの、一連の出版物です。RFC は、インターネットおよびインターネット接続システムの機能に適用可能な方法、動作、研究、またはイノベーションを記述した覚書の形式で、個人またはエンジニアとコンピュータ科学者のグループによって作成されます。これは、ピアレビューのために提出されるか、新しい概念、情報、または時にはエンジニアリングのユーモアを伝えるために提出されます。[1]
  2. Discourse の状態は、RFC タイプ文書の状態に似ています。Discourse の状態は、ユーザーの投稿をよりよく制御するために使用されます。RFC 文書には次の状態があります。
  • 情報提供 (Informational)
  • 実験的 (Experimental)
  • 現在のベストプラクティス (Best Current Practice)
  • 標準トラック (Standards Track)
  • 提案 (Proposed Standard)
  • 下書き (Draft Standard)
  • インターネット標準 (Internet Standard)
  • 履歴 (Historic)
  • 不明 (Unknown)

私の場合、私のリソースでは、投稿タイプに応じてこれらの状態になります。

Discourse の状態 / コード

  1. 下書き (Draft Standard) | 1 - 下書き (Draft Standard)
  2. 実験的 (Experimental) | 2 - 実験的 (Experimental)
  3. 提案標準 (Proposed Standard) | 3 - 提案 (Proposed Standard)
  4. 標準トラック (Standards Track) | 4 - 標準トラック (Standards Track)
  5. 現在のベストプラクティス (Best Current Practice) | 5 - 現在のベストプラクティス (Best Current Practice)
  6. 履歴 (Historic) | 6 - 履歴 (Historic)
  7. 情報提供 (Informational) | 7 - 情報提供 (Informational)
  8. 標準 (Standard) | 8 - 標準 (Standard)
  9. 不明 (Unknown) | 9 - 不明 (Unknown)

Discourse の状態 / ケース

  1. ユーザーが投稿を作成し、その投稿に返信がない場合。この投稿は Discourse の状態が下書き (Draft Standard) です。また、ユーザーが投稿を作成し、その投稿が公開されていない場合も、この投稿は Discourse の状態が下書き (Draft Standard) です。
  2. ユーザーが投稿を作成し、その投稿に返信がある場合。この投稿は Discourse の状態が実験的 (Experimental) です。さらに返信がある場合、この投稿は Discourse の状態が実験的 (Experimental) です。
  3. 複数のユーザーが投稿を気に入って、本当に良いと思っている場合、その投稿は標準トラック (Standards Track) としてタグ付けされます。同じまたは類似の投稿がさらにある場合、デフォルトの状態は現在のベストプラクティス (Best Current Practice Discourse) として発表されます。
  4. 投稿へのあらゆる変更は、履歴 (Historic) の Discourse として発表される状態と見なされます。
  5. 投稿がすべてのコミュニティメンバーに受け入れられた場合、Discourse の状態は情報提供 (Informational) です。
  6. 投稿に修正または改善が必要な場合、状態は Discourse 情報提供 (Informational) として発表されます。投稿が修正および改善された場合、状態は Discourse 提案 (Proposed Standard) として発表されます。
  7. 投稿に 1 週間、1 日、1 か月、または 1 年の返信がない場合、状態は Discourse 不明 (Unknown) として発表されます。

注意事項

  • この状態は自動的に行われます
  • 投稿の状態は常にホームページに表示されます
  • 投稿の状態があることの素晴らしい点は、その投稿をフォローできることです
  • ユーザーの投稿に対する品質管理により、乱用、スパム、順序外の投稿を回避します
  • Discourse は魅力的で、さらにコミュニティ志向のソフトウェアです。ソフトウェアの品質、ユーザーエクスペリエンスの品質を高めること以上に良いことはありません。

アイデア

image
image1285×354 26.7 KB

説明画像

画像でわかるように、同じ投稿に異なる状態が存在する可能性があります。ユーザーのインタラクションに応じて状態が変化します。状態は 1、2、3、4、5、6、7、8、または 9 になる可能性があります。画像では何かが起こったことがわかります。投稿は多くのコメントを受け取り、下書きから標準状態コード 8 になりました。

参考文献

「いいね！」 1
2

アドオンなしでこれを行う1つの方法は、各レベルごとにサブカテゴリ（または単にトップレベルカテゴリ？）を作成し、投稿が「卒業」するにつれてそれらの間で移動させることです。

おそらく、プラグインはあなたの基準に基づいて投稿をカテゴリ間で移動させることができます。または、APIを使用してそれを行う外部スクリプトを用意することもできます。

「いいね！」 3
3

これは、Discourse に RFC 固有の機能を追加することについてですか？このトピックのタイトルはそうであるべきではありませんか？

「いいね！」 2
4

私は推測に基づいて解釈していますが、Discourseに「状態追跡」機能を追加することについてであり、RFC追跡はその一例ですか？「State of Discourse」が一種のジョークとして意図されているのかどうかは正直わかりませんが、いずれにしても、それは非常に混乱しており、何か別のものにするべきです。

いずれにしても…

現在、Fedora LinuxのCommon Issuesで、これよりもはるかに単純なことを行っています。これは、トップレベルの(Accepted) Common Issuesカテゴリと、Proposed Common IssuesおよびArchived Common Issuesカテゴリを持つ、類似のものだと思います。私は外部スクリプト（現時点では非常に場当たり的です。私は実際にはプログラマーではありません）を使用して、投稿を処理し、カテゴリ間で移動させています。これは、上記で提案したとおりです。

「いいね！」 2
7

私は間違いなく推測に基づいて解釈していますが、これはDiscourseに「状態追跡」機能を追加することに関するもので、RFC追跡はその一例ですか？

  • はい。まさにその通りです。Discourseの状態はRFCに基づいています。
  1. RFCについて話したのは、私が開発する技術文書の一部がチームが行うことと似ているからです。
  2. 問題は、このプロセスが非常に官僚的で手動であり、時には人的エラーが発生しやすいことです。
  3. 時々、チームによるレビューが必要な技術的なことを書きますが、チームの担当者が非常に注意深くなかったり、多くの詳細を見る人だったりすると、送信された文書が間違った場所にある可能性があります。私のアイデアは、私たちの小規模チームにDiscourseを実装することです。
  4. 私のアイデアは、技術文書を扱う方法、つまり人々が行う投稿を追跡する方法です。RFCに基づいた投稿の追跡。これは私たちが多くの作業を行っていることなので。
  5. しかし、Discourseやその他のフォーラム型ソフトウェアで、プラグインや同様のリソースを見つけることができませんでした。
  6. この機能は、レガシーソフトウェアを使用している技術文書チームを考えると、私の意見では革新的です。これらのレガシーで古いソフトウェアはDiscourseに置き換えることができると信じています。Discourseは非常に興味深いソフトウェアであり、私はそれが大好きです。できる限り、友人や知人に勧めています。私の問題は、私が今説明したような、RFCベースの投稿状態のようなプラグインや同様の機能を見つけられなかったことです。

Fedora Linuxの「Common Issues」で、これよりもはるかに単純なことを現在行っています。これは、トップレベルの(Accepted) Common Issues カテゴリと、Proposed Common Issues および Archived Common Issues カテゴリを持つもので、おそらく似ていると思います。私は外部スクリプト（現時点では非常に場当たり的です。私は実際にはプログラマーではありません）を使用して投稿を処理し、カテゴリ間で移動させています。これは、前述したように私が提案したことです。

  • カテゴリやサブカテゴリを見続けるのは嫌です。動的なものが欲しいです。
  • ユーザーの対話方法によって、新しい状態が作成される場合とされない場合があります。
  • 状態の変更がない場合、計画しているようなことをしなければなりません。つまり、投稿を別のカテゴリに移動するためのスクリプトを作成しなければなりません。
  • あなたを批判しているわけではありません。このアイデアは良いと思います。それどころか、私もそのようなことをしようと考えたほどです。しかし、同じように考えている人を知りませんでした。唯一の問題は、私がプログラマーではない :frowning: ということです。そして、インターネットでこれを行うスクリプトを見つけることができませんでした。
「いいね！」 1
8

これは理解できません。「カテゴリ」は単なるラベル、階層ビューで表現されるメタデータの一種です。これらすべてをサブカテゴリにしたとしても、最上位カテゴリの「すべて」ビューを見れば、投稿すべてが表示されます。

この状態を何らかの方法で追跡する必要があります。もう一つの選択肢は、かなり侵襲的な追加なしでタグを使用することですが、カテゴリの方が適していると私は本当に思います。例：カテゴリを使用すると、異なる権限レベルを設定でき、検索ランキングで「上位」状態のトピックを優先し、「下位」のトピックのランキングを下げることで、公式ドキュメントが優先されるようにすることができます。

「いいね！」 2
9

何らかの方法でこの状態を追跡する必要があります。もう一つの選択肢は、かなり侵襲的な追加なしでタグを使用することですが、カテゴリの方が適していると私は本当に思います。例：カテゴリを使用すると、さまざまな権限レベルを設定でき、「より高い」状態のトピックの検索ランキングを上げ、「より低い」状態のトピックの検索ランキングを下げることで、公式ドキュメントを優先させることができます。

  • あなたの言う通りです。多くのことを明確にしてくれてありがとう。本当に、カテゴリの方がずっと良いです。
「いいね！」 1