移动端开源项目_在开源项目的各个阶段之间移动

移动端开源项目

在最近的培训课程中，我讨论了承诺梯度–在项目的每个参与阶段之间进行转换需要花费多少额外的精力。 会议结束后，我被要求提供一些承诺梯度的例子，以及如何使承诺梯度变浅，从而使人们更容易地参与项目。

该图表示理想的承诺梯度。 从了解项目到使用和讨论该项目是微不足道的。 报告错误需要一些额外的知识，例如，使用错误跟踪器，但并不是很难的步骤。 发行补丁要困难一些，因为它需要编程语言的知识和对诸如编码风格之类的知识的了解。 最后，要成为领导者角色还需要付出大量的额外努力，因为领导者需要对项目的各个方面都有意识，包括对治理模型的理解，以及获得其他社区成员的信任。

使用软件

此图表示一个项目，其中软件很难安装，因此您需要对项目有深入的了解才能使它正常工作。 例如，如果配置设置是硬编码的，则设置软件时需要了解语言，更改代码，然后甚至在开始之前自己进行编译。 至此，您已经非常了解该软件，因此接下来的步骤几乎不需要额外的工作，但是大多数人都不会打扰，您的用户群也会因此受苦。

为了在此阶段降低承诺梯度，项目应使其易于获取，安装和配置其输出。 例如，在目标平台的软件存储库或应用程序商店中具有打包的版本可使安装更加容易。 在不合适的情况下，可以将几乎不需要技术知识的自动安装程序（例如WordPress使用的自动安装程序）用作初学者的选项，并为经验丰富的用户提供可配置的“专家模式”。 对于配置，能够通过软件界面而不是代码或配置文件来更改设置是有帮助的。

讨论项目

该图表示一个易于使用软件的项目，但是社区持精英主义态度，对新来者怀有敌意。 对所提问题的回答假定对软件具有深刻的技术了解，而没有这种了解的人应该在与从事软件的人接触之前先发现自己。

解决方案是促进节制和指导的文化，以确保讨论以宽容的方式进行，以使新来者能够学习。

此阶段的另一个问题可能是所使用的技术，例如，如果所有用户支持都在Usenet新闻组上进行，许多人将不知道如何访问它们，或者期望遵循这些约定。 使用新用户将更熟悉的渠道，例如网络论坛或社交媒体，可以帮助降低此处的承诺梯度。

报告错误

从讨论项目到报告错误的步骤非常重要，其中该项目使用复杂的错误跟踪器，涉及到访问跟踪器的相关过程，并且收集提交有用报告所需的信息涉及以下方面的知识：该软件。

Ubuntu项目在此阶段通过使用ubuntu-bug实用程序降低了梯度。 任何用户都可以运行以下命令： ubuntu-bug <software name>并生成包含有关其环境的所有必需信息以及任何相关日志或崩溃报告的模板错误报告。 然后，他们所要做的就是编写问题描述。 同样，这里有节制和指导的文化，对引导人们撰写有用的报告很有用。

提交补丁

提交补丁程序不可避免地需要付出更多努力，因为贡献者需要对编程语言，源代码和开发环境等有足够的了解。 但是，如果希望贡献者遵循复杂的或记录较差的编码样式，如果希望他们在提交之前进行大量的手动测试，并且如果实际的提交过程很深奥，则承诺梯度可能会变得过大。

降低梯度的主要方法是进行文档编制，并在可能的情况下进行自动化。 编码样式应明确定义并记录在案。 应使用单元测试工具使测试自动化。 使用GitHub的pull请求等众所周知的工作流程，提交过程应有充分的文档记录，这可以为您提供帮助。

Moodle社区有一个称为“代码检查器”的工具，该工具打包为Moodle插件，允许开发人员分析其代码以确保其符合项目的编码风格。 这样一来，他们可以在提交之前快速识别并解决所有问题，并允许审阅者快速指导他们如何解决任何差异的说明。

负责

同样，在此阶段进行大幅度的升级是不可避免的，并且在某些方面是可取的，因为一个项目可能不希望由没有表现出足够承诺的人来领导。 负责人也可能要遵守法律要求。

但是，对于人如何在项目中获得投票权的要求过高或不清楚，可能会使这一步骤变得过大，因此，这些要求必须公道并有据可查。 同样，领导者将需要对项目的治理模型及其决策过程有很好的理解，因此也需要对这些文件进行充分的记录。

如果一个项目足够大，则在此阶段可以允许不同程度的承诺，因此，并非每个人都需要在技术问题上有发言权，例如，可以做出预算决定。

由Mark Johnson撰写，最初发表在OSS Watch上 。 使用知识共享重新发布。

翻译自: https://opensource.com/business/14/3/open-source-project-commitment-gradients

移动端开源项目