战码先锋，第二期PR征集令（以下简称“战码先锋”）火热进行中，涉及OpenAtomOpenHarmony（以下简称“OpenHarmony”）骨干库、SIG库、三方库，共1000+代码库开放挑战。刚刚看到活动的小伙伴们一定会有一个疑问：什么样的商业背景可以参加战码先锋活动？是否有可能找到一些提高PR的基本方法？为此，我们请来了《战法先锋》一期贡献者、二期舰长之一的河王，为我们带来了他的一些行之有效的经验。以下是他的分享。事实证明，来自不同背景的人可以帮助充分识别问题。如果你是一名翻译，虽然你的技术功底可能不深，但你可以利用你的专业能力帮助人们发现项目中的语言问题。同理，有测试、数据、法律背景的同事也是如此。不同专长的人的加入更有利于充分发现各类问题。这类似于敏捷开发的全功能团队。参与作用更全面，发现问题更充分。无论英雄出身，只要敢于挑战，都可以参与代码先锋之战，为开源项目贡献力量。本文以技术译者的视角，从开发者体验的角度探讨代码文件中常见的数据问题，并在此基础上分享一些个人建议。文章主要分为三个部分：数据内容对开发者生态的意义；影响数据体验的典型问题；以及一些提升数据体验的建议。首先需要简单了解一下数据内容对开发者生态的意义。根据近年来开发者生态的现状和开源生态报告来看，内容的完善和准确是开发者选择生态的重要因素之一。根据埃森哲的调查报告，开发者认为技术上准确和最新的内容是开发者生态系统中最重要的两个要素。来源：ENGAGINGTHEDEVELOPERCOMMUNITY-WhatDeveloperEcosystemsNeedtoKnow，AccentureOSCHINA和Gitee联合发布的《2021中国开源开发者报告》进一步支持了这一点。从报告中可以看出，相关文件/资料是否丰富仅次于源代码质量。--摘自《2021中国开源开发者报告》好消息胜过千军万马，消息的重要性不言而喻。好马配好鞍，好代码需要好材料，才能产生1+1大于2的效果，帮助开发者更好的上手，产生好的开发者体验，吸引更多的人开发商参与。一个复杂的技术产品，如果没有使用说明书，用户将无法高效、正确地使用产品。代码就像一个复杂的产品。如果没有完整的信息，开发者将无法理解源代码的功能和实现机制，这将极大地影响他们的体验。对于OpenHarmony开源项目，正文内容主要包括两部分：一是Docs仓库发布的文档，包括但不限于开发指南、API参考等；二是代码仓库包含的各种描述信息，比如readme、代码注释、log日志、API说明等。那么，影响开发者体验资料内容质量的因素有哪些呢？根据开发者生态相关报告，这些要素包括但不限于：准确性（accuracy）、完整性（integrity）、流通性（recentness）、可查找性（retrieval）和可读性（readability）。需要说明的是，以往的报告大多以主流开源项目为基础研究对象。这些项目主要由欧美顶级玩家主导，在语言和文化方面具有天然优势，具有良好的国际化和本地化成熟度。因此，国际化、本地化、语言基础质量等方面也需要OpenHarmony开源项目重点关注。接下来，我们将重点关注《战典先锋》活动中英文文本内容的典型问题？本次主要以非Docs仓库的文本题为例。特别声明：以下举例仅作技术交流说明之用，不构成任何明示或默示的陈述或声明。同时，由于相关仓库内容不断变化更新，如有出入，请以实际为准。1.准确清楚例1：词不达意。这里的API是DelUser，其功能是删除用户，所以描述应该是Deleteauser，而不是用户认证。例2：意思错误。PIN_MIXED为MixedPIN认证，FACE_2D为二维人脸识别认证。例3：意思相反。这里是inactive状态的回调，叠加语法错误，增加理解难度。实际的意思应该是：当一个能力失效时在主线程中调用的回调。二、内容完整根据开源的要求，开源代码仓库中的评论内容必须是英文的。由于英文表达能力有限或内部合规性考虑，开发者可能会倾向于删除或放弃提供一些需要英文文化的必要内容，例如文档的简要说明、实现机制或注意事项，如下例所示：sideenum缺少必要的注释，开发者无法理解短周期、正常周期和长周期的区别。3.合理组织信息的组织应符合用户的逻辑认知顺序。例如，API介绍应遵循“API功能描述+权限+参数描述+返回描述”的信息组织结构。在下面的例子中，API名称直接被API函数描述代替，真正的API函数描述出现在权限之后。参考修订如下：四、一致性一致性主要体现在两个方面：风格的一致性和内容的一致性。示例1：表达风格不一致。以下日志描述中，上下行大小写风格不一致：例2：内容与实际不符。以下Readme中，目录结构中的代码仓库名称与实际代码仓库名称不符：5.基本语言问题例1：注释语句或API名称、参数等出现拼写错误，如如下例所示：faild拼写错误，正确的应该是failed。我们再来看一个特例。这里的pin虽然不是错字，但实际上是个人识别码的缩写PIN。如果写成pin，表达的意思就完全不一样了。例2：代码文件中常见的语法错误、不规则表达等问题，如下例所示：上下句风格不一致。startdevicefindforrestart不使用句子大写，第一个单词的首字母大写。两句中存在语法错误，而且由于用词不当，没有体现出两句之间的内在逻辑联系。前面表示动作：开始发现重启设备。后者表示动作结果：启动设备发现失败。让我们看另一个例子。这里的Active和Deactive是形容词，不能代替动词使用。相应的动词应该是Activate和Deactivate。六、排版问题单行内容太宽，或者换行不当的问题都会导致排版不美观。如下例所示，句子断句不当，可将下行内容移至上行：修改如下：七．包容性包容性语言是当今的重要趋势，使用不偏不倚、包容性强的语言是品牌温度在文化中合规和人文关怀的重要体现。一些最初被接受的术语逐渐被取代，例如主席、议员暗示男性主导，特别是在对女性讲话时。下面的例子表达了在包容性语言中违反了角色和标签的要求，应该使用parent而不是father：还有一些方面值得我们注意，比如谨慎使用定义class和race的术语。比如目前业界和其他公司的做法是将master和slave替换为primary和secondary，将blacklist和whitelist分别替换为trustlist和blocklist。以上是一些影响语言和文化体验的问题的例子。这类问题大家可以在对战码活动中多加注意。提升数据体验的一些建议一个成功的生态离不开极致的开发者体验。错误，无论大小，都会对开发人员体验产生不同程度的负面影响。我想借此机会呼吁您：?改变您的心态：开发人员资料是开发人员旅程的关键部分，在开发人员体验中发挥着不可忽视的重要作用。对于开源项目，优质的素材是开发者参与贡献的基础。产品特性和材料就像天平的两端，应该给予同等的权重。?用户视角：开发人员是材料的第一位读者和用户。在战斗代码活动中，站在开发者的角度，发现影响开发者任务完成准确性、完整性、清晰度的问题，并积极提出Issue和PR，共同提升数据质量。?清除低级错误：一些低级错误不一定会妨碍用户理解和完成任务，但肯定会对品牌声誉产生负面影响。我们应该尽最大努力发现并解决此类问题，共同捍卫OpenHarmony的质量声誉。欢迎有兴趣的开发者朋友们参与到对战码先锋，PR来电下单！在Gitee的OpenHarmony代码仓库提交PR参与活动，与全球开发者共建OpenHarmony的繁荣生态！现在打开Gitee并为OpenHarmony提一个PR。你的一小步就是OpenHarmony开源的一大步。我们是一群共同努力做一件伟大的事情的人。只有在各自擅长的领域共同打造极致的开发者体验，才能助力OpenHarmony生态的稳步发展，共同见证OpenHarmony成为万物互联时代的引领者。珍珠。若干年后，当我们回首这段历史，我们可以在开源贡献者证书前自豪地对孩子们说，在这个大生态的背后，是我们的辛勤耕耘和付出，是那么的令人着迷。引以为傲。
