对上游提 pr，上游的管理员觉得 pr 里面的功能他不需要或者不满意

[albert0yyyy]

新手刚刚学会提 pr ，有点小打击。

我应该维护自己的 fork 分支吗？

但是我后面又不是经常维护，还想享受上游的更新咋整

[Jinnrry]

自己维护，定时 merge 上游不就行了

[NessajCN]

fork 可以同步上游更新

[anivie]

你提 pr 之前没先跟对方商量吗……

[lesismal]

很正常，没必要心理这么脆弱，有其他的可以继续 pr ，平常心，凭借兴趣、爱好、良好的愿景去做这些，顺其自然就好了

[albert0yyyy]

@anivie 我需要发邮件问问管理员是吗，比如我想做这个功能，问问他们上游需不需要，然后他们的想法还有我的想法

[albert0yyyy]

@Jinnrry
@NessajCN

如果和我写的代码冲突，然后我自己解决冲突就可以是嘛

[albert0yyyy]

@lesismal QAQ 确实

[flyqie]

你可以定时合并 pr

我就单独维护了一个 facebook/idb 分支

[3085570450tt]

@albert0yyyy #5 无需发邮件，开 issue 讨论即可。加油

[guanzhangzhang]

git remote add upstream https://github.com/xxx/xxx
git fetch upstream main
git rebase upstream/main

[superchijinpeng]

@guanzhangzhang 直接用 gh

[sworld233]

正常来说应该先开个 issue ，和仓库 maintainer 讨论确定之后，再开分支提 PR ，最终审查通过了合并。如果 maintainer 不愿意接受的话就只能自己 fork 然后更新了

[bronyakaka]

看下人家项目里的 CONTRIBUTING.md 贡献规则，很多要求先 open 个 issue ，否则会被直接关闭。
我有个项目也是，突然来个 pr 跟我说集成了 ai 功能，不想合并直接掘拒绝又有点残忍，搞得很尴尬

[ericguo]

上游有权利拒绝，很正常，这个功能你真的需要自己维护就好。加新功能一定要先开 issue 讨论，不过即使开了 issue ，讨论了，上游仍然有权利拒绝，而且从我的历史提 PR 经验来看，越是资深开发者，越是行使这个权利没有心里负担，所以 OP 接受就好了。掌控权永远在上游。

[irrigate2554]

fork 出来自己定时同步就好了，你看看我仓库几十个 fork 的项目都是这样的

[orzorzorzorz]

看你目的了。
如果是觉得“这功能很屌我踏马就想放在这项目里”，那你得做一整套的说服动作。从需求分析到代码打包独立拆分，从独自扛起大旗到“哎可以给需要的人加个开关的”的小绿茶，就看你能不能吃得下这套代价了。
如果是练个手，那可以把 pr 链接丢出来挂 v2 上，起个标题说“现在的开源项目真的高傲，我好心开个 pr 到最后直接被关了”，然后就能收获颗粒化到缩进的批评，对心态的磨炼是很有效果的。
当然可以不用这么激进，那句话怎么说来着，最痛苦的时候就是你成长最快的时候，加油。

[Pencillll]

要知道添加了新功能之后，你没有责任来进行后续维护，但管理员有责任，这是会增加负担的，所以对新功能持保守态度很正常

[uiosun]

@albert0yyyy #5 正常来说，PR 是基于 Issue 的，你可以从单词语义上理解这个流程。

所以，如果莫名其妙的就蹦出来一个 PR ，作为管理者，保持一种防御心态有助于软件的整洁，可以理解。

如果你觉得很需要，就提出自己的意见，如果你俩/或多个管理员无法形成共识，且项目对这个功能并没有明确禁止，就提 Issue 来征求更广泛的意见。

这是一个比较正常的流程，就算是最终被拒绝了，也无需难受，这在开源世界太正常了。

举点碰到的极端例子：PR 提了，功能大家都很需要，两位管理员也表示称赞，但提出一个小小的语法错误，你以为马上就能合并？结果是两年后才合并。

[mooyo]

先讨论再提 PR 比较好

[AstroProfundis]

很正常，这属于标准的应该自己 fork 一个的场景

[LitterGopher]

我和 #3 的是一样的，然后我在补充几点，关于为何要先提 issue:

1. 你提交的功能可能其他人已经实现了，只是你可能忽略了使用方法
2. 你提交的功能其他人正在实现，提前沟通可以避免有人做无用功
3. 你提交的功能可能不满足对方的‘产品’定位，比如一个生成二维码的库，你提交了一个验证二维码背后的连接是否为钓鱼网站的 PR ，你觉得对方会合并？
4. 提前沟通也有助于帮助其他人，可能其他人也有相通的想法，这时候他们只需要搜索 issue 就能知道是否已经有实现和其他帮助信息（同样也能帮助其他想要为此提交 PR 或有相似疑问的人）
5. 提前沟通可以一起商量一些实现方式，避免 kakakka 写完之后作者觉得你的实现不好而给你拒绝或让你反复修改

[ExplodingFKL]

是要求更改还是直接关闭了 ？贴出 pr 链接看看

[timewarp]

新建项目起名为 xxx-ng ，意思是新一代的 xxx ，自立门户开始干，实现一些超吊的功能

[julyclyde]

你这个 pr 对应的需求在哪儿呢？是你自己的改进/新功能？还是别人提的需求？
如果是你自己的，那恐怕只能你自己留着 fork 了

[mrbananaeros]

有时候作为 Maintainer 拒绝其实也有心理负担的，会不会不友好什么的，所以有时候会让挂着的 PR 继续开着，实际上这个其实也不是特别礼貌。

[chesha1]

你先说说是什么基础软件是什么，功能是什么，是否应该合并应该具体问题具体分析

我有过很多比较好的 PR 合并经历，但是也有那种 owner 离谱的，不合并我的 PR ，不给反馈也不关闭，同时照常合并其他的 PR ，我就很无语地放弃这个服务了，不一定是你的问题

[zaunist]

嗨，假如你有想法，你就发个 issue 问问社区开发者的意见，没人屌你的话你就艾特两个社区比较活跃的人来讨论，要是艾特了都没人理你，那就自己 fork 一份自己玩，别屌上游了，别人不会在意你的想法和意见，大概率是公司内部一言堂的开源项目，社区的声音是不听的。

[mrbananaeros]

@chesha1 我感觉很符合你这个描述，有时候 PR 太多了，我来不及看，只能看第一页，偶尔才有空去翻到后面几页的内容。