| 关注 @mchua
美国，印第安纳州
Mel Chua 是一位极具感染力的热情黑客、作家和教育家，拥有超过十年的教学和课程开发经验，并在 Red Hat、One Laptop Per Child、Sugar Labs、Fedora 和其他自由、开放和开源软件 (FLOSS) 社区的领导职位上有着良好的记录。作为普渡大学的研究生，Mel 将对成功社区的学术研究与她亲身实践构建它们的深刻经验相结合。
如今，Mel 将大部分时间投入到教育领域的开源工作中，教授教授们如何教授开源，并努力将围绕学习和教学的成功开源文化习惯的补丁“上游”推送到学术界的课堂中。在她假设存在的空闲时间里，她收集古怪的教科书，致力于本科工程教育改革，并弹钢琴，偶尔同时进行。
撰写评论
说得对 - 我应该区分一下。最初的演讲是面向开发人员的（我自己也是一名工程师），所以我心中想的是开发人员文档；在任何技术项目中，我最讨厌的事情之一是很少有工程师让其他工程师测试他们的文档，然后想知道为什么没有人可以与他们的组件交互或扩展他们的组件。
记录代码的目的和所做决策背后的理由也是一个非常好的观点。我见过很多年轻的开发人员加入一个项目，然后说“他们为什么要使用 $technology_foo？他们一定是白痴；为什么不使用 $technology_bar - 我可以在 2 小时内用 $technology_bar 重写它！”（或类似的东西），然后与年长的开发人员交谈，了解到该产品是在 $technology_bar 不稳定时编写的，或者为其制作产品的客户坚持使用 $technology_foo，然后证明 $technology_bar 在十几个用户后崩溃，并且无法移植到不同的浏览器并且不可扩展，等等。
版本控制和保留会议记录（在其中记录这些类型的辩论和决策）是帮助跟踪此问题的好方法，因为不，当您签入代码时，您的逻辑和决策过程不会神奇地嵌入到您的代码中。
（对于那些不知道的人：我也是 Sugar Labs 的人，Scott 也是/曾是。）
这是开源做事方式的一种半实现，导致了工具崇拜。因为，按照开源原则，你不能告诉别人<em>不要</em>使用工具，你会有几十个人有几十个首选的实现，所有人都能够实现它们。其他人可以尝试它们，最终最好的解决方案将获得更多的追随者（呃，理想情况下）。这很好 - “谁做，谁决定。”
社区可以决定授予一个人（项目负责人、基础设施团队负责人等）“祝福”一个实现为“正确方式”的权力，这也很棒。但它也可能很危险 - “谁做，谁决定”可能会变成“谁决定，谁做” - 这些领导者基于个人特有的偏好而不是对项目有利的共识来选择实现，不给其他想法一个扎根的机会，并让每个想参与的人都使用他们决定的任何东西。
我很难表达这一点，因为从不同的角度来看，争论的双方听起来都完全合理……我认为我们在 SL 的基础设施方面可能遇到的问题是未能使其易于 fork，这导致了对工具的焦虑和斗争，而不是为实现 SL 的核心目的而进行的富有成效的工作。
但这就是争论的核心，我怀疑这就是 Scott 和我感觉我们所做的事情的原因 - Sugar Labs 的核心竞争力<em>不是</em>建立协作基础设施。实际上，对于 99.9999999% 的项目和小组（无论是否是开源软件），项目的目的不是托管邮件列表，而是完成<em>其他事情</em>（在这种情况下，为孩子们制作软件环境）。
所以，是的。让别人来做。使用开放工具，以便在需要时可以修改其他人所做的工作 - 但让其他人为您做这项工作。