俗话说，“你只有一次机会留下第一印象。” 这句话虽然老生常谈，但仍然是合理的、实用的建议。
在开源领域，它可能会决定一个项目的成败。这就是为什么当您向世界发布一个代码仓库时，留下积极的第一印象至关重要——至少如果您的动机包括获得用户、建立贡献者社区以及吸引有价值的反馈。
最初印象
当我在 2016 年 1 月担任 Zalando 的开源布道者时，我接手了一个 GitHub 组织组合，它跨越三个组织和 360 多个仓库。深入研究后发现，其中许多仓库在文档、可用性（主要是因为与我们的内部系统耦合太紧密）或新用户和贡献者的入门指导方面并没有提供太多。很少有项目包含贡献者指南、安装和配置说明，或提供对项目目的的清晰了解。
正如我在我的上一篇文章中详细介绍的那样，我对我们的仓库的第一印象并不完全积极。从那时起，我们的团队取得了很大进展。我们为未经测试的项目建立了一个单独的“孵化器” GitHub 组织（它也充当档案库）；修订和改进了我们的文档；并添加了缺失的文件，仅举几例我们为讲述更引人入胜的故事和创造更积极的第一印象而共同做出的努力。这项工作仍在继续，因为我们不断迭代和编辑。
作为一名从事新闻和写作多年的从业者，我倾向于从讲故事的角度思考。故事通常有开头、中间和结尾。
在仓库层面，项目“结尾”的概念与开源对演进的强调不符；希望一个项目能够尽可能长久地存活下去。但是，关于项目从何而来、现在做什么以及将走向何方的指示，对于潜在用户、贡献者和同行来说是非常有价值的信息。为此，您的项目需要一个可靠的 README 文件。这意味着它将包括
- 一个介绍段落（“开头”），它清晰地描述了项目的目的和功能，以及关于它不做什么的一些细节（以便将其与其他类似项目放在一起进行比较），以及它是否已证明可以在生产环境中工作；
- 一个详细的“中间部分”，涵盖基本的安装/使用/配置信息；
- 一个开放的“并非真正的结尾的结尾”——即，关于项目下一步和计划的详细信息，以及邀请其他人贡献和影响项目方向的邀请
在组织层面，应用基本的讲故事原则也是一项有价值的练习。它可以引导您质疑您的整体产品是否连贯一致，以便不属于您组织的人可以查看您在那里存储的内容，并在点击离开时清楚地了解您与 OSS 相关的动机和文化。
这就是采用并遵守一套最低标准可以提供帮助的地方。例如，如果您的开发团队同意在仓库上线之前包含详尽的 README 文件、维护者文件、贡献者文件、许可证文件和开发状态，那么该决定的结果将从外部反映出您的组织重视一致性和掌握基础知识。
另一方面，如果您的仓库缺少其中一些基本要素，那么一个在您的 GitHub 组织中闲逛的访问者——无论是为了应聘工作还是其他原因——可能会得出负面结论。也许是因为您的组织不重视文档，导致开发人员提出更多可以通过文档更有效解决的问题。（为什么您不解决这种低效率问题？）也许是因为您的团队对测试持放任态度，或者（在严重的情况下）甚至不关心生产高质量的软件。祝您好运，用那个故事来说服外部合作者、其他公司/潜在采用者以及最优秀的求职者加入您。
您讲述的故事
讲故事也自然而然地从您构建开源软件的方式中产生。
如果您的团队的项目反映了我所说的“沿着面包屑前进”的方法——“首先安装 A，才能使用 B，然后使用 A 和 B 你可以安装 C，等等”——那么您可能拥有一个引人入胜项目的所有要素。但是您让任何人跟进都变得非常困难。在容器化时代，期望同行做大量跑腿工作才能安装和运行您的东西似乎是不现实的（甚至可能是自以为是的）要求。您的目的是让人困惑或不知所措，还是在提供出色的用户体验的同时引导他们入门？
“目的是什么？” 这是您和您的团队在开始编写任何代码之前要问自己的第一个问题。它为项目开发设定了背景，从而加强了清晰度和重点。在敏捷开发中，我们将大型产品和功能分解为更易于理解的用户故事。这使产品和工程部门能够有效地沟通，并使工程部门能够完成交付客户体验所需的技术工作。标准的用户故事格式如下
- 作为（谁）...
- 我想要（做什么）…
- 以便我可以（产生什么结果）...
以用户故事的方式思考是任何人都可以学习的东西，开源开发人员应该在他们的工具箱中拥有这项技能。在大多数情况下，开源产品负责人应该能够阐明项目试图解决的需求和问题。如果您可以将自己置于与您处境相似的工程师的位置，无论他身处地球的另一端（甚至只是在走廊的另一端），那么您就可以解决他们的问题以及您或您的团队的问题。这种同理心会增加您的影响力，并可能将您和您的项目带到伟大的地方。
扩展您的故事
在组织层面，提供一系列此类软件项目，这些项目在解决您的特定问题的同时提供通用解决方案，表明您的团队是联系紧密的，并且能够与整个行业进行建设性的对话。他们没有专注于眼前的事物，而是拥有参与更广阔世界的信心、心态和知识，通过软件讲述引人入胜的故事。
您的开发实践传达了一个故事，而这个故事揭示了您技术组织的价值观和期望。不友好、不完整或不一致的仓库向世界讲述了关于您的标准和方法的一些信息。统一高质量的仓库讲述了一个不同的故事。
您更愿意阅读哪一个故事？
1 条评论