我们如何使用 GitHub Issues 以及这种方式的改变

2025/11/03

W3C

📢 订阅 Eleventy 新闻源

当新的增强请求进入 Eleventy 仓库 时，我们的标准处理流程包括以下步骤：

1. 添加以下回复评论：

默认情况下，此仓库会关闭新的增强请求并将其放入队列供大家投票。我们这样做是为了避免开放问题堆积，这个想法来自于 lodash 项目

不要忘记用 👍 给第一条评论投票来注册您的投票！您可以查看当前的增强积压工作。

2. 给问题添加 needs-votes 标签。
3. 关闭问题。

这个想法来自 Sam Selikoff。

最近我注意到 Lodash 的仓库有 0 个开放问题。作为 OSS 维护者，我觉得这很有趣，因为 Lodash 非常受欢迎，而保持问题数量少是出了名的困难。

这个技术是很棒的，多年来很好地为我们服务了，主要原因是它传达了增强请求被归类为次要的。但它也提供了一个很好的列表，列出了项目可能的未来，社区人士可以对此发表意见。

然而，它也造成了一些困惑：问题被关闭了但没有实现。"这个队列被认为是开放的/半开放的/关闭的吗？""如果我仍然想要这个功能，我需要重新提交吗？"当问题被放入队列时已经在参与问题的人通常理解发生了什么，但后来通过搜索访问问题的新人可能没有看到有用的解释评论。

更糟糕的是，在2022 年 GitHub 推出问题关闭原因时，他们将所有现有的关闭问题默认为已完成。唯一的替代原因是未计划，这（对我来说）更接近于绝对不。我很希望看到待优先级排序或*也许，如果有足够多的人投票！*这样的原因。

我非常感谢 uncenter，他对上述方法温和地提出了反馈（好几次 😅）。

转向 GitHub Discussions

在与 Cory LaViska 进行了一些非常富有成效的（现实生活中，没错）对话后（他最近写了关于这个主题的优秀博客文章），很明显，也许 GitHub Discussions（2024 年正式推出）将是未来更合适的机制。Cory 阐述如下：

• 错误报告 👉 Issue
• 帮助/支持 👉 Discussion
• 提出问题 👉 Discussion
• 想法/建议 👉 Discussion
• 哲学思辨 👉 Discussion

Cory 在文章后面补充到列表中：

• 可执行的工作（里程碑任务） 👉 Issue

GitHub Discussions 的好处是，在列表视图中投票是一个第一方用户界面功能。主要的缺点是我们将在排序列表中失去现有的投票数量（它们在完整条目中仍然可访问）：这是一个进入 2026 年的公平竞争环境。

另一个好处是，GitHub Issues 变得非常专注于进入发布的可执行工作，而不是更多基于想象的规划或处理"这是如何工作的？"式的教育请求。

欢迎随时观看之前的队列转换为新的Eleventy 增强队列（并留下您的投票！）。

我们在 eleventy 和 11ty-website 上的新问题漏斗将帮助您找到合适的位置！

感谢大家！

阅读更多 博客文章:

• 上一篇：W3C技术联盟 v3.1.0 现已可用 — 速度提升11%，体积减小22%！