由OpenHarmony 文档上的PR三天未处理引发的思考

由OpenHarmony 文档上的PR三天未处理引发的思考

• • 一、前言
  • 二、一些常见的问题
  • • 1.系统判错
    • 2.文字内容
  • 三、一些失败的案例
  • 四、带给我们的思考
  • 五、总结

一、前言

前段时间我不是教大家完成一个 OpenHarmony 代码的贡献流程，结果我自个的PR已经三天了还没处理到，这不得不引发我的思考，到底是啥原因导致的呢（事实上确实就是一个很随便的PR），所以这次带大家重新学习一下，文档需要的真正规范(显式的文档规范)和PR的常见问题，OpenHarmony审核人员对这个文档的审核很仔细，甚至仔细到一个标点符号，在此为工作人员点赞，正文即将开始~~

二、一些常见的问题

1.系统判错

这部分很多时候就是自身的问题了，比如dco没有签署协议，这个按照提示处理一下即可

还有就是可能忘记编译了，即需要评论里面输入start build，由于我们贡献的是文档，所以一般情况下是不会有编译等问题，如果没有编译，成功，可能你的PR就会很久都得不到解决，像下面这位老哥，忘记编译了，结果两个月了还在这里

格式化和静态检查一般的错误类似，英文文档出现中文中文就会出现格式化检查失败

2.文字内容

• 标点符号

  这里常见的错误就是中英文的标点符号，类似

  ,和，""和“”''和‘’.和。()和（）

  这里的话，如果在英文中出现中文的标点符号的话相当明显

• 简称与全称

  在首次出现的时候最好两个都要,其中一个不在下文出现的用括号括起来例如

  TCP(Transmission Control Protocol)

• 样式统一

  首先全局的大小写命名统一，不能出现不一致的情况，其次就是某些专有名词必须遵循特定的大小写规则，类似OpenHarmony必须两个首字母都进行大写。

三、一些失败的案例

• 大小写没补充完整

  

• 图片命名不规范

  

• 中英文混合

  

• dco未签署

  

• 缩进问题

  我们的工作人员好细心

  

• 前后注释不一致

  //这种块注释类似java 中的api说明，//行注释是比较一般的注释

  

四、带给我们的思考

开源的项目正因为有这些工作人员和开发者的贡献才会越来越好，同时，在贡献文档的同时也会有各方面的讨论，一个个思维的碰撞，最初看到这些未合并下的对话，真的有被震撼到，我原本以为审核是很松的，毕竟这么大一个项目，需要投入很多的精力，不太可能如此认真的检查，长见识了，虽然有时候我们也有点气，他为什么不一次性都讲完全部的问题，现在其实已经释然了，只有更加优质的作品才能得到肯定，每一次提交都是一次次进步，这里我甚至看到提交好几个月的，最后还没合并的，respect

五、总结

现在想想我的那个PR确实不太行，就改了几句话，可能也没那么重要，不过还是有点遗憾，毕竟看了一周，PR在不断的下降，我的PR还是没有合并，释怀了，再过几天就去关一下。精益求精，相信OpenHarmony这样开源的项目会越来越好的。

医疗百科