我的第一个开源贡献:谈谈你的拉取请求

我终于收到了项目的回复,我的代码被合并了。
72 位读者喜欢这个。
Why make a new open source software license?  MPL 2.0 (part 3)

Opensource.com

之前,我写过一篇关于保持你的代码相关性的文章,当你为一个开源项目做贡献时。现在,你终于点击了创建拉取请求。你兴高采烈,你完成了。

起初,我甚至不在乎我的代码是否会被合并。我已经完成了我的部分。我知道我可以做到。未来充满了无数我将向开源项目提出的拉取请求。

但当然,我确实希望我的代码成为我选择的项目的一部分,很快我发现自己在谷歌上搜索,“开源拉取请求需要多长时间才能被合并?” 结果并不是特别有说服力。由于开源的性质(任何人都可以参与其中),维护项目的流程差异很大。但我曾在某处看到一条推文自信地说:“如果你在两个月内没有收到回复,你应该联系维护者。”

好吧,两个月过去了,我什么也没听到。我也没联系维护者,因为与人交谈并要求他们批评你的工作是很可怕的。但我并没有过分担心。我告诉自己,两个月可能只是平均时间,所以我把它放在脑后了。

四个月后,仍然没有回应。我再次选择了被动的方式。我决定不尝试联系维护者,但我这次的理由更消极。我开始怀疑我之前关于项目维护活跃程度的一些假设是否是错误的——也许没有人跟进收到的拉取请求。或者他们可能不看随机人士的拉取请求。我再次把这个问题放在脑后,但这次对看到结果的希望更渺茫了。

当我几乎完全放弃希望并忘记整件事时,在我发出原始拉取请求六个月后,我终于收到了回复。在他们要求我做了一些小的更改后,我的代码被批准并合并了。我的第五个错误是在没有收到回复时放弃了我的贡献,并且没有就我的工作进行沟通。

不要害怕沟通你的拉取请求。这样做可能意味着像在你的问题中添加一条评论,说“嘿,我正在处理这个问题!”一样简单。不要因为你暂时没有收到回复就放弃希望。所需的时间量将根据谁在维护项目以及他们有多少时间投入到维护中而有所不同。

这个故事有一个美好的结局。我的代码被合并了。我希望通过分享一些我在第一次开源之旅中遇到的绊脚石,我可以为一些想要第一次探索开源的人铺平道路。

接下来阅读什么
User profile image.
Galen 是纽约市 Simple Health 的高级软件工程师。她喜欢写作(为计算机和人类)、举重和猫。@galenemco

1 条评论

做得好!继续保持。不要害怕贡献,甚至可能收到不好的反馈。不好的反馈总比没有反馈好。而且通常不好的反馈意味着你可能会从经验中学到一些东西。我喜欢收到拉取请求,即使是对于我放在 GitHub 上的东西。我会质疑一些事情吗?但我总是会尝试以一种不会让人感到排斥的方式来做。然而,有时,提交拉取请求并被要求进一步解释某事的人会感到冒犯。甚至可能直接关闭拉取请求。不要这样做!如果你花时间努力提交拉取请求,那对你来说意味着什么。如果我问一个问题,那么你的工作仍然有价值,但我需要更多的背景信息。但有时甚至可能是一种试图让对方以不同的方式看待事物,希望从中学习的方式。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 许可。
© . All rights reserved.