first-contributions写给非程序员开发者之外的开源贡献路径全景指南【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions本文基于 first-contributions 仓库的印尼语入门文档《Things a non Programmer can do》展开系统梳理非程序员身份进入开源世界的完整路径从“开始倾听”社区沟通渠道到处理工单ticket、参与代码工作、完善文档再到社区建设五大板块共 16 项具体可执行的贡献动作。读完后你将掌握即使不写代码也能实质性参与开源项目的方法论并能对照 first-contributions 仓库自身的 fork → clone → edit → pull request 工作流完成自己的第一次贡献。一、背景为什么“非程序员也能贡献开源”是一个成立的命题代码是每个开源项目的心脏但这并不意味着“写代码”是参与开源的唯一入口。原文档印尼语版英文原版见 Things a non Programmer can do.md开宗明义代码是任何开源项目的心脏但请不要认为写代码是唯一的贡献方式。代码及其周边系统的维护往往因为大家忙于开发新功能和修复 bug 而被忽略。把这类区域当作切入项目的“低门槛入口”。first-contributions 仓库本身就是这一理念的实践载体整个仓库的定位就是“帮助初学者完成第一次开源贡献”README 中给出了一条刻意做到最简单的贡献链路——Fork 仓库、Clone 到本地、在 Contributors.md 中加上自己的名字、提交并发起 Pull Request。该文件目前已有数千行贡献者记录从源码仓库结构看它正是无数“最小贡献”累积的结果。换言之非程序员或零经验的新手在这个仓库里完成的第一个 PR与资深工程师提交的代码修改走的是完全相同的社区流程。仓库中另有两份文档与本文形成呼应docs/how-to-contribute-to-open-source-projects.md 提供从零到提交 PR 的通用路线图docs/additional-material/git_workflow_scenarios/additional-material.md 则索引了修正提交、变基压缩squash、解决合并冲突等进阶 Git 场景供读者在代码贡献阶段按需深入。下面按原文档的脉络逐板块继承并展开全部 16 个条目。二、开始倾听Start Listening开源的一切都涉及“人”。你想加入一支团队就意味着要理解这个社区及其运作方式。原文档提醒走进一个项目就说“嗨我觉得这个项目应该这样那样做”通常不会被欢迎——有些项目也许接受这种风格但对于已经运行较久的项目这种态度被接纳的概率很小。原文档给出的核心结论是倾听是了解项目需要什么的最佳方式。1. 加入邮件列表Join a mailing list对很多项目而言邮件列表是关于项目开发进展的主要沟通渠道。大项目往往有数量可观的列表可供选择。原文档举了一个具体的量级参考PostgreSQL 项目在其邮件列表页面上拥有不少于 12 个面向用户的列表和 6 个开发者列表。实操建议原文档原话先订阅主要面向用户的列表和核心开发者列表以“听”为主开始参与。2. 关注博客Follow a blog由核心开发者维护的博客通常会透露未来版本将带来什么、以及为达成目标需要哪些工作。此外planet 站点会聚合与项目相关的众多新闻源和博客条目。如果项目有 planet 站点就从那里开始读找不到时用搜索引擎检索 “planet 项目名” 这类关键词。3. 加入 IRC 频道Join an IRC channel许多开源项目都有专属的 Internet Relay ChatIRC频道开发者与用户在其中聚集讨论问题与开发细节。具体频道名称和所在 IRC 网络需要到项目网站上查询确认原文档印尼语版该条结尾省略了这一句英文原版补充道在项目网站上查看频道名称及它所在的 IRC 网络。三、处理工单Work with Tickets工单系统ticketing system是用户与开发者之间最主要的沟通通道。大多数项目都有公开可见的问题工单系统通常链接在项目网站首页也包含在文档中。让工单保持最新状态本身就是在帮助项目。原文档还指出你可能需要在工单系统中获得特殊权限只要你向项目负责人说明想帮忙清理工单大多数人会乐于授予。4. 诊断 bugDiagnose a bugbug 常常被报告得语焉不详。对 bug 进行诊断和分诊triage能帮助开发者省下自行排查具体问题的时间。原文档给出了可操作的分诊检查清单用户报告“软件在我做 X 的时候不工作”——花时间去弄清楚这个问题的具体细节可复现吗能否构造一组步骤让问题反复出现能否缩小范围例如只在某一个浏览器出现而另一个浏览器正常或只在某一个发行版出现而另一个正常。即使你最终不知道问题的根因你所付出的“缩小问题范围”的努力也会让其他人更容易修复它。无论发现什么都把它补充到工单里让所有人可见。5. 关闭已修复的 bugClose fixed bugs一个常见现象是bug 已经在代码库中被修复但对应的工单却没有在工单系统中更新。清理这些陈年工单虽然耗时但对整个项目非常有价值。原文档给出了标准操作流程在工单系统中查询超过一年的旧工单确认 bug 是否仍然存在检查项目的发布变更日志release change log看该 bug 是否已修复、可以关闭如果确认已修复在工单中注明版本号并关闭用最新版本的软件尝试重现该 bug无法重现在工单中记录并用“已解决”关闭仍然存在在工单中记录并保持工单开启。四、处理代码Working with Code原文档强调所有经验水平的程序员都可以为项目代码出力不必自认为是编码天才才能对喜欢的项目做出真正贡献。同时有一条前置纪律如果你的工作涉及修改代码先去弄清该项目接收贡献者代码的方式。每个项目都有自己的工作流在提交代码之前先问清楚流程。原文档用两个极端案例说明了工作流的差异PostgreSQL 项目流程极为严格——代码修改以补丁patch形式发送到邮件列表核心开发者会审查改动的每个方面而像 Parrot 这样的项目获得代码库提交权限commit privilege则相对容易。如果项目托管在 GitHub 上很可能存在基于 Pull Request 功能的工作流。没有两个项目是完全一样的。代码风格纪律同样重要你添加或修改的代码应当“看起来像其余代码”。你可能不喜欢现有的花括号风格或缩进空格处理但提交一份不符合现有标准的代码变更是不礼貌的——这相当于在说“我不喜欢你们的风格我觉得我的更好所以你们应该按我的方式来”。first-contributions 仓库恰好提供了一个“零风险”的代码工作练习场README 中的完整标准流程如下每一步都可复制执行# 1. 克隆你自己的 Fork将 url 替换为你复制的仓库地址 git clone url you just copied cd first-contributions # 2. 创建分支git switch 不可用时说明 Git 版本较旧改用 git checkout -b git switch -c your-new-branch-name # 3. 修改 Contributors.md 后暂存并提交 git add Contributors.md git commit -m Add your-name to Contributors list # 4. 推送到远端 git push -u origin your-branch-name之后在项目仓库页面点击 “Compare pull request” 按钮发起 Pull Request即可进入审查环节。README 中还在折叠区块里覆盖了常见坑老版本 Git 无switch子命令、2021 年 8 月后密码认证被移除需用 Personal Access Token 或 SSH 等——这正是“每个项目工作流都不同、先问再做”的典型案例。提交 PR 之后若遇到合并冲突、需要修正提交信息或压缩多个提交可参照 进阶 Git 场景索引 中的对应文档如解决合并冲突、squash commits、amend 提交等。6. 测试 beta 版或发布候选版Test a beta or release candidate任何设计为在多平台上运行的项目都可能存在各种可移植性问题。当临近发布、beta 版或发布候选版release candidate发布时项目负责人希望它被大量不同的人在大量不同平台上测试。你可以成为这些人之一帮助确保软件在你的平台上能正常工作。通常你只需要下载、构建、测试软件三步但如果你使用的分发版或硬件比较小众这对项目的价值会非常大——仅报告“构建和测试成功”就能帮助项目负责人判断即将到来的发布是否可靠。7. 修复 bugFix a bug这通常是希望动手写代码的贡献者的起点。原文档的表述很直白找到工单系统里一个听起来有趣的 bug尝试在代码中修复它。配套要点如果合适在代码中记录这个修复最好向测试套件添加一个测试覆盖你修复的那段代码——部分项目要求 bug 修复必须附带测试在摸索陌生代码库时随手记笔记即使最终没修好也要把排查过程中的发现记录在工单里这能帮助后来者。8. 编写测试Write a test大多数项目都有测试套件但很难想象哪个测试套件不欢迎更多测试。原文档给出了工具级建议使用测试覆盖率工具找出未被测试覆盖的源码区域然后补上测试——C 语言项目gcovPerl 项目Devel::Cover。9. 消除编译器警告Silence a compiler warning许多基于 C 的项目在构建时会向屏幕抛出一堆奇怪的编译器警告。这些警告通常不代表真有问题但看起来像。警告太多会让编译器像“狼来了”里的牧童一样失去可信度。正确的处理顺序是先检查代码是否真的隐藏了 bug如果没有再修改源码使警告消除从而掩盖这些“假阳性”。10. 添加注释Add a comment在翻代码时你很可能遇到一些令人困惑的地方。原文档的判断是如果你被搞糊涂了别人大概率也会被。把这些地方在代码里写清楚然后提交补丁patch即可——这是代码类贡献中最小、也最容易被忽视的一种。五、处理文档Work with Documentation文档通常是项目中“被亏待”的部分。它还常常带有一个结构性缺陷文档是从熟悉项目的人的视角写的而不是从刚刚入门的人的视角写的。如果你曾读过某项目的文档并产生“这本手册好像默认我已经会用它了”的想法你就理解了原文档在说什么。新鲜的眼睛fresh eyes往往能指出项目内部人员注意不到的文档缺陷。11. 创建示例Create an example原文断言没有任何项目会嫌 how-to 示例太多。无论是 Web API、例程库、像 Gimp 这样的 GUI 应用还是命令行工具一个好的用法示例往往比成页的文档更快、更清晰地解释软件该怎么用。对 API 或库写一个使用该工具的示例程序——甚至可以从你自己写过的代码中裁剪而来只保留最基本的部分对工具展示你日常真实使用它的例子如果你是视觉型思维者考虑对关键流程如应用安装过程做屏幕录制/截图。first-contributions 仓库本身就是“示例驱动”的典范README 用带命令、带截图说明的完整步骤把一个 PR 从 Fork 引导到合并各语言版本如 README.id.md则让示例对不同语言读者同样成立。六、参与社区Work with Community原文档的观点是开源只有一部分关乎代码是社区让开源真正运转。以下是原文档列出的社区建设动作。12. 回答问题Answer a question帮助社区建设的最好方式就是帮助他人。回答问题——尤其是来自初学者的问题——对项目成长至关重要。你花时间帮助一个新手哪怕他的问题让你想直接甩一句“RTFM”——Read The Freaking Manual长期回报是社区里多了一个活跃成员。每个人都从某处起步项目要保持活力就需要源源不断的新人流入。13. 写博客Write a blog post如果你有博客写写你使用该项目软件的经历你遇到的问题、你如何解决的。这有双重价值——既帮助周围人记住这个项目也为未来遇到同样问题、上网搜答案的人留下记录。原文档还补充了一层职业视角技术冒险日志也是求职时展示该软件真实使用经验的好材料。14. 改进网站Improve a website如果你有 Web 设计技能帮助改进项目网站即项目的公众形象就是时间花在了刀刃上。项目可能需要一次图形大改或者一个用于识别项目的 logo。这类技能在很多社区里恰恰是稀缺的。15. 撰写技术文档Write technical documentation如果你能写清楚一个应用或软件如何工作就可以为它撰写技术文档——尤其是那些希望更新、重构、扩写或从零建立面向公众的技术文档的开源项目。写得越平实plain language越好。最关键的一点你不需要是程序员就能写技术文档。原文档在此条目后附了一个很有说服力的真实案例Parrot 开发者邮件列表曾决定改用 GitHub 作为工单系统放弃旧的 Trac 安装。有人反对因为没有办法把存量工单迁移过去。经过一天的争论作者主动请缨“我来写一个转换器怎么样”大家非常高兴。他花时间写了一个转换程序处理了450 多个工单没有丢失任何工单历史——作者得以参与项目核心开发者则可以继续专注于 Parrot 本身的工作。这个案例恰好印证了前文“倾听 识别迫切需求”的方法论。16. 教学与帮助他人Teach and help others原文档的收尾观点了解一个主题的最好方式是尝试教它。最好的老师能用简单的例子解释复杂的东西因此想成为最好的学习者就要先尝试成为最好的老师。教人会让你对自己感觉更好也会让你的职业技能和知识更上一层楼。当有人帮了你不要把它藏起来分享给更多人——让这个世界变得更值得居住。七、从“倾听者”到“贡献者”的落地路线把原文档 16 个条目与 first-contributions 仓库的实际结构对照可以归纳出一条渐进路线供读者自查所处阶段阶段对应条目门槛典型动作倾听期1–3邮件列表 / 博客 / IRC零门槛只读地熟悉项目节奏与需求工单期4–5诊断 bug / 关闭已修复 bug需要项目授予工单权限分诊、补全复现步骤、核对版本日志代码期6–10测 beta / 修 bug / 写测试 / 消警告 / 加注释需了解项目贡献工作流按 README 的 fork → clone → 分支 → PR 流程提交文档期11创建示例能使用该产品即可示例程序、真实用法、安装截图社区期12–16答疑 / 博客 / 网站 / 技术文档 / 教学各技能均可切入在工单与论坛持续输出其中“代码期”的入门练习可以直接在 first-contributions 仓库完成Fork、克隆、把名字加进 Contributors.mdREADME 明确要求加在文件中间而非首尾按上文命令序列提交并发起 Pull Request。完成这条链路后再借助 进阶 Git 场景文档集 处理 squash、冲突解决等真实项目中高频出现的情况即具备了参与其他项目代码贡献的基本能力。最后回到原文档反复强调的主线先倾听识别迫切需求然后选择门槛与你技能匹配的那个入口切入。无论你的技能是测试、写作、设计还是教学开源项目都有一条对应的位置——区别只在于你是否愿意先听再动手。【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 first-contributions：写给非程序员开发者之外的开源贡献路径全景指南
first-contributions写给非程序员开发者之外的开源贡献路径全景指南【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions本文基于 first-contributions 仓库的印尼语入门文档《Things a non Programmer can do》展开系统梳理非程序员身份进入开源世界的完整路径从“开始倾听”社区沟通渠道到处理工单ticket、参与代码工作、完善文档再到社区建设五大板块共 16 项具体可执行的贡献动作。读完后你将掌握即使不写代码也能实质性参与开源项目的方法论并能对照 first-contributions 仓库自身的 fork → clone → edit → pull request 工作流完成自己的第一次贡献。一、背景为什么“非程序员也能贡献开源”是一个成立的命题代码是每个开源项目的心脏但这并不意味着“写代码”是参与开源的唯一入口。原文档印尼语版英文原版见 Things a non Programmer can do.md开宗明义代码是任何开源项目的心脏但请不要认为写代码是唯一的贡献方式。代码及其周边系统的维护往往因为大家忙于开发新功能和修复 bug 而被忽略。把这类区域当作切入项目的“低门槛入口”。first-contributions 仓库本身就是这一理念的实践载体整个仓库的定位就是“帮助初学者完成第一次开源贡献”README 中给出了一条刻意做到最简单的贡献链路——Fork 仓库、Clone 到本地、在 Contributors.md 中加上自己的名字、提交并发起 Pull Request。该文件目前已有数千行贡献者记录从源码仓库结构看它正是无数“最小贡献”累积的结果。换言之非程序员或零经验的新手在这个仓库里完成的第一个 PR与资深工程师提交的代码修改走的是完全相同的社区流程。仓库中另有两份文档与本文形成呼应docs/how-to-contribute-to-open-source-projects.md 提供从零到提交 PR 的通用路线图docs/additional-material/git_workflow_scenarios/additional-material.md 则索引了修正提交、变基压缩squash、解决合并冲突等进阶 Git 场景供读者在代码贡献阶段按需深入。下面按原文档的脉络逐板块继承并展开全部 16 个条目。二、开始倾听Start Listening开源的一切都涉及“人”。你想加入一支团队就意味着要理解这个社区及其运作方式。原文档提醒走进一个项目就说“嗨我觉得这个项目应该这样那样做”通常不会被欢迎——有些项目也许接受这种风格但对于已经运行较久的项目这种态度被接纳的概率很小。原文档给出的核心结论是倾听是了解项目需要什么的最佳方式。1. 加入邮件列表Join a mailing list对很多项目而言邮件列表是关于项目开发进展的主要沟通渠道。大项目往往有数量可观的列表可供选择。原文档举了一个具体的量级参考PostgreSQL 项目在其邮件列表页面上拥有不少于 12 个面向用户的列表和 6 个开发者列表。实操建议原文档原话先订阅主要面向用户的列表和核心开发者列表以“听”为主开始参与。2. 关注博客Follow a blog由核心开发者维护的博客通常会透露未来版本将带来什么、以及为达成目标需要哪些工作。此外planet 站点会聚合与项目相关的众多新闻源和博客条目。如果项目有 planet 站点就从那里开始读找不到时用搜索引擎检索 “planet 项目名” 这类关键词。3. 加入 IRC 频道Join an IRC channel许多开源项目都有专属的 Internet Relay ChatIRC频道开发者与用户在其中聚集讨论问题与开发细节。具体频道名称和所在 IRC 网络需要到项目网站上查询确认原文档印尼语版该条结尾省略了这一句英文原版补充道在项目网站上查看频道名称及它所在的 IRC 网络。三、处理工单Work with Tickets工单系统ticketing system是用户与开发者之间最主要的沟通通道。大多数项目都有公开可见的问题工单系统通常链接在项目网站首页也包含在文档中。让工单保持最新状态本身就是在帮助项目。原文档还指出你可能需要在工单系统中获得特殊权限只要你向项目负责人说明想帮忙清理工单大多数人会乐于授予。4. 诊断 bugDiagnose a bugbug 常常被报告得语焉不详。对 bug 进行诊断和分诊triage能帮助开发者省下自行排查具体问题的时间。原文档给出了可操作的分诊检查清单用户报告“软件在我做 X 的时候不工作”——花时间去弄清楚这个问题的具体细节可复现吗能否构造一组步骤让问题反复出现能否缩小范围例如只在某一个浏览器出现而另一个浏览器正常或只在某一个发行版出现而另一个正常。即使你最终不知道问题的根因你所付出的“缩小问题范围”的努力也会让其他人更容易修复它。无论发现什么都把它补充到工单里让所有人可见。5. 关闭已修复的 bugClose fixed bugs一个常见现象是bug 已经在代码库中被修复但对应的工单却没有在工单系统中更新。清理这些陈年工单虽然耗时但对整个项目非常有价值。原文档给出了标准操作流程在工单系统中查询超过一年的旧工单确认 bug 是否仍然存在检查项目的发布变更日志release change log看该 bug 是否已修复、可以关闭如果确认已修复在工单中注明版本号并关闭用最新版本的软件尝试重现该 bug无法重现在工单中记录并用“已解决”关闭仍然存在在工单中记录并保持工单开启。四、处理代码Working with Code原文档强调所有经验水平的程序员都可以为项目代码出力不必自认为是编码天才才能对喜欢的项目做出真正贡献。同时有一条前置纪律如果你的工作涉及修改代码先去弄清该项目接收贡献者代码的方式。每个项目都有自己的工作流在提交代码之前先问清楚流程。原文档用两个极端案例说明了工作流的差异PostgreSQL 项目流程极为严格——代码修改以补丁patch形式发送到邮件列表核心开发者会审查改动的每个方面而像 Parrot 这样的项目获得代码库提交权限commit privilege则相对容易。如果项目托管在 GitHub 上很可能存在基于 Pull Request 功能的工作流。没有两个项目是完全一样的。代码风格纪律同样重要你添加或修改的代码应当“看起来像其余代码”。你可能不喜欢现有的花括号风格或缩进空格处理但提交一份不符合现有标准的代码变更是不礼貌的——这相当于在说“我不喜欢你们的风格我觉得我的更好所以你们应该按我的方式来”。first-contributions 仓库恰好提供了一个“零风险”的代码工作练习场README 中的完整标准流程如下每一步都可复制执行# 1. 克隆你自己的 Fork将 url 替换为你复制的仓库地址 git clone url you just copied cd first-contributions # 2. 创建分支git switch 不可用时说明 Git 版本较旧改用 git checkout -b git switch -c your-new-branch-name # 3. 修改 Contributors.md 后暂存并提交 git add Contributors.md git commit -m Add your-name to Contributors list # 4. 推送到远端 git push -u origin your-branch-name之后在项目仓库页面点击 “Compare pull request” 按钮发起 Pull Request即可进入审查环节。README 中还在折叠区块里覆盖了常见坑老版本 Git 无switch子命令、2021 年 8 月后密码认证被移除需用 Personal Access Token 或 SSH 等——这正是“每个项目工作流都不同、先问再做”的典型案例。提交 PR 之后若遇到合并冲突、需要修正提交信息或压缩多个提交可参照 进阶 Git 场景索引 中的对应文档如解决合并冲突、squash commits、amend 提交等。6. 测试 beta 版或发布候选版Test a beta or release candidate任何设计为在多平台上运行的项目都可能存在各种可移植性问题。当临近发布、beta 版或发布候选版release candidate发布时项目负责人希望它被大量不同的人在大量不同平台上测试。你可以成为这些人之一帮助确保软件在你的平台上能正常工作。通常你只需要下载、构建、测试软件三步但如果你使用的分发版或硬件比较小众这对项目的价值会非常大——仅报告“构建和测试成功”就能帮助项目负责人判断即将到来的发布是否可靠。7. 修复 bugFix a bug这通常是希望动手写代码的贡献者的起点。原文档的表述很直白找到工单系统里一个听起来有趣的 bug尝试在代码中修复它。配套要点如果合适在代码中记录这个修复最好向测试套件添加一个测试覆盖你修复的那段代码——部分项目要求 bug 修复必须附带测试在摸索陌生代码库时随手记笔记即使最终没修好也要把排查过程中的发现记录在工单里这能帮助后来者。8. 编写测试Write a test大多数项目都有测试套件但很难想象哪个测试套件不欢迎更多测试。原文档给出了工具级建议使用测试覆盖率工具找出未被测试覆盖的源码区域然后补上测试——C 语言项目gcovPerl 项目Devel::Cover。9. 消除编译器警告Silence a compiler warning许多基于 C 的项目在构建时会向屏幕抛出一堆奇怪的编译器警告。这些警告通常不代表真有问题但看起来像。警告太多会让编译器像“狼来了”里的牧童一样失去可信度。正确的处理顺序是先检查代码是否真的隐藏了 bug如果没有再修改源码使警告消除从而掩盖这些“假阳性”。10. 添加注释Add a comment在翻代码时你很可能遇到一些令人困惑的地方。原文档的判断是如果你被搞糊涂了别人大概率也会被。把这些地方在代码里写清楚然后提交补丁patch即可——这是代码类贡献中最小、也最容易被忽视的一种。五、处理文档Work with Documentation文档通常是项目中“被亏待”的部分。它还常常带有一个结构性缺陷文档是从熟悉项目的人的视角写的而不是从刚刚入门的人的视角写的。如果你曾读过某项目的文档并产生“这本手册好像默认我已经会用它了”的想法你就理解了原文档在说什么。新鲜的眼睛fresh eyes往往能指出项目内部人员注意不到的文档缺陷。11. 创建示例Create an example原文断言没有任何项目会嫌 how-to 示例太多。无论是 Web API、例程库、像 Gimp 这样的 GUI 应用还是命令行工具一个好的用法示例往往比成页的文档更快、更清晰地解释软件该怎么用。对 API 或库写一个使用该工具的示例程序——甚至可以从你自己写过的代码中裁剪而来只保留最基本的部分对工具展示你日常真实使用它的例子如果你是视觉型思维者考虑对关键流程如应用安装过程做屏幕录制/截图。first-contributions 仓库本身就是“示例驱动”的典范README 用带命令、带截图说明的完整步骤把一个 PR 从 Fork 引导到合并各语言版本如 README.id.md则让示例对不同语言读者同样成立。六、参与社区Work with Community原文档的观点是开源只有一部分关乎代码是社区让开源真正运转。以下是原文档列出的社区建设动作。12. 回答问题Answer a question帮助社区建设的最好方式就是帮助他人。回答问题——尤其是来自初学者的问题——对项目成长至关重要。你花时间帮助一个新手哪怕他的问题让你想直接甩一句“RTFM”——Read The Freaking Manual长期回报是社区里多了一个活跃成员。每个人都从某处起步项目要保持活力就需要源源不断的新人流入。13. 写博客Write a blog post如果你有博客写写你使用该项目软件的经历你遇到的问题、你如何解决的。这有双重价值——既帮助周围人记住这个项目也为未来遇到同样问题、上网搜答案的人留下记录。原文档还补充了一层职业视角技术冒险日志也是求职时展示该软件真实使用经验的好材料。14. 改进网站Improve a website如果你有 Web 设计技能帮助改进项目网站即项目的公众形象就是时间花在了刀刃上。项目可能需要一次图形大改或者一个用于识别项目的 logo。这类技能在很多社区里恰恰是稀缺的。15. 撰写技术文档Write technical documentation如果你能写清楚一个应用或软件如何工作就可以为它撰写技术文档——尤其是那些希望更新、重构、扩写或从零建立面向公众的技术文档的开源项目。写得越平实plain language越好。最关键的一点你不需要是程序员就能写技术文档。原文档在此条目后附了一个很有说服力的真实案例Parrot 开发者邮件列表曾决定改用 GitHub 作为工单系统放弃旧的 Trac 安装。有人反对因为没有办法把存量工单迁移过去。经过一天的争论作者主动请缨“我来写一个转换器怎么样”大家非常高兴。他花时间写了一个转换程序处理了450 多个工单没有丢失任何工单历史——作者得以参与项目核心开发者则可以继续专注于 Parrot 本身的工作。这个案例恰好印证了前文“倾听 识别迫切需求”的方法论。16. 教学与帮助他人Teach and help others原文档的收尾观点了解一个主题的最好方式是尝试教它。最好的老师能用简单的例子解释复杂的东西因此想成为最好的学习者就要先尝试成为最好的老师。教人会让你对自己感觉更好也会让你的职业技能和知识更上一层楼。当有人帮了你不要把它藏起来分享给更多人——让这个世界变得更值得居住。七、从“倾听者”到“贡献者”的落地路线把原文档 16 个条目与 first-contributions 仓库的实际结构对照可以归纳出一条渐进路线供读者自查所处阶段阶段对应条目门槛典型动作倾听期1–3邮件列表 / 博客 / IRC零门槛只读地熟悉项目节奏与需求工单期4–5诊断 bug / 关闭已修复 bug需要项目授予工单权限分诊、补全复现步骤、核对版本日志代码期6–10测 beta / 修 bug / 写测试 / 消警告 / 加注释需了解项目贡献工作流按 README 的 fork → clone → 分支 → PR 流程提交文档期11创建示例能使用该产品即可示例程序、真实用法、安装截图社区期12–16答疑 / 博客 / 网站 / 技术文档 / 教学各技能均可切入在工单与论坛持续输出其中“代码期”的入门练习可以直接在 first-contributions 仓库完成Fork、克隆、把名字加进 Contributors.mdREADME 明确要求加在文件中间而非首尾按上文命令序列提交并发起 Pull Request。完成这条链路后再借助 进阶 Git 场景文档集 处理 squash、冲突解决等真实项目中高频出现的情况即具备了参与其他项目代码贡献的基本能力。最后回到原文档反复强调的主线先倾听识别迫切需求然后选择门槛与你技能匹配的那个入口切入。无论你的技能是测试、写作、设计还是教学开源项目都有一条对应的位置——区别只在于你是否愿意先听再动手。【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考