本文发表于CM创始人、Android全局定制之父、开源狂人SteveKlabnik的个人博客，阐述了自己在Github上对Rails的开源服务作者的经验和观点值得国内支持开源的人学习，尤其是筛选问题的算法值得一试。CM创始人：如何成为Github服务于开源的园丁作者做了很多开源工作，但我对开源最有价值的贡献不是写代码。编写补丁是开源中最简单的工作。事实上，除了编写补丁之外，所有其他开源工作都非常困难，例如跟踪错误、管理邮件列表、开发文档以及其他管理任务等等。本文将向大家介绍笔者在开源道路上的经验教训。让我们回到RailsConf2012会议。笔者作为参与者参与了小组讨论。当时Github的rails/rails开源目录下有很多小问题（issues）。数量大约有800个，其中很多还没有解决。所以他们其实很想解决两个问题，一个是如何让这些问题的数量减少，另一个是如何让开源社区帮忙。***，他们认为最好的办法就是组织一个“问题排查小组”，这个小组的工作就是优先解决问题。作者也自愿加入了这个团队。但“问题处理”到底是什么意思呢？好吧，在像Rails这样大的项目中，有很多小错误没有解决，有些只是消失了，有些需要更多信息等等。我喜欢做这种“肮脏的工作”，所以这个项目这时候需要一个“园丁”。他的工作是“除草”，经常定期除草。不过，在讨论如何“除草”之前，先弄清楚你手头的“花园”是什么样的。这些问题是什么？如果你第一次开始一个项目，那么你需要弄清楚问题应该是什么。对于不同的项目，问题是不同的。例如，在Rails项目存储库中，我们的问题仅针对错误修复。我们处理StackOverflow上的问题解决，以及Rails核心邮件列表上的新功能和请求。在Rust项目仓库中，我们会处理issues中的各种问题，比如featurerequests，metaissues...等等。对于其他一些开源仓库来说，解决所有问题是不可行的，可能还有一些开源仓库没有任何问题，比如Sequel。我个人最喜欢的处理开源问题的方法是Rails。理想情况下，你的项目是完美无缺的，你也可以找到一个地方来讨论项目的特点。但其实提前规划好Issues才是开源的第一步。定期护理那么，问题来了，800+的问题你是怎么处理的？我知道的唯一方法是完成所有问题。没错，我就是这么做的：我会在周六或周日花一整天时间，转到Issues列表，然后右键单击以在新的网页选项卡中一个一个地打开所有问题。我将在一个网页中打开31个选项卡，其中包含30个不同的问题（问题），然后重新打开一个新页面。接下来，我进入每个问题并阅读所有内容，包括评论。如果我完成了页面上的最后一个选项卡，我将关闭当前页面，然后转到下一页，解决其他问题，并重新开始！你看，人家说开源是个光鲜亮丽的工作，其实根本不是。如果你为开源工作，你需要用整个周末的时间来阅读800个问题。好吧，无论哪种方式，一旦我完成了所有问题，我就会大致了解我当前的Rails项目遇到的问题类型。好吧，现在我手头有一堆常见问题解答、评论和问题。所以下一步我要做的就是重新做所有的工作。等等，再来一次？为什么？好吧，现在不是我处理问题的时候吗？难道我不应该赶着去工作，去解决真正的问题吗？问题是，在我真正开始解决问题之前，摆在我面前的问题太多了，我可能有很多重复的问题，而且我可能不知道每个问题中哪些无伤大雅的评论，我什至不知道哪些是generalFAQ，简而言之，就是我需要完成的事情，越来越难了。然而，既然我已经把所有的问题都做完了，为了解决上面的问题，我开发了一个算法来得到它：1.这个问题是一个特性请求吗？如果是，复制/粘贴我之前写的答案之一，将它们导入邮件列表，然后单击关闭。2.这个问题是求助吗？如果是，复制/粘贴我写的答案之一，将它们导入StackOverflow，然后点击关闭。3.这个问题是Rails以前版本的问题，而不是当前支持的版本？如果是，请复制/粘贴我曾经写过的答案，并询问是否有人知道某个版本的Rails是否支持这个问题。4.问题是否提供了足够的信息来重现错误？如果不是，请复制/粘贴我曾经写过的答案，并询问是否有人可以提供错误的重现。5.如果这个问题重现了，而且在最新的Rails上没有出现，试试HEAD请求。如果此后问题仍然存在，请发表评论并告诉发布问题的人，情况仍然如此。将是一个问题。6、如果到了这一步，我们就可以判断这个问题现在肯定是一个非常明确的问题了。我会留下一条评论，告诉发布问题的人我会处理它，然后将问题抄送给Rails相关子系统的维护者，以便他们可以找到自己的问题来解决。原文链接：www.leiphone.com/how-to-be-an-open-source-gardener.html
