在 InnerSource 中，规划在两种重要情况下发挥着作用：

贡献团队需要明白，处理上游代码通常比对他们自己熟悉的代码库进行类似的更改花费更多的时间。他们需要意识到这样一个事实：即使主办团队不必实施变革，他们仍然需要接受指导和审查。耗费的时间随所需更改的大小而增加。因此，与主办团队的早期沟通非常重要，特别是在发生较大变更的情况下。

主办团队还需要了解指导和审查所需的时间。简单地告诉贡献团队他们可以将更改作为补丁提交并不会减少主办团队将更改为零的时间。此外，主办团队可能会发现自己处于一种罕见的情况，即他们被大量的拉取请求淹没。对于该事件，需要清楚地了解发送这些拉取请求的项目的业务优先级。当补丁不堪重负时，通常需要考虑共享组件的所有权。特别是定期参与并赢得主办团队信任的贡献者是获得“可信提交者”称号的良好候选人。

不过，由于工作文化略有不同而产生的一些摩擦是不可避免的。此时明确设定期望值就非常重要。

想象一下以下情况：作为贡献者，你最终做出了所需的更改——可能需要主办团队的一点帮助。你自豪地提交了拉取请求。然后——什么也没发生。一天后——仍然没有反应。你开始想知道主办团队是否已经看到了该补丁。你想知道在哪里可以最好地向主办团队传达更新信息。这种沉默非常令人沮丧，尤其对于首次贡献者来说。对于这种情况有几种补救措施——无需编码知识，但至少需要一些基本的沟通技巧：

* 明确主办团队的预期响应时间——例如在贡献文档中。

* 一旦收到拉取请求，就告知收到实质性反馈所需的预期时间，而不是让贡献者等待。

* 为贡献者提供与主办团队的沟通渠道，并在该渠道关注正在发生的沟通。

这些任务都不需要编码技能，这强调了对具有编程知识之外的人员的需求。最好将负责这些任务的人员视为对 InnerSource 项目的承诺，并将他们也视为可信提交者。

=== 小变更与大变更

小的更改和补丁很容易处理——它们可以快速审查，并且在合并时通常不会带来很大的风险。帮助托管团队的方法之一是腾出时间将变更分成更小的块。不过，请确保传达了这些更改所需要的完整背景信息。

通常，做出更大的变更需要尽早传达意图和目的，确保贡献团队和主办团队留出足够的时间来共同应对变更也是很有益的。这意味着设定团队优先级的人在确定变更优先级时需要超越自己的团队视角。然而，协调仍然可以相当独立地进行，因为通常只有贡献团队和主办团队参与。

=== 围绕 InnerSource 项目扩大团队规模

主办团队很少会遇到从贡献团队接收过多补丁的难题。在这种情况下，考虑将可信贡献者发展为可信提交者角色会有所帮助。除了帮助审核，新的可信提交者还可以帮助分流问题、指导新的贡献者等。

当面对大量的贡献意向时，在优先考虑对贡献者的指导帮助时，还有一个因素需要考虑，那就是贡献者是否有兴趣与主办团队建立长期关系。指导所需的时间越长，贡献者就越有可能坚持更长时间。

在实践中，与非常活跃的贡献者共享组件的所有权，已被证明能让新加入的可信贡献者在更长的时间内参与到项目中来。通常情况下，在最初的贡献动机得到满足之后，他们还会帮助保持组件的更新，并长期指导新的贡献者。