工作业务需要在某个著名开源项目上实现了一个不大不小但是对本行业还挺重要的 feature ,于是走完审计流程把它推回给社区。但是提了 PR 之后发现就在半天前另一个人已经提了相同功能的 PR ,但是他的 PR 还是草案状态,而我们的已经基本可用了。
现在的状态是一个资深贡献者(这个 feature 很大程度上是在他的贡献基础上完成的)同时看了两份 PR 认为我们完成度更高更合理所以建议另一个人集中到我们的 PR 上来,对方也表示同意。
从工作的角度来说,由于我们后续会基于这个 feature 开展大量的工作(可以认为是一次对这个功能工程上的检验和认证)所以肯定希望我们来主导开发。
但是站在个人角度,其实在刚启动审计流程的时候我和另一个贡献者就已经联系上了,也知道对方在做,看到了对方的进展,而且都表达了合作的意向。当时的打算是一走完流程公开仓库就可以拉对方过来一起搞,但是没想到流程走了三天,而对方很快就提了个草案 PR 。我看到他是个实习生,这个 feature 就是他的实习项目,所以对他来讲可能是一次重要的开源经历。突然得知之前的工作都不被需要了,即使出于理性我会做出和他一样的选择,但自己想想也会难受,所以总觉得过意不去。
想知道大家对这种情况怎么看,项目维护着、OP 或者另一个贡献者的角度都可以。
1
msg7086 232 天前 1
It is what it is.
被 NTR 不也是开源经历的一种吗。开源也不是就都一路顺风的。你行你上,我跟着做小弟就行了。归根结底目标是把功能实现出来,而不是自我表现。 |
2
leonshaw 232 天前
正常,可以看情况 commit message 加个 Co-Authored-By
|
3
CapNemo 232 天前
遇到过
从维护者角度,选择较好的一个或者综合双方实现搞一个更优的版本都可以 从贡献者角度,还是希望自己的贡献得到承认,被标记为作者或协作者。但如果确实自己的 PR 质量不如对方而被淘汰那也没啥可说的。 |
4
ivvei 232 天前
质量优先,正事不要讲感情。
|
5
Vetalice OP |
6
majula 232 天前 5
我有过类似的经历
一个常用的软件里缺少一个我想要的功能,到 GitHub 一看,发现 6 年前就有人提了 feature request 然后 4 年前有人尝试实现,提了个草案 PR ,但是实现得非常潦草,远达不到可用的程度 虽然看上去原 PR 作者没有下太大工夫,这几年间也没有持续完善 PR ,但我还是在下面询问: 你是否还在进行这项工作?如果不是的话,能否由我接手? 等对方表示他不再继续做这件事,并关闭了 PR 后,我才开始着手进行开发。 虽然我不是基于原 PR 作者的代码开发,而是完全重新实现, 但在最终的 PR 中,还是引用了原 PR 的链接,并对其工作表示肯定。 ---- 个人的看法是: * 事先沟通,避免重复工作浪费双方时间 * 尊重对方劳动成果,哪怕(在你看来)实现得远不如你 * 优先考虑项目的未来,而不是个人感情 |
7
Vetalice OP @majula 感谢分享,理想中确实是这样做最好。我这个问题有点麻烦的是工作上我们确实很快就要用,等不及他慢慢完成,而且我们提交 PR 前后脚不超过半天,我知道对方在做这个还是我问这个 feature 的上游依赖作者的时候他告诉我的,而且当时我们已经完成得差不多了。发现他的 PR 后也给他发过邮件,当时的想法是他可以保留我们共通的部分,然后把这边已经额外做好的合进去。只是那个资深贡献者也是只花了半天就 review 了并且在他那边刚上班就留下了建议。
你提醒了我至少可以在 Acknowledgment 感谢一下,即使不管他做的工作,他也提示过我上游在未来有个比较重要且影响到这个功能的优化要注意。 |
8
Vetalice OP 发现那个小伙已经很积极地在我的 PR 下帮忙 review 了,可能是我太多心了
|
9
msg7086 231 天前
参与开源不是只有提 PR 一种途径。如你所说,与其他 contributer 交流,帮忙做 peer review ,这些都是开源软件开发的一部分。只要对方不是特别心胸狭隘,一般是不会介意的。
|
10
flyingghost 231 天前
该讲逻辑的场合不要讲感情,例如技术和项目。
该讲感情的时候不要讲逻辑,例如哄老婆生气。 |
11
poltao 231 天前
好善良的 op, 如果我是实习生我会很高兴遇到 op 这样的人
|
12
abersheeran 231 天前
别人有更好的 PR 我一般不会提交重复的。虽然我造的轮子多,但都是别人满足不了我的需求或者我觉得别人写的太烂才写的。但凡有一个凑合能用的,我都不会自己写。
|
13
chenshiforever 229 天前
哎,这不正好我可以少些一堆代码了~
|