日历插件功能,使其对我们真正有用

继续关于 Discourse Calendar 的讨论:

Fedora 项目目前有我们自己的日历 Web 应用 Fedocal。它即将进行更新,我正在考虑是否可以用 Discourse 中的日历替换它,而不是重写独立的应用程序。这实际上不是一个功能请求,而是在我们评估下一步行动时,对我们的用例和我认为缺失的功能进行记录。

用例

我认为 Fedocal 有三个重要的用例。如果有更多,请告诉我,我会将其添加到考虑范围。

  1. 安排会议。这是迄今为止最重要的。
  2. 让人们分享他们的可用性。目前,我们要求项目中有责任的人员填写休假信息,但很少有人这样做。(我个人觉得,即使我记得,也太麻烦了。)
  3. 展示 Fedora 活动,如 Flock to Fedora、多样性周或发布派对。我们目前实际上并没有这样做。

其他可能性

  • 我们在 2013 年曾尝试将 Fedocal 用于 Flock 会议日程,但此后没有再这样做。如果我们有一个有吸引力且易于使用的解决方案,那将是 很好 的。
  • 展示 Fedora 发布日程本身。目前,我认为我们只将其用于安排 go/no-go 会议,而不是实际的日程。如果这样做,它需要自动从 Fedora Project schedules 导入,而不是手动输入。

当前 Discourse Calendar 插件的不足之处

目前正在添加到其中的 “事件”系统 对我们来说是错误的。(它从整个站点的帖子中收集“事件”并将它们放在一个全局日历上。我们需要的功能远不止这些。)

我的第一个假设是,我们将专注于扩展日历插件的“传统”部分,该部分在主题的第一个回复中有一个日历,该日历仅由该主题的回复“填充”。但是,另一种方法——抓取整个站点的事件——也 可能 是更好的。在这种情况下,我们需要扩展它,使其能够拥有 多个 日历进行定位。(在这种情况下,能够将它们嵌入到固定的主题中,而不仅仅是隐藏在汉堡菜单中,那将是很好的。)

因此,话虽如此,以下是我们所需的一些内容:

一般来说

  1. 日历显示本身相当粗糙。
    • 它可以更漂亮
    • 它根本不缩放或适应其显示方式
    • 它被硬编码为欧盟风格的周一至周日周
    • 它似乎总是显示 UTC 时间,即使 条目 是本地时区的,这使得本地时区的一整天事件在日历上看起来跨越 两天。(Discourse 团队已意识到此错误。)
    • 月视图目前仅显示事件描述的前几个字符。如果日历只有一个简单的事情(参见 此处用于 Fedora Social Hour),那没关系,但对于有很多不同事情的日历来说则不好。
    • 目前,“假日”版本的日历可以为事件分配颜色,但它是通过从用户名以编程方式派生的值来完成的。这应该可以按事件进行配置,并且适用于所有日历,而不仅仅是假日日历。
  2. 我认为没有 .ical feed?这对于人们能够将其添加到他们的 Google 日历或其他日历中会很好。
  3. 希望有: 能够生成提醒邮件发送到邮件列表,而不仅仅是订阅用户。我们还没有让所有人都使用 Discourse!
  4. 希望有: 一个 个人 日历视图,您可以选择要跟踪的确切条目。

会议用例

  1. Fedocal 有两个主要“轴”——日历条目所属的组(如“理事会”)和地点(如“#fedora-meeting”)。日历插件可以做到其中之一:我们可以创建一个“Fedora 理事会会议”主题或一个“Fedora 会议频道”主题,但条目不会被链接。我不太确定作为插件的最佳设计会是什么样的——我认为我们需要一些 UX 设计师的专业知识来思考这个问题。
    • 如果“组”轴是 Discourse 组,那将是很好的,特别是因为我们 有一天很快我希望 会将 Discourse 组链接到我们的 SSO。
    • 或者,日历“组”轴可能是一个 标签。这可能更灵活,并且对我们有用,因为我们计划为我们的站点组织进行组到标签的映射。
    • “地点”轴很短——我们有几个会议频道,允许一个“其他”地点来处理特殊情况可能就足够了。
  2. 关键: 系统需要防止——或至少警告——两个轴上的冲突。也就是说,同一时间不能有两个理事会组会议,也不能在同一地点同时有两个来自不同组的会议。
    • 除非我们有一个通用的“其他”……所以,我想有些地点应该可以重叠。
  3. 重复事件的语法有点奇怪,但还可以。但是,重复事件仅在日历网格中显示为重复(并在提醒中更新为下一个),而不是更多。而且应该有更多:
    • 关键: 用户应该能够订阅每个重复事件的通知,按日历条目进行。
      • 希望有: 一个针对特定日历的默认通知的每个 Discourse 组配置,例如,理事会组的成员默认会收到理事会日历条目的通知。
      • 希望有: 能够配置即将举行的会议的 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. 希望有: 没有持续时间的条目应该在视觉上有所不同——并且可能只允许“整天”条目。
  5. 希望有: 每个日历条目(对重复条目分开)都可以链接到议程+笔记主题。此主题 不会 在没有交互的情况下自动创建,但应易于单击一次开始,并且一旦创建,应自动链接。

“假日”用例

  1. 假日日历也应该了解组。目前它对(Discourse 站点)员工有一些特殊处理——这应该被泛化和配置,并且允许为不同的组以及全局的一个设置不同的日历。
  2. 在其默认配置中,假日日历会显示每个已配置区域设置的人的标准国家假日。如果人数超过五人,并且分布在不超过两个不同的地点,那就会压倒一切。不过,Discourse 为我们提供了一个临时解决方案来隐藏它。
  3. 希望有: 目前,员工在休假时,用户名旁边会显示一个 :palm_tree: 表情符号,仅对其他员工可见。此图标的可见性应该是可配置的。
  4. 希望有: 允许配置显示哪个表情符号。
    • 额外的希望有: 允许用户从 表情符号列表 和原因中选择一个给定的不可用时间(休假、生病、旅行等)。

Fedora 活动

实际上,我认为我们目前拥有的可以满足此需求。但是,上述的一些功能——更漂亮、更灵活的日历显示、通知、颜色——会很有用。

对于其他可能性

  • 会议日程用例就是会议日程用例,但非常密集。手动跟踪冲突变得不可能。为此,可能需要 用户级别 的轴而不是组级别轴。(演讲者不能同时出现在两个地方。)而且,与我们的会议室地点不同,会议室地点在 15 年来变化不大(除了 URL 更新),并且可能在未来 15 年内也不会有太大变化,每个活动都有自己的一组地点。
  • 发布日程日历:我认为这主要是从现有日程数据导入的自动化问题。我认为现有的日历插件在很大程度上可以工作。同样,与 Fedora 活动一样,颜色编码会很好。
14 个赞

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 个赞

恭喜 Angus!!! 太棒了。这有潜力为更美好的世界做出重大贡献(不仅仅是一堆论坛,但那也很酷)。祝你成功!

8 个赞

你好 Angus,

你在这方面有进展吗?这对我的所有论坛来说一直是个存在的问题,并且导致人们转向其他平台进行会议等活动。

2 个赞

嘿 Nathan,我们大约一个月后会有些事情要分享。在此期间,您可以通过 coop.pavilion.tech 私下联系我,我可以帮助您在论坛上设置活动。

除了 DEIP 项目,我们还在考虑恢复 Events Plugin 并可能用它来解决上述一些问题。

4 个赞

正如我所承诺的,这是关于 Discourse Events Integration Plugin 项目第一阶段的完整报告。

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

这是事件数据模型的原型实现(一个 ruby gem)。请注意,该 gem 尚在开发中,未准备好投入生产使用。

https://github.com/paviliondev/omnievent

正如您在阅读研究报告时会了解到的,该插件本身将在项目第二阶段构建。

4 个赞

Angus,这项工作令人印象深刻。我期待在不久的将来看到成果!

我很好奇我的健康信息学领域与此有多少相似之处。我们遭受着同样的问题,即多个有机增长的专有数据模型无法很好地协同工作。患者因此而受苦。

有一个令人印象深刻的开放数据项目,它基本上试图为所有健康数据做同样的事情:

2 个赞

只是想在此说明,我们第一阶段的工作得到了 DAPSI 的好评,该项目将进入第二阶段,即 Events Integration Plugin 的构建。其中一部分将涉及对 Pavilion Events Plugin 的改造。

确实如此。我在约克午餐时与 @pacharanero 就这种重叠进行了愉快的交谈。

5 个赞

在此最后说明一下,事件集成插件的Beta版本现已发布 :slight_smile:

我将在该主题中发布进一步的更新。

5 个赞