刘易斯·考尔斯 (He/Him, They,Them,Theirs)

将此推给制造商是个好主意，他们应该更加努力地确保用户可以使用他们购买的设备。 我认为最大的问题将是制造商将固件作为计划报废的驱动力（有点像 iPhone 在新 iPhone 发布之前变慢一样）。

作为一个可能被认为是有点脾气暴躁的人。 我宁愿与 1000 个脾气暴躁但有道理，而不是抽象的意识形态偏差的人打交道，也不愿与 1000 个只是同意和点头的可爱的人打交道。 说得粗俗一点，在我看来，参与自吹自擂比持续抱怨更糟糕。

共识确实枯燥乏味。 虽然我们都需要一定程度的共识作为我们构建的基础，但这并不是一个可以永远陷入其中的非常有创新性的状态，正如分歧同样是一种不受欢迎的永久状态一样。

通常，“工作”和/或“被采纳”被视为目标，“但接下来呢？” 是我希望看到更多人提出的问题。 这远不如“被批评”、“收到反馈”以及如何处理这些问题那样是一个伟大的标志或激励因素。

我想赶紧补充一点，反馈不一定是批评，但作为赞扬的问题是我从未见过的（如果你们知道，请指出一个）。 我认为作为文档的问题是一个更强大的想法。 但是，我喜欢忽略社区准则的 PR（如果许可证强制要求回馈，那并不意味着它必须遵循社区准则，或者必须合并到主线）。

真正让我恼火的是当意图被假设或强制执行时。 “这是一个 PR”，不是“这是下一个可发布的版本”。 “这是一个问题”，不是“你必须拥有这个，我现在控制你的产品”，或者“这是一个错误”。 我看到的绝大多数问题都是问题（可能这就是 github 默认有一个问题标签的原因）。

许多项目的反应方式就像客户提交了一个没有预算的变更请求一样。 社区变成了所有贡献者都致力于战斗的三头野兽。 我们在流行的解决方案（如 Github）中内置了“wontfix”、“需要帮助”等标签。 我们可以为不听话的 PR 创建更多类似“需要测试”的标签。

普遍的共识似乎仍然是“表现得像你在 90 年代的微软工作一样”。 贡献者都架起虚拟榴弹炮来防御传入的通信，关闭未合并的问题，而不是附加实际上贡献更多的标签，并且更有可能在默认仅搜索未解决问题的系统上找到。

“我们不想按照问题 {x} 的方向发展，已关闭”，对于智力来说，就像月球土壤对于生命一样。 问题在很大程度上不是程序员的工作请求。 PR 更像是“这是我做的事情”而不是“看看我的新车”。 如果你涉足问题是你的积压工作，那么你遇到的问题比它是否勾选了 CLA、贡献者指南中的许多框，或者它是否遵循了模板更大！

我必须承认，我现在通常只是耸耸肩就过去了，但我很想在一个即时感觉少一些，深思熟虑多一些的世界里醒来。