人脸关键点及检测 开源项目
我喜欢开源:对我来说,这是开发任何产品,获得新技能,获得乐趣并为社区做出有用的东西的好方法。 我不是开源摇滚明星(至少不是:D),但是我已经创建了数十个项目并为之做出了贡献(请查看我的GitHub个人资料 )。 他们中有些人有一点关注像WorldEngine , JavaParser类或EffectiveJava 。 我也是一个狂热的开源用户:几乎每天我都必须选择一些开源程序或库来使用或贡献。 因此,我会定期评估开源项目。 我也很幸运能够与许多开源开发人员保持联系,其中一些我已经在此博客中进行了采访。
因此,我想分享一些我认为对开源项目成功至关重要的方面。
基本原则
我看到的一个问题是,许多开放源代码项目的提交者都缺乏时间:有人对新想法感到兴奋,创建了一个项目,该项目获得了一定的吸引力,过了一会儿,就产生了很多评论堆积如山,问题很长一段时间仍未得到回答,因此新功能永远无法实现。 我没有声称我有解决方案,但我认为我们可以通过以下方法缓解问题:
- 尽可能实现自动化:一次编写文档,而不是回答同一问题十次,自动运行测试,而不是一遍又一遍地纠正相同的错误,等等。
- 让更多的贡献者分担维护项目的负担。 为此,您需要创建一个“贡献者友好”项目
为了在实践中转化这些一般原则,我认为需要考虑五个方面。
1.自动化测试
我认为自动化测试通常在软件开发中非常重要,但是对于开源来说,它们尤其重要,因为它们提供了一种自动评估贡献的方法。 在我所有的项目中,我都使用某种工具进行持续集成:每次收到拉取请求时,都会自动运行测试,并且如果所有测试均通过新补丁或需要修复某些问题,则符号会清晰显示。 很棒,因为它可以帮助新的贡献者获得信心。 它还可以帮助贡献者减少时间,以减少花费在代码审查上的时间:测试已经保证了最低质量标准。 这样,审阅者可以将精力集中在其他方面,例如架构一致性和对样式准则的尊重。
2.文件
我知道,没有人喜欢写文档,但这出于各种原因是必须的。
首先,这是在导致讨论的讨论之后很长时间传达决定的一种方法。 今天,我与其他贡献者讨论我项目中的某些设计决策,将其写下来,从现在起六个月后加入的新贡献者可以阅读它。 这有助于保持项目的体系结构完整性。
还有一些用户只是想从项目中受益。 没有文档阅读,他们要么永远不会采用您的项目,要么不断地问同样的问题。
重要的是要了解针对不同的读者有不同类型的文档。 主要两个是用户和贡献者。 对于用户文档,我建议使用readthedocs ,对于贡献者,我通常使用某种形式的Wiki。 某些域也有特定的格式。 例如,java库应该像对JavaParser一样使用javadoc。
3.React性
几天前,我收到了一封电子邮件,内容涉及三年前我为一个Eclipse项目报告的一个错误。
这是我收到的关于此问题的第一条评论:该问题可能不再存在,我无法帮助确认这一点,因为与此同时,我停止使用Eclipse。 这是因为在报告该错误后三年内我得到了第一个答案。
为问题提供适当的解决方案可能很困难,并且需要我们立即花费的精力。 但是,我认为及时响应用户的请求,问题和错误报告至关重要,也许只是承认我们已经收到他们的消息并且我们将对此进行调查。 如果我们不这样做,那么用户将感到面临一个死项目,而没有人可以帮助或开发该产品。
我意识到这比说起来容易得多,而且我承认我参与的项目中存在的问题开放时间过长。 但是有时仅提供一个简短的部分答案会有所帮助,在我简短回答几次后,用户本身提供了解决方案并最终成为参与者。
无论如何,如果您在两年半后仍回覆,将会有比您做得差的项目…
4.社区
如果您做的正确,那么您的开源项目应该恰好解决了一个问题。 通常,您的项目可能是解决更大问题(可能是工具链的一部分)的更大解决方案的有用部分。 通过找出哪些其他相关项目,您可以找到相互协作并互利的方式,从而提供更多价值。
例如,我们构建了一个名为WorldEngine的伟大世界生成器,我们意识到生成的地图可以在平铺游戏中使用。 因此,我们发现Tiled是平铺地图的出色编辑器,它具有自己的名为TMX的格式。 有许多用于处理许多编程语言的TMX文件的库。 我们知道,为我们的世界生成器编写一个到TMX的导出器将允许许多游戏设计师使用我们的项目,因此我们开始着手研究。
我们在Tiled论坛上进行了讨论,并获得了有用的反馈。
寻找相关项目并开始合作可以增加所有涉及项目的价值,并导致混合贡献者。 它基本上意味着新的活力,新的想法和新的用户。
5.接受新的贡献
当您开始从事开源项目时,您会感到非常兴奋,看到您的孩子长大了,真是令人惊讶。 到那时,您已经非常重视它,并且您希望对其保持控制,请确保它根据您的想法发展,并且仍然是您的项目。 我认为您应该尽早让其他人参与进来,并放弃尽可能多的控制权。 至少有两个原因。 第一个是其他人也有很好的想法 。 如果您没有为贡献者提供空间来提出想法和改善项目,那么您的时间和精力将受到限制。 第二个方面是您希望您的项目能够生存。 希望您不会很快撞上公交车,但是由于新工作或者也许您开始专注于其他一些开源项目,您可能会减少用于该项目的时间。 如果其他人可以在您下台时使该项目继续运行,那将是非常好的。
我知道很难控制自己,但是我认为有必要扩大您的项目。 例如,WorldEngine诞生于合并两个项目:土地(这是我的小项目)和由Bret Curtis创建的WorldSynth。 我们合并了我们的项目,并开始一起维护WorldEngine。 最终,我们得到了其他人的惊人贡献。 这是不完整的列表:
- 埃文·桑普森(Evan Sampson)为霍奇里奇(Holdridge)生活区模型的惊人实现做出了贡献,并大大改善了古代地图,生物群落,降水和温度产生器。 太感谢了!
- Ryan贡献了Windows二进制版本,并讨论了Reddit上的Lands带来了很多用户。 太感谢了!
- stefan-feltmann制作的Lands依靠枕头而不是PIL(已弃用)。 转换为Python 3时,这也可能有所帮助。谢谢!
- 罗素·布林克曼(Russell Brinkmann)帮助将生成参数保存在生成的世界中(例如,以便我们可以再次使用它生成同一世界),改进了命令行选项并添加了跟踪信息(有助于理解各个生成步骤的性能)
- 约书亚·科波拉(Joshua Coppola)实现了卫星视图。 非常感谢,它看起来很漂亮!
- 斯蒂芬让WorldEngine大量使用了numpy,从而有助于加快生成速度。 他还提高了世界代的可复制性,并帮助改善了与Python 3的兼容性。
之所以可能是因为我们愿意接受新的贡献。 当然,WorldEngine不是我自己的小项目,我可以控制每个单独的决定。 它是由一个社区拥有的,也许是一个小社区,但绝对可以为社区带来比我自己更好的东西。
结论
这些只是我运行开源项目时应考虑的一些方面。 我尝试着停留在实践方面并提供示例,但是我确信还有很多其他方面我没有涉及。 我建议您看一下有关开源问题的采访,以及有关使您的项目对新手友好的帖子。 这非常重要,因为在此过程中您将需要帮助。
我认为开源项目主要由专业人员运行和使用。 参与开源项目越来越成为评估开发人员的一种方式。 虽然参加者胜过不参加者,但我认为这还不够:我们应该将与日常工作相同的专业精神应用于开源项目。 附加的约束是在几个项目之间分配有限的时间。
这并不容易,而且我个人认为我有很多方法可以改进。 我只是希望这份清单可以帮助您和我使我们的项目做得更好。 我很想听听您关于开源的故事。
翻译自: https://www.javacodegeeks.com/2016/01/5-key-aspects-successful-open-source-project.html
人脸关键点及检测 开源项目