如何在 Open Source 中不当行为
Source: Dev.to
走到柜台前，要求见经理，要求餐厅提供素食友好选项，递给经理一本满是素食友好食谱的烹饪书，被拒绝后离开餐厅，并留下 1 星评价。
对普通人来说，迎合一个对你的时间、工作或预算毫不在意的个人的特定要求听起来荒唐。另一方面，普通人往往也不会考虑别人的时间、工作或预算。
作为一名开源维护者，我逐渐体会到那些我所倚赖的巨人的艰苦付出。我想让大家看到这些人到底在做多少工作，并希望帮助你以尽可能无摩擦的方式欣赏并贡献。
本文适合谁？
无论你是刚开始接触开源、是“vibe coder”，还是 opencl*w 实例，希望本文能对你有所帮助。
本文假设你对类似 git 的版本控制系统有基本了解，并且对 GitHub 或 GitLab 等 git 托管平台有所熟悉。
如何成为维护者的头疼
让我们来谈谈一些让开源维护者感到绝对痛苦的方法。
可能的副作用包括 在社交媒体上获得负面宣传、被项目封禁，或者在你的 issue 或 pull request 被拒绝后感到不快。
如何让你的 Issue 被拒绝
1. 提交极其模糊的 bug 报告
2. 请求移植到其他语言 / 框架 / 操作系统
3. 提出大范围的功能请求
4. 为了捣乱而打开一个模糊的 PR
如何让你的 Pull Request 被拒绝
1. 用 vibe‑code 实现一个庞大的功能
2. 打开一个仅在 README.md 中添加你名字的 PR
Source: …
成为文明的贡献者
既然你已经对不该做的事情有了大致了解，下面来看看一些能够帮助你更顺畅地与开源维护者和贡献者合作的方法。
通用礼仪 (适用于 issue 和 pull request)
- 表达感谢 – 开源软件可能免费使用，但时间不是。如果某个项目对你很重要或帮助了你，向维护者表达感谢——这正是他们坚持下去的动力。如果你有余力，考虑赞助该项目。
- 搜索并阅读 – 是否有与你相同的重复 issue？是否已有解决办法或变通方案？是否有人写了博客文章正好解决了你遇到的问题？找到已有的解决方案或变通办法，比等待回复更有价值。
- 提供详尽信息 – 尽可能提供完整信息。交叉引用相关的 issue 和 pull request，帮助维护者更容易地帮助你。
Issue
Issue 之所以会计入你的 GitHub 贡献图，是有原因的。不要把 Issue 当作客服支持来对待，而应把它视为对项目的积极贡献。
-
在打开 Issue 之前，考虑实际可用的工程投入：
- 有多少活跃的维护者？
- 项目所有者最近一次活跃是什么时候？
- 已经存在多少未解决的 Issue？
-
避免引入不必要的负担 – 你的 Issue 完成后会提供解决方案，还是只会带来更多问题和负担？例如，为仅支持 macOS 的应用请求 Windows 支持，就会带来一系列新的挑战。
-
评估影响范围 – 你的 Issue 描述的内容如果得到修复，是否会惠及大量用户，还是仅是一个小众的边缘案例？
Pull Request
-
阅读贡献指南 – 大多数项目都有
CONTRIBUTING.md，其中概述了首选的工作流、代码风格和测试要求。 -
从小处开始 – 一个结构良好、聚焦明确的 PR 比起庞大、包含“一切和厨房水槽”的改动更容易被合并。
-
编写清晰的提交信息 – 说明改动了什么以及为什么要改动。
-
添加测试 – 如果项目有测试套件，请添加或更新测试以覆盖你的改动。
-
保持响应 – 当维护者要求修改时，及时且礼貌地进行处理。
TL;DR
- 别惹麻烦：避免模糊的报告、庞大的未经请求的功能以及自我宣传的 PR。
- 做个好公民：表达感激、做好功课、细致入微，尊重维护者的时间。
- 深思熟虑地贡献：小而文档完善的改动以及经过充分调研的问题，使开源生态对所有人更健康。
大规模影响
该问题是否影响了大多数消费者，还是仅对您个人非常特定？
请考虑使用变通方案、分叉仓库或依赖补丁，是否比等待几个月后发布的下一个版本更为有效。
拉取请求（最佳实践）
当打开拉取请求时，尽量严格遵循项目中指定的风格指南和约定。
-
保持干净的提交历史 – 花约30 分钟学习如何压缩、描述、重新排序和变基提交。
- 将你的更改拆分为小且详细的提交，并交叉引用相关的议题和拉取请求。
- 解释为何进行更改，而不仅仅是做了什么。
-
自动化测试 – 如果项目有测试环境，编写单元/集成测试以确保行为正确。
作为维护者的你
成为维护者或项目所有者意味着要承担一系列责任。如果你想为用户构建可靠的软件，就必须投入时间和精力来保持这种可靠性。
-
接受贡献 – 在没有进行测试和彻底审查的情况下，切勿盲目接受外部贡献。
-
保持透明 – 在接受、拒绝或对贡献发表评论时，解释为什么做出该决定。
-
保持有序 – 有条理地管理 issue、pull request 和提交。
- 将更改拆分为 PR 和提交，并详细描述它们。
- 在 issue 与 pull request 之间交叉引用。
- 如果问题并未真正完成，切勿将其标记为“已完成”。
-
“友好”不是你的重点 – 只要表达充分，直率的沟通是可以接受的。
- 不要让贡献者误以为你会接受所有贡献。
- 拒绝贡献可能会伤害情感，但不会伤害你的项目。说“不”没关系。
-
必要时委派工作 – 开源项目很少能支付账单，所以你可能无法全职投入项目。
- 如果过去的贡献者或提出 issue 的人表现出兴趣，邀请他们提交 PR，供你稍后审查。
-
归档 – 如果因个人原因无法继续维护开源项目，请将其归档，以让大家知道开发已停止。
结论
本文仅仅触及了成为开源贡献者和维护者的意义的表面。
如果你从本文中获得了收获，希望你能抽出时间将其付诸实践，让开源贡献者和维护者的生活更加轻松。
我们大家同舟共济。让我们一起分担这份工作。