之前没有用过github给别人贡献过代码，最近用了 org-mode-incremental-reading 这个插件，然后自己动手给它加了许多功能。这个项目本来没有什么关注度，而且issue, PR, fork都是0。我这几天写的东西写了啥就马上全部PR上去了，现在这个项目的issue，PR都是我提的，会不会让别人感觉到冒犯？
大家对于那些热情的和自己想法不一样的贡献者是怎么想的呢？
UNIX 编程艺术有提及
热情不用太高，可能人家也就一个月上两次线，半年以后才注意到有人提了 PR。
谢谢，我之后去认真研读一下，不过好像这本书挺厚的吧
1 个赞
一个月上线两次可能真相了，他好像确实目前可能精力不在这一块，最近在做Python项目
如果作者实在没有精力又比较认可你的能力的话，你可以请求加入共同开发，或者经过允许后自己fork开发。形式还是很多的。
1 个赞
一般不建议直接 PR，除非是那种你确定可以直接合并，不会有其他问题的（比如修复注释中的拼写错误）。
正确流程是先在 issues 中讨论（有的 repo 开了 discussions，也可以在那里讨论，具体看社区规范），和项目维护者达成了一致，然后再根据讨论结果决定是否提 PR。
这样做，一方面是提高效率，避免因为信息没对齐，浪费双方时间。另一方面也是出于礼貌考虑。就好比你要拜访朋友，应该是提前约好时间、地点、内容，而不是突然敲对方家门，喊他出来玩。
7 个赞
不建议发超大PR，我有这种惨痛教训，以前给一个项目发了一个超大的pr，最后也不了了之了。因为超大pr，维护者review太痛苦。。。。
有想法可以先发个 issue 描述一下，看看原作者的意见和建议，并说明如果不介意“我”可以提供一个 PR，
然后再进入 PR 环节，有的作者不喜欢接收 PR,可能你就直接 fork 自己搞了
想那么多干啥，直接pr，不过最好别提交大pr。功能分清楚。
1 个赞
不算很厚,比起《法律之门》而言 
我的 meow 经常收到一些直接的 PR，虽然社区的热情很棒，但有些 PR 让人很头疼。
描述PR解决的问题，尽量让补丁只包含一个修复（不要一堆功能超大补丁，不好review），如果补丁有不完美的地方提前说一下，征求作者意见，不要写workaround补丁。
其他不要想多了，只要补丁质量高，干净，作者都愿意合并。
3 个赞
“嗟，此有 PR 一坨~~”
最近也是第一次参与了开源项目贡献，先提了issue，然后加了维护者的微信，沟通了下实现细节提交了PR，很有成就感