在流行的开放代码库上工作的最显着的优势之一是各种形式的持续反馈流，包括 GitHub 问题和拉取请求。在过去的 6 个月里，我们的团队做了大量工作，对 3 个主要存储库中的 4500 多个问题进行了分类，并合并了数百个拉取请求。通过这个过程，我们对长期存在的请求做出了回应，并巩固了我们对社区最常见请求的理解。

收到如此丰富的反馈真是太棒了，但与此同时，处理数千个请求可能会很麻烦。它可能会减慢我们在讨论线程中的响应速度，并且常常会分散我们对开发人员最重要需求的注意力。

我们多次讨论过不同的自动化流程。他们中的大多数人最关心的一个问题是，如果无法解决这些评论或将它们纳入我们对 Angular 的未来愿景中，就可能会失去宝贵的评论。

分析我们三个主要存储库中的问题，我们发现其中很大一部分是功能请求：

尽管很诱人，但整合所有功能请求是不现实且不健康的。如果 Angular 走这条路，框架就有变得难以学习和难以维护的风险。但显然这样的反馈是宝贵的——来自社区的数百个聪明的想法与 Angular 的未来愿景非常吻合，值得探索。

自动化功能请求

在 GitHub Universe 上，VSCode 团队就“我们如何公开制作 VS Code ”进行了精彩的演讲。 Alex和Benjamin分享了他们的团队如何通过社区参与来自动化功能请求流程。

在接下来的几周内，在 Angular 项目中，我们将引入类似的方法来管理现有和传入的功能请求。

当我们收到票证时，Angular 团队成员将手动审核它并将其分类为功能请求或问题。

下一步，我们将验证功能请求是否与路线图上的任何现有项目一致。如果他们这样做，我们将优先考虑他们。如果没有，他们将经历 60 天的投票过程。

在此期间，任何人都可以通过点赞的方式为相应的功能投票（👍）。如果在 60 天结束时请求已收集到一定数量的投票，我们的 GitHub 机器人将自动对其进行标记以供考虑。否则，它将关闭它。按照 VS Code 团队设置的流程，我们将考虑拥有 20 票或更多票的请求，并迭代不同数量的票是否会产生更好的结果。

如果请求有需要考虑的标签，我们将再次手动审核它并验证它是否符合 Angular 的未来愿景。如果是，我们会将其移至优先队列中。或者，我们将通过解释来结束它。我们希望保持 Angular 的连贯性。关闭功能请求通常意味着它更适合社区可以作为平台扩展进行分发的外部模块。

从历史上看，我们一直对关闭功能请求犹豫不决，即使我们认为我们不会真正推进该功能。通过积极关闭更多功能请求，我们设定了更好的期望，并明确表示我们正在努力专注于影响最多开发人员的工作。

您可以通过查看下面的活动图来更详细地预览该流程：

大规模开源

我们重视所有收到的反馈，对我们来说，响应并关注任何人的请求是首要任务。

为了继续可持续地扩展，我们期待着启动这一流程，以使我们在功能请求管理流程中更加高效和公平！

原文链接：https://blog.angular.dev/new-feature-request-process-a9f69d106fc8