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

我第一次接触 Prometheus 项目是通过 Linux 基金会导师计划 ，当时我在那里进行 UX（用户体验）研究。我记得刚被选为学员时感到的焦虑。我不仅是 Prometheus 的新手，对整个可观测性领域也是一无所知。我担心自己无法胜任，因为我是在一个以开发人员为中心的领域工作，而我没有任何开发背景。

那种焦虑后来证明是多余的。我继续为该项目做出了有意义的贡献，并且我了解到，我所经历的一切在开源社区的非技术贡献者中几乎是普遍现象。

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

非技术贡献者面临的挑战

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

1. 技术层面的畏难情绪

我在开源空间里常感到格格不入，主要是因为技术贡献者的数量远多于非技术人员。即使是非技术人员，往往也拥有技术背景，或者已经在该领域待了足够长的时间，能够理解正在发生的事情。

当每一场对话都充斥着你听不懂的概念时，很容易感到畏难。你参加会议却全程保持沉默。你选择在聊天框中回复而不是打开麦克风，因为你不敢在录制的会议中发言，而其他人似乎都在用一种你仍在学习的技术语言进行流畅交流。

2. 价值定位不明确

开源项目很少像职位描述那样明确列出对非技术人员的需求。你很难找到一个标题为“需要：面试用户并撰写案例研究的人员”或“招聘：负责组织月度聚会的社区经理”的 Issue。相反，你看到的往往是关于 Bug、功能请求和代码重构的 GitHub Issue 堆积如山。

即使你拥有宝贵的技能，你也不知道哪里需要它们，如何表达你的价值，或者你的贡献是被视为任务关键型还是仅仅是“锦上添花”。如果没有清晰的定位，你很难自信地伸出援手。最终你可能会发出类似“我想帮忙！如果有我可以做的请告诉我”这样模糊的信息，但这往往收效甚微，因为维护者们很忙，没有时间去琢磨如何将你的技能与他们的需求匹配起来。

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

吸引我加入某个开源社区或项目的原因之一是找到志同道合的人。我想大多数人也是如此。代表性很重要。如果你看不到某类人，就很难成为那样的人。

寻找非技术贡献者之所以更难，是因为他们的贡献在项目通常展示工作成果的方式中往往是隐形的。GitHub 的贡献图表计算的是提交记录（commits）。变更日志（Changelogs）列出的是代码修改和错误修复。只有当你创建了被合并的拉取请求（PR）时，你才会获得“贡献者”标签。因此，即使人们在组织活动、支持用户或进行研究，他们的工作也无法像代码那样以显眼的方式体现出来。

4. 入门引导（Onboarding）的鸿沟

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

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

为什么会存在这些差距

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

在大多数情况下，一小群开发人员构建了一些有用的东西，并决定将其开源。他们邀请那些可能需要这些工具的朋友（通常也是开发人员）来做出贡献。项目在这些网络中自然生长。它变成了开发人员为开发人员构建工具的社区，某些功能此时显得并不必要。营销？口口相传在技术圈内自然发生。社区管理？社区规模很小且能自我组织。UX 设计？他们是习惯命令行界面的开发者，因此可能并没有充分考虑到使用图形界面的用户体验。

这并非出于恶意。只是项目在一个并不显然需要这些技能的背景下发展起来了。

转变发生在有人（通常是看到了潜力的非技术贡献者）介入并说：“你们构建了一些有价值的东西并建立了一个令人印象深刻的社区。但以下是你们可能缺失的东西：文档可以降低准入门槛；社区管理可以留住贡献者；用户研究可以指导你们的路线图。”

为什么非技术贡献很重要

Prometheus 是一个功能强大的监控系统，背后有一个庞大的开发人员社区。但像任何开源项目一样，它的繁荣不仅仅依赖于代码。

它需要易懂的文档。 根据我与工程师合作的经验，大多数人宁愿专注于构建功能也不愿写文档，这完全可以理解。对系统了如指掌的工程师编写的文档，往往会假定读者拥有他们所具备的知识。对构建该功能的工程师来说完美的东西，对初学者来说可能就像天书。一位从终端用户角度（而非构建者角度）测试产品的技术文档工程师可以填补这一鸿沟，降低准入门槛。

它需要组织协调。 GitHub Issue 列表里有数百个未分类的待办事项。维护者花费宝贵的时间去解析用户真正需要什么，而不是专注于构建解决方案。项目经理或拥有分类经验的人可以化繁为简，整理出清晰的路线图，让维护者能够专注于解决核心问题。

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

这些都是非技术贡献可以帮忙解决的情况。好的文档降低了准入门槛，意味着更多的采用率、更多的反馈和更好的功能。积极的社区管理可以留住本会流失的贡献者，这意味着知识的共享和维护者精力的节省。组织和分类则将分散的输入转化为可执行的优先级。

Prometheus 的维护者们在构建鲁棒且可扩展的监控系统方面做了卓越的工作。但他们无法做所有事，也不应该由他们做所有事。现在的问题不在于非技术贡献是否重要，而在于我们是否创造了让他们发挥作用的空间。

你可以为 Prometheus 做出贡献的实用方式

如果你准备好为 Prometheus 做出贡献，但不知道从哪开始，以下是一些非常需要非技术技能的领域。

1. 加入 UX 团队

Prometheus 正在积极改善其用户体验，社区现在专门设立了一个 UX 工作组  来致力于此项工作。

如果你是 UX 研究员、设计师或对易用性有敏锐眼光的人，现在是参与的好时机。该工作组还在成形阶段，关于优先级和流程的讨论正在进行中。加入 Slack 频道以参与这些对话，并留意关于具体贡献方式的后续公告。

我可以凭经验告诉你，社区非常乐于接受 UX 贡献，你的工作将产生真正的影响。

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 社区为你留有位置。现在你知道该从哪里开始了。