人脸关键点及检测 开源项目_成功的开源项目的5个关键方面

人脸关键点及检测 开源项目

我喜欢开源：对我来说，这是开发任何产品，获得新技能，获得乐趣并为社区做出有用的东西的好方法。 我不是开源摇滚明星（至少不是：D），但是我已经创建了数十个项目并为之做出了贡献（请查看我的GitHub个人资料 ）。 他们中有些人有一点关注像WorldEngine ， JavaParser类或EffectiveJava 。 我也是一个狂热的开源用户：几乎每天我都必须选择一些开源程序或库来使用或贡献。 因此，我会定期评估开源项目。 我也很幸运能够与许多开源开发人员保持联系，其中一些我已经在此博客中进行了采访。

因此，我想分享一些我认为对开源项目成功至关重要的方面。

基本原则

我看到的一个问题是，许多开放源代码项目的提交者都缺乏时间：有人对新想法感到兴奋，创建了一个项目，该项目获得了一定的吸引力，过了一会儿，就产生了很多评论堆积如山，问题很长一段时间仍未得到回答，因此新功能永远无法实现。 我没有声称我有解决方案，但我认为我们可以通过以下方法缓解问题：

1. 尽可能实现自动化：一次编写文档，而不是回答同一问题十次，自动运行测试，而不是一遍又一遍地纠正相同的错误，等等。
2. 让更多的贡献者分担维护项目的负担。 为此，您需要创建一个“贡献者友好”项目

为了在实践中转化这些一般原则，我认为需要考虑五个方面。

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

人脸关键点及检测 开源项目