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

贡献 功能
1

继续关于 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:00Z → 2021-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 个赞
Please better document the Discourse Calendar plugin
User status overview
Available hours / work hours flair
2

Pavilion 正在开发一个 Discourse 事件集成插件（DEIP），该插件除其他功能外，还将允许您从其他服务和平台向 Discourse 发布事件。我们向 DAPSI（一个欧盟 NGI 计划）提交了一份提案，并已获得资助批准。该计划已于昨晚正式启动，我们已开始着手开展工作。这将与您提出的一些要点有所重叠。

提案执行摘要的编辑版本

目前在线事件服务中尚未有通用的日历事件抽象数据模型。我们将首先基于对以往标准化尝试的整合以及主流事件服务的数据模型，制定并原型化一个可行的数据模型（“DEIP 规范与原型”）。随后，我们将以开源 Discourse 插件的形式将该规范产品化，使在线社区能够轻松地在主流活动管理平台（初期包括 Eventbrite、Meetup 和 Zoom）与 Discourse（最受欢迎的开源社区软件）之间传输日历事件数据（“DEIP 产品”）。我们将向使用最小可行产品（MVP）的企业提供面向服务的订阅，以确保插件的长期可持续性。

DEIP 产品将是一个具有商业可行性的开源替代方案，用于替代 Facebook 最近推出的 官方事件 API。该 API 提供类似功能，但仅限于 Facebook 的社区数据“围墙花园”。Facebook 长期以来一直在投资其社区功能，且 该投资正在增长。Facebook 持续专注于其产品的这一方面，意味着开源替代方案必须不断改进同类功能以保持竞争力。DEIP 规范与产品将成为这场竞争中的关键工具。

Discourse 是少数真正可行的开源在线社区平台之一。它是 GitHub 上最受欢迎的社区项目，并 近期筹集了 2000 万美元，以进一步推动其不断壮大的组织发展（55 名员工支持超过 32,000 个社区）。Discourse 平台 100% 开源，并深深植根于开源软件社区与文化之中。

Pavilion（申请方）是一个由开发者和产品经理组成的合作社，并且是 Discourse 的官方合作伙伴。我们与 Discourse 合作已超过 6 年，已构建了现有第三方 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 的日历事件数据。通过 Eventbrite、Meetup 和 Zoom 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，以及与 位置插件 集成，利用开源地图解决方案实现 GeoJSON 位置映射。

部署（相关性、影响与效益）

Pavilion 通过有偿咨询工作和无偿开源工作支持数千个在线社区，其中许多社区已明确表达了对 DEIP 产品的需求，包括大学研究人员、健康支持社区、爱好者、小型企业、邻里组织、初创公司、非营利组织、财富 500 强企业、奇幻小说作家以及自然摄影爱好者。关于这种需求的示例，请参阅 此处、此处、此处、此处、此处、此处 以及 此处。事件可移植性和集成的便捷性不足，往往是选择像 Facebook 这样的锁定型专有解决方案与像 Discourse 这样的开源解决方案之间的关键因素。

Pavilion 成员将亲自为现有运行事件活动的客户部署 DEIP 产品，并协助许多开源用户（如上述链接所示）。除了 Pavilion 在 Discourse 社区内的工作外，DEIP 还将具备：

我们的目标是使 DEIP 产品成为专有社区平台上事件管理的可行替代方案，并推动 DEIP 规范与原型在日历事件数据模型标准化方面的进展。

商业模式（商业利用）

Pavilion 为其开源 Discourse 插件开发了一种订阅模式，该模式既坚持了对开源和非营利社区的支持承诺，又确保了成员的工作得到合理报酬。该模式具有以下特点：

  • 100% 开源代码。
  • 精选的“企业”功能，除非社区管理员购买了订阅，否则在应用程序客户端中不可见。
  • 为非营利社区提供免费订阅，使其能够使用“企业”功能。
  • 为付费订阅者提供面向企业的服务。

在 100% 开源代码库中，功能限制可以通过编程方式绕过，但这与付费订阅的目标市场无关。企业愿意为能带来效益的服务付费，而那些选择绕过限制的人并不是该方面产品的目标客户。

我们有可能扩大本项目的范围，以涵盖您提到的其他内容，即那些专注于 Discourse 内部事件功能的内容，但这需要额外的资金支持。如果您希望进一步讨论此事，可以给我发私信。无论如何，随着项目的推进，我将在此 meta 板块分享更多关于 DEIP 项目的详细信息。

10 个赞
3

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

8 个赞
4

你好 Angus，

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

2 个赞
5

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

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

4 个赞
6

正如我所承诺的，这是关于 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 个赞
Events Plugin :calendar:
Events Plugin :calendar:
7

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

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

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

2 个赞
8

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

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

5 个赞
9

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

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

5 个赞