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

[albert0yyyy]

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

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

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

[LitterGopher]

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

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

[ExplodingDragon]

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

[timewarp]

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

[julyclyde]

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

[mrbananaeros]

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

[FlashEcho]

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

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

[zaunist]

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

[mrbananaeros]

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