记录你的指导原则
Title
记录你的指导原则
Patlet
通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。
问题
该组织正试图在更大范围内推广内源。 该倡议是从开源爱好者发起。现在的目标是获得缺乏开源经验的人的支持。 对于这些人来说，典型的"应用开源最佳实践"的口号已经不足以传递内源是什么、它解决了哪些问题以及它使用哪些工具来解决这些问题的信息。 因此，内源在组织中的采用速度减慢了。 当贡献者开始跨越团队边界时进行协作是， 团队对内源的目标是什么以及如何实施最佳实践产生了疑惑。
故事
在一个组织中的早期实验表明，开源合作的最佳实践可以带来好处。 现在的下一步是将该倡议影响到缺乏开放源码深厚背景的团队和个人。
现在的目标是要清楚地传达内源计划的目标以及实现这些目标的明确路径。
上下文
内源作为一个术语在员工中流传。
该倡议由开源爱好者发起。
约束
团队难以准确地沟通实施内源在哪些方面比较重要。
缺乏开源经验的人无法理解将开源最佳实践引入组织的意义。
在日常工作中，试图遵循内源最佳实践的团队很难决定他们所做的是否符合内源的一般价值观。
解决方案
那些在组织中推动内源计划的人需要帮助那些缺乏深厚开源背景并对内源的缺乏直观理解的团队和个人。
应该通过记录这两个方面来向团队和个人传递清晰的信息。
目的 - 组织为什么要采用内源？
原则 - 哪些内源原则将有助于解决这些挑战？
下面的章节提供了关于这两个方面的更多细节，意味着可以作为你的组织记录这些原则的起点。
为什么该组织要采用内源？
在过去，内源已被证明可以成功地解决组织中常见的几个问题。
然而，您的组织希望使用内源来改善哪些组织挑战？
与其一概而论，不如尝试准确地找出与你的组织的挑战相匹配的解决方案 - 最好是和哪些你想影响的人一起。
其他人通过遵循内源最佳实践解决的一些挑战：
减少由过度地盘意识造成的开发孤岛。
通过促进健康的代码重用，减少解决类似问题的时间，从而提高创新速度。
通过更好的跨团队合作来提升开发速度。
解决项目/团队的依赖性，超越 "等待解决方案 "和 "建立变通办法"，从而减少工程瓶颈。
提高质量。
增加员工的幸福感。
提高新员工的入职成功率。
建立可操作的文档。
哪些内源原则将有助于应对这些挑战？
一旦团队了解内源将帮助他们解决哪些问题，下一步就是解释哪些原则有助于解决这些挑战。
基于基本的开源开发原则，以下准则已被证明是成功的。
(1) 代码必须透明地托管在组织内
源代码、文档、与项目开发相关的数据必须对组织内的任何人都是可用的，并且容易找到。
(2) 贡献大于提交功能要求
一个项目的所有利益相关者都是潜在的贡献者，并被作为贡献者对待和予以支持。 贡献仍然是建议而不是要求。 贡献前的协调有助于避免精力浪费。 项目提供贡献指南以避免摩擦。
(3) 错误是学习的机会
由于工作在整个组织中都是可见的，任何错误都会被所有人看到。 因此，必须建立一种文化，使错误成为学习的机会，而不是应该不惜一切代价避免的失败。
(4) 书面沟通大于口头沟通
对于跨越多个团队的项目，可能会有不同的会议时间表，需要有可能进行异步协作。 内源项目的目标是招募新的贡献者。 为此，未来的潜在贡献者需要能够在以低门槛，自我服务的基础上关注项目的进展。 如果项目的相关交流是通过同步交流进行的，那么所讨论的论点需要在书面渠道中透明化--最终决定应该只在书面渠道确定。 作为一个副作用，这会产生被动记录的基础文档，对任何项目的新人来说都是非常有价值的。
(5) 允许书面建议积累在一个持久的、可搜索的档案中
所有的项目交流，特别是所做的决定和导致这些决定的讨论，都需要被归档。 必须有可能通过稳定的URL来提供参考链接交流。 以往的交流需要以一种容易搜索的方式来储存。
但有两点需要注意:
这并不能取代结构化文档。但它可以作为收集结构化文档的一个起点。
所有的东西都要写出来，而且要让整个组织都能看到，这个规则也有例外。与个人有关的讨论以及与安全有关的讨论是敏感的，不应公开进行。
(6) 奖励 Trusted Committer 人员
所有的贡献（如源代码、文档、错误报告、对讨论的投入、用户支持、营销）都是受欢迎的，并应该得到奖励。 那些对项目表示支持的人将被邀请成为Truested Committer。 一个项目的所有 Truested Committer 都会被公布。
结果
组织成员了解他们可以通过应用内源最佳实践来解决哪些挑战。
缺乏开源经验的组织成员了解内源项目的基本价值和原则。
缺乏开源经验的组织成员能够根据一套共同的既定价值观来检查他们的日常活动。
组织的开发实践变得与开源项目更加相似，从而使组织成员更容易参与到开源项目中。
已知实例
Europace AG
上述解决方案中列出的内源原则大部分是基于Europace公司的经验。 详情见 Europace InnerSource Prinzipien（德语）。
GitHub
目的
在GitHub，我们的工作模式是团队为其职责范围以外的领域贡献功能。常见的例子包括：销售工程部贡献功能以促进销售，特别项目部贡献急需的、对整个产品有高度影响的功能，以及一个团队在多个领域工作以交付一个功能。
原则
总的来说，这份文件中概述的原则是为了避免增加技术债务和项目东道主团队的支持负担。很多时候，为东道主团队提供帮助是因为他们在自己的责任范围内由于支持和维护成本导致忙不过来，而且他们没有相关资源来实现这个功能。任何由其他团队完成的新功能，如果增加了支持负担或技术债务，就意味着东道主团队在新功能上的时间更少了，所以我们要确保他们（贡献团队）做得正确。
同时，我们努力成为一个工程师可以自由地跨边界工作的公司，业务优先事项经常要求我们在我们的核心领域之外的领域作出贡献。
对这些原则的一个很好的总结是，离开这个领域时要和你发现它时一样好，甚至更好。
考虑到这一点，以下是我们同意的原则。
避开累积功能债务的最小可用产品（MVP）。为了获得客户的反馈，发送一个MVP是可以的，但是贡献团队必须致力于完成功能集。这方面的例子包括。
承诺超越MVP，形成一个能满足大多数客户的解决方案。
完全支持对新功能的管理（例如，在设置的用户界面中支持，而不是只做命令行）。
在UI和API中展示功能，而不是只提供API（或反之）。
确保功能在云和本地服务器环境中工作。
对功能提供不局限在部署到生产环境中支持。
协调渐进式的推广
处理支持任务单
计划好时间来处理客户的反馈（功能和bug）
以正确的方式构建功能（不要积累技术债务）
与产品和工程团队就需求和解决方案达成共识
合理的架构和设计
确保数据被正确存储，以避免以后的数据迁移。
具有适当的遥测技术
具有适当的测试覆盖率
在云和本地生产环境中得到支持（包括设置、配置、备份/恢复、迁移等）
修复错误
更新文档
参与
我们之所以使用参与模式，是因为我们喜欢让团队在为其职责范围以外的领域贡献功能时，可以采取哪些具体步骤。
在GitHub，一个典型的参与模式是这样的。
获得产品负责人对功能集和推广计划的批准。
获得工程负责人（通常是工程经理和总监）对工程设计的批准，包括解决非功能需求（遥测、测试覆盖、多环境测试和支持）。
沿途进行代码审查，同时审查任何新的或改变的需求。
Robert Bosch GmbH
目的
促进合作、学习和创新是 Bosch 内源计划（BIOS）的主要重点。
原则
为此，Bosch 采用了以下原则。
开放性：我们尽可能地降低进入BIOS社区的门槛。
透明度：我们是完全透明的，与公司所有员工分享我们的工作成果、我们的沟通和我们的决策。
自愿：加入BIOS社区并为之做出贡献的决定是由每个员工自己决定的。员工应该在 BIOS 工作，因为他们有内在的动力，而不是因为他们的经理告诉他们这样做。
自我决定：BIOS社区可以自由选择工作内容、工作时间以及工作工具和流程。
任人唯贤：BIOS项目成员的权力是基于他们的功绩，也就是基于他们贡献的质量和数量。
开放、透明 和 自愿 的原则有助于发展由内在动机的同事组成的多样化社区。 事实证明，任人唯贤 是做出巨大贡献的有效激励。 自我决定 使社区能够以最有效的方式利用他们有限的时间来做出贡献。
状态
结构化
作者
Isabel Drost-Fromm
Georg Grütter
致谢
Zack Koppert - for sharing GitHub's approach in the Known Instances
别名
明确的内源原则
翻译校对
最后更新于
