大家好，我是 aspoem.com 现代化诗词学习网站 的维护者，目前用此方法一周的时间首次收到了 3 个 pr。有 2 个比较具有代表性的问题：
对吧，都很简单，第二个即使不用 clone 源码也可以提交 pr。
当然此方法不是我的原创，是在看了很多优秀的开源项目之后，进行了一些总结，他们都比较喜欢将简单的问题作为 good first issues，甚至还会很细致的列出如何实现的步骤，有兴趣的开发者只需要按照步骤就能够轻松的解决掉问题。
为什么会这样呢？参与者将得到什么？
成就感
对自己喜欢的项目，提交了 issues 并且被 pr ，是一件非常有成就感的事情。特别是对于首次提交 pr 的开源爱好者，感觉更加强烈。我自己也是如此，第一次提交 pr 的时候，基本是每隔1个小时都会打开 github 刷新看一下，合并的那一刻的感觉还是非常 nice 的。
简单
大部分的开源爱好者，没有提交 pr 的经历，都会有一种心态，开源项目的代码有点复杂，需要花费大量的时间去阅读源码。如果再加上一个复杂 issues 的 debuff ，可想提交 pr 的概率有多大。一个简单的 issues 正好弥补了这一个空白，算得上是一个增益 buff。
那么想象一下：当前端看见一个 issues 的标题是将字体加粗、边距调大这样的需求的时候，会不会有捡漏的感觉呢？
直接打开浏览器 F12 找到对应的 dom 样式一改，然后 clone 代码 > 运行 > 全局搜索关键词 > font-weight / padding 一加 > 提交 pr。 so easy.
对于开源项目有什么好处？
无论这个 pr 有多么的简单，那么参与者至少 clone 你的代码，启动起来了。还全局搜索了修改了部分代码，对你的项目也是有一个大致的了解。
另外大家有没有发现，任何代码从局部来看，其实都很简单，仔细一看甚至会产生 这 TM 代码写的真烂，还不如我写的好。 有了这样的想法之后，参与者的信心就更足了，减少了上面说的 开源项目很复杂的看法。
那么，下一次通过 issues 提交 PR 的机会也会大大提升，从而达到了解整个开源项目。
并且，这样的了解还是带着问题去的，比单纯的直接看会更加容易让人接受，也不容易让人产生疲劳，从而放弃。
维护者应该如何做呢？
一个非常简单的贡献指南和本地部署指南，即使是首次想要贡献的爱好者也能按照你的步骤提交 pr。像这样
哈哈，又打广告了。
要经常去优化你的文档，比如我这个，目前的 sample 数据就还不是很简单，还需要修改 3 个文件，但是很清晰，一定程度上，只要按照流程一定能成功。
特意留一些无关痛痒的问题，作为 good first issuts
很多时候，因为是自己作为主要运营人员面对比较简单的问题，顺手就改了。这个时候可以把他留下来，作为 good first issues，如果可能的话，可以把如何解决这个问题的步骤写下来。
最后
我也是首次使用这个方式，后续也会向着这个思路继续运营我的开源项目。如果有新的发现再来更新，希望对你有帮助。
介绍一下我的开源项目 aspoem.com - 一个现代化的诗词学习网站，更加注重 UI、用户体验，欢迎大家体验。
