一、前言
前段时间我不是教大家完成一个 OpenHarmony 代码的贡献流程，结果我自个的PR已经三天了还没处理到，这不得不引发我的思考，到底是啥原因导致的呢（事实上确实就是一个很随便的PR），所以这次带大家重新学习一下，文档需要的真正规范(显式的文档规范)和PR的常见问题，OpenHarmony审核人员对这个文档的审核很仔细，甚至仔细到一个标点符号，在此为工作人员点赞，正文即将开始~~
二、一些常见的问题
1.系统判错
这部分很多时候就是自身的问题了，比如dco没有签署协议，这个按照提示处理一下即可
还有就是可能忘记编译了，即需要评论里面输入start build，由于我们贡献的是文档，所以一般情况下是不会有编译等问题，如果没有编译，成功，可能你的PR就会很久都得不到解决，像下面这位老哥，忘记编译了，结果两个月了还在这里
格式化和静态检查一般的错误类似，英文文档出现中文中文就会出现格式化检查失败
2.文字内容
标点符号
这里常见的错误就是中英文的标点符号，类似
,和， ""和“” ''和‘’ .和。 ()和（）这里的话，如果在英文中出现中文的标点符号的话相当明显
- 简称与全称
在首次出现的时候最好两个都要,其中一个不在下文出现的用括号括起来例如
TCP(Transmission Control Protocol)
- 样式统一
首先全局的大小写命名统一，不能出现不一致的情况，其次就是某些专有名词必须遵循特定的大小写规则，类似OpenHarmony必须两个首字母都进行大写。
三、一些失败的案例
- 大小写没补充完整
- 图片命名不规范
- 中英文混合
- dco未签署
- 缩进问题
我们的工作人员好细心
- 前后注释不一致
/**/这种块注释类似java 中的api说明，//行注释是比较一般的注释
四、带给我们的思考
开源的项目正因为有这些工作人员和开发者的贡献才会越来越好，同时，在贡献文档的同时也会有各方面的讨论，一个个思维的碰撞，最初看到这些未合并下的对话，真的有被震撼到，我原本以为审核是很松的，毕竟这么大一个项目，需要投入很多的精力，不太可能如此认真的检查，长见识了，虽然有时候我们也有点气，他为什么不一次性都讲完全部的问题，现在其实已经释然了，只有更加优质的作品才能得到肯定，每一次提交都是一次次进步，这里我甚至看到提交好几个月的，最后还没合并的，respect
五、总结
现在想想我的那个PR确实不太行，就改了几句话，可能也没那么重要，不过还是有点遗憾，毕竟看了一周，PR在不断的下降，我的PR还是没有合并，释怀了，再过几天就去关一下。精益求精，相信OpenHarmony这样开源的项目会越来越好的。
