这是一个创建于 963 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样的：
我在社区开了一个 RFC ，希望加入新的浮点类型 (#3451)，收到了一些回复。
结果发现其中一个回复的人自己又开了另一个 RFC #3453，其中的内容也是基于我的 RFC 改的，只提供了一个原 RFC 的链接，内文和描述都没有提到我的名字。理由是我的涵盖的内容太多了，准备抽出一个更容易被讨论通过的子集出来讨论。
一开始我没太当回事，以为只是专门拿出来讨论其中的一个部分。结果后来有好几个人跑到我开始的 PR 下面问我，让我把我的 RFC 内容改成 #3453 没包括的剩下的部分。
这下就有点不舒服了，我的东西被拿到另一个地方引发那么多讨论、点赞，然后和我一点关系都没有了？也许是我过于敏感，也许 RFC Proposal 的价值和货真价实的 Patch 不能比（但这个功能本来也打算后面自己来实现），但开源社区不应该是这样的吧？
不知道有没有熟悉 Rust 社区的朋友们来说说，这是否是社区 RFC 流程的某种「惯例」。
 | 1 my3157 2023 年 7 月 10 日 via Android  1 很正常吧，最小化便于跟踪，后面改 stable 也方便 |
 | 2 zk8802 2023 年 7 月 10 日 via iPhone 4 感觉不舒服的话就不用改或者不要回复。一个变通的方法是保留原来的 RFC ，然后创建一个新的 RFC 来描述“剩下的部分”。 开源社区里谁都不欠谁的，不开心的话不做就好了。 |
 | 3 simen513 2023 年 7 月 11 日 偷别人劳动成果的人太多了，就算是公司的同事都有这样的，更何况是公开的社区呢。 没有办法，偶尔碰到一小撮这样的人，就会一颗老鼠屎毁掉一锅粥。 |
 | 4 xinyu391 2023 年 8 月 29 日 KPI ？ |
 | 5 tison 2023 年 9 月 2 日 3 这个事情主要是两方面的问题： 1. #3453 的作者没有想到提前跟你沟通，用合作的方式来承接一些工作而不是直接引用 2. 恰好没有 Maintainers 知道这两个 issue 的上下文，充当中间人给到双方对应的 credit 相对的有两个我参与开源社群的经验： 第一个是自己提出的想法甚至连 patch 都弄好了，结果被后面的人无论是直接复刻还是其他人独立解决了同一个问题，Maintainers 合并了后来人的方案。这个事情经常发生，尤其经常出现在企业开源内部员工的后续 PR 比“外部”开发者得到更多关注上。 典型案例可以参考 - https://xuanwo.io/reports/2023-24/ 第二个是开源社群根本上是关于人的社群。以我在多个社群参与的经历来看，找到一个引路人（ TA 同时是社群的 Maintainer / Committer ）带着你做事情，他在社群当中有更高的声誉和人际关系，能把你的工作跟其他 Maintainer 的注意力较好的协同起来，是参与开源社群的一个好实践。如果你自己发起过项目，且能吸引到其他人参与贡献，在协同其他开发者的贡献的时候应该就能理解到这种注意力策略的原因和运行方式。 我写过一篇文章可以作为这个问题的参考： * 高效参与开源的诀窍 https://mp.weixin.qq.com/s/9aERt1faSxyD_WBpdnI8iw |
Select Language