建议增加贡献者指南

[bianjp]

刚刚提了个 PR，增加了 EPEL 和 MariaDB 的帮助文档。由于没接触过 Sphinx 和 reStructureText ，很是费了一番功夫。

希望提供一份贡献者指南，以帮助初学者快速入门，并保证文档风格的统一。

建议包含以下内容：

• 如何在本地预览文档（环境要求，安装依赖）
• 如何添加一个新文档（文件位置、名称，添加后要相应修改哪些地方）
• 帮助文档的结构（需包含那些部分）
• 统一风格，比如
  • 各级标题分别使用哪种标识符（= - ` : ' " ~ ^ _ * + # < >），长度多少（目前很多 "WARNING: Title underline too short"）
  • Code block 的标识符（::）是单独写在一行，还是写在前一句的末尾？偏爱前者，以免在中文中混入英文冒号
  • 支持多个发行版、同一发行版的多个版本的源，“使用说明”一节是列出所有组合下的配置文件内容，还是提供命令修改默认的配置文件（比如我提的 PR 中对 EPEL 的处理），亦或说明一下原理，让用户自己手动处理？
  • “相关链接”一节使用 Field List，还是无序列表并且使用 Embedded URL 形式不直接显示链接地址。偏爱后者，以免标题、链接过长时分行显示，不美观

[knight42]

@zhsj 我对 reST 不太熟悉...

[bobby285271]

对，强烈建议加一个...

[bubbleatgit]

我想知道怎么贡献，又不能提交

[hosiet]

诶，我本来以为修改内容是很简单的吧？

RST 的语法在编写时必须熟悉，就和 markdown 语法必须熟悉一样，这个绕不开。

各级标题的符号？你熟悉 RST 语法的话就明白这个就不是问题了，只要渲染无误即可。遇见语法警告请顺手帮我们修复。统一这个我还真没想过，也许我在这里说一下 # >> = >> - >> ^ >> ~ 就行？

语法偏好的问题，随意就好？内容的话我个人觉得只要说得清就行。

有各种本地预览 .rst 文档的工具和编辑器，最方便的应该是retext。即使本地没法预览，直接在 GitHub 上编辑也可以，GitHub 原生支持 rst 语法的，只要你文件后缀名正确即可。

提交请使用 GitHub 标准的分支/合并请求（fork + pull request）的方式。当然如果把 git 提交的 diff 信息发来也不是不行，只是会多此一举。