虽然已经使用GitHub很长时间了，但是几乎没有给别的开源项目提过issue和pr，终于鼓起勇气在4月8号提了第一次issue以及pr，在4月22日，issue和pr都关闭了，在此记录一下。

发现问题

起因是我在使用开源库某个函数时，发现输出结果不对，函数好像没有将输入的参数maker传递下去，画出来的图也不对，在排除个人因素之后，我去查看了源代码，很显然，作者把这个参数漏写了。作者也是会犯错的。

提交 Issue

很快啊，我去GitHub的库里面确认了一下，最新的库里面问题还存在，于是我开始写issue，友好的开头，交代一下问题，附上所使用各种库的版本信息，附上了一个简单的复现例子，由于问题很简单，修改的也很少，我还想尝试一下自己提交一个pr，于是我还写了我想交pr的意愿和我是第一次交很可能犯错，有点小虚荣，没啥不好的。给gpt翻译成英文，以及改得尽量礼貌一点。

提交 PR

流程是先 fork 项目到自己的账户，再 clone 到本地进行修改。我只改了一行代码，把漏掉的参数补上了，然后 push 到自己的 fork，再提交 PR 到原项目。

听着很简单很顺利，但是我还是翻车了。

总的来说还是没好好看协助文档，脑子一热，直接克隆了master分支，但是实际上项目修改都在dev分支中进行，于是就可以看见我的pr，除了我的一项修改，还有二十多个修改是GitHub机器人改得，但是我也不知道咋修改，就待在那了。

最终结果

作者在当天就回复了我的issue，肯定了我的想法，并表示会看看pr。但是显然我还没搞定怎么修改，于是没有管，在4月22日，我发现pr消失了（？，也不能这么说，只是主页看不见了，应该是属于被打回），意料之中，我看了看最新的dev分支，bug已经修复，于是我对我的垃圾pr道歉，关闭了它，issue被解决，我也关闭了。

意外的是，作者之后又在pr中回复我，感谢我的贡献。也挺好的，即使操作不是很完美，还是被认可和鼓励了。

小结

1. 认真看文档，冷静之后再动手。尤其是分支。
2. 大家人都挺好的，自信勇敢一点。