跳过正文
  1. Posts/

开源维护者最讨厌的一句话"Any updates?",你说过吗?

·1090 字·3 分钟· ·
沈显鹏
作者
沈显鹏
DevOps & Build 工程师 | Python 爱好者 | 开源贡献者
目录

今天在逛 Pydantic 的 GitHub 仓库时,我看到一个熟悉的评论和一个链接:

Any updates on this?

https://justinmayer.com/posts/any-updates/

Any updates?


顺着这个链接,我第一次读到了 Justin Mayer 写的这篇文章:《“Any updates?”》

下面我就来分享一下这篇文章的主要内容和我的看法。


在开源世界里,这样的场景你一定熟悉:

有人在项目仓库里发现了一个问题(issue),看到最后一条评论已经是几周前的,于是便在下面留言:

“有什么最新进展吗?”

“Any updates?”

看似无害的一句话,其实往往会带来不小的麻烦。

为什么不该这么问
#

如果一个问题有了更新,它一定会出现在对应的 issue 中,所有人都能第一时间看到。

开源项目不像公司内部那样会有“私下会议”“内部冲刺”或“隐藏计划”,所有的开发进展都公开、透明。

所以,当有人留言“有什么更新吗?”,并不会带来任何新信息, 却会让所有订阅这个 issue 的人都收到一条无意义的通知。

要知道,其中很多人是无偿贡献者或维护者。他们投入自己的业余时间来改进项目,而这样的“提醒”通知,只会让他们感到烦躁甚至挫败。

那该怎么办?
#

其实,想知道项目的进展是可以理解的。但与其发一条“有更新吗?”,不如做点更有价值的事。

  1. 资助项目

    维护者的时间是有限的。如果项目能获得资金支持,他们更有动力、也有条件去持续改进。 哪怕是一笔小额捐助,都比一句“有更新吗?”更有帮助。

  2. 贡献时间

    如果你暂时不打算捐款,也可以想想自己能否贡献一点时间。 比如可以这样留言:

    “非常感谢所有为这个项目做出贡献的人! 我能帮忙做点什么,让这个问题更快推进吗?”

    这类留言既友善,又能传递出积极的合作意愿。

  3. 什么也不做(真的)

    如果你暂时没办法捐助,也无法参与贡献, 那么最友善的选择,其实是——什么也不做

    静静等待项目的更新,让维护者按照自己的节奏前进。

附:别用留言订阅通知
#

有些人会在评论里发“有更新吗?”只是为了订阅后续消息。

千万别这样。

只要点击 GitHub 页面右侧的 “Subscribe(订阅)” 按钮,就能收到所有更新通知,不必额外留言。

保持友善
#

“有什么更新吗?”这句话背后的含义其实是:

“我希望这件事能尽快完成,但目前看来还没有人去做。”

这会无形中给维护者带来压力。 而开源项目最需要的,不是催促,而是理解与支持。

所以,请做一个友善的开源公民:

有能力,就出一份力; 没时间,就多一点耐心。

💫 世界因为你的善意与尊重,会变得更美好。

我的看法
#

确实,这种“Any updates?”的留言,看着就让人很烦躁,属于是白嫖式的“催更”。

下次如果还有人发“Any updates?” 或 “有什么更新吗?”,你就直接把这篇文章的链接发给他,让他自己去看吧!


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

相关文章

白嫖了这么多年,开源基础设施要开始收费了?
·923 字·2 分钟
开源基础设施并非免费,自来水般的 pip/npm 安装背后是高昂的带宽、存储和运维成本。声明呼吁开发者与企业共同分担,优化工具、支持赞助,才能让我们习以为常的“免费”体验真正可持续。
做开源四年,我得到了 3 个意想不到的收获
有人说开源没用,既赚不到钱,又浪费时间。但我在四年的坚持中,发现了 3 个意想不到的收获:让工作被真正看到、接触更优秀的人和项目、以及一份长期的价值积累。这些收获,其实每个开发者都能借鉴。
2023 年开源状况和人工智能的崛起(GitHub)
·7338 字·15 分钟
本文介绍了 GitHub 发布的 2023 年开源状况和人工智能的崛起报告,分析了开发者社区的增长、生成式 AI 的应用以及云原生技术的发展趋势。
被 Airflow Maintainer 一顿夸:Rust 重写版 pre-commit 项目 prek 的崛起
·1242 字·3 分钟
昨天在网上冲浪,突然看到了一个仓库叫 prek,一看介绍是 —— ⚡ Better pre-commit, re-engineered in Rust。这就引起了我的兴趣,毕竟 pre-commit 作为非常广泛的预提交的工具,如果能改进,尤其是性能方面的改进,肯定是好事。
Commit Check v2.0.0 重磅发布:支持 TOML 配置、简化 CLI & Hooks、重构验证引擎!
·1010 字·3 分钟
经过了断断续续一个月的开发和测试,我终于完成了这次重大更新。这也是 Commit Check 迎来了自诞生以来最大的一次更新。
Jenkins Explain Error 插件现已支持 Ollama!🤖
·713 字·2 分钟
本文介绍了 Jenkins Explain Error Plugin 的新功能,即支持 Ollama 本地模型,帮助用户更高效地分析和解决构建错误。