V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Vetalice
V2EX  ›  程序员

做开源的时候遇见实现相同功能的不同 PR 大家会怎么办

  •  
  •   Vetalice · 2024-04-04 22:51:43 +08:00 · 2186 次点击
    这是一个创建于 376 天前的主题,其中的信息可能已经有所发展或是发生改变。

    工作业务需要在某个著名开源项目上实现了一个不大不小但是对本行业还挺重要的 feature ,于是走完审计流程把它推回给社区。但是提了 PR 之后发现就在半天前另一个人已经提了相同功能的 PR ,但是他的 PR 还是草案状态,而我们的已经基本可用了。

    现在的状态是一个资深贡献者(这个 feature 很大程度上是在他的贡献基础上完成的)同时看了两份 PR 认为我们完成度更高更合理所以建议另一个人集中到我们的 PR 上来,对方也表示同意。

    从工作的角度来说,由于我们后续会基于这个 feature 开展大量的工作(可以认为是一次对这个功能工程上的检验和认证)所以肯定希望我们来主导开发。

    但是站在个人角度,其实在刚启动审计流程的时候我和另一个贡献者就已经联系上了,也知道对方在做,看到了对方的进展,而且都表达了合作的意向。当时的打算是一走完流程公开仓库就可以拉对方过来一起搞,但是没想到流程走了三天,而对方很快就提了个草案 PR 。我看到他是个实习生,这个 feature 就是他的实习项目,所以对他来讲可能是一次重要的开源经历。突然得知之前的工作都不被需要了,即使出于理性我会做出和他一样的选择,但自己想想也会难受,所以总觉得过意不去。

    想知道大家对这种情况怎么看,项目维护着、OP 或者另一个贡献者的角度都可以。

    13 条回复    2024-04-07 12:37:45 +08:00
    msg7086
        1
    msg7086  
       2024-04-04 23:10:43 +08:00   ❤️ 1
    It is what it is.
    被 NTR 不也是开源经历的一种吗。开源也不是就都一路顺风的。你行你上,我跟着做小弟就行了。归根结底目标是把功能实现出来,而不是自我表现。
    leonshaw
        2
    leonshaw  
       2024-04-04 23:28:02 +08:00
    正常,可以看情况 commit message 加个 Co-Authored-By
    CapNemo
        3
    CapNemo  
       2024-04-04 23:56:06 +08:00
    遇到过
    从维护者角度,选择较好的一个或者综合双方实现搞一个更优的版本都可以
    从贡献者角度,还是希望自己的贡献得到承认,被标记为作者或协作者。但如果确实自己的 PR 质量不如对方而被淘汰那也没啥可说的。
    ivvei
        4
    ivvei  
       2024-04-05 00:10:34 +08:00
    质量优先,正事不要讲感情。
    Vetalice
        5
    Vetalice  
    OP
       2024-04-05 00:30:41 +08:00
    @msg7086 道理是这样,所以如果我是他我也会干脆放弃掉自己的 PR 。只是之前邮件往来对方非常热情地介绍了自己的工作,不想打击到他热情,毕竟从他 Github 的介绍看来他还挺珍惜这个第一份实习。

    @leonshaw 其实因为目前的实现还有些边角问题需要处理所以他也可以提一些 commit 。但是我不知道他是怎么想的,他的实习公司又会怎么安排所以不好自作多情。在别人建议他放弃之前我给他发过邮件提议合并我们的实现,我认为我们共同已经实现的一半差不多,另一半则是我这边更好。先等他回复吧,虽然不确定他还回不回……
    majula
        6
    majula  
       2024-04-05 00:59:07 +08:00   ❤️ 5
    我有过类似的经历

    一个常用的软件里缺少一个我想要的功能,到 GitHub 一看,发现 6 年前就有人提了 feature request
    然后 4 年前有人尝试实现,提了个草案 PR ,但是实现得非常潦草,远达不到可用的程度

    虽然看上去原 PR 作者没有下太大工夫,这几年间也没有持续完善 PR ,但我还是在下面询问:
    你是否还在进行这项工作?如果不是的话,能否由我接手?

    等对方表示他不再继续做这件事,并关闭了 PR 后,我才开始着手进行开发。
    虽然我不是基于原 PR 作者的代码开发,而是完全重新实现,
    但在最终的 PR 中,还是引用了原 PR 的链接,并对其工作表示肯定。

    ----

    个人的看法是:
    * 事先沟通,避免重复工作浪费双方时间
    * 尊重对方劳动成果,哪怕(在你看来)实现得远不如你
    * 优先考虑项目的未来,而不是个人感情
    Vetalice
        7
    Vetalice  
    OP
       2024-04-05 01:39:00 +08:00
    @majula 感谢分享,理想中确实是这样做最好。我这个问题有点麻烦的是工作上我们确实很快就要用,等不及他慢慢完成,而且我们提交 PR 前后脚不超过半天,我知道对方在做这个还是我问这个 feature 的上游依赖作者的时候他告诉我的,而且当时我们已经完成得差不多了。发现他的 PR 后也给他发过邮件,当时的想法是他可以保留我们共通的部分,然后把这边已经额外做好的合进去。只是那个资深贡献者也是只花了半天就 review 了并且在他那边刚上班就留下了建议。

    你提醒了我至少可以在 Acknowledgment 感谢一下,即使不管他做的工作,他也提示过我上游在未来有个比较重要且影响到这个功能的优化要注意。
    Vetalice
        8
    Vetalice  
    OP
       2024-04-05 01:44:07 +08:00
    发现那个小伙已经很积极地在我的 PR 下帮忙 review 了,可能是我太多心了
    msg7086
        9
    msg7086  
       2024-04-05 05:48:03 +08:00
    参与开源不是只有提 PR 一种途径。如你所说,与其他 contributer 交流,帮忙做 peer review ,这些都是开源软件开发的一部分。只要对方不是特别心胸狭隘,一般是不会介意的。
    flyingghost
        10
    flyingghost  
       2024-04-05 11:35:07 +08:00
    该讲逻辑的场合不要讲感情,例如技术和项目。
    该讲感情的时候不要讲逻辑,例如哄老婆生气。
    poltao
        11
    poltao  
       2024-04-05 16:42:04 +08:00
    好善良的 op, 如果我是实习生我会很高兴遇到 op 这样的人
    abersheeran
        12
    abersheeran  
       2024-04-06 00:06:32 +08:00
    别人有更好的 PR 我一般不会提交重复的。虽然我造的轮子多,但都是别人满足不了我的需求或者我觉得别人写的太烂才写的。但凡有一个凑合能用的,我都不会自己写。
    chenshiforever
        13
    chenshiforever  
       2024-04-07 12:37:45 +08:00
    哎,这不正好我可以少些一堆代码了~
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   956 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 20:31 · PVG 04:31 · LAX 13:31 · JFK 16:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.