InnerSource的原则

开放式项目的配置可以实现无摩擦贡献。项目应该通过在主仓库的 README.md 和 如何贡献.md中被发现，并得到良好的文档记录。 组织中的任何人都应该能够找到想要的项目，并且不需要过多的来自维护团队(host team)成员的直接指导。 维护团队的联系信息应该在对项目有意义的尽可能多的渠道中流行。宿主团队接受来自内部的对项目的贡献的意图应该通过相关组织渠道来共享，以提高意识。 特别是在较小的设置中，您可能希望在您的团队正在进行的内部源工作上建立一个定期的“广播”。 但是，在较大的环境中，这样的广播可能会产生很多噪音，而且更适合确保项目可以在一个易于使用的工具中被发现。 记住，我们的目标是让员工意识到，要利用 本公司 的适当渠道。

以上绝不是一份详尽的清单。项目的开放性通常与项目内部资源的成功程度直接相关。 它越开放，对潜在的贡献者设置的障碍就越少。它越不开放，任何人就越难做出贡献。

为了让调用团队(guest team)能够对项目做出有意义的贡献，维护团队必须是透明的。这意味着调用团队应该能够理解:

在可能的情况下，从团队对项目的内部定义到特定于项目的特殊情况场景，都应该清晰而详细地传达上述内容。 这种沟通应该以一种容易被非核心团队成员查询和理解的方式进行。

通过 Trusted Committers ，从维护团队到调用团队的 辅导（Mentorship） 是InnerSource的一个关键方面。 调用团队中的 贡献者（Contributors） 被提升，这样他们就足够了解维护团队的项目/仓库，从而能够成功地更改它。 在这个过程中，他们作为项目/软件的一般用户和负责人，更好地理解了维护团队的软件系统。 随着时间的推移和经验的积累，这个独立的贡献者可以在项目中扮演更广泛的角色，成为一个Trusted Committer。

重要的是，维护团队应该 优先考虑（Prioritized） 这种对贡献者的指导。 维护团队应该努力在贡献者需要的时候，而不是在维护团队方便的时候， 抽出时间来指导调用团队的贡献者。有时，对于维护团队的工程师来说，花时间帮助其他人编码而不是自己编码可能是一种文化上的改变。 这种指导对个人贡献者和主导团队都很有价值，值得好好做。从长远来看，这对双方都是有利的。通过改进代码，贡献者可以扮演原有组织中不存的职责或者角色。 开源很容易认识到这一点，并将其视为在项目中成为Trusted Committer的荣誉。

第一个词 自愿（Voluntary） 是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。 调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。 维护团队从来没有被要求接受与他们的整体任务不一致的贡献。调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。 第一个词“自愿”是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。维护团队从来没有被要求接受与他们的整体任务不一致的贡献。 调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。

代码（Code） 这个词强调的是协同方和主导方之间在代码上的顺畅协作。在开放问题、更新需求、修复文档等方面的客户参与是好的， 但是协作需要达到提交代码以实现我们讨论过的所有好处。