目录
模式
30天保修 - 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
Trusted Committer - 许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。
不要吝啬对参与者的夸奖 - 及时感谢贡献者对内源项目贡献的时间和付出是很重要的。 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。
专职的社群领导 - 选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。
交流工具 - 一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
代码仓活跃度评分 - 潜在的贡献者希望找到需要他们帮助的活跃的内源项目。通过计算每个项目的代码库活跃度评分，可以创建一个项目的排名列表（例如在内源门户网站上），这样潜在的贡献者可以更容易地确定他们想要贡献的项目。
以实验的方式开始 - 将内源实践倡议作为一个有时间限制的实验开始，使不熟悉内源的管理人员更容易认可和支持该倡议。
共同的需求 - 共享代码库中的通用代码不能满足所有想要使用它的项目团队的需要；这一点可以通过需求调整和重构来解决。
内源许可证 - 属于同一组织的两个法律实体希望彼此共享软件源代码，但他们担心在法律责任或跨公司会计方面的影响。
内源门户网站 - 潜在的贡献者很难找到他们感兴趣的内源项目。你可以通过创建一个索引所有可用的内源项目信息的内部网站，可以让贡献者了解他们可能感兴趣的项目，也可以让内源项目的负责人发展外部受众。
利用RFC进行透明的跨团队决策 - 内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。
基准级的文档 - 内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
成熟度模型 - 各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
服务 vs. 库 - 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
核心团队 - 即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
签约贡献者 - 想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。
记录你的指导原则 - 通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。
评审委员会 - 对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。
跨团队的项目评估 - 要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。
问题追踪器使用案例 - 内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。
零工市场 - 建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
附录
资源
最后更新于
