在最近的一次培训课程中，我讨论了承诺梯度——在项目内部的每个参与阶段之间转换需要付出多少额外的努力。课程结束后，有人向我询问承诺梯度的一些例子，以及如何使其更平缓，从而使人们更容易在项目中取得进展。
此图表示理想的承诺梯度。从了解项目到使用和讨论项目，这一步相当简单。报告错误需要一些额外的知识，例如使用错误跟踪器，但这并不是一个明显更难的步骤。提交补丁稍微难一些，因为它需要编程语言的知识以及对编码风格等方面的了解。最后，进入领导角色需要付出大量的额外努力，因为领导者需要了解项目的所有方面，包括理解治理模型，并获得其他社区成员的信任。
使用软件
此图表示一个项目，该项目的软件非常难以安装，以至于您需要对项目有深入的了解才能使其正常运行。例如，如果配置设置是硬编码的，则设置软件需要语言知识、更改代码，然后在开始之前自行编译。到这时，您对软件非常了解，以至于后续阶段几乎不需要额外的努力，但是大多数人不会费心，您的用户群将会遭受损失。
为了降低此阶段的承诺梯度，项目应使其输出易于获取、安装和配置。例如，在目标平台的软件存储库或应用商店中提供打包版本可以使安装更容易。在不适合使用打包版本的情况下，可以使用需要较少技术知识的自动化安装程序（例如 WordPress 使用的安装程序）作为初学者的选项，并为更有经验的用户提供更可配置的“专家模式”。对于配置，能够通过软件的界面而不是在代码或配置文件中更改设置会很有帮助。
讨论项目
此图表示一个项目，该项目的软件易于使用，但社区具有精英主义态度，并且对新人不友好。对问题的回答假定对软件有深入的技术理解，并且不具备这种理解的人需要自行查找答案，然后再与那些具备理解的人互动。
解决此问题的方法是提倡一种节制和指导文化，以确保讨论以容忍的方式进行，从而使新人能够学习。
此阶段的另一个问题可能是所使用的技术——例如，如果所有用户支持都在 Usenet 新闻组上进行，则许多人将不知道如何访问它们，或者他们应遵循的约定。使用新用户更熟悉的渠道（例如 Web 论坛或社交媒体）可以帮助降低此处的承诺梯度。
报告错误
从讨论项目到报告错误的步骤可能很高，如果项目使用复杂的错误跟踪器，访问跟踪器需要复杂的流程，并且收集提交有用的报告所需的信息需要对软件有深入的了解。
Ubuntu 项目通过使用 ubuntu-bug 实用程序降低了此阶段的梯度。任何用户都可以运行命令：ubuntu-bug <软件名称>，并生成一个模板错误报告，其中包含有关其环境的所有必需信息，以及任何相关的日志或崩溃报告。然后，他们需要做的就是编写问题的描述。同样，节制和指导文化在这里也很有用，可以帮助指导人们编写有用的报告。
提交补丁
提交补丁不可避免地需要付出更多的努力，因为贡献者需要充分了解编程语言、源代码、开发环境等等。但是，如果期望贡献者遵循复杂或文档不完善的编码风格，如果期望他们在提交之前进行大量手动测试，并且如果实际提交过程很深奥，则承诺梯度可能会变得过于陡峭。
降低此处梯度的主要方法是文档化，以及尽可能自动化。编码风格应明确定义并记录在案。应使用单元测试工具自动化测试。提交过程应有完善的文档，使用众所周知的工作流程（例如 GitHub 的拉取请求）可以有所帮助。
Moodle 社区有一个名为“代码检查器”的工具，该工具打包为 Moodle 插件，使开发人员能够分析其代码，以确保其符合项目的编码风格。这使他们能够快速识别和修复提交前的任何问题，并使审阅者能够快速指导他们如何修复任何差异。
掌控全局
同样，此阶段的巨大进步是不可避免的，并且在某些方面是可取的，因为项目可能不希望由没有表现出足够承诺的人来领导。负责人可能还需要遵守法律要求。
但是，对于一个人如何在项目中获得投票权的过度或不明确的要求可能会使此步骤过大，因此这些要求需要公平且有完善的文档。此外，领导者还需要很好地了解项目的治理模型及其决策过程，因此这些也需要有完善的文档。
如果一个项目足够大，则可以在此阶段允许不同程度的承诺，因此并非每个对技术问题有发言权的人都必须做出预算决策。
作者：Mark Johnson，最初发表于 OSS Watch。根据 Creative Commons 重新发布。
2 条评论