如果你有兴趣阅读本章，那么你一定希望对peony这个项目贡献自己的一份力量，我非常高兴，也非常欢迎你的加入。
但是，一码归一码，为了保证项目的健壮性与发展性，我希望大家能够牢记并且遵守本章所写的东西。
peony基于git进行代码管理，我个人使用qmake+qtcreator作为默认集成开发环境，虽然我不会强制要求大家和我使用一样的开发环境，但是在修改/贡献代码时，我也不希望因为各种原因而导致的对项目不利的因素出现。我列出如下几点要求与建议，如果我在进行review时发现贡献的代码不符合以下几点，我可能会要求你进行修改或者直接打回。
我不会说使用最新的qt和glib进行开发，但是我希望你能够基于当前Debian和Ubuntu最新版本来build这个项目。目前的qt版本是5.12，glib版本是2.62。
即使你具有直接上传的权限（不一定是我赋予的），我也不希望你直接向master分支进行push/merge操作。如果要向peony贡献代码，你应该fork到自己的仓库进行修改，在请求合并时，你需要通过pull或其它方法同步上游最新的代码，并且整合你的修改。针对特定的问题，可以创建一个新分支进行描述然后请求合并。
你需要保证你写的代码没有内部的、直接的内存泄露问题，我推荐你使用valgrind进行内存分析，为此你需要安装valgrind。在qtcreator的debug模式下，可以通过图形化界面的操作进行内存分析，十分方便，这也是为什么我推荐你使用qtcreator的原因。
当然，如果你没有检测出其它的问题那就完美了，另外，如果你解决了我没有解决的问题，我也十分欢迎你提交补丁。
我使用qtcreator默认的代码美化工具进行代码格式调整，所以你在换行时需要使用四个空格。
如果你需要创建一个class，那么你最好将他放在Peony这一命名空间中，我希望class的成员和方法的命名能够对应他们的功能或者意义，以便于进行review。对于这个类的私有成员，需要以“m_”开头，比如int m_count；类中的方法则需要以小写字母开头，中间使用大写代替分隔符，比如int getCount()（不写成int get_count()）。
代码的注释建议你使用/*! ... */，对你的方法、变量或者class等进行说明，关于注释变量的前缀我建议你使用\（反斜杠），而不是@，比如\brief xxx, this is xxx。我希望你使用英文注释，这样代码永远不会乱码，也方便与上游社区接轨。
如果是issue，你需要给出详细的描述，比如复现的步骤；如果是严重的崩溃问题，我希望你能够提供gdb运行相关用例时，进程崩溃时的堆栈信息，如果你之前没有接触过这些，能需要你去网上仔细查找相关的资料。
如果是wishlist，我希望你能够明确具体的功能需求，而不是好不好看之类的问题。如果你的建议十分有意义，我会积极的将它整合进我的项目中。
peony延续了旧版peony的一些设计理念，并且包含了旧版peony没有的一些更加先进的理念和思想，我认为在设计上它是更加合理的。首先是它还是延续了旧版peony的可扩展性（菜单插件等扩展），第二是对一些旧版peony不合理框架的重新设计，让它们更加先进（比如搜索框架、视图与数据框架）。
在你向peony增加一个新的功能时，你需要考虑你的代码是否符合peony的设计理念和框架，比如如果你想在右键菜单中增加一个选项，你需要优先考虑使用菜单扩展的形式，而不是直接在菜单中增加代码。
为了更好的向peony做出有意义的贡献，我希望你能够了解peony的实现思路，除了一些通用的编程的通用概念，比如接口，工厂模式等等，你还需要对glib/gio和qt足够的熟悉，并且对它们的一些高级特性，比如插件、接口相关的知识有一定的了解。如果可以，我也希望你能够熟悉qt的model/view编程以及qt的style、painter和delegate等绘制框架的概念和知识，这些是在实现peony-qt时不可或缺的基础。
多人开发可能会引入一些意想不到的问题，我可能在review时没有发现这些隐藏的很深问题，如果合并之后他们出现了，我可能会比较头疼，所以我希望你能够对你修改的代码进行大量的测试，以确保它的正确性。
如果你是新的贡献者，我极力推荐你从解决简单的问题，或者通过我提供的测试用例开始。我可能对你不够了解，对于你提交的代码会抱有一定的怀疑，越是复杂的代码，我在review的时候可能越会谨慎处理。如果我们不能直接面对面的交流，我们的信任关系最好一步一步慢慢构筑起来，这不仅可以从代码层面，也可以从提交问题、协助翻译等贡献层面展开。我的项目其实只是代表了我的思路，目前还只是一个雏形，我希望这个雏形能够引起你的共鸣，吸引更多开发者参与到这个项目的开发中去。