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

特徴
1

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:00Z → 2021-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
2

Pavilion is working on a Discourse Events Integration Plugin (DEIP), which, inter alia, will allow you to publish events to Discourse from other services and platforms. We submitted a proposal to DAPSI (an EU NGI program), which was accepted for funding. The program just kicked off (last night) and we’re starting work on it. This will overlap with some of the points you raised.

Edited version of the executive summary from the proposal

There is no abstract data model for calendar events in regular use by online event services. We will first specify and prototype a working data model based on an assimilation of previous standardisation attempts and the data models of popular event services (“DEIP Specification and Prototype”). We will then productize this specification in the form of an open source Discourse plugin that will allow online communities to easily transfer calendar event data between popular event management platforms (initially Eventbrite, Meetup and Zoom) and Discourse, the most popular open source community software (“DEIP Product”). We will be offering service-orientated subscriptions to businesses using the MVP to ensure the plugin’s continued viability over time.

The DEIP Product will be a commercially-viable open-source alternative to Facebook’s recently-launched Official Events API, which provides similar functionality, but for Facebook’s “walled garden” of community data. Facebook has been investing in its community features for some time, and that investment is growing. Facebook’s continued focus on this aspect of its product means open-source alternatives need to be continually improving equivalent offerings to stay viable. The DEIP Specification and Product will be vital tools in that struggle.

Discourse is one of the few truly viable open source platforms for online communities. It’s the most popular community project on github, and recently raised $20 Million USD to further grow its expanding organisation (55 employees supporting over 32,000 communities). Discourse’s platform is 100% open source and is deeply embedded in open source software communities and culture.

Pavilion (the Applicant) is a co-operative of developers and product managers and an official partner of Discourse. We’ve been working with Discourse for over 6 years and have built a substantial portion of the extant 3rd-party plugins for Discourse, including the most popular Discourse plugin and a number of plugins which have subsequently been adopted (made “official”) by Discourse.org.

The combined Specification and Product will serve as both an exponent of calendar event data model standardisation, and provide an efficient open-source solution for event management on the tens of thousands of online communities using Discourse.

Summary (Problem and Solution)

The primary problem faced by online communities managing events is service integration. Communities use a mixture of marketing platforms such as Eventbrite, discovery platforms such as meetup.com, meeting tools such as Zoom, or all-in-one solutions such as Facebook. The difficulty of managing a community across multiple services means there is an incentive to use proprietary solutions which offer convenience over transparency and portability.

The DEIP will be both a calendar event data model specification and prototype, and an open-source commercially-viable Discourse plugin. In summary, the DEIP will:

  1. Define a practical calendar event data model specification.
  2. Implement the specification in a working prototype.
  3. Develop the prototype into a Discourse Plugin with support for importing from popular event services, and exporting using common calendaring standards.
  4. Release the plugin as an open source product, with a subscription service targeted at business users.

Specification (The Research Component)

The main standards in the management of calendar events are RFC 5545 (.ics format) and RFC 4791 (CalDAV, or “ical feeds”). The problem with these standards is that they are not currently used to model calendar event data available from modern APIs. The equivalent objects available via the Eventbrite, Meetup and Zoom APIs do not translate to RFC 5545, or to each other. Attempts by industry bodies to develop an Abstract Calendaring API have yet to bear fruit, despite some recent attempts. Moreover, proprietary services do not provide group/site/community-wide CalDAV feeds (they sometimes provide user-specific feeds). In short, there is a significant paucity of calendar event data model standardisation.

The primary research component of the DEIP will be to specify an abstract event data model that implements the existing standardization attempts, while maintaining practical usability vis-a-vis the most popular proprietary event-related services (the “DEIP Specification”). This specification will then be converted into a working prototype (initially in Ruby; subsequently in other languages), allowing for the creation, reading, update and deletion of generic calendar events (the “DEIP Prototype”). Depending on the outcomes of this work, we may seek to package the DEIP Prototype for distribution via different package systems, e.g. ruby gems.

As well as forming the basis of the MVP (see below), the specification and prototype will be published on the DEIP landing page with accompanying explanations of the thinking behind it. We will also dedicate a section of our own community to it for further discussion. We want to be an active part of efforts to bring event software services closer to the use of standard data models to improve service interoperability and portability.

Development (The Development Component)

We will develop the DEIP Specification and Prototype into an MVP Discourse Plugin offering the following features:

  • Discourse Event API with Create, Read and Delete support. Update support (i.e. two-way communication) will be added in a later product version.
  • Specific support for popular services. Initially Eventbrite, Meetup and Zoom.
  • Integration with the Discourse Event Plugin to display events within Discourse topics and provide an Events Calendar within Discourse itself.
  • A CalDAV server to provide a unified feed of all events in a community, with the ability to filter by category and user.
  • Integration with the Legal Tools Plugin for GDPR support and the Locations Plugin for GeoJSON location mapping using open source mapping solutions.

Deployment (Relevance, impact and benefits)

Pavilion supports thousands of online communities through our paid consulting work and unpaid open source work, many of which have evinced a clear need for the DEIP Product, including university researchers, health support communities, hobbists, small businesses, neighbourhoods, startups, non-profits, Fortune-500 companies, fantasy novelists and nature photography enthusiasts. For a sampling of this need, see here, here, here, here, here, here and here. The lack of ease of event portability and integration is frequently a key factor in the choice between locked-in proprietary solutions like Facebook and open source solutions like Discourse.

Pavilion members will be personally deploying the DEIP Product for our existing clients who run events, as well as assisting the many open source users of our work, like those linked above. In addition to Pavilion’s work within the Discourse community, the DEIP will have:

Our goal is for the DEIP Product to be a viable alternative to event management on proprietary community platforms and for the DEIP Specification and Prototype to advance efforts in calendar event data model standardisation.

Business Model (Commercial Exploitation)

Pavilion has developed a subscription model for our open source Discourse plugins that maintains our commitments to open source and supporting non-profit communities, while ensuring our members get properly compensated for their work. The model has the following features

  • 100% open source code.
  • Selected “business” features that are not visible on the application client unless the community manager has purchased a subscription.
  • Free subscriptions for non-profit communities that use the “business” features.
  • Business-orientated services for paid subscribers.

Feature-restriction in a 100% open source code base can be programmatically overcome, however this is not relevant to the target market for paid subscriptions. Businesses want to pay for services that benefit them, and those that choose to overcome the restrictions are not the target customers for that aspect of the product.

We could potentially expand the scope of this project to include some of the other things you’ve mentioned, i.e. those focused on event features within Discourse itself, however we’d need additional funding. If you want to discuss this further you can PM me about it. In any event, I’ll be sharing more details about the DEIP project here on meta as we progress.

「いいね！」 10
3

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

「いいね！」 8
4

Angusさん、

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

「いいね！」 2
5

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

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

「いいね！」 4
6

約束通り、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
7

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

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

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

「いいね！」 2
8

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

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

「いいね！」 5
9

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

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

「いいね！」 5