Skip to content

再见,GitHub 讨论

随着 Zensical 的推出,我们正在改变与社区合作的方式,以确保长期可持续性和专业支持,促进有意义的合作。

Zensical 的推出 两周前 标志着一个重要的里程碑,因为它为我们构建可扩展的开源技术写作系统的使命奠定了新的基础。此外,我们正在采用一种结构化、透明和以社区为驱动的方法来指导我们项目的发展——优先考虑构建内容,并共同塑造 Zensical 的未来。

我们新的方法 提炼了十年的维护 Material for MkDocs 的经验,使我们能够将努力从一个小团队专业化和规模化,转变为一个完全组织化的运营,同时保持软件对所有人免费和开放。

随着 Material for MkDocs 进入 维护模式我们的讨论板现在为只读模式

在本文中,我们反思了我们所经历的挑战和所学到的经验,因为这些经历塑造了我们与 Zensical 一起构建的社区管理和支持的方法。

您可以订阅 我们的新闻通讯 以保持信息更新


这是四部分系列文章中的第四篇也是最后一篇:

  1. 转变 Material for MkDocs
  2. Zensical – 由 Material for MkDocs 的创作者构建的现代静态网站生成器
  3. Material for MkDocs Insiders – 现在对所有人免费
  4. 再见,GitHub 讨论

GitHub 问题

与开源项目的互动可以采取多种形式——报告错误、提交功能请求、寻求帮助、分享想法、参与讨论和贡献代码。每种类型的互动都需要不同的管理方法。

历史上,我们依赖 GitHub 问题追踪器来处理错误报告和功能请求。然而,用户询问的很大一部分——问题、支持请求和指导——也进入了问题追踪器。随着时间的推移,这模糊了开发工作与支持之间的界限,使我们越来越难以专注于核心开发任务。

这并不是我们项目所独有的;许多开源维护者由于社区内技能水平和期望的多样性面临类似的挑战。显然,开源项目需要更好的解决方案来将用户支持与开发工作分开。

GitHub 讨论

在 2020 年,GitHub 推出了 GitHub 讨论 作为社区互动的专用空间——一个将支持请求从问题追踪器中转移的新渠道。我们立即为 Material for MkDocs 启用了讨论,并引导用户发布问题和寻求帮助。1

然后,随着我们的社区不断扩大——而绝大多数参与者寻求帮助而不是提供帮助——我们推出了 社区专家计划,给予那些持续提供高质量帮助的社区成员免费访问 Insiders 的权限。

结构性挑战

尽管采取了这些措施,我们仍然面临几个结构性挑战:

  1. Material for MkDocs?MkDocs?一样的 – 我们常常被视为整个生态系统的入口。因此,许多实际上属于上游的问题和讨论——例如 Python Markdown、MkDocs 插件或 MkDocs 本身的问题——都落到了我们这里。这为重定向问题创造了额外的分诊工作。

  2. 又一个收件箱 – 尽管讨论板与问题追踪器是分开的,但我们最终处理了大多数问题,有效地将讨论板变成了另一个收件箱。由于讨论板与代码库相关联,未回答的讨论可能被视为项目未维护,从而给我们带来了回应的压力。

  3. 每件事都有通知 – GitHub 的通知系统加剧了这个问题。在问题或讨论中的任何互动都会让您订阅整个线程,导致每条评论都收到通知,包括:+1——花 2 秒钟输入并提交的内容,会向所有其他参与者的收件箱发送通知。

  4. GitHub 讨论是聊天 – 许多用户开始将 GitHub 讨论视为聊天平台,而不是结构化的知识库。这造成了通知疲劳,强化了社区隐含依赖维护者处理支持请求的模式。每个人都收到了消息,因此假设事情得到了处理——对吗?

  5. 在我们的讨论板上报告错误 – 不时地,我们的 贡献指南 被忽视,导致在我们的讨论板上出现虚假的错误报告,而不是在问题追踪器上——“搜索不起作用”并不是一个可操作的错误报告。然而,当用户遵循我们的 错误报告指南 时,我们能够在 24-48 小时内修复大多数错误。

解决这些挑战

我们通过多种方式积极应对这些挑战:在我们的问题追踪器上引入精心设计的问题模板,并创建详细的逐步指南,指导如何有效地报告错误、请求更改和创建拉取请求。

尽管做出了这些努力,但成功有限。根本问题在于,虽然 GitHub 讨论是朝着正确方向迈出的一步,但并未设计为处理我们社区的规模和多样性。它缺乏支持寻求帮助的大型活跃用户群所需的结构和功能,使我们无法完全解决面临的挑战。我们相信,这并不是我们项目所独有的,而是 GitHub 讨论的系统性问题,许多开源维护者也遇到类似的困难。

社区专家计划 有助于减少一些支持负担,但无法完全解决使用 GitHub 讨论进行用户支持的结构性限制。

讨论现在为只读

随着 Material for MkDocs 进入 维护模式我们的 GitHub 讨论板现在为只读模式——它仍然可以访问,但将不再接受新的讨论或评论。所有现有的答案将保持不变,确保用户仍然可以找到以前解决问题的解决方案。

Material for MkDocs 现在处于维护模式

我们希望对继续使用 Material for MkDocs 的风险保持透明。由于 MkDocs 未维护 并面临根本的供应链问题,我们无法保证 Material for MkDocs 将在未来继续可靠地工作。我们意识到过渡需要时间,这就是为什么我们承诺至少在接下来的 12 个月内支持它,修复关键错误和安全漏洞,但前进的道路是 Zensical。

如果文档在您的组织中扮演着关键角色,并且您担心这可能会影响您的业务,请考虑加入 Zensical Spark,或者随时通过 contact@zensical.org 联系我们安排通话。

这对您意味着什么

对于与更广泛的 MkDocs 生态系统相关的问题和疑问,我们鼓励用户在相关上游项目的问题追踪器和讨论板上寻求帮助:

MkDocs 和 Python Markdown

流行的 MkDocs 插件

对于所有其他 MkDocs 插件和 Markdown 扩展,请查阅 MkDocs 目录,并联系相关项目的维护者。

加入我们的 Discord,成为 Zensical 不断壮大的社区的一部分!

展望未来

本文结束了我们关于维护 Material for MkDocs 的旅程的四部分系列反思,以及它如何为 Zensical——我们的下一个章节铺平道路。

我们新的方法 在社区管理和支持方面直接建立在我们多年来所学到的经验之上。我们期待与您一起开始这一新篇章,并共同培养一个充满活力、参与度高和可持续的社区。

您可以订阅 我们的新闻通讯 以保持信息更新


  1. 在采用 GitHub 讨论之前,我们维护了一个 Gitter 频道,但最终选择了 将我们的支持工作整合到一个平台。虽然 GitHub 讨论看起来很有前景,但其机制证明是无效的。