Information: 代码 PR 的审查期

我的印象也是，这个过程是在考虑以社区为中心的 repos 的情况下编写的，也就是说，PR 更接近于组织变革。

同意，代码可以被视为改变组织运作方式的实施规则，但对我们编码方式的严格限制是不可行的。 它将使发展停滞不前。

也许让这个过程更清楚，所以它不适用于代码 PR？

尽可能快地？ 因此，理想情况下，您会在打开拉取请求或问题后立即合并？ 我们需要一个对话窗口吗？

我会立即争辩说这是不可能的。 :-) 我们需要允许审阅者进行知情审阅，但由于他们已经需要时间来执行此操作，并且在他们完成之前不会发生合并，“立即”只是假设。

所以，我不完全同意@megoth ，我们不能简单地将流程应用于代码，因为存在有争议的代码更改。

但是，还值得注意的是，使用修订系统的全部意义在于代码更改并非不可逆转。 在代码更改完成完整版本之前，还原确实是一件大事，而且需要更长的时间。

我认为这里的底线是，对于每个 PR（无论是代码还是其他）在合并之前应该保留多长时间，确实没有一个硬性规定。

大量的代码更改和大量面向人类的文档更改将是没有争议的，并且没有理由在 PR 提交和合并之间强制延迟 14 天或 3 天甚至 3 小时，例如“修复错字” ，超链接到超链接" ...

PR 通常应由熟悉正在更改的事物的人（无论是否是代码）进行审查。 说“w OR ((x and/or y) AND z) will review all PRs for this repo/file/whatever”之类的话似乎是合理的——审查的时间范围可能会随着审查者的工作量而变化当下也是公关目标！

那些潜在的有争议的变化——无论是什么类型的——都应该被那些审查者注意到，他们应该被信任然后请求更广泛的审查，可能包括任何类型的“上级”。

我选择固定期限的原因是，关于 1) 问题和拉取请求的处理速度不够快 2) 问题和拉取请求没有被发布到足以提供输入的机会和合法性的对话。建议因此受到质疑。 没有明确地写下来意味着长期从事 Solid 工作的人比新来的人更有优势，他们不得不猜测参与的潜规则，这使得加入社区不是一个开放透明的环境。

作为一种解决方案，我们是否应该说所有拉取请求和问题在发布后有 3 天的时间来处理？

作为“一刀切”的解决方案，我仍然存在问题。 我认为这会对代码质量和项目进度产生一些不利影响。

首先，没有至少五年不存在的潜规则，这在成千上万个项目中是非常标准的做法。 因此，当然，如果您对整体开发完全陌生，那么您将处于劣势，但这并不是因为 Solid 有什么特别之处，当进入一个新的努力领域时，总会有一条学习曲线。 正如我所说，对我来说，Solid 的入门门槛非常低很重要，但我不确定服务器开发是否是人们应该开始发展他们的技能的地方，以及他们不需要与其他人密切合作的环境相同代码库的开发人员可能更适合他们。

许多（如果不是大多数）PR 自然会有超过三天的审查期，受审查者的可用性限制。 然而，我们自然也在努力争取相对较小且易于审查的 PR。 这样做是一个很好的做法，这样您就可以获得早期反馈，并且对审阅者来说不会太难。 但是，这通常意味着解决更大的任务将涉及多个增量 PR。 如果每个 PR 都需要 3 天的审核期，将会大大减缓开发速度。 如果这是政策，那么我怀疑我们作为开发人员最终不会写小的 PR，而是做一个大的 PR，这样你就不需要为每个 PR 等待三天的审查期。

这将导致更大的 PR 更难审查，背离敏捷开发，并且更大的风险错误将潜入审查过程。

我很想听听其他大型项目在这方面正在做什么，但对我来说，一刀切的方法既不可取，也不可实现。

我很难说，因为我是发布经理，但我认为@TallTed会支持它，这个过程在很大程度上应该由发布经理自行决定。 发布经理必须确保询问最适合的审阅者，根据问题询问适当数量的审阅者，并且在正确数量的审阅者响应批准之前不会发生合并，合并不会如果有更改请求，正确的分支被锁定以强制执行审核流程，可能有争议的 PR 通过某种通知方式引起社区领袖的注意，并且确实，当然欢迎其他审核者这样做，则不会发生也是。

只是想包括社区支持会议对话中的笔记。 这些观点是由 Solid Team 中的不同人提出的：

• 3天的审查期可能会减慢Solid的工作。
• 时间段的实际好处是什么？ 实际的好处是创造一个更加开放的包容性环境，具有透明的决策过程，可以理解和参考。
• 我们要解决的问题是什么？ 还有其他方法可以解决吗？ 我们真正想要解决的是，在进行更改时存在限制，并且他们没有机会提供他们的观点。 时间限制是一种给予机会的方式。 邀请包容性的另一种方法是确保将建议发布在人们可以检查的环境中，例如，可靠/建议。
  – 歧视是副作用而不是根源。
• 包容性和效率之间的界限在哪里？ 实行统治，你需要让做事的人来决定。 几乎没有自主权是我们不应该走向的另一个极端。 精英统治——做统治。 这些理想的实施可能对少数群体有害。

• 让我们努力走在前列。 我们可以从错误中学到什么。 让我们不要像以前那样做所有事情，让我们反思为什么我们正在做我们正在做的事情。 致力于将规范翻译成自然语言。 尤其是当规范不断发展时，很难让它们保持最新。 它可能很长，而且对人们来说更容易阅读，但可能难以咀嚼。 建议尝试在规范中查找主题。 寻找分发查看规范的方式的方法。 多写教程，解决各种问题。 还有一些博客文章解释规范元素的空间。 把它变成可咀嚼的花絮。

• 我们可以删除提交，它们是可逆的，但是，逆转是否可行？ 恢复社区提交的速度很慢，因此需要更长的时间才能恢复。 更难在服务器中恢复，因为项目建立在先前的决定之上。

• 我们所做的与另一个项目没有什么不同。 虽然设定一个时间段和以往的做法不同，但我们要做的是建立一个不同的模型，而以前的模型一直是由同质群体主导的，所以我们是想沿用过去的做法还是力争在边缘思想？ 我们能否从前面的例子中学习如何不落入同样的陷阱并分析什么是有效的？ 我们承诺会有所不同——过去行之有效的方法没有奏效。

• 我们可以区分回购吗？ 如果是这样，怎么做？

• 代码与规则不同吗？ Node solid server 对社会有影响，社区 repo 和 Solid 规范也是如此。 那么如何区分呢？ 很难评估什么会产生社会影响，尤其是当进行评估的专业人员无法访问信息时，因为信息不是他们可以解释的语言。
• 固态服务器是对社会有巨大影响的规范性软件，因此代码决策具有很大的影响。
• 单个拉取请求是微小的更改，不具有该属性。 他们只是在那里进行渐进式的更改，以使我们的思想围绕它进行。 与社会变革不同，因为它们在质量和数量上都不相同。
• 三个规范回购和社区回购应该有更严格的流程，例如定义最短审查期和分配审查员。 该规范具有很大的规范作用。 通过它们可以产生的规范效应来区分回购的好方法。 社区回购和可靠规范属于该类别。 所以有一个透明的合并会很好。

• 可以为 node-solid-server 设置一个混合规则集，说明如果更改偏离规范，则需要更长的审核时间。 我们在代码中实现与规范不同的规范的情况对于有一个流程也很重要。

• 没有记录工作流程和步骤。

• 工程师比非工程师更信任管道。 也许我们相信这一点。 也许有一点。 开发人员文化的人口统计，也许那是因为我们认为这正是它应该的方式。
• 当关键决策实际上具有超越技术的巨大影响时，它们被伪装成技术性的。
• 代码可以对社会产生巨大影响，因此了解这种影响并让人们参与进来非常重要。
• 自然语言——规范在任何情况下都可以使用一些令人耳目一新的东西。 这样做有更好的方法来解释事情。 不会将技术元素重写为非技术元素。 有机会提高规范的可读性以确保它是正确的。 会得到很多回击说技术将被淘汰。
  
  
  
  • 我们需要构建被接受的东西，因此需要被所有人理解。
  
  

@TallTed你对之前评论中的会议记录有什么想法吗？

作为前进的方向，我提出以下建议：

与以下存储库相关的拉取请求和问题需要至少开放三天：
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

与所有其他 repo 相关的拉取请求和问题可以立即关闭，并且没有最短时间必须保持打开状态，除非它们偏离规范，在这种情况下，它们需要至少打开三天。

有异议吗？

为我工作。 也可以在发布经理的角色描述中添加文本，描述他们应该如何处理剩余的存储库。

我也喜欢这个解决方案

@kjetilk是的，我会在https://github.com/solid/community/pull/44中添加注释

@megoth ok 将在社区 repo 自述文件中包含简短描述

https://github.com/solid/community/blob/master/README.md