Comment on page
目录
内源模式脑图
- Trusted Committer - 许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。
- 代码仓活跃度评分 - 潜在的贡献者希望找到需要他们帮助的活跃的内源项目。通过计算每个项目的代码库活跃度评分，可以创建一个项目的排名列表（例如在内源门户网站上），这样潜在的贡献者可以更容易地确定他们想要贡献的项目。
- 利用RFC进行透明的跨团队决策 - 内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。
- 基准级的文档 - 内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
- 服务 vs. 库 - 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
- 核心团队 - 即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能 够增加和使用满足他们自己使用场景需要的特性。
- 评审委员会 - 对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。
- 零工市场 - 建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员 工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
- 额外