在上一篇文章中，我们已经概述了为什么要重用组件并成为活跃的贡献者。本文将与你分享如何成功地将更改提交到项目团队的代码库。
一个 InnerSource 贡献者试图对项目维护团队做出贡献，本质上就是项目维护团队的客人。一般来说，一个好的客人应该有特定的行为方式：
● 敲门。
● 预测并遵守家规。
● 明白自己不是房主，并据此行事。
这些如何适用于 InnerSource 项目？
进入
拜访邻居时，即使门开着你也不会未经敲门或按门铃就擅自进入。同样的，身为 InnerSource 的房客你将无法（或被邀请）直接将代码提交到代码库中。
相反，在你对代码库进行更改后，你将以拉取请求（Pull Request）的形式提交它们。就如同你不会对你的邻居家做很大的改变或改进，在 InnerSource 你将预知并遵循项目的协作准则。反之，你的主人将花时间向你介绍房间 — 翻译到 InnerSource 场景下，是Truested Committer花时间来指导贡献者。
你参加的那些可爱的夏日派对是怎样的？它们通常有提前的计划来选择合适的日期和时间，来准备足够的食物，或让客人贡献食物。在 InnerSource 项目中发生的更大的变化也是如此：一个项目可能会要求你在进行大修改之前提交一个问题，描述你的需求和解决方案。在初始设计上花点时间，而不是直接实现，这样可以避免贡献者花大量时间去返工。早点分享进展——即使还没有完成——这样有助于项目团队指导贡献者得到更好的解决方法。就像 Yonik关于未完成补丁的定律 Yonik’s law of unfinished patches 一样：“Jira中一个不成熟的补丁，就算它没有文档、没有测试、没有向后兼容性，也远比没有补丁要好。”
这是否意味着 InnerSource 项目不需要面对面交流？不完全是这样：面对面会见参与者是有价值的。请记住，所有书面交流都比不上面对面交流：没有手势，没有模仿，甚至连帮助理解的语调都没有。面对面会议对于人与人之间的挑战、解决冲突和误解尤其有价值。然而，关于项目的决策沟通则应该以书面形式进行，这样其他人可以跟随并影响项目，甚至在几年后也可以追溯为什么做了某个决策。
这是我的经验法则：可以边喝咖啡边见面。这通常有助于建立一个更强大的团队，特别是当团队被分割到不同地方时。确保所有的决定都是以透明和异步的方式做出的，这样每个人——包括那些 潜伏 lurking 在你谈话中的人——都能参与进来成为积极的贡献者。在 开放组织工作簿 Open Organization Workbook 中的几个练习中说明了关于一个人可以在多大程度上进行开放式决策的一个例子。
现在，如何确定 InnerSource 项目想讨论项目的变化和未来方向？许多 InnerSource 项目在 README.md 中概述了他们希望潜在贡献者来接近他们。如果文档太大无法处理，贡献准则往往会被拆分为名为 CONTRIBUTING.md 的文件。遵循这些建议将极大的帮助贡献者提供他们的信息。
在所有这些互动中，都要准备好向项目团队“推销”你的贡献。阐明贡献将给他们的生态系统带来价值。
项目团队将接管你的代码进行维护。你得保证有 _30天保修 _ 在你的提交记录里。这将缓解项目团队对于贡献者贡献代码以后不进行后续的bug修复的担心。
预测并遵守内部规则
当你去拜访你的邻居时，他们可能会带你到他们的公寓里转转：他们会带你去他们的客厅和洗手间的位置。如果你待的时间更长，他们会给你更多的细节：就我而言，举一个例子就是避免同时打开洗碗机和电水壶，以免保险丝烧断。
同样，每一个软件系统都有自己的怪癖和复杂性。最明显的例子往往都有详细的记录。在较小的项目中，此记录可以在 README.md. 中找到。在较大的项目中，详细的贡献文档通常可以在 CONTRIBUTING.md 中找到。
在这些文件中，你可以找到有关如何签出和构建项目、如何运行测试套件、如何向项目提交更改的信息。如果某些工具的使用方法与常规不一致，或者在修改代码过程中需要注意一些事情，那你还需要参考其他的文档。
浏览这些文档通常会节省大量的时间，因为它会防止你走错路，并提醒你注意死胡同。如果根据你的经验，你发现它缺少一些东西，那么通常非常欢迎对该文档进行修补：没有比第一次看到该项目的新贡献者更适合更改它的人了。
如果你所想到的改变总体上是有意义的，试着在他们喜欢的沟通渠道一起找出答案。刚开始，在公司的公共媒体上进行这些对话是很可怕的，因为这些对话都是可以存档和搜索的。但这样做的好处是其他人也会跟着提出类似的建议：他们不用再走完全相同的道路，而是可以从这里学习已经讨论过的内容。
明白他们不是房主，并采取相应的行动。
作为一个贡献者，本质上意味着比仅仅请求一个特性的人更接近项目维护团队。尽管如此，贡献者并不对他们所贡献的软件项目负责。
因此，关于贡献必须是什么样子的最终决定是与项目维护团队一起做出的。它有助于以谦逊的心态接近项目维护团队，假设所有人都朝着共享组织的目标协作。它有助于做到公开和透明——不仅是关于实施了什么和如何实施，还有为什么需要改变。
把任何反馈都当作礼物：其他人正试图改进你的解决方案，使你在后面的道路上免于麻烦。
项目维护团队有可能根本不接受你的贡献。在这种情况下，和团队合作会有帮助，找出你的需求中是否有一个子方面可以在他们的项目中解决。在这个子方面上进行协作，然后找到另一种方法来解决剩下的问题。
本节小结
在本节中，我们学习了如何以贡献者的身份最佳地处理 InnerSource 项目。我们还研究了如何最好地传达我们对更改的需求，并与项目团队一起制定解决方案。
