非开发人员如何为 Prometheus 做出贡献

我最初接触 Prometheus 项目是通过 Linux 基金会导师计划 ，我在那里进行了用户体验（UX）研究。我记得当被选为学员时，我感到非常焦虑。我不仅对 Prometheus 不熟悉，对整个可观测性领域也是个新手。我担心自己超出了能力范围，在一个以开发人员为中心的领域工作，却没有开发背景。

后来证明，那种焦虑是毫无根据的。我继续为项目做出了有意义的贡献，并且我了解到，我所经历的在开源领域的非技术贡献者中几乎是普遍现象。

如果你也感到同样的不确定，这篇文章就是为你而写的。我将分享你可能面临（或已经面临）的挑战，为什么你的贡献很重要，以及如何在 Prometheus 社区中找到你的位置。

非技术贡献者面临的挑战

作为一名非技术贡献者，我在开源领域遇到了不少障碍。通过与其他在这些领域探索的人交流，我发现大家遇到的困难惊人地一致。以下是最常见的障碍：

1. 技术上的威慑因素

我曾在开源社区感到格格不入，主要是因为技术贡献者的数量远远超过非技术贡献者。甚至那些非技术人员也常常有技术背景，或者已经在社区里待了足够长的时间，能够理解正在发生的事情。

当每次对话都涉及到你不了解的概念时，你很容易感到畏惧。你参加会议，全程保持沉默。你在聊天框里回复，而不是打开麦克风说话，因为你不敢在一个被录制的会议上发言，而其他人似乎都能流利地使用你仍在学习的技术语言。

2. 价值定位不明确

开源项目很少会像招聘启事那样明确说明他们的非技术需求。你几乎找不到标题为“需求：需要有人采访用户并撰写案例研究”或“招聘：社区经理组织月度聚会”的 issue。相反，你更有可能看到的是一个积压了大量关于 bug、功能请求和代码重构的 GitHub issue。

即使你拥有宝贵的技能，你也不知道哪里需要它们，如何阐明你的价值，或者你的贡献是否会被视为项目关键任务，而不仅仅是锦上添花。没有清楚地了解自己如何融入其中，就很难自信地与人接触。你最终只会发送一些模糊的信息，比如“我很乐意帮忙！如果有什么我能做的，请告诉我”，这很少能有什么结果，因为维护者们都很忙，没有时间去琢磨如何将你的技能与他们的需求相匹配。

3. 缺乏可见的非技术贡献者

吸引我加入一个开源社区或项目的原因之一是找到其他和我一样的人。我想大多数人都是这样。代表性很重要。你无法成为你看不见的样子。

找到非技术贡献者更加困难，因为他们的贡献在项目通常展示工作的方式中是不可见的。GitHub 的贡献图表统计的是提交（commit）。更新日志列出的是代码变更和 bug 修复。只有当你创建的拉取请求（pull request）被合并后，你才能获得“贡献者”的标签。因此，即使人们在组织活动、支持用户或进行研究，他们的工作也不会像代码那样以同样显眼的方式展示出来。

4. 新手引导的缺失

一份典型的“贡献指南”会引导你设置开发环境、创建分支、运行测试以及提交拉取请求。但它很少解释如何贡献文档改进、设计反馈应该提交到哪里，或者社区支持是如何组织的。

你看到“加入我们的社区”，附带一个 Slack 工作区的链接。但在加入和做出你的第一次贡献之间，存在着巨大的鸿沟。有成百上千的人在几十个频道里。谁是维护者，谁又只是另一个社区成员？哪个频道适合提问？当你需要指导时应该@谁？

为何存在这些差距

值得承认的是，大多数时候，这些差距并非有意为之。项目并不是故意排斥非技术贡献者或让他们更难参与。

在大多数情况下，一小群开发人员构建了一些有用的东西，并决定将其开源。他们邀请他们认识的可能需要它的人（通常是其他开发人员）来贡献。项目在这些网络中自然地成长。它变成了一个由开发人员为开发人员构建工具的社区，某些职能根本感觉不到必要。市场营销？项目在技术圈子里自然传播。社区管理？社区很小并且可以自我组织。用户体验设计？他们是习惯于命令行界面的开发人员，所以他们可能没有充分考虑使用图形界面的体验。

这一切都不是恶意的。只是项目在一个那些技能不明显需要的环境中演变而来。

转变的发生，往往是因为某个人——通常是一个看到了潜力的非技术贡献者——站出来说：“你们构建了一些有价值的东西，并发展了一个令人印象深刻的社区。但这里是你们可能缺失的。文档可以如何降低入门门槛。社区管理可以如何留住贡献者。用户研究可以如何指导你们的路线图。”

为什么非技术贡献很重要

Prometheus 是一个强大的监控系统，背后有一个庞大的开发者社区支持。但和任何开源项目一样，它需要代码之外的东西才能蓬勃发展。

它需要易于理解的文档。 根据我与工程师合作的经验，大多数人宁愿专注于构建而不是编写文档，这是可以理解的。对系统了如指掌的工程师写的文档常常假设新手不具备某些知识。对于构建该功能的人来说完全合理的内容，对于第一次接触它的人来说可能难以理解。一位从最终用户的角度（而不是构建者的角度）测试产品的技术撰稿人可以弥合这一差距，降低入门门槛。

它需要组织。 GitHub 的 issue 积压中有数百个未分类的待办事项。维护者们将宝贵的时间花在解析用户的实际需求上，而不是构建解决方案。一位项目经理或有分类经验的人可以将这种混乱转化为清晰的路线图，让维护者能够将时间花在构建解决方案上。

它需要社区支持。 想象一个用户加入了 Slack 工作区，满怀热情地想要做出贡献。他们不知道从哪里开始。他们提出的问题被淹没在信息流中。他们悄悄地离开了。项目就这样失去了一个潜在的贡献者，因为没有人欢迎他们并为他们指明方向。

这些就是非技术贡献可以帮助预防的情况。好的文档降低了入门门槛，这意味着更多的采用、更多的反馈和更好的功能。积极的社区管理留住了那些否则可能会流失的贡献者，这意味着知识的分散和维护者倦怠的减少。组织和分类将零散的输入转化为可操作的优先事项。

Prometheus 的维护者们在构建一个健壮、可扩展的监控系统方面做得非常出色。但他们不能做所有事，也不应该做所有事。现在的问题不是非技术贡献是否重要，而是我们是否为它们创造了发生的空间。

你可以为 Prometheus 做出贡献的实际方法

如果你准备好为 Prometheus 做出贡献，但不确定从哪里开始，这里有一些积极需要非技术技能的领域。

1. 加入用户体验（UX）工作

Prometheus 正在积极努力改善其用户体验，社区现在有一个专门致力于此项工作的用户体验工作组 。

如果你是用户体验研究员、设计师，或者对可用性有敏锐的洞察力，现在是参与进来的绝佳时机。该工作组仍在形成中，关于优先事项和流程的讨论正在进行。加入 Slack 频道参与这些对话，并关注即将发布的关于具体贡献方式的公告。

我可以根据经验告诉你，社区对用户体验的贡献持开放态度，你的工作将产生真正的影响。

2. 为 Prometheus 博客撰稿

如果你是技术撰稿人或内容创作者，Prometheus 博客是一个天然的切入点。该博客发布教程、案例研究、最佳实践、社区更新以及通常帮助用户从 Prometheus 中获得更多价值的内容。

查看博客内容指南 ，了解如何提出一个好的博客提案以及如何在博客上发表文章。有大量读者渴望从你的经验中学习。

3. 改进和维护文档

文档是开源项目中一个永恒的需求。总有东西可以变得更清晰、更完整或组织得更好。Prometheus 的文档仓库也不例外。

你可以通过修复拼写错误和损坏的链接 、扩展入门指南、为常见的监控场景创建教程，或者分类 issue 来帮助确定需要关注的优先事项。即使你不认为自己是技术撰稿人，如果你曾经被文档搞糊涂过并最终弄明白了，你就可以帮助下一个人更容易地理解它。

4. 帮助组织 PromCon

PromCon  是 Prometheus 的年度会议，举办它需要大量的协调工作。组织团队处理从演讲者选择和日程安排到场地后勤和赞助商关系等所有事务。

如果你在活动策划、赞助商联络、市场营销或沟通方面有经验，PromCon 组织者会欢迎你的帮助。联系组织团队 或关注 Prometheus 社区频道中的公告。

5. 宣传和推广

最后，你能做的最简单但最有影响力的事情之一就是谈论 Prometheus。写博客文章介绍你如何使用 Prometheus。在本地聚会或会议上发表演讲。在社交媒体上分享技巧和心得。创建视频教程或直播。向正在评估监控解决方案的团队推荐 Prometheus。

每一篇内容，每一次会议演讲，每一条社交媒体帖子，都在扩大 Prometheus 的影响力，帮助新用户发现它。

如何开始

如果你准备好为 Prometheus 做出贡献，以下是我作为一个非技术贡献者在社区中探索时学到的经验：

从自我介绍开始。 当你加入 #prometheus-dev Slack 频道时，打个招呼。Slack 并不总是能明显地提示有新人加入，所以如果你保持沉默，人们根本不知道你在这里。一个简单的介绍——你的名字，你的工作，你为什么来到 Prometheus——就足以让大家知道你的存在。

参加社区会议。 查看社区日历并将你感兴趣的会议同步到你的日程中。即使你一开始不理解讨论的所有内容（这完全正常），也要坚持下去。你参加得越多，就越能了解社区的需求，并找到更多贡献的机会。

先观察，再行动。 立即提出想法很诱人，但先花时间观察会带来回报。阅读 Slack 讨论和 GitHub issue 中的对话。浏览文档。注意人们正在做什么样的贡献。你会开始看到一些模式：反复出现的问题、文档的空白、需要帮助的领域。那就是你的机会所在。

提问。 每个人都曾是新手。如果有什么不清楚的地方，就去问。如果没有立即得到回应，给点时间——大家都很忙——然后再跟进。社区是欢迎的，但你必须让自己被看到。

Prometheus 社区有你的位置。现在你知道该从哪里开始了。