カレンダープラグインの機能を、私たちにとって本当に役立つものにするには

Discourse Calendar からの議論の続きです。

Fedora Project は現在、独自のカレンダリング Web アプリである Fedocal を使用しています。これは更新時期を迎えており、スタンドアロン アプリを書き直すのではなく、Discourse のカレンダーで置き換えることができるかどうかを検討しています。これは機能リクエストというよりは、ユースケースと、何をすべきかを評価する際に欠けていると思われる点をまとめたものです。

ユースケース

Fedocal には、私が把握している限り 3 つの重要なユースケースがあります。もし他にありましたら、お知らせいただければ検討に追加します。

  1. 会議のスケジュール設定。これは圧倒的に最も重要です。
  2. 人々が自分の空き状況を共有できるようにすること。現在、プロジェクトで責任のある立場にある人々に休暇のためにこれらを入力するように依頼していますが、実際に実行している人はほとんどいません。(個人的には、覚えていても非常に面倒だと感じています。)
  3. Flock to Fedora、Week of Diversity、または Release Party のような Fedora イベントを表示すること。これは現在実際には行っていません。

その他の可能性

  • 2013 年に Flock カンファレンスのスケジュールに Fedocal を使用しようとしましたが、それ以降は行っていません。それを魅力的で簡単なソリューションにできると 良い のですが。
  • Fedora のリリース スケジュール自体を表示すること。現在、これは go/no-go 会議のスケジュール設定にしか使用しておらず、実際のスケジュールには使用していないと思います。これを行う場合、手動入力ではなく、Fedora Project schedules から自動的に取得する必要があります。

現在の Discourse Calendar プラグインの短所

現在追加されている “events” システム は、私たちのニーズには合っていません。(サイト全体の投稿から「イベント」を収集して 1 つのグローバル カレンダーに表示しますが、それ以上の機能が必要です。

私の最初の仮定は、「トピックの最初の返信にカレンダーがあり、そのトピックへの返信のみで「供給」される」カレンダー プラグインの「従来の」部分を拡張することに焦点を当てるということです。しかし、サイト全体からイベントを取得するという別の方法の方が良い可能性もあります。その場合、複数のカレンダーをターゲットにできるように拡張する必要があります。(そしてその場合、ハンバーガー メニューに隠されているだけでなく、ピン留めされたトピックに埋め込めるようになると良いでしょう。)

したがって、それを踏まえて、必要となるものを以下に示します。

一般的に

  1. カレンダーの表示自体は非常に基本的なものです。
    • もっと見栄えを良くできる
    • 表示方法に合わせてスケーリングしたり適応したりする方法が全くない
    • 月曜日から日曜日までの EU スタイルの週にハードコードされている
    • エントリはローカル タイムゾーンにありますが、常に UTC で日を表示しているように見えるため、ローカル タイムゾーンの終日イベントがカレンダー上で 2 日間 にまたがって表示される可能性があります。(Discourse チームはこのバグを認識しています。)
    • 月表示では、イベントの説明の最初の数文字しか表示されません。カレンダーが単純なことだけを扱う場合は問題ありません (たとえば、Fedora Social Hour での使用を参照)。しかし、さまざまなことがたくさんあるカレンダーには適していません。
    • 現在、「Holiday」バージョンのカレンダーはイベントに色を割り当てることができますが、ユーザー名からプログラム的に派生した値を使用しています。これは、イベントごとに設定可能であるべきであり、ホリデー カレンダーだけでなくすべてのカレンダーに適用されるべきです。
  2. .ical フィードはないと思いますか?人々が Google カレンダーなどに簡単に追加できると良いでしょう。
  3. Nice to have: メーリング リストにリマインダー メールを送信する機能。サブスクライブされたユーザーだけでなく。まだ全員が Discourse に参加しているわけではありません!
  4. Nice to have: 追跡するエントリを正確に選択できる 個人用 カレンダービュー。

会議ユースケース

  1. Fedocal には 2 つの主要な「軸」があります。カレンダー エントリが属するグループ (例: 「council」) と場所 (例: 「#fedora-meeting」) です。カレンダー プラグインはどちらか一方を実行できます。私たちは「Fedora Council Meetings」トピックまたは「Fedora Meeting Channel」トピックを作成できますが、エントリはリンクされません。プラグインとして最適な設計がどのようなものになるのか、私にはよくわかりません。UX デザイナーの専門知識を活用して、それについて考えることができると思います。
    • 「グループ」軸が Discourse グループであれば問題ありません。特に、いつか _いつか _ SSO に Discourse グループをリンクさせる予定であるためです。
    • または、カレンダーの「グループ」軸は タグ である可能性があります。これはより柔軟性があり、サイトの組織のためにグループからタグへのマッピングを計画しているため、私たちにとってうまく機能するでしょう。
    • 「場所」軸は短いです。会議チャネルがいくつかあり、奇妙なケースのために「その他」の場所を許可するのが十分でしょう。
  2. 重要: システムは、両方の軸で競合が発生しないようにする必要があります (または少なくとも警告する必要があります)。つまり、同じ時間に 2 つの council グループ会議を開催することはできません。また、同じ場所に異なるグループからの 2 つの会議を同時に開催することはできません。
    • ただし、「その他」というキャッチオールがある場合は… いくつかの場所では重複が許可されるべきだと思います。
  3. 繰り返しイベントの構文は少し奇妙ですが、大丈夫です。しかし、繰り返しイベントはカレンダー グリッドに繰り返しとして表示されるだけで (リマインダーは次のものに更新されます)、それ以上のものはありません。そして、もっとあるべきです。
    • 重要: 各繰り返しイベントに対して、カレンダー エントリごとに通知を購読できるようにする必要があります。
      • Nice to have: 特定のカレンダーのデフォルト通知の Discourse グループごとの設定。たとえば、council グループのメンバーは、council カレンダー エントリの通知をデフォルトで受け取ります。
      • Nice to have: 今後の会議の 15 分前通知も設定できる機能。
    • 重要: 全体を変更することなく、特定のイベントをスキップする (または別の時間に開催する) ようにマークできる必要があります。
  4. 現在、イベントの期間は [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"] のようなエントリで行われます。入力が面倒で、結果 (2021-11-28T17:00:00Z2021-11-28T18:00:00Z) がすぐにわかりません。代わりに [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"] の方が良いでしょう。
    1. Nice to have: 期間のないエントリは視覚的に異なるように表示されるべきです。また、「終日」エントリにのみ許可されるべきかもしれません。
  5. Nice to have: 各カレンダー エントリ (繰り返しエントリは個別に) に、議題 + メモのトピックへのリンクを含めることができます。このトピックは、対話なしでは自動的に作成されませんが、ワンクリックで簡単に開始でき、作成後は自動的にリンクされるべきです。

「Holidays」ユースケース

  1. ホリデー カレンダーもグループを認識する必要があります。現在、(Discourse サイトの) スタッフに対して特別な処理がいくつかありますが、それは一般化され設定可能であるべきであり、グローバルなものだけでなく、グループごとに異なるカレンダーも許可されるべきです。
  2. デフォルト設定では、ホリデー カレンダーは、ロケールが設定されているすべてのユーザーに対して標準の国内休日を表示します。それが 5 人未満で、2 つ以上の異なる場所にない場合、他のすべてを圧倒します。Discourse は一時的なハックを提供して、それを非表示にできるようにしてくれましたが。
  3. Nice to have: 現在、スタッフ メンバーは休暇中のときにユーザー名の横に :palm_tree: 絵文字が表示されますが、これは他のスタッフ メンバーにのみ表示されます。このアイコンの表示は設定可能であるべきです。
  4. Nice to have: 表示される絵文字を設定できる機能。
    • Bonus nice to have: ユーザーが特定の利用不可時間 (休暇、病気、旅行など) に対して、絵文字と理由の リスト から選択できる機能。

Fedora イベント

実際、現在あるものでも機能すると思いますが、上記のいくつかは、より見栄えが良く柔軟なカレンダー表示、通知、色などが役立つでしょう。

その他の可能性について

  • カンファレンス スケジュール ユースケースは、会議スケジュール ユースケースと同じですが、非常に集中的です。手動で競合を管理することは不可能になります。このためには、グループ レベルの軸ではなく、ユーザー レベル の軸が必要になる場合があります。(スピーカーは同時に 2 つの場所にいることはできません。) また、私たちの会議室の場所は 15 年間ほとんど変わっておらず (URL の更新を除く)、今後 15 年間も変わらないでしょうが、各イベントには独自の場所のセットがあります。
  • リリース スケジュール カレンダー: これは主に既存のスケジュール データからのインポートの自動化の問題だと思います。既存のカレンダー プラグインは、ほとんどの場合機能すると思います。Fedora イベントと同様に、色分けができると良いでしょう。
「いいね!」 14

Pavilion は、Discourse イベント統合プラグイン(DEIP)の開発に取り組んでいます。これにより、inter alia、他のサービスやプラットフォームから Discourse へイベントを公開できるようになります。私たちは DAPSI(EU の NGI プログラム)に提案書を提出し、資金提供の承認を得ました。このプログラムは先夜に正式に始動し、私たちはすでに作業を開始しています。これは、あなたが提起したいくつかの点と重複する予定です。

提案書の要約の編集版

オンラインイベントサービスで一般的に使用される抽象的なカレンダーイベントデータモデルは存在しません。私たちはまず、過去の標準化の試みと人気のあるイベントサービスのデータモデルを統合し、機能するデータモデルを特定し、プロトタイプを作成します(「DEIP 仕様とプロトタイプ」)。次に、この仕様をオープンソースの Discourse プラグインとして製品化し、オンラインコミュニティが人気のあるイベント管理プラットフォーム(当初は EventbriteMeetupZoom)と、最も人気のあるオープンソースコミュニティソフトウェアである Discourse の間でカレンダーイベントデータを簡単に転送できるようにします(「DEIP プロダクト」)。私たちは、プラグインの持続的な存続を確保するため、MVP を使用する企業向けにサービス指向のサブスクリプションを提供します。

DEIP プロダクトは、Facebook が最近発表した 公式イベント API の商業的に実現可能なオープンソースの代替案となります。これは同様の機能を提供しますが、Facebook のコミュニティデータの「囲い込み(ウォールドガーデン)」に限定されます。Facebook はコミュニティ機能に長年投資しており、その投資は増加しています。Facebook がこの製品面への注力を継続している以上、オープンソースの代替案も同等の提供を継続的に改善し、存続可能性を保つ必要があります。DEIP 仕様とプロダクトは、その闘争において不可欠なツールとなります。

Discourse は、オンラインコミュニティのための数少ない真に実現可能なオープンソースプラットフォームの一つです。GitHub 上で最も人気のあるコミュニティプロジェクトであり、最近 2,000 万米ドルを調達して、拡大する組織(32,000 を超えるコミュニティを支援する 55 名の従業員)をさらに成長させています。Discourse のプラットフォームは 100% オープンソースであり、オープンソースソフトウェアのコミュニティと文化に深く根ざしています。

Pavilion(申請者)は、開発者とプロダクトマネージャーの協同組合であり、Discourse の公式パートナーです。私たちは 6 年以上にわたり Discourse と連携しており、Discourse 用の既存のサードパーティ製プラグインの大部分を構築してきました。これには 最も人気のある Discourse プラグインや、その後 Discourse.org によって採用(「公式」として認定)された複数のプラグインが含まれます。

統合された仕様とプロダクトは、カレンダーイベントデータモデルの標準化の象徴となるだけでなく、Discourse を使用する数万のオンラインコミュニティにおけるイベント管理のための効率的なオープンソースソリューションを提供します。

要約(問題と解決策)

オンラインコミュニティがイベントを管理する際に直面する主な問題は、サービス統合です。コミュニティは、Eventbrite などのマーケティングプラットフォーム、meetup.com などの発見プラットフォーム、Zoom などの会議ツール、または Facebook のようなオールインワンソリューションの組み合わせを使用します。複数のサービスにまたがってコミュニティを管理する難しさから、透明性や移植性よりも利便性を提供する独自のソリューションを使用するインセンティブが生まれます。

DEIP は、カレンダーイベントデータモデルの仕様とプロトタイプであると同時に、商業的に実現可能なオープンソースの Discourse プラグインとなります。要約すると、DEIP は以下のことを実現します:

  1. 実用的なカレンダーイベントデータモデル仕様を定義する。
  2. 仕様を実装し、動作するプロトタイプを作成する。
  3. プロトタイプを Discourse プラグインに発展させ、人気のあるイベントサービスからのインポートと、一般的なカレンダー標準を使用したエクスポートをサポートする。
  4. プラグインをオープンソースプロダクトとしてリリースし、ビジネスユーザーを対象としたサブスクリプションサービスを提供する。

仕様(研究コンポーネント)

カレンダーイベント管理における主要な標準は、RFC 5545(.ics 形式)と RFC 4791(CalDAV、または「ical フィード」)です。これらの標準の問題点は、現代の API から利用可能なカレンダーイベントデータモデル化には現在使用されていないことです。EventbriteMeetupZoom の API を通じて利用可能な同等のオブジェクトは、RFC 5545 にも、互いにも変換されません。業界団体による 抽象カレンダー API の開発の試みは、最近のいくつかの試みにもかかわらず、まだ実を結んでいません。さらに、独自のサービスは、グループ/サイト/コミュニティ全体の CalDAV フィードを提供していません(ユーザー固有のフィードを提供する場合があります)。要するに、カレンダーイベントデータモデルの標準化が著しく不足しています。

DEIP の主な研究コンポーネントは、既存の標準化の試みを実装しつつ、最も人気のある独自のイベント関連サービスとの実用的な使いやすさを維持する抽象的なイベントデータモデルを特定することです(「DEIP 仕様」)。この仕様は、その後、汎用的なカレンダーイベントの作成、読み取り、更新、削除を可能にする動作するプロトタイプ(当初は Ruby で、その後他の言語でも)に変換されます(「DEIP プロトタイプ」)。この作業の結果次第では、DEIP プロトタイプを ruby gems などの異なるパッケージシステムを通じて配布するためにパッケージ化することを目指す可能性があります。

MVP の基礎を形成するだけでなく(以下参照)、仕様とプロトタイプは、その背後にある考え方の説明を伴って DEIP ランディングページに公開されます。また、私たちのコミュニティ のセクションをこれに割り当て、さらなる議論の場とします。私たちは、標準データモデルの使用にイベントソフトウェアサービスを近づけ、サービス間の相互運用性と移植性を向上させるための取り組みに積極的に参加したいと考えています。

開発(開発コンポーネント)

私たちは、DEIP 仕様とプロトタイプを、以下の機能を提供する MVP Discourse プラグインに開発します:

  • 作成、読み取り、削除をサポートする Discourse イベント API。更新サポート(つまり双方向通信)は、後の製品バージョンで追加されます。
  • 人気のあるサービスへの特定のサポート。当初は Eventbrite、Meetup、Zoom。
  • Discourse イベントプラグインとの統合により、Discourse トピック内でイベントを表示し、Discourse 自体にイベントカレンダーを提供します。
  • コミュニティ内のすべてのイベントの統合されたフィードを提供する CalDAV サーバー。カテゴリやユーザーでフィルタリングする機能も備えています。
  • GDPR サポートのための Legal Tools プラグインとの統合、およびオープンソースの地図ソリューションを使用した GeoJSON 位置マッピングのための Locations プラグインとの統合。

展開(関連性、影響、および利益)

Pavilion は、有料コンサルティング業務と無償のオープンソース活動を通じて何千ものオンラインコミュニティをサポートしており、その多くが DEIP プロダクトの明確な必要性を示しています。これには、大学の研究者、健康サポートコミュニティ、趣味愛好家、中小企業、地域コミュニティ、スタートアップ、非営利団体、フォーチュン 500 企業、ファンタジー小説家、自然写真愛好家などが含まれます。この必要性のサンプルについては、こちらこちらこちらこちらこちらこちら、およびこちらをご覧ください。イベントの移植性と統合の容易さの欠如は、Facebook のようなロックイン型の独自ソリューションと Discourse のようなオープンソースソリューションとの選択において、頻繁に主要な要因となっています。

Pavilion のメンバーは、イベントを運営する既存のクライアントのために DEIP プロダクトを個人的に展開し、また上記のようにリンクされているような、私たちの作業の多くのオープンソースユーザーを支援します。Discourse コミュニティ内での Pavilion の活動に加えて、DEIP は以下のものを持ちます:

  • DEIP 仕様とプロトタイプを含むスタンドアロンのプロダクトウェブサイト。
  • API ドキュメント。
  • Pavilion のサポートチャネルを介したサポート。

私たちの目標は、DEIP プロダクトを独自のコミュニティプラットフォーム上のイベント管理の実現可能な代替案とし、DEIP 仕様とプロトタイプがカレンダーイベントデータモデルの標準化の取り組みを前進させることです。

ビジネスモデル(商業的活用)

Pavilion は、オープンソースと非営利コミュニティへの支援に対するコミットメントを維持しつつ、メンバーが自分の仕事に対して適切に報酬を得られるようにする、オープンソースの Discourse プラグイン向けのサブスクリプションモデルを開発しました。このモデルには以下の機能があります:

  • 100% オープンソースのコード。
  • コミュニティマネージャーがサブスクリプションを購入しない限り、アプリケーションクライアントには表示されない選択された「ビジネス」機能。
  • 「ビジネス」機能を使用する非営利コミュニティ向けの無料サブスクリプション。
  • 有料サブスクライバー向けのビジネス指向サービス。

100% オープンソースのコードベースにおける機能制限は、プログラム的に回避可能ですが、これは有料サブスクリプションの対象市場には関連しません。企業は自分たちに利益をもたらすサービスにお金を払いたがっており、制限を回避することを選択する者は、その製品の側面におけるターゲット顧客ではありません。

私たちは、Discourse 自体内のイベント機能に焦点を当てた他の事項も含めて、このプロジェクトの範囲を拡大する可能性があります。ただし、そのためには追加の資金が必要です。さらに議論したい場合は、私に PM を送ってください。いずれにせよ、DEIP プロジェクトの詳細については、進行に合わせて meta で共有していきます。

「いいね!」 10

おめでとう、アンガス!!! 素晴らしいですね。これは、より良い世界に大きく貢献する可能性を秘めています(フォーラムの集まりだけでなく、それも素晴らしいですが)。成功を祈っています!

「いいね!」 8

Angusさん、

これに関して何か進展はありましたか?これは私のフォーラムすべてに常に存在する問題であり、人々が会議などのために他のプラットフォームに移動する原因となっています。

「いいね!」 2

ネイサンさん、1ヶ月ほどで共有できることがあります。それまでの間、coop.pavilion.techで個人的にご連絡いただければ、フォーラムでのイベント設定をお手伝いできます。

DEIPプロジェクトに加えて、Events Pluginを復活させることも検討しており、上記で言及された懸念の一部に対処するために使用する可能性があります。

「いいね!」 4

約束通り、Discourse Events Integration Pluginプロジェクトのフェーズ1に関する完全なレポートを以下に示します。

https://docs.google.com/document/d/1-oJsXivT_KRBZ-wUQ-TbHdO7Z-qf7z4GeiRiJ014V-E/edit?usp=sharing

そして、イベントデータモデル(Ruby gem)のプロトタイプ実装を以下に示します。gemは開発中であり、本番環境での使用には適していないことに注意してください。

https://github.com/paviliondev/omnievent

調査レポートを読むとわかるように、プラグイン自体はプロジェクトのフェーズ2で構築されます。

「いいね!」 4

アンガス、素晴らしい仕事ぶりですね。今後しばらくの間、その成果を見るのを楽しみにしています!

私の専門分野である医療情報学と、いかに多くの共通点があるかに興味をそそられています。私たちは、うまく連携しない、有機的に成長した複数の独自データモデルという同じ問題を抱えています。そして、その結果、患者が苦しんでいます。

これは、基本的にすべての医療データを対象に、まったく同じことを目指す、印象的なオープンデータプロジェクトです。

「いいね!」 2

フェーズ1での作業がDAPSIによって好意的にレビューされ、このプロジェクトがフェーズ2、つまりEvents Integration Pluginの構築に進むことをお知らせするもう1つのアップデートです。これには、Pavilion Events Pluginの改造が含まれます。

確かに。ヨークでの昼食中に、この重複について@pacharaneroとじっくり話しました。

「いいね!」 5

イベント統合プラグインのベータ版が利用可能になったことをお知らせします :slight_smile:

さらに詳しい情報は、そのトピックに投稿します。

「いいね!」 5