非开发者如何为 Prometheus 做贡献

我第一次接触 Prometheus 项目是通过 Linux Foundation 导师计划 ，在那里我进行了用户体验研究。我记得当我被选为受训者时感到的焦虑。我不仅对 Prometheus 不熟悉，对可观测性（observability）也一无所知。我担心自己力不从心，在一个高度以开发者为中心的领域工作，而我没有任何开发背景。

事实证明，那种焦虑是多余的。我后来为该项目做出了有意义的贡献，并且我了解到，我在开源领域非技术贡献者中经历的感受几乎是普遍存在的。

如果您也有同样的疑虑，那么这篇文章就是为您准备的。我将分享您可能会面临（或已经面临）的挑战，为什么您的贡献很重要，以及如何在 Prometheus 社区找到您的位置。

非技术贡献者面临的挑战

作为一名非技术贡献者，我在开源领域遇到过不少障碍。从与其他在这类空间中摸索的人交流，我发现这些困难非常一致。以下是最常见的障碍：

1. 技术上的胆怯因素

我曾在开源领域感到格格不入，主要是因为技术贡献者的人数远远超过了非技术贡献者。即使是非技术人员，他们也常常拥有技术背景，或者已经在这个领域待了足够长的时间来理解正在发生的事情。

当每一次对话都引用您不了解的概念时，很容易感到畏惧。您会参加会议，但全程保持沉默。您会在聊天中回复，而不是直接发言，因为您不相信自己能在录制的会议中自信地发言，而会议中的每个人似乎都精通您仍在学习的技术语言。

2. 价值主张不明确

开源项目很少像招聘启事那样明确说明其非技术需求。您很难找到一个标题为“需求：有人采访用户并撰写案例研究”或“招聘：社区经理组织月度会议”的问题。相反，您更有可能看到积压的 GitHub 问题，内容涉及 bug、功能请求和代码重构。

即使您拥有宝贵的技能，也不知道它们在哪里有用，如何表达您的价值，或者您的贡献是否会被视为关键任务还是仅仅是锦上添花。如果不清楚自己如何融入，就很难自信地主动联系。您最终会发送模糊的信息，例如“我很乐意提供帮助！如果有我能做的，请告诉我”，这通常不会有什么结果，因为维护者很忙，没有时间弄清楚如何将您的技能与他们的需求匹配。

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

吸引我加入一个开源社区或项目的因素之一是找到和我一样的人。我认为大多数人也是这样。代表性很重要。看不见的东西很难成为目标。

寻找非技术贡献者甚至更难，因为项目通常展示工作的方式使得他们的贡献常常不为人所见。GitHub 贡献图统计提交次数。发布说明列出了代码更改和 bug 修复。只有当您的拉取请求被合并时，您才会获得“贡献者”标签。因此，即使人们在组织活动、支持用户或进行研究，他们的工作也不会像代码那样得到突出展示。

4. 入门差距

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

您会看到“加入我们的社区”，并附有一个指向 Slack 工作区的链接。但是，从加入到做出第一个贡献之间存在着巨大的差距。数十个频道里有数百人。谁是维护者，谁只是另一个社区成员？哪个频道适合您的问题？当您需要指导时，应该标记谁？

为什么存在这些差距

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

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

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

当有人（通常是一个非技术贡献者，看到了潜力）介入并说：“你们已经建立了一个有价值的东西，并发展了一个令人印象深刻的社区。但这里是你们可能忽略的地方。文档可以降低入门门槛。社区管理可以留住贡献者。用户研究可以指导你们的路线图。”时，情况就会发生转变。

为什么非技术贡献很重要

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

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

它需要组织。 GitHub 问题积压中有数百个未分类的开放项目。维护者花费宝贵的时间来分析用户真正需要什么，而不是构建解决方案。项目经理或有分类经验的人可以将这种混乱转化为清晰的路线图，让维护者能够专注于构建解决方案。

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

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

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

贡献 Prometheus 的实用方法

如果您准备好为 Prometheus 做贡献，但又不知道从何开始，以下是一些积极需要非技术技能的领域。

1. 加入用户体验工作

Prometheus 正在积极致力于改进其用户体验，社区现在有一个 用户体验工作组  致力于此。

如果您是用户体验研究员、设计师或具有可用性意识的人，现在是参与的好时机。工作组仍在成型中，关于优先级和流程的讨论正在进行中。加入 Slack 频道参与这些对话，并留意即将发布的有关具体贡献方式的公告。

从我的经验来看，社区对用户体验的贡献持开放态度，您的工作将产生实际影响。

2. 为 Prometheus 博客撰稿

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

查看 博客内容指南 ，了解什么构成一个好的博客提案以及如何发布博客文章。有许多人渴望从您的经验中学习。

3. 改进和维护文档

文档是开源项目中持续存在的需求之一。总有可以更清晰、更完整或更好地组织的内容。Prometheus 的文档仓库也不例外。

您可以贡献纠正拼写错误和 损坏的链接 ，扩展入门指南，创建常见监控场景的教程，或者 分类问题  来帮助优先处理需要关注的事项。即使您不认为自己是技术撰稿人，如果您曾经对文档感到困惑并弄明白了，您也可以帮助下一位读者更清楚地理解。

4. 帮助组织 PromCon

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

如果您在活动策划、赞助商拓展、市场营销或传播方面有经验，PromCon 组织者非常欢迎您的帮助。联系 组织团队  或在 Prometheus 社区频道中留意公告。

5. 宣传和推广

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

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

如何开始

如果您准备好为 Prometheus 做贡献，以下是我作为一名非技术贡献者在社区中摸索时学到的一些经验。

先介绍自己。当您加入 #prometheus-dev Slack 频道时，请打个招呼。Slack 并不总是能清楚地显示新人加入，所以如果您保持沉默，人们根本不会知道您在那里。简单的自我介绍——您的姓名、您的工作、您为何来到 Prometheus——足以让您被注意到。

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

先观察，后行动。立刻提出想法是诱人的，但先花时间观察会带来回报。阅读 Slack 讨论和 GitHub 问题中的对话。浏览文档。注意正在做出哪些类型的贡献。您会开始看到一些模式：反复出现的问题、文档的缺失、需要帮助的领域。这就是您的机会所在。

提问。每个人都曾是新手。如果有什么不清楚的地方，请提问。如果您没有立即得到回应，请稍等片刻——人们都很忙——然后跟进。社区很友好，但您必须让自己变得可见。

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