开源 - freeCodeCamp.org

freeCodeCamp 课程重大更新在圣诞节上线

Miya Liu — Tue, 24 Dec 2024 05:19:00 +0000

原文： Major freeCodeCamp Curriculum Updates Now Live in 2025

圣诞快乐，campers！🎄 freeCodeCamp 刚刚发布了大量免费的学习工具，方便大家在假期里体验：

🏗️ 新的认证全栈开发者课程上线啦！

🗨️ 新的开发者英语 CEFR B1 级别课程

🤳 我们的移动应用程序进行了重大更新

freeCodeCamp 认证全栈开发者路径

以下是全新的认证全栈开发者路径的完整内容，非常丰富：

🛠️ 64 个工作坊 – 涵盖从 HTML 到 SQL 到 Python 的互动式分步骤编程课程（现已上线 42 个）

🏛️ 513 堂讲座 – 涵盖计算机科学概念的短视频，包含测试你是否理解的选择题（现已上线 313 个）

⚗️ 83 个实验室 – 从空白编辑器和测试套件开始，你需要构建项目以通过所有测试（现已上线 60 个）

📰 62 份复习材料 – 每个模块的综合主题列表，帮助你复习并准备测验和考试（现已上线 46 份）

🔬 66 个测验 – 确认你掌握全栈开发概念和工具（现已上线 46 个）

🏔️ 1 个终极项目 – 你将为自己的作品集构建一个大型独特的项目，此项目将由 freeCodeCamp 社区的教师进行评审（2025 年上线）

🤺 1 次期末考试 – 全面的监考式认证考试，共 90 个问题，将在 freeCodeCamp 的新开源考试环境中进行（2025 年上线）

即使你以前已经学习过其中的一些主题，我还是建议你从头开始学习。

你可以立即开始学习新的认证全栈开发者课程。

开发者英语课程 CEFR B1 级别

去年圣诞节，我们发布了 CEFR A2 级别的英语课程。

经过一年的努力，我很高兴地告诉大家，我们不仅上线了所有内容，还推出了相当一部分 B1 级别课程。

认证考试也将在 2025 年上线。

你可以尝试我们的 CEFR B1 级别开发者英语认证课程。

freeCodeCamp iPhone 和 Android 应用程序

freeCodeCamp 移动应用程序比之前更加出色。我们的 Flutter 代码库刚刚收到 1,000 个 commits！

你现在可以：

📺 观看我们的课程

📚 阅读我们的书籍

🤳 直接在手机上快速学习课程

在 iPhone/Android 上下载并留下五星好评。⭐️⭐️⭐️⭐️⭐️ 😉

获取 Android 应用

获取 iPhone 应用

2025 年将会很精彩。

再次感谢所有为 freeCodeCamp 课程和我们的众多开源项目做出贡献的人们。

任何人都可以随时在论坛和 Discord 上获得 camper 们的帮助，这太棒了。

鼓励你的朋友参与进来。大家可以从我们的开源贡献文档开始。

最后，感谢所有捐款支持 freeCodeCamp 使命的人们。我们才刚刚开始。🥞

请鼓励你的朋友也来支持我们的慈善事业。我们共同努力，让每个人都能获得免费的世界级教育。你可以和全球 11,043 位慷慨的人们一起成为我们的支持者。

祝贺 freeCodeCamp 全球开源社区 2024 Top Contributors

Miya Liu — Fri, 01 Nov 2024 03:25:34 +0000

原文： https://www.freecodecamp.org/news/freecodecamps-top-open-source-contributors-of-2024/

对于 freeCodeCamp 社区来说，2024 年是极富成效的一年。我们为实现为所有人创建开放式学习资源的使命积蓄了巨大的动力。

在过去的 12 个月中，freeCodeCamp 社区取得了以下成就：

在我们的 GitHub 开源仓库合并了 2,455 个代码贡献
在 YouTube 上发布了 193 个免费的完整视频教程
通过 freeCodeCamp 出版社发布了 850 篇编程教程和 5 本免费书籍
翻译了 150 多万字的英文资源，让母语是其他语言的人们更容易学习我们的课程和教程

我非常感谢今年参与志愿贡献的善良的人们。我们在多个方面取得了实质性进展。

以下是按贡献类别列出的 top contributors 的完整名单。

GitHub Top Contributors

论坛 Top Contributors

翻译 Top Contributors

Afonso Branco
rustamdocstranslator
Madlen
Alan Luo
LisaGo
majidah
Karel Vanhelden
SeunghyunKim
Nadja Sellinat
Kevin Matthew
Siyana Zdravkova
Ricardo Cuauro
Liu dakang
Álvaro Dávila
Ira Bohach
Laureline
Nils Goeke
ViktoriaKushnir0-
ピンク人
sohyun
kimploo
franciscomelov
Andriana Cabrera
Kostiantyn Melnyk
athen
JulianLobonAguilar
moonki kim
Suzie
Kasia
mamaruo
VL
Solomiia Karpachova
Diana Kolosovska (Діана Колосовська)
steven ding
Elias Pereyra
nin3lee
Juanma
Naelko
Álvaro Dávila
Tamiris
Devan
Leslie Suh
Dario
mix bo
Eduardo Lima
isaura-ribeiro
nighttheduck
Caroline Andrade
salvatore luciano
Nikolai
Frankline Were
Mikadifo
MaxiNZ
SleepyGogo
Brendo Arruda
rkang13
TikaZ
shaudvetis
Minh Tuấn Nguyễn
wdthor
BeGeosDev
Kristian Pavic
Dalton Cuenca
jonathanq
Erick
Sreya Satheesh
Freddy R
Wilmer Gulcochía Sánchez
Shannon
André Garcia
Saikrishna Anumula
Sharvio
David Gómez Redondo
Jimmy Yem
Lucy Macartney
vLeov
Sunce
1615_P._Enrique
Ener Octavio Buitrago Camelo
ProjektMing
nrached
Camila
Maria Luz Davico
EricF
Bobby M
lime
irabucha
Filippo Crespi
MrTL3
Li Chuan (李川)
Rodrigo Lajas
Jarvis Hack
invoker
claudiomavi
Kato Tsune (加藤恒)
yk1537
Jose Zambrano
Takkapi
BlackAndRed.eth
leopard355
DariaShu
Daniel R. da Silva
Adham Muhammadjonov
Davi Stadlinger
w w
KenGan
cezin17
Dylan Gabriel Diroché
luluhwenceslau
Chinchu Ori
albasantalo
Dira R P
William Hincapié
aldid95
Fran Martinez
Yao990815
Miracle
Julian Andres Lasso Figueroa
pame.gon
watanaki
Faisal Hanafi
Jiwon
Abo_AbdelSalam
Vé
Lu Mu (辂木)
martinvostatek
Patrick Hähnel
Stanley S
Alexia Javadd
peperluiz
Lina Guio
adnen rebai
Pasan Hewavitharana
Monir Adam
Adi Nugroho
YumiClmpn
Daniel Garcia Sanchez
bugrahankaramollaoglu
Hannibal_TN
Ucky Deni Ulinnuha
David Beyer
Nicolás Folli
IM Grigore
Bill Gao
Baris
Simón San Juan Gallardo
Eralpozcan
Maria Fernanda Rios
Tsukistar (月落星河)
Tao
Gabriel Kraemer
mementog
petyaDeveloper
TrueJackWu
Nicolvs
Juan Diego Jaimes
Cássio Barth
Aekkapob Pangtan
Sergitxin
Bettina Neuwirth
juanalbglz
Marta Escriche
adrianna
pcaballero
Nico Van Pletzen
Rafael Quintero
Ozat21
Dinto
orikes
fanqie
Kamil Kliczbor
Francisco Mancuello
Roberto Perez
Luis Aguilar
kersen
miller-danilo
castrovca
ChristianMoya
Felipe Navarro
Felipe Hernández
DongHyeon
Denisse Lemos
Meer Sajib
AR Dhrubo
Paola Rosati
Andrea Sisti
Charlotte Stone
Saki Basken
Yuki Shibata
YUUSUKE OKAMOTO
Constanza Areal
Elias Ezequiel Pereyra Gomez
Diego Lopez
Cristian Fernando Villca Gutierrez
Francisco Melo V.
HeZean
Mingxun Liu
Tsukistar
James Z. Zhang
huqi
JunoWei
YiWei
luojiyin
herosql
李小宁
Afonso Branco
Kris Lagerström
Filipe Barbosa
David Esdras
João Eduardo Gomes
Luis Felipe L. C.
Marcelo Pena
Gabriel Balbueno
Sabrina Alves
Ana Laura Reis
Isabel de Souza

YouTube Top Contributors

专栏 Top Contributors

Discord Top Contributors

plamoni
jeremylt
Versailles
Science99
rhombert
localhost
goks563
Razzle Dazzle
hana
SaintPeter
Maestro
xCoffeeMan
Tex
Jim
bradtaniguchi
Mohammed_malleck
andrewdmitriev39r
ilenia
ArialLeslie
Chara
SaintElGandoSmokio
CapslockHero
g0vX
tgrtim
alpox
AlexG
dark
Lycelia
WangGang
Saburo
Bordin
Dylan
bulhaa
bro keeps whining
Tek

freeCodeCamp 社区中有成千上万的参与者，这里我只是列出其中贡献最多的一些人们。

如果你有兴趣作为 freeCodeCamp 社区的开源贡献者，我建议你阅读我们的贡献者指南，并加入我们的贡献者 Discord。

再次感谢大家，happy coding。🏕️

技术文档工程师如何参与开源贡献

Narcissus91 — Wed, 25 Oct 2023 04:26:00 +0000

原文： How to Contribute to Open Source – a Guide for Technical Writers

可能想到开源贡献，你就会觉得畏惧，尤其是如果你之前从未参与过开源贡献，或者你习惯的是写文档而不是写代码。

本指南将帮助技术文档作者开启开源项目贡献之旅，并概述在开始贡献时，你可能会遇到的常见误区。

另外，本指南会重点介绍一些参与开源贡献的好处，也会提供一些便于技术文档作者开始参与开源贡献的资源。

你能学到什么？

本文内容包括：技术文档作者参与开源贡献的方式、好处、一些潜在的坏处，以及一些新手入门资源。

什么是开源？

开源是一种软件开发与发布的协作方式。世界各地的人们通过为软件添加功能、修复bug（错误）、回答问题、翻译文本或写作教程来做开源贡献。

为什么要贡献？

为开源软件做贡献是技术文档作者和其他知识工作者回馈社会并为社会带来改变的最佳方式之一。

你可以帮忙改进你每天都在使用的软件，或者你可以从开源界前辈那儿学到东西。此外，参与贡献也是一种结识志趣相投的朋友的好途径。当你所做的贡献被人赞赏时，你会觉得自己是社区的一部分。

你可能会想自己应该什么时候参与贡献呢？嗯，如果你是开源新手，按你自己的节奏参与贡献就好啦——不要担心过早地尝试做太多。你会找到自己觉得舒适的节奏。

为开源做贡献不仅可以增加你的技能，还可以发展你的社区人脉，甚至创造自由工作的机会。

要成为一名活跃的贡献者需要花一些时间积累必要的知识和技能（尤其是因为通常文档写作所需要的技能是不同于编程的），但是，这些时间是值得投入的。

参与贡献会面临的挑战

技术文档作者在开始参与开源项目贡献时，会面临一些挑战。最常见的一项挑战就是不确定如何最大化做出贡献，特别是如果你还对项目一无所知。

你可能也不清楚你的任务应该做到什么程度或者这个任务对贡献者有什么期望。对于这个问题，有几个解决办法：你可以阅读 README 文件和/或文档，看看里面有没有贡献指南。你也可以与项目团队成员联系，并寻求帮助。

如何参与开源项目？

首先，在GitHub上找到你想要参与贡献的一个项目。你可以阅读这份教程查看如何在GitHub上进行搜索并找到项目。

然后，打开README文件，确保你理解里面提到的说明。

接着，点击屏幕右上角的Fork按钮，将这个repo（仓库）fork（复制）下来。

使用下列命令将fork（复制）的仓库复制到你的本地电脑：

git clone <链接到仓库>

当你点击代码下拉菜单时，会看到仓库链接。

复制好后，打开包含你的新fork的目录，开始添加你的贡献。

完成后，使用下列说明将你的修改推送到GitHub：

git status //显示哪些修改已经分阶段完成
git add . // 在复制的仓库里添加更改
git commit -m "changes" //对复制的仓库进行一次提交
git branch -M changes //创建一个新的分支
git push -u origin changes //推送修改

将修改推送到复制的仓库后，GitHub页面会弹出提示创建一个Pull Request（PR，拉取请求）。创建PR，等待项目维护者将你复制的仓库合并到主仓库。

如果你不久前fork了该项目，请确保将上游的修改纳入你的本地仓库 。

如果你遇到一个大文件，并且还没有安装git-lfs的话，就用这条命令brew install git-lfs去安装一个git-lsf。

Git LFS（Large File Storage大文件存储）是由Atlassian、GitHub以及其他开源贡献者开发的Git扩展。它通过缓慢下载大文件的相关版本（译注：将音频、视频、数据集、图形等大文件存放在远程服务器上）来减少文件在仓库中的影响。

你也可以根据这个文档安装git-lfs。

开源贡献的最佳实践

确定一个你可以提供帮助的领域，然后在GitHub上找到相关的项目。
阅读任何可能与你感兴趣的项目或程序相似的文档。这样你就会更了解贡献会涉及什么以及其他人做了什么贡献。
搜索标注了good first issue（适合第一次做开源贡献的人的任务）的问题，并通读这些问题——这些问题通常是很容易解决的。
遵循项目的贡献指南，准备好你的代码。
写一个详细的PR，给出你的解决方案，并解释为什么你的方案可以解决当前问题。如果有必要，附上相关资源的链接。
提交你的PR以待审阅。项目团队会讨论是否将你的PR合入仓库，并将结果更新给你。
如果他们决定不接受你的PR，你就询问如何能解决他们的顾虑，这样他们之后就会重新考虑接受PR。
如果他们确实接受了你的PR请求，记得表示感谢！
继续寻找要解决的新问题，并在此过程中分享你的进步！

我能做什么类型的贡献？

你可以通过多种方式为项目做贡献，包括为bug修复或功能新增提PR、编写软件使用文档、改进已有文档、翻译文档和修改拼写错误。

在深入参与贡献某个项目之前，你应该首先挑选一个你感兴趣的项目，并通读该项目的文档。

参与开源项目的文档写作，有助于将自己打造成行业专家并为将来获得自由职业机会做准备。

在为开源项目写文档时，技术文档作者始终应牢记的一点是，文档读者主要是开发人员。这意味着相较于其他类型的文档，读者需要在技术文档中看到更多的技术细节。

去哪里找开源项目？

有很多地方都能找到开源项目。GitHub是最受欢迎的地方，但在BitBucket、Gitlab和其它网站也有开源项目的仓库。

如果你有一个想法，但还没有对应的开源项目，可以先把你的想法和计划放在一个README文件中。如果你不确定如何开始为一个已有的项目做贡献，那么可以查看该项目的文档或通读一些PR，然后提交自己的PR。

示例项目

HTML5 Boilerplate项目是一个受Web网页开发者欢迎的开源项目。项目支持通过HTML、CSS和Javascript代码来创建网站或网页应用。
Bootstrap框架也是一个开源项目，是一个帮助开发者快速创建响应式网站的工具集合。
Jekyll 是一个用Ruby编写的静态网站生成器，为个人博客而设计。
React.js文档上有官方的React.js使用文档。
GitHub pages 包含所有你需要知道的GitHub信息。
Galaxy项目（培训资料）是Galaxy项目的一个培训资料集。该项目是一个基于网页的开放平台，用于数据密集型的计算研究，其范围超出了生物科学。
CNCF（云原生计算基金会） CNCF是开源的云原生计算，托管Kubernetes和Prometheus等项目，使云原生无处不在且可持续。

你还可以看看谷歌文档之季，它帮助开源项目优化文档，同时让技术熟练的技术文档作者获得开源方面的经验。

不同的贡献方式有很多，你总能找到适合自己的。

总结

对技术文档作者和内容创作者来说，参与开源贡献是一种很好的与世界分享知识的方式。

参与开源贡献的方式有很多，总之，人人皆可贡献。

Ep. 11 琚致远：多一份踏实和耐心，解锁技术旅程中更多可能性

Miya Liu — Thu, 28 Sep 2023 13:00:00 +0000

2019 年的夏天，我用文字的形式采访了致远。那时候他刚大学毕业，他说自己正在努力成为一名优秀的 Web 全栈工程师，希望自己未来可以踏踏实实，继续做自己喜欢的事情，在此前提下，能够鼓励、帮助身边的人自我实现。

这个 9 月，我邀请他作为播客嘉宾，聊聊他的学习、工作和生活，发现他这几年确实持续着这种状态：踏实地做喜欢的事情，也为他人提供帮助，不仅是一位优秀的开发者，也逐渐成为经验丰富的创业者。

琚致远

致远在 7 岁时接触计算机，小学、中学时自学编程，还尝试写程序帮助老师管理资料。在大学期间他带着同学一起承接技术项目，逐渐熟悉项目管理流程。他也帮助同学们学习编程，比如推荐他们使用 freeCodeCamp 的课程学习 Web 开发。

在经历了去德国做交换生、加入海外远程开发团队和网易研究院工作之后，他进入一个全球化的创业公司，担任 global team leader，也维护这个公司捐赠给 Apache 软件基金会的开源 API 网关项目 APISIX。

在节目中，致远聊到他如何适应从工程师转做客户支持，如何平衡商业和开源，以及给印度开发者捐赠最新款的苹果电脑，这些丰富的体验给我挺多启发，也让我想起 4 年前我在那篇访谈文章里写的：淡泊明志，宁静致远，愿我们始终年轻。

希望你也喜欢这期节目，期待你把致远的故事分享给更多朋友，当然也欢迎你给我们发邮件分享自己的故事。你可以在这篇文章里找到我们的邮箱地址。

欢迎在 https://chinese.freecodecamp.org/ 查看更多免费的编程学习资源。

主要话题

04:06 小学初中自学编程
05:33 脚本小子找回被盗的 QQ
06:39 投入 Web 开发
08:39 第一个正式个人项目
12:12 大学两年赚 20 多万
13:06 组建小型远程开发团队
15:32 怎么使用这么多钱
18:25 教同学们学 Web 开发
20:35 去德国做交换生
22:20 家庭的支持
24:57 不适应网易研究院的安逸节奏
26:39 在远程团队拓展技术
29:29 给 Ant Design 做贡献
31:59 为 APISIX 贡献 dashboard
36:28 从开源贡献者到创业伙伴
37:48 基于开源项目做企业版
39:25 如何进入 Apache 软件基金会
44:32 成为年纪最小的 Apache Member
46:38 在基金会中的收获
51:31 离用户最近
56:25 工程师转做客户支持
58:19 全球团队每周只开会半小时
60:38 平衡开源和商业利益
64:29 给印度开发者捐赠 MacBook
66:26 做好 2B 产品
71:23 参与进去

提到的资源

《琚致远：优秀 Web 全栈工程师的成长之路》(https://www.freecodecamp.org/chinese/news/fcc-devtalk-ju-zhi-yuan-growth-path-of-an-excellent-full-stack-web-developer/)
Ant Design
Apache 软件基金会
Apache APISIX
API7.ai
B2B Startup: Customers Want Solutions Than Software

Ep. 9 Rick：在开源世界里追求下一份“疯狂”

Miya Liu — Thu, 14 Sep 2023 13:00:00 +0000

我们今天的嘉宾是《开源面对面》播客的发起人和主播 Rick。

Rick

Rick 有多年研发工作经验，热衷于贡献开源，也通过很多方式帮助人们走近开源，比如以开源的方式维护一个播客。

他在学生时期对电子产品很有兴趣，大学时他自己组装电脑，开始摸索着学习软件开发，接着毕业后从事开发工作。

在工作几年后，Rick 逐渐为开源软件项目、持续集成工具 Jenkins 的中文本地化做贡献，有很多有意思的体验，比如收到 Jenkins 创始人 KK 的邮件、为中文版的工作提供支持，组织线上线下的技术交流活动，招募更多人参与翻译，通过和世界各地的开发者们沟通来练习英语。这些体验是在日常的开发工作中很难获得的。他形容自己在刚开始参与开源贡献时不计成本地投入大量时间。现在，他对于平衡参与开源和本职工作的时间，有了更全面的思考。

2021 年，Rick 和朋友们发起《开源面对面》播客，采访开源社区里的人们。他希望这个播客能帮助听众、嘉宾以及协作的伙伴都获得成功，给更多普通人带来价值。那他是如何以开源的方式维护这个播客、获得越来越多人的支持的？这个问题就留给大家在我们的节目中探索啦。

与回顾自己过往的成绩相比，Rick 觉得更令自己感到兴奋的是不断在开源世界里追求下一份“疯狂”。希望收听这期节目的你能从他的分享中得到一些能量，保持思考保持年轻。

如果你喜欢我们的节目，请记得在收听播客的平台上给我们五星或者好评，并把节目推荐给更多朋友。

欢迎在 https://chinese.freecodecamp.org/ 查看更多免费的编程学习资源。

主要话题

03:34 技术旅程的起点
10:08 什么时候开始接触开源软件
11:56 为 Jenkins 中文版做贡献
15:10 非常社区化的 Jenkins 社区
21:33 Jenkins logo 趣味设计
24:02 没有黑洞的开源社区
27:38 中文本地化
29:37 收到 Jenkins 创始人 KK 的邮件
33:27 working in public
33:42 在社区中的声誉
38:09 免费学英语的好环境
43:05 降低预期
46:40 首先让自己变得更成功
48:16 平衡工作和贡献的时间
55:38 站在舞台上是什么体验
65:10 社区是个万花筒
72:40 DevRel 开发者关系
77:38 1700 个项目
79:08 发起播客的初衷
82:38 开源的播客
85:05 公开和帮助别人
90:12 被听众吐槽“太烂了”
91:32 用声音记录改变
93:09 帮普通人打破限制
96:40 追求下一份“疯狂”
98:58 欢迎参与《开源面对面》协作

提到的资源

Ep. 7 水歌：在开源社区中成长，在开放生态中为社会创造价值

Miya Liu — Thu, 31 Aug 2023 17:05:54 +0000

在开源社区中成长和贡献 20 年是一种什么样的体验？

这期节目我们邀请了嘉宾水歌。他是一位 Web 全栈工程师，是 WebCell 前端开源框架作者，也是一位创业者。

水歌

水歌在念初三的时候，抱着试一试的心态，在 Ubuntu 网站上填表申请免费操作系统的安装光盘，然后真的收到从欧洲寄来的 9 张 CD 和 1 张 DVD，这开启了他在开源世界中的旅程。

在接下来将近 20 年的时间里，他在高中和大学校园里创办 IT 社团、在本地城市组织 freeCodeCamp 社区技术交流活动、开发开源框架、发起开源市集、组织开源实训、推广“开放式协作”的理念......他持续在开源社区中贡献和成长，也帮助身边的人们成长。

接下来，我们从水歌的分享中感受一位开发者的成长经历，以及如何应用技术在开放生态中为社会创造价值。

如果你喜欢我们的节目，请记得在收听播客的平台上给我们五星或者好评，并把节目推荐给更多朋友。

欢迎在 https://chinese.freecodecamp.org/ 查看更多免费的编程学习资源。

主要话题

03:35 技术旅程的起点
07:36 第一次了解开源
12:05 在高中创办技术社团
15:30 自己动手解决问题
19:39 开源的核心是“开放式协作”
24:22 开源社区的人们在做什么
26:00 通过编程改善书店的工作流
33:12 为 jQuery 做第一次开源贡献
34:42 新手如何给开源项目做贡献
37:35 JavaScript 开源生态
41:32 如何做自己的开源项目
43:18 选择什么开源许可证
49:51 英语水平是参与开源的障碍吗
52:30 通过办技术活动提升自信
58:46 成为微软 MVP
63:08 因为台湾开源社区的启发发起开源市集
70:26 用开源的理念创业
85:13 最重要的是“主动”

提到的资源

如何使用 GitHub Actions 实现开源项目的自动化

Chengjun.L — Thu, 30 Mar 2023 10:21:00 +0000

原文： How to Use GitHub Actions to Automate Open-Source Projects

如今，开发人员经常使用自动化工具来有效地管理任务，并简化他们的日常活动。GitHub Actions 就是这些流行的工具之一。

你可能会同意我的观点：软件（包括开源软件）对效率的要求很高。在这种自动化工具的帮助下，维护者可以将重复性的工作自动化，并专注于更重要的任务，如编写高质量的代码、审核贡献，以及围绕项目创建一个活跃的社区。

我曾经不得不手动完成一些本可以自动化的任务，所以我觉得我有资格分享如何使用 GitHub Actions 来节省时间。

我花了大半天的时间去研究我的一个已经吸引了贡献者的迷你 Python 项目。我给新的贡献者写热情洋溢的欢迎词，检查最近 pull requests，以确保他们遵守项目的规则比如 README 文件和说明、如果需要的话提供截图，等等。

但我不知道的是，我可以自动执行其中一些任务以及更多任务，以减少自己的工作量。我可以在 GitHub Actions 的帮助下做到这一点。

在本指南中，我将分享更多关于 GitHub Actions 的信息，以及我如何使用它。我将向你展示如何利用它来自动化项目的各个方面，从欢迎新贡献者到分配任务、检查代码质量等等。我们一起来让你的项目更加高效、更具有交互性。

GitHub Actions 是什么

GitHub Actions 是一种工具，可让你在 GitHub 仓库中执行不同的自动化操作。它允许你创建自定义工作流，你可以使用这些工作流来自动化开发过程，例如构建、测试和部署代码。

将此工具与其他 GitHub 功能集成后，你可以转变你的项目管理程序，让每个参与其中的人都更加愉快，更加有参与感。

如何在你的仓库中设置 GitHub Actions

一切都从根文件夹开始。默认情况下，GitHub Actions 通常集成在你的 GitHub 仓库中，因此你无需在安装时注册单独的账户。但是你需要执行几个步骤才能访问它的功能。

在你的 GitHub 仓库中，在顶部导航选项卡上，你将看到 Actions 选项卡。单击它，你可以访问推荐的工作流列表以及创建自己的工作流的选项。
现在，根据项目的性质，你可以选择从可用列表中选择一个已经创建的工作流，也可以选择自己创建一个。由于你了解项目的全部内容以及可能需要自动化的内容，因此我建议你自己设置一个新的工作流程。这将使你更好地了解正在发生的事情。
要设置新的工作流程，请单击 Set up a workflow yourself（自行设置工作流程）。这将带你进入一个工作流创建界面，其中包含一个名为 main.yml 的新 YAML 文件。既然你选择编写自己的工作流程，在这里，我应该提到了解 YAML 非常重要。

在幕后发生的事情是，一旦你单击此选项，就会在 main.yml 文件旁边创建两个文件夹。如果你之后访问你的仓库或查看文件名之前的路径，你将看到：.github/workflows/。

在 main.yml 文件中是你定义工作流程的地方，在编写完所有内容后，你可以提交更改（commit the changes），就像对仓库进行更改时所做的那样。这样，你就设置了工作流，它将根据 YAML 文件中定义的触发器运行。

或者，你仍然可以在你最喜欢的代码编辑器中完成这一切。你需要做的就是将仓库克隆到你的计算机上，在项目的根文件夹中创建一个 .github 文件夹，在其中创建另一个名为 workflows 的文件夹，最后添加一个扩展名为 .yml 的文件并将你的脚本写入这个文件。

在下面的示例中，我将引用我在项目中实现的代码来帮助你理解。

GitHub Actions 组件

GitHub Actions 主要由三个主要组件组成，包括：

工作流（Workflows） - 这些是定义自动化过程的规则集。它们在 YAML 文件中定义，该文件存储在 .github/workflows 目录中。
事件（Events） - 它们启动工作流。例如，你可以将事件设置为在创建 PR 或新开 issue 时运行工作流。要在工作流中定义事件，请使用关键字 on 后跟事件名称。

例如：

on:
    issues:
        types: [opened]
    pull_request_target:
        types: [opened]

任务（Jobs） - 这些构成了工作流程。默认情况下，任务是同时运行的。要在给定的工作流中定义你的任务，请使用关键字 jobs，后跟每个任务及其配置的唯一标识符。

例如：

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: 3.10
      - name: Install dependencies
        run: |
          pip install -r requirements.txt

所有这些组件确保一组特定的规则被成功执行。现在看看我们的项目。

如何自动化管理 issue 和 pull request

管理 issue 和 pull request 可能是一项非常耗时的工作，尤其是对于大型开源项目。但有了 GitHub Actions，维护者就可以把这些流程自动化，把更多的时间花在编码和与社区互动上。

如何创建 issue 和 pull request 模板

如果你是一个活跃的开源贡献者，你有可能遇到过一个指南，告诉你在创建 issue 或提交 PR 时应该包括什么。这种模板的主要目的是提供指导，确保贡献者提供所有必要的信息。

现在，让我们看看你如何在你的项目中创建这个模板：

第一步是确保在仓库的 root 中有一个 .github 目录，如果你还没有的话。
在 .github 文件夹内，创建两个文件夹 ISSUE_TEMPLATE 和 PULL_REQUEST_TEMPLATE。
在这两个文件夹中，添加代表你想自动化内容的 markdown 文件：例如，你可以将 feature_request.md 和 issue_report.md 作为 issue 模板，将 pull_request_template.md 作为 PR 模板。

下面是我在 pull_request_template.md 文件中写的内容，作为参考。这是一个简单的指南，告诉贡献者在提交 pull request 之前应该包括什么。

**Related Issue(s):**
Please provide a title for this pull request.

**Description:**
Please provide a brief description of the changes you are proposing.

**Checklist:**

-   [ ] I have read and followed the [contributing guidelines](/CONTRIBUTING.md).
-   [ ] I have included a README file for my project.
-   [ ] I have updated the main README file where necessary.
-   [ ] I have included a requirements.txt file.
-   [ ] I have added tests that prove my changes are effective or that my feature works.
-   [ ] All new and existing tests pass.

**Screenshots**
If applicable, add screenshots to help explain behavior of your code.

**Additional Notes:**
Please provide any additional information about the changes you are proposing.

如需更详细的解释，请在这里查看 GitHub Action 关于 issue 和 pull request 模板的文档。

欢迎新的贡献者并表彰社区的努力

作为一个维护者，与社区打交道是很重要的，因为你有机会与你的朋辈直接互动并获得反馈。但如果你正在运行一个吸引众多贡献者的大型项目，你可能不会经常有机会直接与社区互动。

在 GitHub Actions 的帮助下，你可以完成其中的一些任务，比如欢迎新的贡献者，认可他们的努力，并为现有的社区成员创造一个积极的氛围。

如果你正在管理一个小项目，你可能可以直接与社区互动，但仍然利用自动化来完成一些工作。

例如，这里有一些示例代码，当新的贡献者创建 pull request 或在仓库上创建一个新的 issue 时，我通过这些代码来欢迎他们。在其中，你可以看到我有一条信息，感谢他们的努力，也向他们保证我将尽快审核他们提交的修改。尽管如此，如果需要额外的东西或提出新的想法，我还是会通过对话去跟进。

name: Welcome New Contributors

on:
    issues:
        types: [opened]
    pull_request_target:
        types: [opened]

jobs:
    welcome:
        runs-on: ubuntu-latest
        steps:
            - name: Welcome Issue
              if: github.event_name == 'issues'
              uses: actions/github-script@v5
              with:
                  script: |
                      const issue = context.issue;
                      const repo = context.repo;
                      const issueAuthor = context.payload.sender.login;
                      const welcomeMessage = `
                        Hi @${issueAuthor}! :wave:
                        Thank you for creating an issue in our repository! We appreciate your contribution and will get back to you as soon as possible.
                      `;
                      github.rest.issues.createComment({
                        ...repo,
                        issue_number: issue.number,
                        body: welcomeMessage
                      });
            - name: Welcome Pull Request
              if: github.event_name == 'pull_request_target'
              uses: actions/github-script@v5
              with:
                  script: |
                      const pr = context.issue;
                      const repo = context.repo;
                      const prAuthor = context.payload.sender.login;
                      const welcomeMessage = `
                        Hi @${prAuthor}! :wave:
                        Thank you for submitting a pull request! We appreciate your contribution and will review your changes as soon as possible.
                      `;
                      github.rest.issues.createComment({
                        ...repo,
                        issue_number: pr.number,
                        body: welcomeMessage
                      });

除了这个简单的工作流程外，如果你正在领导一个更复杂的项目，你可以考虑编写一个更详细的工作流程，能够自动为贡献者分配徽章、标签或自定义标题。

同样，你也可以选择添加一个工作流，在贡献者的 pull request 被合并或 issue 被关闭时对其表示感谢。你可以查看 GitHub Action 文档，了解详细的指南。

如何实现代码 QA 的自动化

对于大多数开发人员来说，编写高质量的代码是非常重要的，特别是如果他们正在创建与消费者有关的应用。虽然一个项目的成功取决于精心编写和测试的代码，但有时审核修改可能会花些时间，甚至会使用户正需要的功能延迟上线。

在代码自动化工具的帮助下，你可以保持一致的编码风格，并快速和容易地识别潜在的错误，保持你的项目整洁。

那么，如何用 GitHub Actions 设置持续集成（CI），整合代码 formatting 和 linting 工具，并在项目中使用自动化代码审核服务？

持续集成（CI）帮助你实现流程自动化，如构建、测试和验证代码更改。就像其他自动化代码一样，CI 代码写在一个 .yml 文件中，存储在 .github/workflows 文件夹中。

下面是一个 Python 项目 CI 工作流程的例子，它在向仓库的 main 分支 pull request 时运行。它测试 Python 多个版本的代码，安装必要的依赖，并使用 unittest 模块运行测试。

name: Python CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.7, 3.8, 3.9, 3.10]

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v2
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run tests
      run: |
        python -m unittest discover

除了上面的代码，如果你想保持代码风格的一致性，你可以整合代码 formatting 和 linting 工具，如 black、isort 或 flake8。为此，你只需要在 requirements.txt 文件中加入这些工具，该文件已经包含在上述代码中。下面的代码块运行这些工具。

#...
    # ...
    - name: Run black for code formatting
      run: |
        black --check .
    - name: Run isort for import sorting
      run: |
        isort --check --diff .
    - name: Run flake8 for linting
      run: |
        flake8 .

如果它发现任何代码格式问题，CI 构建将失败。要解决这个问题，你必须手动检查日志。请查看这个关于构建和测试 Python 的指南，了解更多的例子。

上面的想法只是你可以在项目中使用的一些自动程序。对于一个更复杂的应用，你可以考虑增加工作流程，用 Sphinx 或 MkDocs 等工具生成文档，自动化依赖性更新，自动化发布管理和项目跟踪，等等。

关于构建自定义 GitHub Actions 的提示

在 GitHub Actions 市场上已经有很多预制的 action。但有时你可能想要或需要定制工作流程以满足你的需求。

为此，你可以选择 JavaScript 或 Docker 容器，并与社区分享。

这里有一些可以遵循的最佳做法：

了解问题 - 就像其他项目一样，在开始构建之前，确保你了解要解决的问题以及你将如何解决它。
选择正确的技术栈 - 如上所述，可以使用 JavaScript 或 Docker 编写 GitHub Actions。请确保选择最适合你的需求和理解的方式。
确保你遵守最佳的编码实践，以便别人能够轻松地理解和阅读你的代码。
利用已有的软件包，如 @actions/core 和 @actions/github，它们提供了与 GitHub Actions 环境和 GitHub API 的简单互动。
在成功创建自己的工作流程后，你有可能想要发布它。无论你是否发布，请确保测试你的 action 是否有潜在的问题或错误。

通过这些简单的技巧，你可以创建一个自定义的 GitHub Action 来自动完成项目中的一些主要/基本任务。除了上面的提示，你可以在官方文档中找到更多关于创建自定义 action 的详细信息。

总结

在本指南中，我们看到了 GitHub Actions 能给我们的项目带来的好处。它不仅简化了生产流程，而且还允许我们自定义 action 以适应项目需要。

这仅仅是我们能实现的东西的一小部分。我鼓励你更好地理解和探索不同的方法，以进一步用 GitHub Actions 改进你的开源项目。让我们拥抱自动化，利用它来完成更多工作。

初学者的开源项目参与指南

PapayaHUANG — Fri, 09 Sep 2022 02:36:00 +0000

原文： Open Source for Developers – A Beginner's Handbook to Help You Start Contributing

听到开源的时候你脑海中会浮现什么画面？在编程世界中，开源是开源软件（OSS）的统称。开源软件建立在对所有人开放查看、更改、扩展和分发的源代码之上。

本文将讨论开源软件和其生态系统的各个方面。包括为开源项目贡献的条件、你需要掌握的技能、如何维护开源项目、挑战和资源，以及一些你可以开始着手尝试的激动人心的项目。

在开始之前，让我简单介绍一下我自己以及我对开源社区的兴趣。

我每天都会使用开源项目、产品和服务，我也参与贡献开源项目提升自我。我维护着一些向初学者提供 Web 编程教学的开源项目。

你可以在我的 GitHub 资料上查看我的开源项目。

如果你尚未开始贡献开源项目，我将通过这篇文章分享我自己的经验帮助你开启开源之旅。

开源是如何运作的？

开源项目包含以下人物和元素：

项目维护者：维护者有一位或者多位，他们启动开源项目、管理项目、制定决策、集思广益并且和贡献者、用户以及营销平台密切接触。

项目维护者拥有额外的权利来控制项目的各个方面。

项目贡献者：启动开源项目的维护者是早期贡献者。随着项目的壮大，更多人了解到项目并且愿意参与贡献。

项目越大，贡献者越多。任何人都可以查看项目代码、修改代码、请求校对并将改变并入项目中。

源代码和文档库：维护者将项目源代码保存在一个中心化的源代码库（例如 GitHub）。这样所有贡献者就可以访问代码并且参与贡献。

项目许可证：每一个开源项目都必须指定一个分发许可证，给用户和使用者提供清晰的信息。

有各种各样的许可证，维护者可以根据项目做选择。比较广泛被采用的许可证包括：MIT、 Apache License 2.0、 GNU General Public License（GPL）3.0 等。

贡献指南：OSS 项目的维护者创建贡献指南帮助贡献者理解合并请求（pull request）的流程、标准、范围等。

行为准则指南：行为准则指南讨论各种指导方针、对贡献者的协同和行为期望，以及如何提出和解决 issue（问题）。

项目文化：项目文化随着项目社区发展而变化。虽然维护者对其影响重大，但贡献者也有同样的责任来维护一个健康学习、分享和成长的文化。

社区：随着项目发展，围绕项目的社区也发展起来。组织社区交流的常用平台有 GitHub Discussions 和 Discord。

分发：开源项目应该接触到终端用户和消费者，所以应该有一个分发模型将代码转化为最终的产品，进行交付。

用户/客户：用户和客户是开源团队通过源代码构建产品的消费者。

让我们查看下面的图片，图片是一个包含维护者和开发者的开源项目社区。

中心化的仓库里包含源代码。贡献者 fork（分叉）（你马上要学到这个术语）upstream repository（上游仓库）并贡献。一旦完成，项目维护者将其 merges（合并）到主分支（main branch）。

开源项目运作模型的高层视角

如果你不熟悉 fork、 branch、 merge 这些词，不用担心！我们马上就会讨论这些词，请继续阅读。

现在让我们讨论一下开源软件是如何交付给用户/客户的。

下面的图片显示了一种可能性的高层视角。开源项目应具有构建-打包-部署机制，该机制使用持续集成和持续部署（CI/CD）流程。

每当main branch（主分支）的代码发生改动，CI/CD 工作流就开始自动工作：构建源代码、打包并部署，供终端用户和目标客户能够使用。

从源代码到用户的高层视角

请注意：CI/CD 或者其他部署机制并不是开源软件开发的一部分，但了解它有助于理解 OSS 端到端的工作模型。

开源项目贡献是什么意思？

开源贡献就是使用一切办法来提升开源项目。一个常见的误解是你只能贡献源代码，完全不是这样。

贡献源代码是参与开源项目的一种形式，但是还有其他方式：

项目的文档。提高文档质量，帮助贡献者和用户更容易参与和使用。
测试应用、发现问题，并在问题管理系统创建问题（issue）。
参与代码校对，帮助提高项目的编码标准。
编写单元测试、端到端测试，使得应用的质量更高。
创建如文章、视频之类的内容来提升项目的知名度。
帮助创建兴趣社区。

以上都是重要的开源贡献方面。

参与开源贡献的好处

贡献开源项目对于开发者来说好处多多，但是主要的好处有：

抓住机会、提高技能水平
提高软件/应用的代码和文档水平
接触想法相似的朋友、建立人脉和社区
理解应用开发和维护的流程
从 Pull Request 反馈中学习
学习如何管理自己的开源项目

开源迷思

我们已经了解了开源模型和它的好处。接下来我们就要学习如何作为项目的维护者 和参与者来开启开源之旅。

在开始之前，让我们先消除一些迷思。

❌ 迷思：我不了解代码，开源不适合我。

✅ 事实：开源不仅仅是编写代码！你可以通过改善文档、测试、创建媒体、内容等各种方式参与进来。所以不要让不具备编码技能成为你参与开源项目的绊脚石。

❌ 迷思：我知道怎么写代码，但是我对开源项目使用的技术不熟悉，我不能贡献。

✅ 事实：相反，这是学习新东西绝佳的机会！开源生态系统提供足够的时间和耐心让你学习和参与贡献。

❌ 迷思：开源项目的维护标准不如企业。

✅ 事实：完全不对，实际上有非常多的企业软件来源于开源软件，所以认为开源项目的质量和标准不高不对。

❌ 迷思：开源项目难以维护。

✅ 事实：开源项目是由贡献者支持的。维护者主要的工作是设定范围、创建路线图、创建社区以及保持社区的贡献热情。

许多开源项目的维护者甚至不需要编写代码。只要维护者提供必要的支持，贡献者就可以将项目运作起来。

❌ 迷思：开源软件总是免费的。

✅ 事实：大多数开源项目是免费的，但不是所有的都是。这是由项目的许可证所决定的。有一些许可证要求必须让使用和分发免费。你需要格外注意项目许可证信息，了解 OSS 到底免费到什么程度。

❌ 迷思：开源项目只适合初学者。

✅ 事实：许多开发者认为开源项目是为初学者和学生设计的，实际上任何人都可以参与进来。对于主题专家来说，利用他们的知识和经验来增强开源项目是有意义的。

开始参与开源需要具备什么条件？

开发者想要快速开始参与开源项目需要了解一些基本技能。这些是可选的，但是如果具备，你将更享受参与开源贡献。

了解 Git 基础

如果你已经了解 Git 的概念及其主要用途，那么你已经前进了一大步。Git 在开源世界中无处不在，你不能忽视它。

你至少要了解以下话题：

什么是 Git，它是怎么运作的？
仓库是什么？
如何复制（clone）一个仓库？
如何 stage/un-stage（暂存/取消暂存）修改？
如何 commit（提交）你的修改？
如何编写更好的提交消息？
如何解决合并冲突？
如何将你的修改推送（push）到远程仓库？
如何从远程仓库拉取（pull）修改？

如果你尚不了解 Git，我推荐你观看这个视频，了解 Git 的概念和上面提到的用例：为初学者揭开 Git 的神秘面纱。

熟悉 GitHub

GitHub 上有超过 1.28 亿个公开仓库，其中很大一部分是开源项目。你想要参与贡献的开源项目可能在 GitHub 上，所以你应该学习如何使用 GitHub。

作为开源项目的贡献者，你应该知道：

如何 fork（分叉）一个仓库？
如何找到仓库的 URL 并 clone（克隆）仓库？
如何创建一个 Pull Request？
如何校对一个 Pull Request？

作为一个项目维护者，你应该知道：

如何创建一个仓库？
如何为项目添加许可证信息？
如何创建贡献指南和行为准则指南？
如何创建提交 issue 和 pull requests 的标准？
如何合并 pull requests？

你可以关注下面的 Twitter thread，它分步骤讲解了上面的所有信息：

Do you have public GitHub repositories?

Here are 10 tips to help you with,

🤝 Gain more engagements
💻 Code contributions
⭐ Acknowledgment of work(like stars, maybe sponsors)
🔥 Building followers on GitHub

A Mega Thread

🧵 👇
— Tapas Adhikary (@tapasadhikary) September 21, 2021

学习如何 fork（分叉）一个仓库

Fork（分叉）是一个重要的概念。大部分开源 项目不允许贡献者直接在仓库创建分支。取而代之的工作流如下：

fork（分叉）仓库。
clone（克隆）分叉后的仓库。
编写修改。
从 UPSTREAM（上游）提取修改。
创建从分叉仓库到基础仓库的 pull request。

在我和众多贡献者的工作经验中，大部分人觉得理解 fork（分叉）的概念有点困难。

你可以通过这个视频学习 fork的概念：如何分叉一个 GitHub 仓库。同时你可以在这个 GitHub 仓库练习分叉，这是为初学者设计来提升信心的仓库。

学习解决合并冲突（Merge Conflicts）

如果询问任意一位开发者对解决待合并冲突的看法，你得到的答案会是不那么简单。遇到得越多，自然就更熟练。了解解决合并冲突的过程，并且思考背后的逻辑和如何具体操作十分有必要。

这里有一份解决合并冲突实用指南，欢迎查阅。

学习 Markdown 语法

文档是任何开源项目的基础。Readme.md文件介绍了项目，如何设置、运行、部署等。

Contributing.md文件介绍如何给项目做贡献。

CODE_OF_CONDUCT.md文件介绍了对贡献者行为和参与的期望。当然，你可以基于自己的项目，编写任意 .md文件。

md代表着 markdown（标记语言），是一种在 GitHub 上用于写文档的语法。了解基础的语法有助于你流畅地编写文档。

这里有一个开源项目提供了 Markdown 语法，可以复制和使用。欢迎查阅。

发展你的软技能

开源是许多开发者工作、学习和共同创建的天地。若想成为一位贡献者，仅仅具备技术技能不足以让你在此畅游。

让我们来看看开发者需要具备的一些软技能：

耐心：耐心是所有开发者必备的技能。当你在学习新知识，排查复杂问题的 bug，和其他人一起工作、谈判，给予和吸收意见的时候都需要耐心。事情常常不如预期的节奏推进，所以你需要保持耐心面对现状。
好奇心：好奇使人进步。参与开源贡献将拥有无限可能。你需要对解决问题充满好奇心。好奇心不仅适用于解决技术难题，也适用于和他人一起工作。
责任心：在开源生态中，你可能不会经常和人见面及交流。你必须对所有查询、任务、请求以及委任于你的事情负责。许多伟大的倡议往往因为人们缺乏责任心而不了了之。
谦逊之心：谦虚是成功的关键。有学识但不谦逊的人往往不适合团队协作。

如何开始参与开源项目贡献？

让我们来看看如何开始参与开源项目贡献。下面的清单提供了一些链接和资源助你马上开启开源贡献之旅。

GitHub Explore

GitHub Explore 会向你展示你感兴趣的仓库，你可以给特定仓库设置提醒。

同时，你可以使用话题和趋势来寻找仓库。使用 GitHub Explore 来寻找最合适你的技能、需求以及对你最有启发的项目。你可以通过这个地址查看：https://github.com/explore/。

如何参与 freeCodeCamp 的开源项目？

freeCodeCamp 的仓库绝对是一个宝藏，它提供了许多资源和知识帮助你开启开源之旅。你可以通过这个地址查看：https://github.com/freeCodeCamp/how-to-contribute-to-open-source。

Contributor Ninja

这个网站供你选择一系列编程语言：JavaScript、 HTML、 Rust、 Go 等。你可以通过卡片选择对应的仓库，简单方便，是一个不错的开始。你可以通过这个地址查看： https://contributor.ninja/。

First Contributions

这是一个巨大的清单，包含供你查找和过滤的开源项目。每个项目都有编写清晰的文档。你可以通过这个地址查看：https://firstcontributions.github.io/。

CodeTriage

CodeTriage 是一个包含巨量开放 issue 项目的清单。它将 issue 和文档归类后分发给你。这个网站十分有用，你可以通过这个地址查看：https://www.codetriage.com/。

Up For Grabs

这里包含了各种各样的开源项目，你可以基于自己兴趣筛选。你可以通过这个地址查看：https://up-for-grabs.net/#/

First Timers Only

如果你之前从未参与开源贡献，并且跃跃欲试，可以考虑阅读这个网站。

在阅读的过程中，你或许会碰到我们讨论过的资源，这个网站能量满满。你可以通过这个地址查看：https://www.firsttimersonly.com/。

Open Source Friday

你本周五或者下周五有什么打算？花点时间给你使用或者喜欢的软件做点贡献？推荐你查看这个网站并且注册。你可以通过这个地址查看：https://opensourcefriday.com/。

希望这些资源对你来说有帮助。另外，你还可以查看这个 Twitter thread 以及相关的回应，你或许会有所收获。

Looking forward to contributing to OPENSOURCE? Here are 8 RESOURCES to get you started immediately.

A 🧵 👇
— Tapas Adhikary (@tapasadhikary) September 8, 2021

开源项目维护者

到目前为止我们讨论的都是开源项目的贡献者，如果止步于此这篇文章就不完整，所以我们也讲讲开源项目维护者相关的内容。

作为项目维护者，你应该遵循一些标准使得其他人能够理解并且参与贡献你的项目仓库。

提供项目明确的名字和介绍。你也可以添加项目相关的话题。
添加清晰的Readme.md文件介绍项目的目标、如何使用、设置等。如果说源码是项目的心脏，那 README 文件就是项目的脸面。
建立社区档案。开源仓库维护者可以通过它来检查工作、了解哪里需要帮助。
建立编码行为准则。
创建贡献指南。
决定 issue 的模板。
创建 Pull Request（PR）模板。
激活 GitHub 赞助。

你可以通过阅读这篇文章了解更多细节。

在结束之前......

就这么多！到这里，我们就到了本文的结尾。希望这篇文章对你有所启发，并且给了你足够的动力开始为开源做贡献。

在我们结束之前，我想再提几个开源项目和仓库：

这个列表可以继续增加，但让我停在这里。如果你喜欢阅读本文，或有任何疑问想要联系我，可以在以下地方找到我：

谷歌文档之季（Google Season of Docs）项目申请指南

Narcissus91 — Tue, 19 Jul 2022 07:00:00 +0000

原文：How to Crack the Google Season of Docs Application Process for 2020，作者：Edidiong Asikpo

近年，有调查表明良好的文档对开发者如何选择和使用开源非常重要。

2019年首届Google Season of Docs（GSoD，即谷歌文档之季）项目，共收到了近450份技术写作者的申请，最终有50多名技术写作者被录取。

作为入选参加GSoD项目的技术写作者之一，我想分享一些关于如何为GSoD项目做准备并制作有竞争力申请书的想法。

Google Season of Docs是什么？

文档之季是一个由谷歌组织的年度项目。其目标是连接开源组织与技术文档写作者，促进开源领域中的文档协作和提升。

这项活动非常重要，因为通过开源项目的文档，用户不仅可以理解该项目，还可以为项目做出贡献。

在项目期间，入选的技术写作者将花费3-5个月的时间来构建一套新的文档、改进现有文档的结构、开发一个急需的教程或改进一个开源组织的贡献流程和指南。

哪些人有资格参与该项目？

根据谷歌的规则，在注册时你必须已年满18岁。你还必须有技术写作者的实践经验，并且有资格在你的居住国工作。

如果你符合这些资格，就可以申请参加GSoD项目。

参与该项目的好处

参加文档之季项目，有很多好处，比如：

你可以获得一笔津贴

在完成GSoD项目后，你会获得由谷歌支付的一笔津贴。值得注意的是，这项津贴是可选的，因此你必须在申请阶段表明你希望获得津贴。

津贴金额是基于申请人所在地区的情况来计算的。有关津贴的完整详细信息，请参考此处。

你可以提高自己的技能

参与GSoD项目的另一个明显好处是，可以提高你的技术写作技能。

你可以扩大自己的人际圈子

除了提高自己在技术写作方面的技能，你还有机会与在开源领域做着了不起事情的人一起工作。

就我而言，我有机会与VideoLAN组织合作，这意味着我必须与该组织的社长和项目的主要贡献者密切合作。

你可以获得推荐和介绍

在申请任何工作时，一封好的推荐信往往有助于提高你申请的成功率。

与文档之季项目的导师紧密合作，将有机会获得丰富的推荐和介绍资源。

你可以获得未来进入谷歌的机会

如果你准备申请谷歌的技术写作职位，那么与其他申请人相比，你简历中的文档之季项目经验会让你有更多优势。

你可以成为一个开源贡献者

除了上述所有好处之外，参加文档之季项目意味着您可以为开源项目做出贡献。这有助于人们打破开源贡献仅适用于软件开发人员的刻板印象。

让你的GSoD申请脱颖而出的5个建议

以下5个建议，帮助你为GSoD项目做准备和制作有竞争力申请书。

在你的博客上创建和发表文章

在GSoD项目中被录取为技术写作者的最重要标准之一是能够证明你以前有写作经验。

谷歌和你想从事项目的拟派导师需要确信你是从事该项目工作的合适人选。这意味着他们希望能看到你创作的大量优质文档和文章。

值得一提的是，现在去创建一个博客或在现有博客上发布更多内容还不算太晚。

如果您已经有一个博客，那么在你提交申请之前、期间及之后发表更多优质文章是个不错的方法。如果你没有任何博客，那么使用Hashnode's Devblog或你喜欢的平台创建一个博客并发布优质文章仍为时不晚。

选择合适的开源项目

事实上，我再怎么强调选择合适的开源项目的重要性也不为过。这是因为它对你是否能进入该项目有重大影响。

以下是我对选择合适项目的想法：

认真查看所有已录取的项目，并尝试选出至少5个你感兴趣的项目。
选出至少5个项目后，再次浏览，将项目数量缩减至2到3个。
虽然可能在申请阶段只专注于一个项目是合理的，但我鼓励你至少申请两个项目，这样你至少被一个项目录取的机会就会更大。
对于你选择的每个项目，加入其所在组织的沟通渠道，并让项目的维护者知道你对该项目的兴趣。这样，你将能够与导师建立关系。另外，请注意，导师选择人时并不仅仅因为申请人拥有必要的技能，还因为他们认为申请人能够与他们合作。因此，当你向导师发送信息时，要明确说明你的需求。最重要的是不要因为他们没有立即回复而感到沮丧，因为大多数导师都是有其他全职工作的志愿者。
不要被动等待。对项目进行大量研究，去发现并理解你需要了解的所有内容，如果你有任何疑问，请向该项目的拟派导师寻求帮助，或询问该社区的其他成员。
最重要的是，在研究过程中，写下任何有用的信息。一些信息在将来若你被某项目录取后，可能会用上。而一些信息可以用于优化你的提案。

撰写一份提案

很多人不知道这一点，但写一份提案是至关重要的。它让你清楚地了解项目的目标、你完成项目所需的时间线、你需要了解的内容等等。

除此之外，写提案还可以向你的导师展示你对该项目的目标、为什么你认为你是这个角色的合适人选、你的经验、项目时间线等等。

写完提案后，将其发送给项目的导师进行审核。他们的审核将帮助你从导师的角度了解项目的要求。我在Resources部分添加了我的GSoD提案的链接。

至少为开源组织做出一项贡献

文档之季项目并不像Google Summer of Code（GSoC，即谷歌编程之夏）项目那样要求你对感兴趣的开源项目至少做出一项贡献。但是做出贡献绝对可以提高你被录取的机会，所以试试吧。

在申请截止日期后仍在社区中保持活跃

提交申请后，尽量在该开源组织中保持活跃。这可以最大程度地向导师们表明，你对这个项目和开源社区充满热情。

我的GSoD项目经验

在去年的GSoD项目中，我有机会与VideoLAN组织合作开展VLC用户文档现代化（重写）项目。

在我的提案被VideoLAN组织接受后，我的导师和我就商定了我在GSoD项目中要实现的目标。

这些就是我的目标：

重构文档。
更新文档以适应VLC的现代版本。
使用Sphinx和ReadtheDocs将用户文档迁移到Gitlab。
删除过时的图像和信息。
重写用户文档，使其易于理解。
使用国际化版Sphinx进行翻译。

我对VideoLAN组织和VLC有了更多的了解，我发现了很多我从未了解的VLC功能，并且我学会了如何使用Sphinx文档平台并重构文本。

我的技术写作技巧也得到了极大的提高。总的来说，参加GSoD项目是2019年我经历的最好的事情之一。

有用的参考资源

以下是一份有用的资源列表，帮助你了解更多关于文档之季项目和技术写作的信息。

喜欢这篇文章？Twitter上关注我@Didicodes。

如何为开源项目做贡献

luojiyin — Fri, 29 Apr 2022 10:08:00 +0000

原文：How to Contribute to Open-Source Projects – A Beginner's Guide，作者：Ankita Tripathi

如果你一直在考虑为一个开源项目做贡献，你可能正在权衡这样做的利弊。

你可能会听到这样的话：开源项目不会帮助你成长，或者它们不能改变你的职业轨迹，还有，你的贡献肯定不会为你的简历增添光彩。

如果你曾经听到过这样的话，这些人可能对为开源项目做贡献的好处了解不多，而实际上好处是很多的。

在这篇文章中，我将分享贡献机会和以及如何开始贡献。

许多人认为，开发人员总是在孤岛上工作，与外界没有任何联系。

但现在的开发者不一定是这样的，他们：

在公开场合创造东西
在社交媒体上很活跃，而且
积极与世界各地的人联系

事实上，开源项目比其他任何东西都更能将开发者聚集在一起进行合作。

什么是开源？

你可能经常听到关于开源项目和在公开场合构建项目的说法，但这些术语是什么意思？

最简单的是，它意味着你所创造的东西是免费的，开放给任何人使用。它还意味着，随着合作的进行，你的项目会不断变得更好。

开放的博客平台

使用开源，你可以让其他人自由地学习或参与构建你现有的项目。

现在有很多平台可以让开发者有机会公开写作。有 Hashnode、Dev.to、谷歌的 Dev Library，还有更多。我们甚至可以称这些开发者为 “Developer-as-a-blogger”（DaaB），因为他们的博客贡献。:)

我已经在 Dev Library 工作了一年多。我现在已经看到了来自 80 多个国家的近 2000 多份稿件，相当不错！

如何开始编写技术教程

但是，作为一个开发者，你怎么知道你的博客创作之旅从哪里开始呢？

让我们关注以下提示：

不要被冒名顶替综合症打败。无论你在技术职业中处于什么位置，冒名顶替综合症可能会不时地出现。即使有 7-8 年的经验，我有时也会流汗，认为自己是否足够好。

所以，不要担心。开始写作的最好方法是在你建立一个项目时尝试写作。解释给自己听，就像你在和朋友说话一样，帮助他们理解它。这样一来，任何读到你的教程的人都会知道如何建立这个项目。

同一主题存在许多文章。这就是典型的情况。在世界上 70 亿人中，很可能有其他人正在写你写过的主题。

但你描述、定义和展示功能的方式将是不同的，专注于此。

我甚至如何开始？。空白页的焦虑是存在的。为了克服这个问题，开始创建具有高级主题的部分。如果你愿意的话，可以制定一个大纲。然后开始在其中添加内容。确保添加更多的步骤、要点和视觉效果。

为了更好地组织和编辑你的内容，你可以参考谷歌的技术写作课程和风格指南，如 freeCodeCamp 的和 MailChimp 的。

如何进行首次贡献。第一次贡献是特别的，但也是令人不知所措的。为了确定合适的 GitHub repo，寻找你专业领域的开源项目。与那些在你的技术栈中做出贡献的人建立联系。了解流程并开始贡献。

现在我们已经了解了这些要点，你已经准备好启动你的开源之旅了。

我的开源之旅

为了帮助你开始为你的专业领域的项目做贡献，我将在一分钟内分享一些提示和指南。但首先，再介绍一下我的情况。

直到 2019 年，我都不知道开源这个词。是的。我在社交媒体上并不活跃，除了 LinkedIn，那里没有人谈论开源。

总而言之，我的视野相当狭窄。

但由于我是一名科技作家，我是一个名为 Write the Docs 的全球科技作家社区的活跃成员。我在浏览他们的 Slack 频道时，发现了 Google Season of Docs。

我浏览了参与组织的名单，发现了一个有趣的组织。然后，我通过他们的 Slack 频道联系了他们，并提出担任志愿者。

在 The Good Docs Project 做了一年的志愿者，我得到了很多机会。我们为各种使用情况创建了开源模板，例如：

用于全球开放空间组织的词汇表模板
一个入职模板
一个 API 模板
文档模板

一年后，在建立人脉并积累经验后，我申请成为参与者。 Metanorma 组织看到了我的志愿服务经验，并选择了我参加 GSoD'21。正是这样，我成为了不断发展的开源社区的一员

如何开始为开源项目做贡献

当你开始做贡献时，不要只关注结果——要关注过程。

以下是一些帮助你开始贡献的要点：

学习 Git 和 GitHub

在寻找可供贡献的仓库之前，先对 Git 命令和 GitHub 平台进行实践了解。:）获得对以下内容的基本了解:

如何复刻（fork） repo
如何进行提交（commit）
如何合并（merge）提交的内容
如何提出拉取请求（pull request，简称 PR）

在许多其他的 Git/GitHub 概念中，这些是最重要的一些。

如果你想了解更多，这里有一些有用的资源：

浏览一些项目

现在你已经很熟悉这些工具和软件了，你如何决定从哪个项目开始？

嗯，首先，从你感兴趣的主题开始。浏览 github topics，搜索你想做的事情。例如，如果你想浏览有关 Python 的项目，那么你可以用这个。

除非是非常小众的东西，否则你应该找到大量有关你所选主题的项目来开始你的贡献。

一旦你找到了一个项目，就去找那个 repo 的初学者友好问题。为此，输入 github.com/[所有者]/[仓库]/contribute。选择一个问题来开始贡献。你可以在 “适合初学者的第一个问题（good first issue for beginners）”标签下找到这些问题。

如果你在 GitHub 上一直很活跃，你的探索页面（explore page）会显示一些基于你过去的贡献、收藏或复刻的精心推荐。

参与开源计划

参加主要组织举办的开源项目。如果不是作为贡献者，那就作为志愿者来学习、构思、贡献，然后参加。

例如：

大量探索

开源贡献的最大盲点是没有进一步观察或没有探索。

开源项目并不局限于代码贡献。其他各种贡献的方式有：

更新文献

对于任何项目来说，拥有一个详尽的 README 是很重要的。因此，潜心改进你最喜欢的项目的 README，使之更容易为他人所用。

那么，你是如何做到这一点的呢？

嗯，对于 Metanorma 项目：

在下载本地版本后，我执行了文档中提到的操作。这有助于我找出遗漏的步骤、错误或任何变动。
接下来，我对现有的文档进行了定性和定量的分析。这帮助我找出缺失的 URL，以及难以理解的部分。
找到这些部分后，我建立了一个适当的信息结构。然后，文档的信息结构将帮助你专注于内容。

帮助进行设计

组织确实需要他们的项目设计师。因此，如果您是设计师，请为开源组织创建海报、视觉效果或轮播。

成为社区建设者

开源是关于社区的一切。人们走到一起，一起编码，一起贡献，并一起改进项目。

成为这些开源项目的社区人员。把贡献者聚集在一起。与他们一起履行各种职能：

分配任务
解决问题
组织聚会
建立大使计划
举办研讨会
创建时事通讯

本地化的帮助

帮忙把项目翻译成你熟悉的语言。假设你是一个以西班牙语为母语的人。在你的社区寻找一些项目。把主要的项目从英语翻译成西班牙语，这样项目就能被全世界更多的人使用。

要了解一些其他的贡献方式，请参考 freeCodeCamp 的这个仓库。

需要贡献的开源项目

这是一个各种开源项目的列表，这些项目有一个活跃的社区，等待人们的贡献。他们有从初级到专家级的问题。

Supertokens。Supertokens 是一个开源的 auth0 替代品，它允许你在 30 分钟内设置认证。该项目提供企业内部部署，给予你对用户数据库的所有权。要做出贡献，请关注他们的 GitHub repo。
Nimble Edge。Nimble edge 是一个去中心化的平台，它正在把世界从传统的云计算带向边缘计算。从云计算到边缘计算的转变将允许设备之间进行智能通信，共享工作负载，并相应地使用云。要做出贡献，请关注他们的 GitHub repo，留意问题，并开始贡献。
Dev library。Dev Library 是谷歌新的开源平台，显示由外部开发者使用任何谷歌技术（Android、Angular、Flutter、Firebase、谷歌云、机器学习）创建的内容。该平台被划分为产品领域，显示可以贡献的优质项目。要做出贡献，请关注任何开源项目并挖掘贡献。
Codetriage：通过从这个金矿中找到任何开源 repo 开始贡献。
The Good Docs 项目。The Good Docs 是一个创建模板的开源社区，以消除空白页的焦虑感。该社区希望为任何事物创建模板。如果你觉得你也有一个模板的想法，请加入他们的 slack 频道。要做出贡献，请关注他们的 GitHub repo，加入他们的 slack 频道，并开始贡献。

我们在 Dev Library 上也看到了一些开发者使用谷歌技术的令人难以置信的工作。有些人建立了使用 Angular 的 Spotify 的克隆应用，有些人建立了一个项目，使用皮肤病变图像检测黑色素瘤（一种皮肤癌），而有人创建了一个 Whatsapp 图像采集器副本。

当然 freeCodeCamp 本身也是一个开源项目。freeCodeCamp 可以成为你学习和贡献于开源的首选平台。

结束语

那么你怎么看--是时候开始为开源做贡献了？

看看 Angular 领域的开源专家、GitHub 明星人物 Santhosh Yadav 是如何分享的：

“对开源的贡献以我从未想象过的方式帮助了我。我开始时是把它作为回馈社区的一种方式，并得到了社区的认可。然后我成为了 Angular GDE，也是印度的第一个 GitHub 明星。

OSS 帮助我深入学习技术，并帮助我找到了一份好工作。我甚至做了 1 年半的顾问，我的开源工作帮助我轻松地获得了客户。

我能够给我的家人一个好的生活。在开始开源之前，我有 10 年的时间是靠定期领工资生活的，而它改变了我的生活”。

这些故事告诉我们，开源贡献可以改变你的职业轨迹。不管你的工作情况如何——开始为开源项目做贡献吧。

如何为开源项目做贡献——入门指南

Li Jia Qi — Mon, 07 Jun 2021 12:30:00 +0000

如果你是一名开发者，你可能会遇到“开源”这个词。如果你曾想知道它的全部内容以及如何为其做贡献，那么你来对地方了。

在 2020 年的 Hacktoberfest 期间，我抛开了所有我对如何以及贡献什么的恐惧，并为开源世界做出了我的第一个贡献。由于对我来说是第一次，我从一些对初学者友好的项目开始，然后慢慢提高。

而现在，如果你是新手，你可能想知道开源到底是什么？如何开始？你应该期待什么？在本文中，我们将涵盖所有这些内容甚至更多。

什么是开源？

开源是指在许可证的许可下向公众提供可以查看、使用、修改和分发的源代码。

无论是个人、公司、小型企业、非营利组织还是政府机构，开源代码通常符合企业或个人的最大利益。

为开源项目做出贡献是一种学习、教授、分享和积累经验的有益方式。你应该为开源项目做出贡献的原因有很多，例如：

改进你每天使用的软件
如果需要，可以找一位导师
学习新技能
分享你的技能
更深入地了解你正在使用的软件
建立声誉并帮助你发展你的事业
另外，它本身很有趣，会让你感觉很棒

你为开源项目做贡献的原因是什么？回复这篇文章或通过 larymak 1 告诉我。

如何为开源做贡献

为开源项目做贡献并不一定意味着你必须为代码库做贡献。你可以通过多种不同方式为开源做贡献，例如：

你可以在项目文档中添加描述以详细说明某一点
你可以针对特定的项目提供指南
你可以添加示例来展示代码的工作原理
你可以为项目编写教程
你可以为项目添加翻译
你可以回答有关项目的问题（比如在 Stack Overflow 或 Reddit 上）
你可以对其他贡献者提供建议
你可以修复错误并正确地安排项目的工作文件夹

所有包括但不限于这些方式都可以为开源项目做贡献。

为开源项目做贡献之前需要了解的内容

每个开源社区都是不同的。每个社区都有不同的人，有着不同的角色和奖励。他们每个人都有自己的职责和预期贡献。

一个典型的开源项目会有这些人：

作者 - 创建项目的人。他们有权为其他成员分配角色以帮助维护项目。
所有者 - 所有者拥有项目的管理所有权（可以与作者为同一人）
维护者 - 这些人负责推动项目的愿景和目标。他们通常是对项目方向负责并致力于改进项目的人
贡献者 - 贡献者以一种或多种方式加入到项目中。他们遵循相同的代码审查流程，遵守相同的代码风格要求等等。
社区成员/用户 - 这些有价值的社区成员可以提供相关功能、错误报告等反馈。

所有开源项目都应该具备的重要元素

每个开源项目都应该有以下指南和信息：

License - 如果一个项目没有开源许可证，那它就不是开源的。许可证有助于保护开源贡献者和用户。没有这种保护，企业和精明的开发者通常不会接触该项目。如果你想知道如何获得开源许可证，请单击此处以了解更多信息。
README - 这是一本说明如何开始项目的手册。一个好的 README 应该包含潜在的贡献者想要了解的有关项目的所有不同内容。你可以阅读更多关于如何编写一个好的 README 文件点击这里。
How to Contribute - 这些指南帮助人们做出贡献并展示需要什么类型的贡献者（这个文件不是必须的）
CODE_OF_CONDUCT - 这是一份文件，用于确定你对贡献者和参与者的行为方式的期望。采纳并遵守行为准则有助于为你的社区创造一个积极的环境。

要创建一个开源项目，你需要创建一个环境，可以让人们分享他们的挑战并进行深入讨论。这个可以通过以下工具实现：

Issue Tracker（问题追踪器） - 人们在这里讨论与项目相关的问题
Pull Requests（拉取请求） - 这是人们审查正在进行更改的地方
Synchronous Chat Channel（同步聊天频道） - 这是专门供人们分享他们的想法并进行对话的地方（如 Slack、Discord 等）

如何找到你想要贡献的开源项目？

既然知道了开源项目如何运作，那么是时候找到一个可贡献的开源项目了。

贡献在各个层面都有效——不要过分思考你将如何去做，而是想想你已经使用过的一些项目，如何对它们进行改进提高。

研究表明，大约 30% 的贡献是文档、错别字修复甚至是翻译。

如果你是第一次贡献（每个人在某个时候都是这样），这儿有一些网址可以让你开始拥抱开源世界：

在开源软件的世界中，问题会很快得到报告和修复。所以，如果你想解决一个问题，一定要尽快解决它。

如何选择开源项目？

找到你想要贡献的项目后，让它符合以下标准，以确保它是一个不错的选择：

首先，你需要检查：

它有许可文件吗？
最新提交是什么时候完成的？是最近的吗？（也就是说，项目是否在积极维护/工作？）
它有多少贡献？
人们多久提交一次？

如果你看到最近有很多活动，那很好，这意味着它有一个活跃的社区来维护它。

其次，你应该继续检查以下内容：

有多少未解决的问题？
维护者需要多长时间才能做出回应？回应及时吗？
是否对某个问题进行了积极的讨论？
问题是否会定期关闭？
有多少开放的拉取请求？
最新的拉取请求最近多久合并？是最近吗？
是否首先审查拉取请求？（他们应该是）
维护者是否感谢人们的贡献？

如果上述所有条件都满足你的需求，那就去做吧，开始为这些项目做贡献。

在进行开源项目之前需要考虑什么？

所以你迫不及待地要开始致力于自己的第一个开源项目了。让我们来了解一些可能会帮助你选择项目的方法。

项目使用什么编程语言？

任何应用程序背后最基本的技术都是它使用的编程语言。GitHub 上一些最流行的语言包括但不限于JavaScript、Python、Java、Ruby 和 PHP。

你的能力和兴趣也许会契合众多项目，所以选择一个你感觉舒服的项目即可。

项目类型

在你确定了你想要使用的语言后，你需要选择你喜欢的项目类型。只需概览一圈并选择一个你感兴趣的主题的项目即可。

项目一旦确定，你一定想要有一番作为。你将通过提交拉取请求来做到这一点。现在让我们来详细说说这个。

如何提交拉取请求（Pull Request）？

如果你处于这个阶段，已经找到了一个项目，你就可以继续了。让我们来谈谈如何实际提交拉取请求。

首先，什么是拉取请求？这是你在 GitHub 中请求更新的方式，也是你将代码合并到另一个分支之前让某人检查你的代码的方式。

提交 PR 的步骤

Fork 存储库
在右上角，你将看到“fork”一词。单击它，将在你的帐户中创建同一个项目的副本。 URL 将更改为：

https://github.com//projectname

将其 Clone 到你的本地
在你的电脑上，如果安装了 Git，请打开 CMD 并运行此命令。如果你还没有 Git，请参阅此处，它将向你展示如何开始使用 Git。然后继续执行以下步骤：

git clone https://github.com//

这会在你的本地电脑上创建项目的副本。现在你已经克隆了存储库，我们需要做两件事：

首先，你需要创建一个分支。切换到你电脑上的存储库目录（如果你还没切换的话）：你可以通过以下方式执行此操作：

cd project folder name

使用 git checkout 命令创建一个分支：

git checkout -b your-new-branch-name

比如：

git checkout -b lary-mak-blog

接下来，你需要进行必要的更改并提交这些更改。在进行更改和添加新文件之后，将这些更改添加到你创建的分支中了。

要查看你做的所有更改，请运行 git status 命令：

git status

这会显示你最近做的所有更改。现在添加它们，使用 git add * 命令：

git add *

现在使用 git commit 命令提交这些更改：

git commit -m " "

将更改推送到 GitHub
你可以使用 `git push 命令轻松完成此操作：

git push origin

用你之前创建的分支的名称替换。

提交你的更改以供审核
如果你转到 GitHub 上的存储库并刷新页面，你将看到“Compare and pull request”按钮。单击该按钮。

很快，维护者会将你的所有更改合并到该项目的主分支中（除非他们需要你的更改）。合并更改后，你将收到一封通知电子邮件。

对其他存储库的拉取请求类似于“Push”。但是，它允许做一些事情：

首先，它允许你为其他存储库做贡献，而无需管理权限来对存储库进行更改。

其次，它允许其他人查看你的更改并提出更正、添加、编辑等建议。

第三，它让管理员可以控制添加到他们项目存储库中的内容。

在完成第一个拉取请求后，下一步做什么？

恭喜你！刚刚完成了作为开源贡献者经常遇到的标准工作流程！fork -> clone -> edit -> pull request

现在，你可以继续寻找其他项目并做出更多的贡献。并且一定要留意Digital Ocean举办的开源月，这样你就可以参加Hacktoberfest并有机会赢取一些很有意思的东西。

为开源做贡献的好处

既然你已经了解了如何为开源做出贡献，那么做贡献有好处有什么呢？

为开源项目做贡献的人比仅仅使用该技术的人更深入地了解该技术
你可以根据在现实世界中有效和无效的经验，专注于添加和利用对企业有益的功能
它可以建立你的士气和声誉。为开源项目做贡献的人得到其他社区成员的见解和经验
对开源的贡献可以清晰地了解一个项目的未来
如果你使用 GitHub ，你在该平台上做的很大一部分事情都是公开的。利用这一点来发挥你的优势，在贡献和与其他贡献者交流时，始终做到最好。因为你永远不知道谁在看着你，你的下一个雇主可能就在那里😊

为什么你应该为开源做贡献？

作为一名开发者，以下我认为你应该为开源做出贡献的原因：

它可以帮助你编写更清晰的代码
它可以帮助社区和同行了解你。这种认可可以为你的职业生涯带来很多机会
它可以帮助你了解有关项目的更多信息
它提高了你的编码技能

更多有关信息，请阅读 freeCodeCamp 的指南。

感谢你读到这里！

与我联系 Twitter | Insta | YouTube | LinkedIn | GitHub

请分享你的宝贵意见，感谢你的诚实反馈！

享受编程吧❤

原文：How to Contribute to Open Source Projects – A Beginner's Guide，作者：Hillary Nyakundi

送你一份美味又营养十足的开源社区贡献指南！

Hunter Wang — Sun, 02 May 2021 11:00:00 +0000

在这篇文章里，我想和你分享我对开源的理解。

让我们先从简单的开始。

你知道什么是产品吗？你日常轻松购买的某种东西就是产品，比如餐馆里的卷饼。但是要制作这款产品就需要遵循一定的步骤：在餐馆里，懂食谱的厨师熟练地使用相同的配方和相同的成分，确保每份卷饼味道可口。

你不仅可以通过贡献开源来进入某个技术领域，实现职业转型或促进现有职业的发展，还能以此来帮助社区！

在大多数餐馆，如果你走进去询问厨师：“我非常喜欢您做的卷饼，可以把制作配方给我吗？”，他们通常都会拒绝——因为配方并非开源。开源就是除了产品本身，你还能够获得制作产品的食谱和配方，然后你在家里也可以制作出同样的卷饼。

图片来自 Pixabay，作者 samuelfernandezrivera

现在假设你开始制作卷饼了，但你不想吃那么多肉，于是用鳄梨取而代之。在这种情况下，你拿到了食谱并用鳄梨代替了肉，接着完全按照剩余的步骤进行下去，然后看看做出的卷饼是什么样子的。

结果可能是你做的卷饼比餐馆里的还要好吃。如果餐馆是以开源项目的形式运作的，你就可以对厨师说：“嘿，你的卷饼很好吃，但我加了一些鳄梨之后味道更棒了！可以把这个配方加入到你的食谱中哦。”

此时厨师就扮演了产品维护者的角色，他们可能会接受你的建议，也可能认为添加鳄梨是个坏主意，不符合餐馆的理念。无论如何，通过分享对项目的修改，你成为了一名开源贡献者。

恭喜你！

可以为开源项目做哪些贡献？

Firefox 浏览器就是开源项目的一个范例。它是由数千行源代码和如何将此源代码转换为可用产品（如 Web 浏览器）的指令组成。这些代码是公开的，每个人都能获取、阅读、评审或构建它。每个想要修改 Firefox 的人都可以更改源代码并构建自定义版本。不仅如此，每个人还可以将自定义的修改反馈给项目维护者。

然而，代码并不是开源项目的全部，还有用户界面和图形设计。没错，即使像 Vim 这样的终端程序也有自己的图形界面。

你无需编写代码即可为开源做贡献！

除了界面，还有用户交互、可用性和用户体验（UX）等等——这些在近几十年来越来越重要。如果你拥有设计背景，精于艺术或心理学，你就可以在 UI/UX 领域施展能力。产品的另一个组成部分是媒体，包括声音、图形或视频，这些元素虽然不是所有项目必备的，但也挺常见。

文档是项目中经常被忽视的一部分。改进文档也是向开源社区做贡献的一种方式。如果你热衷于文字创作、文章编辑或翻译，那你也能成为开源社区的贡献者。

此外，开源项目经常缺少市场运营人员，如果你能解决运营问题，整个社区都会随之受益，因为这会吸引更多潜在的贡献者。

最后还有法务工作者，这类人群在普通开源项目中相当罕见，多见于大型项目。有很多律师为开源项目处理法务问题，而他们中的大多数都是志愿者。

如果你可以写散文、画画、制作音乐，是一个好的营销人员，或者是律师，那么，开源社区需要你！

如果你觉得自己无法胜任设计、修改代码、编写许可证等工作，不必担心，你依然可以做出贡献，比如报告一个错误或提出修改建议。

最好的状态是这样的：每个成员都贡献出一点点时间、一点点努力、一点点经验，整个社区协作产出一款出色的产品，而且通常是一款免费产品！

觉得自己不是一位创造者？去发现 bug、或者向程序猿提需求吧！

为什么值得我花时间？

为什么向开源社区做贡献是值得的？为什么你要在提建议、写代码或翻译文章上花费时间，而不是出去走走玩玩？有很多理由，所有理由的前提是：对开源社区做出的贡献是公开可见的，每个人都能看见其他任何人所做的事情，这种感觉非常棒！

提升竞争力

当你在编写代码，设计界面，或者绘制图形时，你就是在学习，这对那些正在寻求职业转型的人来说是很好的锻炼机会。在开源世界，没有人会在意你是一个资深开发人员还是一个园艺工人，真正重要的是你所做贡献的质量。当你在开源项目中证明了自己，你将获得宝贵的经验，不用再觉得自己是刚从训练营毕业的新手，你已经是社区的正式成员，所有人都看得到你的贡献。

当你在某项技术工作中遇到困难，想要转型做别的，那么参与开源贡献是一个很好的途径。比如，你是一名 COBOL 开发者，想要成为一名 UX 设计师，那么从现在开始尝试改进 Firefox 的交互体验，为开源做出贡献吧。如果你的建议被社区接受，那么你就可以在简历中新增一项工作经历：Firefox 交互设计师。像这样，你既能学到有用的知识，又能丰富自己的经历，一箭双雕。

提升知名度

加入开源社区之后，你会很快地认识新的小伙伴，接触共事的团队成员，你可以向他们学习并与他们交流想法。

另一个加入开源社区的好处是你会自动地获得更多的曝光机会。举个例子，有人通过访问你所在的开源项目找到你的 YouTube 频道，或者通过 LinkedIn 为你提供工作机会。

目前 IT 行业招聘人员们寻找人才的一个重要渠道就是 GitHub，把你的代码发布到 GitHub 就相当于编写了一份所有人都能验证的简历，而无需联系你之前的雇主或者客户。如果你的个人 GitHub 资料包含了跳转到领英或个人主页的链接，那么你找到梦想中工作的机会将大幅增加。

记住，你甚至都不必拥有特定领域的从业经历，对于招聘者来说，你对开源的贡献就是你具备经验的最好凭证！

寻找工作机会或新的客户

如果你真的很优秀，你将会获得为开源项目工作的有偿 offer。这主要是指那些有稳定财务来源的开源项目，可能是获得公司或者非营利组织的支持。

招募贡献者

你还可以招募到一些有潜力的新人。如果你做了一些酷炫且有用的项目，请毫不犹豫地把它开源，这样就有机会让其他人帮你改进。

帮助他人

另一个参加开源的好处是，你将有机会为他人做一些有意义的事情并且获得尊敬。你收到的所有“感谢”将让你觉得你所花费的心血都是值得的，而且你也拥有了参与一些很棒项目的经历。

有机会接触到很棒的统计数据

很多人很喜欢统计数据，对他们而言，GitHub 就是一块宝藏。我们在 GitHub 上的每一次提交，都会在一个日历上产生绿色方块标记，每天的提交数越多，对应方块的颜色越明亮。当我们连续几天都有提交时，类似于每天打卡，GitHub 会保留分数以供将来参考。

GitHub 贡献数据（不是我的）

如何找到你的第一个项目？

你可以通过多种方式找到想要贡献的项目。首先，像火狐和安卓这样的重量级项目拥有庞大的用户基数，需要大量的修改和优化。一旦你向这种项目提交了代码，你的修改将会被数百万人看到。你可以访问 GitHub 看看有哪些流行的仓库，比如，目前 GitHub上拥有最多 star 的项目是 freeCodeCamp。

GitHub上拥有最多 star 的仓库

如果你是个新手，我不会推荐上面第一种方式。一个庞大项目最大的优势往往也是它最不好的地方。每个人都想做出贡献，但是维护人员的数量是极为有限的。如果你真的想产生影响，不如试试一些小规模的、处于上升阶段的项目。GitHub Trending 就是一个好的方法。

GitHub上的热门项目

另一种方式是选择 awesome 项目作为第一次贡献者，这是比较节省精力的方法。awesome 项目是一个链接列表的大集合。比如，awesome-shell 列出了一些酷炫的命令行工具，而 awesome-JavaScript 列出了每天涌出的优秀 JS 框架，当然还有 Mind Expanding Books 和 awesome_lists 等等。

为什么说这是个好办法？因为给这些项目做贡献的门槛比较低，而贡献的成就感更容易刺激产生多巴胺，多巴胺又会刺激做下个贡献。一旦皮球开始滚动，就很难让它停下来了。

我推荐的最后一个方法是参加大型开源活动，比如每年十月举办的 Hacktoberfest，参与者需要提交5次 Pull Request（即 5 次贡献），每个完成任务的参与者都会从赞助方那里领取到精美的礼物（T恤或贴纸）。为了让降低参与门槛，活动网站上会列出一些入门的示例项目以供选择。

另一个类似的活动是 Google Summer of Code。你可以参考往期的项目列表，也许这回给你带来灵感！哦对了，这里还有一个 Awesome First PR Opportunities 列表。

如果你希望持续不断地参与开源，你需要先找到适合的项目，这样的话对你自身的提高大有裨益，也能保证高质量的工作。

如何做出有价值的贡献？

图片来自 Unsplash，作者 rawpixel

我们现在了解了为什么贡献开源以及在哪里参与开源，现在我们讨论一下如何让我们的贡献变得有价值。毫无意义的贡献是不会被接受的，所以最好有所准备。

我们需要尊重工作须知

首先，我们需要尊重他人制定的工作须知。在许多项目中，你可以找到像 CONTRIBUTORS.md 这样的文档，它说明了做贡献的首选方式。如果项目中没有 CONTRIBUTORS.md，你也可以阅读 README.md 或项目 wiki 页面，熟悉并理解这些规则，然后按照规则参与开源。

如果你没有遵循开发指南列出的规则，很可能在 review 之前就被拒绝。那些规则就是为了节省维护者的时间的，如果你不遵守，那么维护者会认为你对待其它工作的时候也经常粗心大意。

思考你的贡献对他人有着怎样的价值

当我们知道了怎样参与开源，下一步让我们思考一下我们的贡献究竟对他人有着怎样的价值。想象有一家生产定制西服的公司，你在门店里买了一套西服然后穿着它去了酒吧。你突发灵感，把开瓶器挂在了西服上，这样每次去酒吧喝酒的时候，你都能随时使用衣服上的开瓶器打开啤酒了。

于是你把这个“伟大的想法”告诉了裁缝，让他在制作西服时顺便挂上一个开瓶器。然而，无论你的想法多么具有独创性，裁缝都是不可能同意的，就像开源项目的维护者不会接受一个与其观念不同的代码提交。这并不是说你的工作很差或者毫无价值，而是你提交的功能特性仅仅适用于极小部分用户，不能代表大部分用户的需求。既然每个功能都需要维护成本并确保其稳定性，项目维护者自然就需要确保每个功能点都能为大多数用户带来价值。

详尽沟通

如果你提交的不是功能点的修改，而是一篇报告，那么你一定详细描述，尽可能地把问题的背景解释清楚。这点建议当你在报告 bug 时格外有用。你描述得越详细，别人在修复问题时就会更容易直击要害。请记住，列出可能的用例和预期的行为，忽略与报告不相关的任何细节。比如，你想让某个元素变成绿色，因为这能够与竞品相匹配，那么你长篇累牍地描述竞争的背景则会显得有点多余。

运行、测试、校验，提交前仔细检查

在提交代码之前要详细地检查和测试，确保你的更改针对的是当前的开发版本，而不是某个历史版本。记住你只需运行一次测试，而项目维护者需要每天运行各种各样的测试，为了节省他们时间，你需要确保一切都运行正常。这也体现出你严谨的态度，而不是马马虎虎地提交一份半成品。

直面批评

图片来自 Unsplash，作者 Wes Hicks

请记住这点：你每次在网上发布一些东西的时候，都是把自己暴露在攻击之下。不管你发布的是一句评论，一张照片，一篇文章，还是一份代码，你都可能受到批评。所以，请对批评的声音持开放的态度，这样会有助于你的成长。

有些批评甚至是毫无根据的。因此，在你分享自己的工作之前，需要想想如何处理各种各样的批评，这样你才会为那些终将到来的批评做好准备，而不是每次都默默地慢慢消化。

我们的最佳想法并非对所有人都是最佳的

首先，你能想到的最佳想法可能并不是对所有人都是如此，请千万记住这点。当有人告诉你开瓶器跟西服根本就不搭的时候，不要觉得受到了冒犯。如果这是项目维护者的观点，你一定要尊重，这将会是你下次参与开源项目的宝贵经验。或者你也可以参与那些接受你的“最佳想法”的项目。

我们最好的作品可能并不符合标准

尽管话很难听，但你的最佳作品可能并不符合标准。我亲身经历过这种事情，我参与了一个项目，本想在第一次提交时就做到完美（但只是我认为的“完美”），毕竟我知道需要注意哪些事情。但是结果我收到了一份指导我如何写出好代码的教程——我发送了代码，过段时间收到了答复，几乎每一行代码都被高亮标记出来，有趣的是，所有的评论都是有理有据并且准确的。我眼中的完美在专家眼中却并非如此。我根据批注做出了修改然后重新提交了代码，这次我只收到了五个批注。

即使你已经做得很好了，仍会有人推动你去做得更好，这就是代码 reviewer 的目的。他们并不是在批评或责怪你，而是在帮助你，请记住这点！

即使我们做到了能做的一切，还是可能被拒绝

有时你仅仅得到一个简短直接的回复， “no”，这让你感觉无能为力。你仍然坚信把开瓶器挂在西服上是个好主意，这时该怎么办？是时候创造你自己的项目了。在开源世界里，在已存在项目的基础上创建新项目的行为叫作“新建分支”。

相应的，新项目被称为原项目的“分支”。比如，Ubuntu 就是 Debian 的一个分支。如果维护者拒绝把你的代码合入他的项目，你可以考虑新建一个分支，自己成为项目维护者。当然只在极端情况下才应这样做，因为这不仅给两方维护者带来负担，也会给社区造成困惑。如果你不幸恰好收到了 “no”，你应该好好想想得到这个答复背后的原因，这将会成为你未来宝贵的经验。

网络暴力无处不在

现在来谈谈网络暴力。

互联网给人一种匿名感，涌现了一种亚文化：“键盘侠”（或者“网络喷子”）以故意诋毁他人为乐。这种亚文化被称为“网络暴力”。我自己还没遇到这种情况，但我推荐你阅读 Ragen Chastain 写的文章 “The Complete Guide to Understanding and Dealing With Online Trolls”，它将帮助你为这种令人不适的遭遇做好准备。

通过开源赚钱

图片来自 Unsplash，作者 rawpixel

如果你已经读到了这里，你可能会想是不是有可能在为开源项目工作的同时赚点外快。

当然可以！

虽然软件本身通常是免费使用的，但是会有其它方式让你利用开源项目赚钱。赚钱是一门艺术，因为一些办法只适用于你自己，在别人那里却不管用，它是门“伪科学”。

普遍适用的方法

我最喜欢的方法就是“捐款”按钮，你可以在我的一个叫 Songcorder 的项目中看到这是怎样的。捐款人可以通过 PayPal 支付大于 15 美元的捐款，或者点击 Buy me a Coffee 支付小于 15 美元的捐款。

（你也可以在这里 https://www.freecodecamp.org/donate 为 freeCodeCamp 捐款，你的每 1 美元捐款将为全世界人们提供 50 小时免费的编程教育机会。）

除了通用的按钮之外，还有一些开源项目专用的方法，比如 Gittip/Liberapay（后者经常换名字）。有趣的是，Liberapay 所支持的最受欢迎的仓库是 awesome。

这与 Flattr 很类似。你可以选择每月要捐的金额，当你认可某些作品时，作品的作者将获得捐款的一部分。也就是说，如果你决定每月向开源项目捐 5 美元，在某月你认可 4 个项目的工作（通过 star 或者点击 Flattr 按钮），那么每个项目的作者将会得到 1.25 美元。就是这么简单。

与 Liberapay 关联的仓库

除了支持整个项目，你也可以直接（近乎直接）向开发者捐款。Tip4Commit 就是以这种方式运作的，支持者向某项目的账户存入一定数量的比特币，然后每个开发者就可以从这个账户分到一笔钱了。

另一个可能的方法是 Patreon，支持者将固定金额的现金分配给他们选择的任何开发者，而不是平均分配预算。如果你想了解这种方式是否适合你，可以阅读 Erika Sauter 写的文章《Why Patreon is Dope AF for Creators》。享有盛誉的 Sindre Sorhus 就是最主要的开源维护者之一，而像 Homebrew 和 Linuxbrew 这种颇具规模的项目同样也使用 Patreon 筹集资金。

如果你把开源视为业余爱好，那么你可以尝试上面提到的所有方法。幸运的话，它们甚至可以让你将兴趣变成全职工作。然而，实际上，如果你想使开源项目成为你的日常工作，一个常见的方式是提供咨询服务，比如向企业客户出售专业功能或者帮助企业客户部署和定制产品。很多企业缺乏利用开源项目解决其内部需求的能力，而谁又能比原始项目的维护者更能胜任这项工作呢？

如果你在帮助别人的同时能够获得报酬，那就这样去做吧！

众筹

为开源项目筹集资金的一种流行方法是众筹，有很多提供这类服务的平台。比如， Kickstarter 为开源语音助手 Mycroft Mark II 筹集了启动资金。另一个平台 Indiegogo为电子邮件客户 Geary 主持了一场众筹活动，但很可惜，这个项目未能达成它的预期目标。MediaGoblin 甚至在没有任何第三方的情况下启动了自己的众筹系列活动。

如果担心你无法找到很多众筹者，那么你可以尝试融资。在我的印象中，有至少两个提供融资的基金会，其中一个是著名的 Travis CI 公司旗下的 Travis Foundation，另一个是开发了 Firefox 浏览器的Mozilla 基金会。

目前我介绍的大多数工具和方法都是适用于开源项目维护者的，而开源贡献者也可以通过做“悬赏任务”来赚钱。项目方在某个平台发布需求，贡献者完成这些需求即可获得奖励。目前 Bountysource 似乎是最受欢迎的众包平台。

如果你更喜欢将加密货币作为付款方式，Gitcoin 是一个与众包具有相似原理的平台。想做更多的了解，可以看 Vivek Singh 写的文章《Everything You Need to Know About Gitcoin》。

带薪实习是另一个有效的方法，有两个备受欢迎的选择：

Google Summer of Code——面向学生
Outreachy——面向技术领域的少数派

或者，如果你真的对开源充满激情，为什么不加入一家专注于开发开源软件的公司呢？有很多这样的选择，就像咨询一样，你将获得报酬，并同时能够为社区做点事情。

这是一个双赢的选择！

遇到志同道合的人

图片来自 Unsplash，作者 “My Life Through A Lens”

到目前为止我尚未提到的是：无论产品、项目还是技术，都是整个开源活动的一小部分，开源最重要的组成部分是丰富多彩的社区！当你开始为开源做出贡献，你会很快结识很多新朋友，你可以向他们学习，可以为他们提供帮助，也可以与他们交换思想。

每个项目都有专属的社区，而且也有很多地方让众多拥有不同背景的开源爱好者聚集起来。

你可以加入一些在线交流社群，比如领英的 Linux & Open Source。你也可以加入很多有趣的 Gitter 频道，Gitter 是为开源社区打造的即时通讯软件。当然，还有一些邮件组、论坛或平台（如 GitHub）让大家互相协作和交流。但是，如果你想亲自结识志趣相投的人，请考虑访问或加入线下黑客空间。

在黑客空间，人们将对实践的热爱传递到软件世界之外。不管你是对软件、硬件还是 DIY 和手工制作感兴趣，都可以去这些空间。有一个维基百科页面专门列举出了所有的黑客空间，找到离你最近的那个，去拜访他们，你将被思想与行动碰撞所迸发的火花点燃！

原文：The Definitive Guide to Contributing to Open Source，作者：Piotr Gaczkowski

开源项目负责人指南

Nicholas Zhan — Sat, 10 Apr 2021 10:00:00 +0000

你有没有想过拥有自己的开源项目？我敢打赌，你一定有——因为你正在读这篇文章。

也许你现在正在考虑这事儿。也许你来这里是为了了解应该对开源项目有何期望，你将面临哪些挑战，以及如何应对这些挑战。好吧，你来对地方了。

以下指南基于我个人拥有一个开源项目中的经验。我指的是拥有一个开源项目，而不仅是向一个开源项目做贡献。这两者之间有着巨大的差别，我们将学习为什么。

所以让我们从开源项目负责人终极指南开始吧……

我是谁

我叫 Jeb，这几年一直在维护几个开源项目。其中最受欢迎的一个是 @angular-builders，它也是我从中学到最多东西的一个开源项目。在写这篇文章的时候，它在 GitHub 上有约九百颗星，月下载量大约一百万。

是的，它与 Angular 或 React 这样的大型项目相差甚远，但是我觉得我有足够的经验和你分享，帮助你避免重蹈覆辙。更重要的是，帮助你了解拥有一个开源项目的成本。

那么什么是开源

首先，让我们建立共同语言，并在关键术语和定义上达成共识。

什么开源（open source）？

这里是一个非常通用的定义，来自著名的开源百科全书（亦称维基百科）：

开源是指允许复制或修改的信息向公众开放的概念。

或者，从软件开发模式来看：

开源模式是一种去中心化的软件开发模式，鼓励开放协作。

开源软件开发的一个主要原则是对等生产，源代码、蓝图和文档等产品免费向公众开放。

以维基百科为例，我们有编辑文章的人（贡献者），也有批准编辑的人（经验更加丰富的成员、版主）。

如果我们将其投射到软件世界，那些编辑们将形成一个开源项目的核心团队，而做贡献的人就是贡献者。

维基百科是一个非常庞大的开源项目，但这一切都是从一个小东西开始的。维基百科诞生自新百科全书（Nepedia），它的创建是有原因的：

尽管邮件列表里有很多感兴趣的编辑，还有一个全职主编 Larry Sanger（威尔士聘请的哲学研究生）在场，但新百科全书的内容写作还是非常缓慢，第一年只写了 12 篇文章。

所以第一个问题来了……

为什么你应该关注开源

你可以想象，将某些东西开放给更多人的一个主要的原因是 为了招募协作者（collaborator）。

Together we’re strong.
(Zarya, 2016)

在写这篇文章的时候，维基百科拥有 37899499 个注册账户，其中有 134022 个账户正在积极编辑。

想想看…… 134022 名活跃的协作者。噢，它还有六百万的内容页！

如果新百科全书（维基百科的前身，Nupedia）没有转向开源，这个数字还会是这样吗？我对此表示高度怀疑。

在软件领域也没有什么不同。为了解决某个问题，你必须写代码。为了解决一个大问题，你必须写很多代码。而为了妥善解决这个问题，你必须写出高质量的代码，做出高质量的设计，等等。

所有的这些都需要资源。说实话，你可能还没有这些资源。毕竟，你需要交房租。

为什么要启动一个开源项目

虽然招募协作者是一个合理的动力，但几乎没有人仅仅因为这个原因就启动一个新的开源项目。你的理由可能会有所不同，但是我们来聊聊最流行的理由吧。

#1 你想解决一个没有免费解决方案的问题

你遇到一个问题，但没有任何东西可以为你解决它（或者有，但是要花钱），所以你不得不自己解决它。你设法解决了这个问题，你对自己的工作感到非常兴奋，而且你认为其他人可以从中受益，所以你把这个项目开源了。

#2 你想成为发起人

你想成为一个开源项目的发起人，你想在你的简历上写上那漂亮的一行。你真自以为是（毕竟，我们都是人）。如果这是你的主要理由，那么我向你保证——读完本指南之后，你会重新考虑的，这么做可能很不值得。

#3 你想比别人更好地解决一个问题

你面临一个问题，有一个开源项目实际上为你解决了这个问题，但是它不够好（在你看来）或者它没有你需要的确切功能。

如果你仅仅因为这个就创建一个新的开源项目，那么你 很有可能处于第二种情况（自以为是）。让自己成为一个贡献者，然后为现有的项目创建一个 PR 吧。

如果那个现有的项目有不同的愿景，创建 PR 并不可行，那么你应该考虑通过在你的项目中重用它的功能来扩展它，或者复刻（fork）它，这可能会让你以后省去很多头疼的事情。

#4 你想通过创建一个开源项目来解决一个问题

你面临一个问题，并且现在没有任何人为你解决过它。所以，你认为从一开始就以开源的方式解决问题是一个非常好的想法。

在我看来，并不是。

解决这个问题，确保它对你有用，然后进入第一种情况。

这是我最常发现人们创建新的开源项目的四个动力。但是在这篇指南中，我们将主要关注第一种情况。

原因很简单——我相信，如果你发起开源项目的主要原因不是热衷于分享或者贡献你所做的东西，那么这就不成立了。

在相当长的一段时间内，你帮助别人这一事实可能是你得到的唯一回报。如果这不是你要找的那种满足感，那么你或许应该就此打住，不要再浪费你的时间了。

另一个相当流行场景值得一提：有些公司将它们的部分代码开放给社区。例如 Angular（由 Google 维护）、React（由 Facebook 维护）、VSCode（由微软维护）等等。

它们的理由可能各有不同，但是赢得协作者和为社区做贡献肯定是少不了的。

虽然我不能否认这种做法的重要性，但是这种情况与其它的情况有很大不同，因为维护这些项目的雇员们会因自己的工作得到报酬。

如果你在一家考虑创建开源项目的公司工作，那么这里的大部分内容对你来说还是有意义的，但是动力可能有所不同。

那么你是否应该创建一个开源项目呢？

如果要我用一句话对这部分进行总结的话，那就是：

确保你的意图符合你的期望。

要相信，你想拥有一个开源项目与你实际拥有一个开源项目并不相同，你将会这接下来的几章中看到。

如何发起一个开源项目

所以你现在处于第一种情况——你有某个问题的解决方案，并且你渴望与世界分享。让我们再强调一遍：

它与你的自负无关
你不是希望从中获益
你真的想要帮助有着相同问题的其他人

对于所有这些问题，如果你的答案都是肯定的，那么这里是一份为你准备的快速检查单，让你确保你做的是正确的事情：

确保开源是正确的形式。如果它只是某个你想与世界分享的小东西，那么一篇博客文章可能就足够了。
仔细检查是否已经有类似的项目存在。或许你的解决方案对某个已有的开源项目来说是一个绝佳的 PR。

为即将到来的事情做好准备

正如我所提到的，拥有一个开源项目会带来很多挑战。

其中最突出的一点就是，它需要你投入大量时间。你为项目做的一切都需要时间，无论是写代码、管理议题（issues）、更新依赖、与人交谈、回答问题等等。

你每多投入一分钟到你的开源项目中，你本可以投入到你的家庭、爱好、健康和其它的一切中的时间就会少一分钟。

你能做的唯一一件能让这种情况变好的事情就是开始委派任务。当（或者我应该说“如果”）你有足够多的协作者时，你可以将部分责任外包给你信任的人。

代码分离

所以我们开始了，你有一个针对特定问题的解决方案，并且你认为其他人可以从中受益。这个解决方案仍然集成在你的代码库中，你可能并不想让整个代码库开源（除非你真的想）。

首先你需要将这部分代码从代码库中的其它代码分离出来。

这最终会意味着将要开源的所有代码都会位于一个单独的目录中。

让代码变得通用

确保新目录中的代码是通用的，同时也不局限于你那特定的问题。如果需要的话，写一个抽象层。

举个例子，我发起angular-builders 的时候，有一个非常具体的需求（来自我其它的开源项目之一），就是为 Angular 构建添加一个自定义原生模块加载器。

我本可以创建原生模块构建器，它只用于这个目的。然而，我意识到我可以以相对较低的代价创建一个更加通用的解决方案，来解决相似（但不相同！）问题。

custom-webpack 构建器就是这样诞生的。

保持简单

通用的方案会非常棒，但要注意别过头了。

过早优化（premature optimization）和过度泛化（over-generalization）是软件工程中两个非常著名的问题。你应该找到那个最佳的点，你的解决方案可以解决你的问题之外的问题，但是不能解决世界上所有的问题。

如果你建立了一个量表，其中你那特定问题的解决方案是 1 ，而世界上所有问题的解决方案是 100，那么你应该从 2 开始。

你的通用代码应该能比你的特定代码多解决几个问题。

吃自己的狗粮

坚持在你的代码库中使用这部分通用代码——这样可以确保你去除不必要的部分，只留下必需的。它可以确保你要开源的代码能够正常工作。

记住，你是你的开源项目的第一个用户。

别被告了

如果你正从公司的代码库中提取代码，咨询一下你的上级，如果需要的话，也咨询下法律部门。确保他们支持你的提议，并且你打算开源的那部分代码不会违反公司的知识产权。

这也能帮你决定哪个开源协议更加适用于你的项目。

当一切正常，代码已经分离并且足够通用，你也得到了所有的批准（如果需要的话），那么就是时候向世界开放它了。

当你的开源代码分离完成并且通用化，就可以把它从你的代码库中完全分开了。

公开你的代码

首先，你需要开放你项目的源代码（在一天结束时，这让它成为了一个开源项目！）。

在线托管源代码的选择有很多，但是我们将会采用默认的——GitHub。

在 GitHub 上创建一个新仓库
克隆该仓库
将源代码从你之前创建的目录（暂时不要删除这个目录）移动到这个仓库
提交并推送（Commit & push）——就这样，它现在是一个开源项目了。

不是吗？

创建一个包

你的项目已公开，但是没有人使用它（包括你，因为你正在自己更大的代码库中使用这份代码的副本）。并且，没有人知道它的存在。

此外，你的项目在网上公开的唯一形式是源代码，而使用它的唯一方式就是将它复制-粘贴进代码库中。这种方式并不是很方便，对不对？

为了恰当地分发你的项目，你需要：

从源代码创建一个包
将这个包放到某个公开的程序包注册中心中。（根据你的生态系统进行选择，例如，对 Java 来说可能是 Maven Central Repository，对 JavaScript 来说可能是 Npm Package Registry，等等）。

这时，你要为你的新仓库添加一个构建链，确定项目的名字，等等。

我并不打算对整个过程进行分解，因为它非常依赖于你的生态系统、工具集和你使用的编程语言。

你可能无所不包，对你来说，确定新项目，添加构建链，发布程序包都是小菜一碟。如果是这样的话，那就好办了！

你可能习惯于只写代码，从未面对过所有的这些定义、配置、工件和类似的东西。对你来说，这可能是一个全新的新世界。

如果你是后者，就该学习了。我向你保证，要不了多久就能达成目标。

不论如何

当你完成脑海中所有缺失拼图的拼装，你就学会了有关程序包注册中心的一切。并且你的程序包已经发布了，那时，也只有那时你才能真正地认为你的项目开源了。

这时，你可以告诉人们：“嘿，我已经有你那问题的解决方案了，你只需要把这个包添加到你的项目中，然后使用它就行了！”

进行完整性检查

确保你的项目在开始像病毒一样传播之前能够正常工作。

对程序包的完整性检查，实际上就是从你那更大的代码库中删除通用的目录，并改用这个公开的程序包。

毕竟，你是你的开源项目的第一个用户。

如何处理你的代码库中的进一步开发问题

当你开始在你的代码库中使用这个程序包时，开发流程可能会发生变化。在之前，开源代码是你代码库的一部分——你可以立即使用所做的更改。

但是现在，它与你代码中使用的任何其它第三方软件包一样，都是外部的软件包。

因此，当你在崭新的开源项目中开发新的功能时，必须先发布它，才能在你那更大的代码库中使用它。然而，如果你不确定它是否可行，你就不能发布它。因为一旦发布，就可能会影响其他用户。

为了避免发布有问题的版本，你可以做以下几件事情：

用测试覆盖你的代码，包括单元测试和端到端测试。
我认为我不需要跟你讲测试是多么的重要。
在本地打包并安装新版本的程序包到你那更大的代码库中。
验证一切按预期工作之后，你就可以发布它了。
发布一个 Beta 版本，仅开放给那些明确希望使用该版本的用户，而不是全世界。
例如，在 npm 的程序包注册中心中，dist tags 就可以用于这个目的。
默认的 tag 是 default，当你运行 npm install mypackage 时，它实际上会运行 npm install mypackage@latest。当你用另一个 tag（比如 beta）发布一个新版本时，人们只有显式地从这个 tag 安装才能获取到最新的版本：npm install mypackage@beta。

小结

与前一节的纯理论不同，这一节实际上会要求你做一些事情。根据你经验和学习能力，可能需要花费你几天甚至几周的时间来完成这个必需步骤，而我们甚至还没有开始呢。

这就是为什么我有责任再问你一次：

你真的准备好将宝贵的时间奉献给社区了吗？

如何为你的开源项目编写文档

这篇文章的前两部分是针对那些正在考虑创建开源项目的人写的。我想让他们知道应该期望什么，并帮他们在开源世界里开个头。

这一部分，以及后面的部分，也会与那些已经在维护开源项目并希望有所改进的人们有关。

这一部分的基线：

你已经有了一个开源项目，我们可以在 GitHub 上访问它，并且可以很容易地通过某个程序包注册中心使用它。

为什么你需要文档，它应该包含哪些内容？

一个没有文档的开源项目毫无生命可言

之所以说毫无生命，是因为没有人会深入你的代码，去了解应该如何使用它。在此之前，甚至没有人知道你的代码是干嘛的。

所以你的文档应该基本上包含这两部分的内容——它是做什么的以及如何使用它。这两点是文档的奠基石，是文档的必备内容。

如何写项目描述

人们在进入某个 GitHub 仓库时，首先看到的就是项目的描述信息。因此，一个好的描述应该简明扼要地回答“它是做什么的”这个问题。例如：

React:

一个声明式的、高效且灵活的 JavaScript 库，用于构建用户界面。https://reactjs.org

Moment.js:

在 JavaScript 中解析、验证、操作并展示日期。http://momentjs.com

Angular builders （这个项目是我的）：

Angular 构建门面扩展（Jest 与自定义 webpack 配置）

你可以在仓库的 About 部分编辑描述信息：

如何写 README.MD 文件

README.MD 是一个位于你的项目根目录中的文件，用 Markdown 语法编写，它包含别人需要知道的有关你的项目所需要的一切信息。

README 文件应该包含一个详细的描述（在“它是做什么的”这个问题上进行展开），以及关于“如何使用你的开源项目”的详细说明。

说明的内容应该覆盖每一个公共 API，最好是有使用示例。

这里编写良好 API 文档的几个要点：

最简法则——API 和示例越简单，使用者就越容易理解它是做什么的以及如何使用它。
条理清晰——对所有的 API 方法都使用相同的模板和可视化结构。这样，你就可以定义自己的语言，向使用者传达 API。
变身用户——总是从用户的角度编写 API 描述。假设你对项目的内部一无所知，并且这份文档就是你的全部。
保持最新——随着项目的演进，API 可能会发生变化。确保你的 README 文件总是包含最新的 API 和示例。

README 可以（但不是必须的）包含以下内容：

贡献指南的链接
贡献者名单
变更日志的链接
最新版本
协议
构建状态
下载次数
用于快速反馈的聊天链接

这里是一个优秀 README 的示例。

何为徽标

徽标（Badge）是一种很好的方式，可以直观地显示项目的基本信息，例如：构建状态、版本、协议以及项目使用的各种工具。

选择有很多，但是我推荐你使用 shields.io 的徽标。他们的徽标很丰富。

给 README 文件添加徽标真的非常简单：

前往 shields.io
选择合适的分类
点击你想要添加到 README 的徽标
填写需要的信息（如果需要的话）
从下拉菜单中选择 Copy Markdown
将 markdown 粘贴到你的 README 文件中

徽标通常放在 README 文件的顶部，就在详细描述的前面。它看起来像这样：

确保你进行了测试

API 参考很棒，但是没有什么比使用你的公共 API 的真实代码更好了。

完善文档的最佳方式之一就是用描述性测试来覆盖代码。有时，测试比任何文档更能解释代码。

小结

在这一部分，我们只覆盖了文档的基础知识。例如，除了 README 和描述信息，还有很多其它内容。随着项目的发展和问题（issue）的出现，它们将成为文档的组成部分。

然而，对于任何一个像样的开源项目来说，拥有一份覆盖公共 API 的 README 文件只是最低要求。

如何推广你的开源项目

我们已经讨论过发起一个项目意味着什么，如何以最佳的方式去做，以及如何为它写好的文档。

现在，我们就来聊聊如何将公众的注意力吸引到你的项目上来，以及如何在吸引与正确管理贡献者上面对项目进行优化。

这一部分的基线是：

你已经有了一个开源项目，人们可以在 GitHub 上访问它，它有良好的文档，并且可以很容易地通过某个程序包注册中心使用它。

如何宣传你的项目

咱们开门见山吧：随着项目的发展，你根本无法独自处理每件事情。所以，如果你想让项目长久生存下去，繁荣昌盛，你需要更多的人参与到项目中来。

为了让更多的人参与到你的项目中，你需要更多的人知道它，更重要的是相信它。

根据我的经验，将你的开源项目暴露给合适的受众的最佳方式是 使用知名的资源渠道，并写一篇关于项目的博客文章。

资源渠道可以是纯面向开发的（比如 dev.to），也可以不是（比如 Medium）。

所有这些资源之间都有一个共同点：它们都有既定的受众，并且是相关的受众。

你也可以在不同在线资源之间交叉发表你的文章，从而覆盖到更到的受众。但是要注意，交叉发表有几个弊端：

每个平台可能都有各自不同的标记语言，你不得不重新调整所有的格式
维护性——如果某部分内容变了（事情会发生变化），你就需要在所有的资源中对你的博客进行更新

如果你选择 Medium，我会高度推荐你将自己的文章提交到某个大型专栏。这将要求你做更多的事情，因为你需要让你的文章满足专栏的要求。但是它也能确保更多的受众接触到你的文章，更重要的是，相关的受众。

你还可以决定选择 metered paywall（你可以从中赚钱！）：

属于付费专区的故事也可以通过主题分发给 Medium 读者，这些主题可在我们的主页、主题页、每日摘要和应用程序中被推荐。

我无法告诉你哪种方式更好，但是我个人更喜欢专栏，因为它能确保你的文章被读者看到，而不是像“符合发布条件”一词这么模糊。

如果你的博客广为传播，那么它就可以产生级联效应，为你的开源项目带来更多的人。

例如，如果你的 GitHub 项目在发表文章之后的一天之内收获了几十颗星，就可以进入 GitHub 的趋势页，这本身也是另一个暴露源。

让你的博文更加优秀的几个要点：

以问题陈述作为开始，它甚至可以是博客的标题。
人们通常是在寻找某个特定问题的解决方案，在他们决定花时间读你的文章之前，他们应该知道你的文章是否是他们正在寻找的东西。这里是我写的一篇文章的示例。
如你所见，它在标题中清晰地阐述了它所解决的问题。
如果你在谷歌搜索“Customizing Angular build”，它将会出现在排名靠前的几个结果中，并且你可以直接从搜索页面上看到它解决了哪个问题。
描述一下你的项目为什么要解决了这个问题，它是如何解决的。
提供一份详细的逐步指导，从安装开始，以可以正常运行的示例结束。
有很多开发者都更喜欢可以正常运行的示例，而不是博客文章。
在发表文章之前，先获取一些反馈。
让你的朋友们仔细阅读你的文章，不要告诉他们你的文章是关于什么的，看它们能够自己说出来。如果他们做不到，那么很有可能是你的文章不够清晰，你需要写得更加详细。

在发表博文之后，在社交媒体上与你的朋友、家人和马路上的陌生人分享。

这将会增加你的项目的曝光度——但是你也要让人们愿意向你的项目做贡献。

项目如何吸引贡献者

最好的办法就是与他人一起发起一个开源项目。通过这种方式，你从一开始就能拥有一个可以一起分担责任的团队。

然而，并不总是如此。

如果你独自发起开源项目，你必须吸引贡献者。根据我的经验，有两种类型的贡献者：

想要产生影响并在找项目做贡献的人（虽然很少见，但是也有）。
使用你的程序包并且发现了缺陷或者缺少某些功能的人。

在这两种情况下，只在 GitHub 上分享你的源代码并写一篇关于如何使用它的博文是不够的。以下是一些可以使人们愿意做贡献的事情：

一个待实现清单

它可能包含已知缺陷、规划的功能或者其它的东西。这个清单会让第一类贡献者更容易选择正确的事项并发起 PR。

它可以是一个独立的清单，你也可以（或许是应该）使用 GitHub 上的议题（issues）和标签（labels）。

一份贡献者指南

基本的贡献者指南应该解释仓库的结构，包含关于构建并运行项目与测试的逐步指导。扩展的指南可以包含架构、设计决策、行为准则等。

Atom 的贡献者指南就是一个很好的例子。千万不到低估它的价值！随着项目的发展，这需要花费大量的时间，我希望我从一开始就创建它，并随着项目的发展逐渐更新。

不幸的是，我没有人指出它的重要性，而我的项目今天都还没有贡献者指南。它一直在我的待办清单上，但总有比它更紧急的事情。

感谢你的贡献者们

在项目的主页列出贡献者们，这会让他们有更多的动力去做贡献。

只添加他们的名字就够了，但是我将会推荐你使用 All Contributors。它不仅能为你的所有贡献者创建带有个人资料图片和徽标的精美部分，还能通过创建 PR 来自动添加新的贡献者，将贡献者添加到这个区域。

小结

我们在这一部分讨论了增加项目曝光度以及赋予人们初始动力去创建 PR 或议题的几件事情。

但是这并不能让他们坚持做贡献者，也不能确保他们完成已开始的工作。

如何管理议题与拉取请求

既然我们已经探索了共享信息和如何让你的开源项目变得更具吸引力，让我们来讨论一下贡献吧，它是每个开源项目的圣杯。

什么是开源贡献？

对一个开源项目的贡献是指由所有者以外的人所做的任何改变。在实践中，它有两种形式：

议题

这里是 GitHub 关于议题（issues）的描述：

你可以在仓库中使用议题收集用户反馈，报告软件漏洞，并且组织要完成的任务。议题不只是一个报告软件漏洞的地方。

简而言之，议题可以是需要采取某种行动的任何信息。

拉取请求（PR）

这里是 GitHub 关于拉取请求（Pull Request，PR）的描述：

拉取请求可让你在 GitHub 上向他人告知你已经推送到仓库中分支的更改。在拉取请求打开后，你可以与协作者讨论并审查潜在更改，在更改合并到基本分支之前添加跟进提交。

简而言之，拉取请求就是对项目的实际修改。

如何使用议题和 PR

那么，你应该如何使用议题和 PR，又该如何处理贡献者创建的议题与 PR 呢？

以身作则

我能给你的最好建议是，结合某个具体的工作方法以身作则。这意味着，当你开发新功能时，你应该为这个功能创建一个 PR，在它满足你所有的要求之后就进行合并。

你应该在发现缺陷或者一些缺失功能时创建议题。

这个方法不仅能组织好你的工作，让你的项目变得井井有条，还能给贡献者们提供一个参考，他们可以从中学习并调整自己的议题与 PR。

此外，如果你的标准很高（即你相信每个 PR 都应该有适当的文档、测试覆盖等等），那么你应该像对待任何其他贡献者一样对待你自己。你不能要求别人做你自己都没有做的事情。

还有就是，有时候你对贡献者应该比对自己更宽容。在你的项目处于初期阶段，没有很多贡献者时，更应该这样。这就涉及到了下面这一点。

感谢一切付出

与他人协作就是要相互尊重。你应该尊重你的贡献者们，耐心地回答他们的问题（即便问题看起来很简单），礼貌地对待建设性批评。

记住：对贡献者工作的感谢至关重要。如果某人只是创建了一个议题（即使这个议题没有经过深入研究，甚至没有重现），感谢他们。他们费力地把自己的椅子挪到离桌子近一点的地方，坐直身子，然后打了一点他们认为对你有用的东西，感谢他们。如果需要的话，用礼貌而又尊重的方式向他们询问更多的细节。

如果某人创建的 PR 没有满足你的高标准，感谢他们。感谢他们并礼貌地请求他们修改代码/编写测试/添加文档，等等。给他们一个你的 PR 的链接作为参考，或者给他们一个贡献指南的链接。

建设性地积极对话将会给予那些贡献者们额外的动力，让他们继续工作。

质量 vs 数量

最终，几乎总会有一个折衷（除非你自己拥有一个像 Angular 或 React 这样的大型开源项目）。你可以决定不放低标准，哪怕是一点点也不行，很有可能你最终会自己完成所有的工作。

或者，你可以决定放低对贡献者的标准（但是这可能会让你的标准显得毫无用处，因为它们没有被执行）。

我了解到，每个贡献者都需要使用不同的方法。这真的是由他们个人及其对贡献的兴趣决定的。

你应该考虑议题的紧急性、贡献者的经验、代码的复杂度、所需修复或功能的复杂度、贡献者的动机等因素。

通常，当议题非常重要时，我会礼貌地请求贡献者进行更改，然后等个几天，如果没有任何进展，我就会自己进行更改。至于那些没那么重要的（有了会更好）修复或者功能，我通常会把它们完全留给社区。

随着议题和 PR 数量的增长，跟踪、确定优先级并对它们进行分类就会成为一项艰巨的任务。这意味着标签会变得异常重要。

使用有用的标签

GitHub 的标签是让议题和 PR 保持优先级与组织性的好工具。虽然你可以通过标签进行搜索和过滤，但是我发现最有用的还是它可以帮助可视化项目的整体状态。

这样，你可以进入“议题”页，看到大部分议题都被打上了 bug 标签（这意味着你应该停下来集中精力修复它们，而不是往前推进了）。

或者，你可以看见大部分议题（issue）都被标记为 enhancement 或需要 features。priority 是另一个有用的标签，可以帮你首先关注到重要的东西。

此外，你的贡献者可以（也会）从你使用的标签中受益。例如，回到吸引贡献者，一些人可以进入议题页（issues），然后直观地地识别出那些需要社区帮忙处理的议题（help-wanted、pr-welcome，等等）。

除了职责单一的标签（比如 bug 或 enchancement）外，我推荐你使用标签来限定议题/PR 的范围。例如：

priority:low，priority:high
required:investigation，required:tests，required:docs
或者在单仓库的情况下： packages:package1，packages:package2 等等

这里是一个使用了标签的议题页，它来自我的项目：

标签让你可以快速地分辨出哪些问题是需要你（或你的贡献者）注意的，这些问题与哪个组件相关以及需要什么才能继续进行。

使用 PR 和议题模板

我强烈建议你花几分钟时间，为议题和 PR 定义模板。

利用议题和拉取请求模板，可以自定义和标准化你希望贡献者在你的仓库中打开议题和拉取请求时加入的信息。

这将为你节省大量的时间，因为你不需要对每个问题或 PR 进行附加信息或更改的请求。有时候你还是需要这样做（因为有些贡献者根本不关注模板），但是它发生的频率要比不创建模板少得多。

这里是默认议题的一个例子，你可以看到对应的模板是何时在你的仓库中定义的：

使用 GitHub 的应用程序与操作

有很多的 GitHub 应用程序和操作可以帮你管理 PR 与议题。相关应用程序和操作的数量仍在不断增长，但是我个人发现这些功能最有用：

及时响应

如果我在其它开源项目上打开了一个议题或 PR，并且等了很长时间才收到回复，那么我就会对它失去兴趣。这里是一个例子：

最初的响应非常快，只花了两天
讨论的成果丰富
PR 仍然处于打开状态，但却没有关于到底是什么少了/错了的更新

最终，我转向了另一个包。

如果你不及时响应，这也会发生在你的项目上：如果你要花两周的时间响应一个需要你处理的 PR，而不是等待你要求的贡献者更改，那么你就会失去用户（即潜在的贡献者）。

所以帮你自己一个忙——及时响应。不一定要立马解决某人的问题，但是，即便是让用户知道你会在下周研究他们的议题，也给了他们一些确定性和时限。

坏消息是，你应该信守诺言。如果你的诺言有时没有完成，不要担心——我们所有人都有自己的生活，如果你因一些紧急的事情推迟了你在开源上的工作，是可以理解的。

如果发生了这种情况，就给一个简短的更新——又不是什么大事儿，只需要写一两个字，让人们知道他们一直在等待的那个功能被推迟了。

如何确定议题的优先级

有几种方法可以帮你确定最重要议题的优先级。

首先，应该如何识别出最重要的议题呢？我个人认为，最重要的议题就是用户最想要的那些东西，不管它是新功能、缺陷修复，还是其它东西。

有时候，用户会在议题中表现出他们的兴趣，但是他们很有可能不会这么做。因此，我给大家介绍一种了解用户对哪些东西感兴趣的简单方法：

GitHub 上的每个项目都有一个 “Insights” 选项，其中有一部分叫 “Traffic"：

你可以在这部分的底部找到热门内容表（Popular Content table），它可以让你深入了解哪些页面是使用者们访问得最多的：

这个表中展示的议题是访问频率最高的那些议题，因此对你的用户来说，它们最有可能是最重要的。

甄别出最重要的议题后，你需要在议题页面突出它们。这里是几种方式：

固定议题

每个仓库可以有最多三个固定议题（pinned issue）。固定议题出现在议题页面的顶部，所以几乎不可能忽略他们：

添加标签

我们已经讨论过使用标签了，并且对 help-wanted 和 priority:high 标签的应用来说，这是一个绝佳的例子。这些标签会让潜在的贡献者们知道这个议题很重要，并且他们的任何帮助都会被感谢。

持续集成

在将每个拉取请求合并到主干（master，或者 main）之前，先进行构建和测试，这将让你对即将合并到主干分支的代码充满信心（取决于测试的覆盖程度）。

尽管我不能不提到它是 PR 管理过程的一部分，但是它是一项任务的自动化，否则你不得不自己做，这样它就与 PR 管理没有直接关系了。

你仍然可以检出（check out）每个 PR，在本地构建，运行测试，然后在一切都通过之后进行合并（这样的话，持续集成就与 PR 管理没有直接关系）。不过别担心，我们将会在下一部分详细介绍持续集成。

小结

让你的项目保持整洁有序非常重要，因为，我们都知道，整洁是一种美德。它不仅让管理过程更加高效，还能改善项目给人的总体印象。

PR 和议题（以及代码库）是开源项目门面的不可或缺的一部分。不要低估它们的价值。

如何实现流程自动化

管理贡献（即议题和 PR）的一个自然部分是自动化——可能是 OSS 项目管理中最重要的方面之一。

为什么要自动化？

如果说我在拥有一个开源系统的这些年里学到了什么，那就是你要做的例行事项越少，你就有越多的空闲时间用于实际的工作（比如修复缺陷或者开发新功能）。因此，我力求尽可能自动化。

这里是我希望我们如何实现这个目标的方式：首先检查两个工作流程（非自动化和全自动化），看你有多少时间实际上是花在例行事项上的。然后，我们将探讨如何实现改进的工作流程，让我们有更多的时间来修复缺陷。

最糟糕的情况——没有自动化

如你所见，在没有任何自动化的情况下，所有的工作都由你来做。仅仅对于一个缺陷修复来说，你就需要做很多工作，更重要的是，每次修复缺陷或开发新功能时，你都要做这些工作！

现在我们来看看另一种情况。

最好的情况——一切都是自动化的

在这种情况下，你只需要做必须要做的事情——检查代码和（偶尔）批准拉取请求，其他的一切都是自动完成的。

科幻小说？不，它被称为持续集成（continuous integration） 和 持续部署（continuous deployment）。在这里，我们并不会深入构建脚本和特定系统配置的细节。相反，我们将会查看让它发挥作用所需的工具，我将会让你自己决定具体细节。

什么是持续集成（CI）?

持续集成（CI）是一种自动将代码改动从多个贡献者集成到单个软件项目中的实践。 CI 过程由自动工具组成，这些工具会在集成之前断言新代码的正确性。

一个非常基础的 CI 运行将会包括 构建（build） 和 单元测试（unit tests），但是并不局限于这两种。可能也会包含各种各样的静态代码分析工具、链接器等等。这里的标准由你定。

为什么你应该使用端到端测试

构建和单元测试可以为你提供有关代码变动的快速反馈，所需时间相对较短，并且在出现问题的时候迅速失败。但是端到端（end-to-end，E2E）测试在 CI 中有着特殊的地位。

端到端测试不仅应该覆盖代码的正确性，还应该覆盖到你的部署流程、包的完整性等等。

我自己也意识到了这一点，当我不小心发布了一个不包含代码的新版本包。构建通过了，单元测试和端到端测试也没有问题（这一次是通过链接测试项目的构建输出目录来安装的）。哪里失败了呢？在打包阶段。

这里有一个关键点：端到端测试应该像真实用户使用那样测试你的软件包。

为了达到这个目标，我推荐以下几步：

在你的 CI 运行期间，启动一个本地的包注册中心。每个语言/生态系统都有几个选择，例如对 Java 或 Scala 项目来说，你可以用 Nexus 仓库，对 JavaScript 来说，可以使用 Verdaccio（我在 @angular-builders中使用它）。
有一个使用你的软件包的独立项目（它可以位于同一个仓库中）。这个仓库中的测试应该测试你的打包功能。
配置这个项目使用本地包注册中心。
构建完你的包之后，将其发布到本地包注册中心（在你的 CI 系统中启动）
安装改包的最新版本（你刚才构建的那个）到你的测试项目中。
运行测试。

这不仅可以测试软件包的完整性和可靠性，还可以在进行持续部署时给你省去一些工作。

CI 系统是如何工作的

很多 CI 系统都有针对开源项目的免费计划，其中有 Travis CI、CircleCI、AppVeyor、GitHub Actions 等。

它们的功能都比较多，做的事情也基本相同：检出你的代码到虚拟机、运行你定义的脚本（通常运行构建和测试），然后向 GitHub 报告成功或失败。

所有这些系统都有一个用于和 GitHub 集成的应用程序，它们当中的集成过程也非常类似：

在平台上注册。
在你的 GitHub 账户中安装对应的应用程序。
配置对所选仓库的访问。
创建一个配置文件（比如 travis.yaml），定义构建矩阵、所需构建链和 CI 脚本。
将它推送到主干。

这会使你的 CI 在每个 PR 上运行，并向 GitHub 报告状态——但是这还不够。你真正想要的是在 PR 通过所有检查之前，阻止合并到主干分支。

这可以通过定义分支保护规则来实现。为了定义这些规则，你需要前往你仓库的 Setting 中的 Branch 部分，然后点击 Add rule 按钮：

然后选择多选框 Require status checks to pass before merging：

如你所见，相应的 GitHub Apps 多选框也已经出现在了这里，所以剩下的唯一一件事情就是启用它们。

具体的构建脚本由你的生态系统、编写项目的语言、你所使用的框架等决定。因此，我不会在这里进行介绍——你需要自己检查 CI 系统的文档，了解具体细节。然而，你现在对什么是 CI 以及它是如何自动化你的 PR 有了很好的认识，让我们继续前进吧。

持续部署（CD）是如何工作的

持续部署（CD）是一个软件发布过程，它使用自动化测试来验证对代码库的更改是否正确和稳定，以便立即自动部署到生产环境中。

在我们的情况中，生产环境就是程序包在包注册中心中公开可用的时候。这是一个无法返回的阶段，因为一旦发布，就不能取消发布了，因为程序包是公开可用的（因此，它可能正被使用）。

持续部署有多种策略，具体策略取决于项目及其复杂程度。但是在我看来，发行（release）只应该基于主干分支，因为这会让工作流变得非常简单。具体做法如下：

每个 PR 要么代表一个缺陷修复，要么代表一个新功能。
代码在进入主干之前经过了测试（包括端到端测试）。
主干分支是受保护的分支，所以只要你不合并失败的 PR，它就会保持稳定。
每个合并到主干的 PR 都会触发主干 CI 运行，CI 最终会发布一个新版本。

这将确保所有的发布都是按顺序进行的，并且可以很容易地将某些 PR 与特定的版本联系起来。

为了自动化程序包的发行过程，你需要做几件事情：

基于提交信息自动升级版本。
基于提交信息自动更新 CHANGELOG。
自动发布程序包到公共程序包仓库。
自动在 GitHub 上发行。

给大家带来一个好消息：语义化版本（semantic-release）已经支持所有这些功能了。坏消息是：你需要花一些时间才能让它发挥作用（但是最终会有所回报）。

Semantic-release 是如何工作的

semantic-release 自动化整个程序包发行工作流程，包括：确定下个版本号、生成发行说明和发布程序包。

这消除了人类感情和版本号之间的直接联系，严格遵循语义化版本版本规范。

我们不会在这里介绍整个集成过程，因为它们有良好的文档，也没有理由在这里进行复述。不过，我还是会提几点：

在你开始 Semantic Release 之前，确保你理解语义化版本声明和约定式提交的格式。
为了使 semantic-release 能够良好地工作，你应该强制执行某些提交消息格式。为此，你可以将 Commitlint 作为一个 husky 预提交钩子运行。当有人创建本地提交时，它将强制执行常规提交，但对于直接从 GitHub Web UI 进行的提交就无能为力了（这通常发生在有人想要快速修复他们的 PR 时）。因此，我建立你通过 commitlint GitHub Action 对其进行备份。

在将语义化发行设置为工作流的一部分之后，你差不多就快完成了，你不再需要在这些常规过程上花时间。尽管你还可以进行另一项优化。

如何保持项目的更新

如果你的项目没有外部依赖，跳过这一部分。然而，大多数项目都依赖于其它程序包，而其它程序包往往会发生变化。

使项目保持最新的依赖关系很重要，但这很耗时。幸运的是，我们有一个解决方案。实际上，有一些，例如 Greenkeeper、Renovate 和 Dependabot。

它们的想法几乎相同，因此我只引用 Dependabot 的 “How it works” 部分：

1. Dependabot checks for updates
Dependabot pulls down your dependency files and looks for any outdated or insecure requirements.

2. Dependabot opens pull requests
If any of your dependencies are out-of-date, Dependabot opens individual pull requests to update each one.

3. You review and merge
You check that your tests pass, scan the included changelog and release notes, then hit merge with confidence.

你可能已经注意到，他只在你有能发挥作用的 CI 时才有意义。

小结

如果你有一个全自动化的 CI/CD 闭环，并且在你的 OSS 仓库中有一个新打开的议题，你可以在几分钟内提供一个缺陷修复。

实际上，你可以在你的手机上进入 GitHub 移动版，修复一两行缺陷代码，然后提交。剩余的事情就自动完成了，你的客户马上就能得到一个新的版本。

我自己就能够快速、轻松地向客户多次提供修复版本。

拥有强大的自动化能力并不是为了腾出一些时间进行休闲娱乐，而是要把时间用在真正重要的事情上，并提高响应能力。

版本管理

在这篇指南的最后，我想谈一谈版本管理，对于任何拥有大量用户的 OSS 项目来说，版本管理总是很重要。你将会了解到版本符号、中断性变更、向后移植，等等。

什么是软件版本控制？

咱们来看一下维基百科对软件版本控制（software versioning）的解释吧。

软件升级版本控制（Software upgrade versioning）是将唯一的版本名称或版本号分配给计算机软件的唯一状态的一个过程。

现代计算机软件通常采用两种不同的软件版本控制方案进行版本跟踪——可能在一天内增长很多次的内部版本号，比如修订控制号，还有一个就是发行版本，它变化得通常没这么快，比如语义化版本[1]或项目代号。

确实，有很多方法可以唯一标识你的软件产品的版本。

最广为人知的方式就是给它起一个名字。

地球上的绝大多数人，甚至包含那些与技术有着间接关系的人，都可能听说过安卓的冰淇淋三明治（Ice Cream Sandwich）和棉花糖（Marshmallow）或 Mac OS 的美洲豹（Leopard），以及它的冷冻表亲雪豹（Snow Leopard），还有 Big Sur。

程序员可能听过 Eclipse 及其天体版本 Luna、Mars 和 Photon。

所有这些都是软件产品的大版本号。

尽管名字非常适合市场营销，但是它们有时候也会让人感到困惑。

实际上，谷歌已经在它们的安卓版本名字中取消了对糖果的使用，因为它们：

多年以来都听到用户在反馈：这些名字总是不能让全球社区中的每个人都有直观的理解。

没错，但也许只是我们还没进化到从动物种类推断出版本号的程度，尽管雪豹（Snow Leapard）比美洲豹（Leopard）要酷很多。

天体和糖果都是比较容易理解的概念，但前提是你必须按照字母的出现顺序命名（像安卓和 Eclipse 这样）。但是有一点可以肯定——没有什么方法能够比数字更好地确定连续的情况。

因此，如果你将你的软件产品的第一个版本命名为“Product 1”，将第二个版本命名为“Product 2”，那么就可以很直观地说第二个版本是最新的，不是吗？

然而，不同于不暴露 API 的独立软件产品，那些被其他软件（比如 OSS 产品主体部分）使用的软件需要更好的版本控制，而不仅仅是一串数字。

例如，如果我们用一个简单的数字序列进行版本控制，用户如何能区分出缺陷修复和中断现有 API 的变更呢？

答案就是……语义化版本。

什么是语义化版本？

语义化版本（又称 SemVer）是一个广泛采用的版本管理方案，它使用格式为 MAJOR.MINOR.PATCH 的三位数字序列。

规则很简单——给定一个版本号 MAJOR.MINOR.PATCH，分别在不同的情况下递增不同的版本：

当你进行了不兼容的 API 变更时，递增 MAJOR 版本
当你以向后兼容的方式添加了一个功能时，递增 MINOR 版本
当你进行了向后兼容的缺陷修复时，递增 PATCH 版本

预发行和构建元数据的其他标签可以作为 MAJOR.MINOR.PATCH 格式的扩展使用。

它提供了一种简洁明了的方式，来将软件产品中的变更传递给你的用户。

但是最重要的是，它被所有种类的包管理器和构建工具（比如 NPM 和 Maven）广泛使用，这些工具允许用户依赖 某个范围内 的版本，而不是某个特定的版本。

例如，声明版本区间 ^2.2.1 而不是显式的版本号 2.2.1 将会让用户接受任何向后兼容的缺陷修复或将会在 2.2.1 版本之上发布的新功能。

也就是说，构建工具和包管理器依赖用户和包的所有者之间的约定——这个约定是由 SemVer 定义的。

那意味着你要全权负责——你就是那个给中断性变更和小型变更下定义的人。你可以不小心将一个中断性变更作为缺陷修复（补丁版本）发布，并且它将会破坏依赖某个范围的构建。

破坏构建是一件非常恐怖的事情，所以我推荐你使用带有预定义消息格式的 semantic-release 和提交格式的强制工具。

你可以在 Server.org 的官网找到更多有关语义化版本的信息。

既然我们已经学了如何识别中断性变更，我们就来聊聊如何引入它们吧。

如何管理中断性变更

中断性变更（breaking change）是那些对公开 API 的变更，这些变更以不兼容的方式移除、重命名或更改了你与用户之间的约定。

理想情况下，你将会在你的代码中保持向后兼容，并且永远不会引入中断性变更。但是，你会意识到现实的残酷的。

软件在不断演进，你的代码也是。用户的需求会变，你的 API 也会变。你作为一名开发者在成长，你的产品也在成长。

因此，特别是作为一个不拿工资的开源开发者，你就是不能容许你自己维护的项目中存在的所有遗留代码。有时，你需要移除它们。

问题是如何移除？

与往常一样，需要进行权衡。你会更清楚这个或其它的变更对用户的影响。

你不必不惜代价地保持向后兼容，也不必在每个旧版本中实现所有的新功能。但是，这毫无疑问是你应该考虑到的事情。

如果用户的迁移成本比较低，那么进行中断性变更是可以的，在较老的版本中不支持这个功能也很合理。

然而，如果迁移成本很高，绝大多数用户无法承担的话，你或许应该先考虑让这个变更向后兼容，然后发布一个废弃警告。

废弃警告通常和新的 API 一起发布，旧的 API 仍然受到支持。这样一来，用户就有时间进行迁移。在他们完成迁移之后，你就可以再下个大版本中安全地移除废弃警告和旧的 API 了。

无论如何，不管你何时引入中断性变更，都要确保有一份迁移指南，包含迁移的每一步。

此外，出于礼貌，你最好给用户留下为中断性变更做准备的时间，尤其是在没有宽限期的情况下（新旧 API 都支持）。

一个解释中断性变更、其背后的原因以及预期的时间范围的预先通知是非常有用的。这个通知可以是一条推特、一篇博客文章，甚至是任何带有废弃警告的新的小版本。

记住，虽然中断性变更基本上是一个负面体验，但是一个突然的中断性变更却是一个非常负面的体验。

自动迁移

我们可以将中断性变更分为两类——非确定性（non-determinstic）变更与确定性（determinstic）变更。

非确定性变更是指那些你无法预测迁移工作结果的变更，比如将某个 API 的特定部分完全移除。

在这种情况下，由用户自己决定是否要用第三方库替换它、自己实现它。

确定性变更是指那些给定代码 X 和用户输入 I，允许你将其转变为代码 Y 的变更（即通过输入可以明确地知道输出）。比如，改变函数名或者导入语句。

如果你引入了一个确定的中断性变更，你可以编写一个自动化程序，修改用户的代码库，并将其调整为新的 API。

有了这种自动化，你就不必担心向后兼容和详细的迁移指南了。你给用户提供一种不需任何努力就能升级他们代码的方式，这对软件更新至关重要。

然而，这里也存在固有的权衡。写代码需要花时间，就像编写迁移指南一样。当然，编写将复杂代码流迁移到新 API 的代码比编写替换函数名的代码花费更多的时间。

有时，你并不能负担起这个时间。

如果你决定这么做，有一些工具可以帮你实现目标。

其中最广为人知且语言无关的就是 Facebook 的 Codemode。

codemod 是一个工具/库，可以帮助你重构大规模代码库，重构可以部分自动化，但仍然需要人工监督和偶尔干预。

还有一些更加复杂的工具，它们使用抽象语法树（AST），可以用于更加复杂的任务，而不仅仅是查找并替换。

例如，Facebook 的另一个库（只适用于 JS/TS）被称为 JSCodeShift。或者 code-migrate——一个允许你比较容易地编写迁移指南的工具（还是只适用于 JS/TS），为用户提供一个漂亮的基于命令提示符的 CLI 界面。

一些大型 OSS 项目甚至有他们自己的解决方案。其中有一个例子就是 Angular schematics ——一个基于模板的代码生成器，支持复杂逻辑。

自动代码迁移可以作为一个单独的程序包（比如 my-cool-oss-migrate-v4-v5）发布，并作为迁移指南中的一个步骤被提到。

另外，迁移可以是包含中断性变更的大版本的一部分，可以在用户在代码库中安装该版本后执行。具体由你决定。

移植

另一个惯例就是将重要的变更移植到以前的版本中。例如，在某个主要发行版本（此版本包含中断性变更）之后发现了一个严重缺陷，但是这个缺陷也存在于之前的版本中。

这时，你不能指望用户们因为这一个缺陷就去进行繁琐的迁移。相反，检出老的修订版本，在它的上面进行修复，然后以该老版本的小版本发行，可能会很复杂。

解决方案：为每个大版本建立一个受保护的分支。

每当你计划发行一个大版本时，就从主分支创建出一个命名为 c.x.x 的分支，其中 c 就是当前的大版本号。把所有这样的分支设置为受保护的分支（就像主分支一样），这样你就不会在不经意间破坏到它们。然后，在你不得不从一个新的大版本中移植某个功能或缺陷修复的任何时候，你可以在这个分支上重新实现它，也可以（如果可能的话）从主分支挑选（cherry-pick）对应的提交。

此外，有一个策略值得一提：为下一个大版本创建一个单独的分支（而不是只为之前大版本创建分支）。

这通常适用于大规模项目（比如 Webpack 或 Babel），这些项目在每个新的大版本中多有很多的变更。

为即将到来的大版本建立一个单独的分支允许在其上开展工作，并将其发布进行测试，同时仍然将最相关的版本（在其上开展工作）保留在主分支。

新版本发布之后，它的分支就成为主分支，下个大版本的新分支也会被创建。

最后的想法

我希望你喜欢这篇指南，现在已经对拥有一个开源项目意味着什么有了一个更好的理解。

最后，我想和大家分享一件事，在拥有一个开源项目时，你应该使用牢记。

倾听用户的声音

这听起来可能有点违反直觉，但事实就是这样——你并不是唯一一个定义路线图的人，用户也定义了它。实际上，用户定义了路线图的绝大部分。

如果你拥有一个开源项目，你维护它的目的是为了帮助他人，而不是你自己。

准备多个反馈渠道。有些用户只有一个快速的问题，你可以在一秒钟内给出答案。

也有潜在的贡献者想要讨论路线图，但是他们又不想公开讨论，那么给他们一个联系你的途径。提供一个 Slack 或 Discord 的链接，分享你的 Twitter 账户，等等。渠道越多越好。

说到渠道，如果你有任何问题或想法，可以随时在 Twitter 上直接给我发消息。

原文：How to Be a Good Open Source Project Owner – The Ultimate Guide，作者：JeB Barabanov

开源 - freeCodeCamp.org

freeCodeCamp 课程重大更新在圣诞节上线

freeCodeCamp 认证全栈开发者路径

开发者英语课程 CEFR B1 级别

freeCodeCamp iPhone 和 Android 应用程序

2025 年将会很精彩。

祝贺 freeCodeCamp 全球开源社区 2024 Top Contributors

GitHub Top Contributors

论坛 Top Contributors

翻译 Top Contributors

YouTube Top Contributors

专栏 Top Contributors

Discord Top Contributors

技术文档工程师如何参与开源贡献

你能学到什么？

什么是开源？

为什么要贡献？

参与贡献会面临的挑战

如何参与开源项目？

开源贡献的最佳实践

我能做什么类型的贡献？

去哪里找开源项目？

示例项目

总结

Ep. 11 琚致远：多一份踏实和耐心，解锁技术旅程中更多可能性

更多关于嘉宾的信息

主要话题

提到的资源

Ep. 9 Rick：在开源世界里追求下一份“疯狂”

更多关于嘉宾的信息

主要话题

提到的资源

Ep. 7 水歌：在开源社区中成长，在开放生态中为社会创造价值

主要话题

更多关于嘉宾的信息

提到的资源

如何使用 GitHub Actions 实现开源项目的自动化

GitHub Actions 是什么

如何在你的仓库中设置 GitHub Actions

GitHub Actions 组件

如何自动化管理 issue 和 pull request

如何创建 issue 和 pull request 模板

欢迎新的贡献者并表彰社区的努力

如何实现代码 QA 的自动化

关于构建自定义 GitHub Actions 的提示

总结

初学者的开源项目参与指南

开源是如何运作的？

开源项目贡献是什么意思？

参与开源贡献的好处

开源迷思

开始参与开源需要具备什么条件？

了解 Git 基础

熟悉 GitHub

学习如何 fork（分叉）一个仓库

学习解决合并冲突（Merge Conflicts）

学习 Markdown 语法

发展你的软技能

如何开始参与开源项目贡献？

GitHub Explore

如何参与 freeCodeCamp 的开源项目？

Contributor Ninja

First Contributions

CodeTriage

Up For Grabs

First Timers Only

Open Source Friday

开源项目维护者

在结束之前......

谷歌文档之季（Google Season of Docs）项目申请指南

目录

Google Season of Docs是什么？

哪些人有资格参与该项目？

参与该项目的好处

你可以获得一笔津贴

你可以提高自己的技能

你可以扩大自己的人际圈子

你可以获得推荐和介绍

你可以获得未来进入谷歌的机会

你可以成为一个开源贡献者