manuel
(Manuel Kostka)
1
これは、私が参加しているボランティアプロジェクトのコミュニティフォーラムをどう発展させるかという提案のサンプルサイトです。目標は、会話だけのコミュニティフォーラムから、プロジェクトの中心にコミュニティを据える形へと移行することです。
カテゴリは「会話」「共有」「行動」の3つです。チーム領域はタグ付けのみで行われます。アイデアは、カテゴリでコミュニティを分断せず、チームを全体的にアクセスしやすく保つことです。
この提案では、Assign 機能を Lead に、Solved プラグインを Completed にそれぞれ適応させました。トピックで Solved を選択するとデフォルトでアサインが解除されるため、ここではうまく機能します。Lead には、完了していないアクティビティのリードのみが表示されます。
また、Event 機能を使ってアクティビティをスケジュールするのにも適しています。ここでは、出席の Going/Not going を Join と Leave に改名する適応のみ行いました。デフォルトでは、Upcoming events カレンダーにアクティビティがリスト表示され、これは便利そうです。
コミュニティコラボレーションのために Discourse をどのように設定しましたか？単純なフォーラム設定以外のアプローチについても、ぜひ聞かせてください！
「いいね！」 12
投稿していただき、本当にありがとうございます。私も非常に似た用途で Discourse のセットアップを計画中なのですが、あなたが何をされているのかを見て、考えさせられ、刺激を受けます。
私のアイデアや解決策はここに投稿しません。おそらくそれについては別トピックを立てた方が良く、このトピックはあなたのアイデアについての議論に集中させるべきだからです。
-
非常にクリーンでシンプルに見えるのが素晴らしいですね。
-
「Talk / Share / Act」の区分けが非常に明確で、その明快さが気に入っています。ただ、使うかどうかは迷っています。なぜなら、それが私のコミュニティの実際の動きに合っているとは確信が持てないからです。例えば、誰が「Talk」は閲覧したいのに「Share」は無視したいと思うのか、その区別が誰の役に立つのか分かりません。
-
左のカラムは素敵ですね…それはテーマコンポーネントですか、それともカスタムテーマですか？
-
左サイドバーの上部にカテゴリーがあるのに、トップメニューに「Categories」を追加する目的は何でしょうか？
-
「solved」プラグインを「Completed」として適応させるというあなたのアイデアは非常に興味深いです。試してみたいと思います。
「いいね！」 6
manuel
(Manuel Kostka)
3
フィードバックをありがとうございます、Jonathan さん！そうですね、このトピックをさまざまな解決策の集まりとして設定しないのは良い考えです。私の OP のタイトルと本文を調整しました！
- はい、これらの用語をそのまま使うことを提案したわけではありませんでした。ただし、一般的な提案として、コミュニティを 1 次カテゴリでサブグループに分けないという点があります。これを可視化するためにマインドマップを作成しました。私にとっては、同様の白い吹き出しに含められるものはすべて、このレイアウトを効果的にサポートします：
-
Custom Layouts プラグイン と、その現在のすべてのウィジェット（カテゴリリスト、プロフィール、カスタム HTML、トピックリスト）を使用しています。そのため、タグ（コミュニティ、デザイン、開発、マーケティング）を一覧表示するナビゲーションメニューは、カスタム HTML リストです。
-
サイドバーはデスクトップ表示でのみ使用しており、モバイルでは使用していません。そのため、トップナビゲーションにもカテゴリを表示しています。また、サイドバーメニューで同様にスポットライトを当てたくないカテゴリがさらにあるかもしれません。
「いいね！」 8
あなたの考え方にとても共感します。Discourse プラグインの作成を始めた当初、私もカテゴリに焦点を当てすぎたという過ちを犯しました。Discourse 上で行う動作を実生活でどう行うかを想像するのは良いことだと思います。「カテゴリに入って『新しいトピックを作成する』」という動作は、私には不自然に感じられます。実生活でそのようなことをした覚えがありません。「会話を始める」や「質問をする」といった行動の方が、ずっと自然に感じられます。
アクションは、実生活で実際に自然に感じられるものであるべきです。「トピックを作成する」という表現は機械的で、場合によっては少し失礼にさえ感じられます。そのため、現在開発中のプラグインでは、コンポーザーの動作をカスタムされたものに置き換える API を構築しています。また、「目的を持ったコミュニティを作る」というあなたのアイデアも気に入っています。Discourse を基盤とした協働辞書を作成するという私の目標も、同じ方向性を指していると感じます。Discourse は何らかの形でカスタマイズする必要があります。そうでなければ、Facebook グループとあまり変わらないものになってしまい、Facebook グループ特有の摩擦が非常に低くなってしまうからです。
couchers.org が成功することを願っています。私は3月に台北に到着した際に couchsurfing.org を利用しましたが、それ以降は使っていません。しかし、他の旅行者から、サイトが少し混乱状態にあったと聞きました 
VC 資金はすべてを台無しにしてしまいます 
「いいね！」 7
angus
(Angus McLeod)
5
素晴らしいですね！
これは、Pavilion でプロジェクト管理に Discourse を活用している私たちの運用方法と非常に似ています。私たちは以下の通り活用しています：
- 割り当てには Assign を使用
- イベントには Discourse Event を使用
- トピックを閉じることで完了を示す
- 「チーム」にはカテゴリを使用（例：当社の各クライアントには専用のプライベートカテゴリとグループを割り当て）
- 「プロジェクト」と「タスク」を区別するためにタグを使用
また、サイドバーには Layouts Plugin と Layouts Category List Widget も活用しています
モバイルレイアウトビューを使用しないことを選んだ理由が気になります。
私たちは（テーマコンポーネントを使用して）カテゴリのドロップダウン全体を非表示にすることにしました。カテゴリリストウィジェットを特定のカテゴリを選択するように調整しましたか？それとも excluded_categories 設定を使用していますか？何人かのユーザーにとって役立つかもしれないので、included_categories 設定（あるいはそれに似たもの）を追加することを検討していました。
実際、最近では knowledge-base の組織化のために、thepavilion.io でカテゴリを 3 階層化するようにしました。以前は以下の構造でした：
knowledge
layouts
custom-wizard
category-highlighter
現在は以下の構造に変更しました：
knowledge
plugins
layouts
custom-wizard
themes
category-highlighter
プラグインやテーマの処理が特に複雑になるため、この変更を長らく避けてきました。例えば、カテゴリリストウィジェットは 3 階層をサポートしていませんでした（最近ようやくサポートを追加しました）。
しかし、組織的な理由（例：カテゴリ単位で特定の知識トピックを API から取得する必要があるなど）により、knowledge-base には 3 階層が必要になりました。プロジェクトや業務を基盤とした Discourse では、より議論中心のフォーラムとは異なり、組織のニーズが分類に影響を与えることが予想されます。
「いいね！」 7
manuel
(Manuel Kostka)
6
実は、現在のモバイルビューで十分満足しています。また、適応機能を過度に凝らさない方が有用だと感じています。そのため、サイト内の基本的なナビゲーションは標準のナビゲーションメニューで動作しています。
確認してみたところ、フィードバックとして、その仕組みがどうなっているのか理解するのが難しかった点を挙げたいです。どうやら、別のハードコーディングされた HTML メニューのようです。これも避けた方が良いと思います。
はい、ウィジェット設定からいくつかのカテゴリを除外しました。そして、それらを含める方が直感的だと思うのです。なぜなら、多くの設定がそのように機能しているからです。ウィジェットを初めて有効にした際に、既存のすべてのカテゴリでそのリストを自動生成できるかもしれませんね。
全体的に、Discourse Layouts プラグインが本当に気に入っています 
。そのウィジェットに関する追加のフィードバックはこちらに投稿しました：
「いいね！」 5
angus
(Angus McLeod)
7
素晴らしいフィードバックありがとうございます！thepavilion.io で返信いたしました
「いいね！」 3
