王莉

華為技術有限公司

翻譯及本地化工程師

對于開源項目及其開發者而言，一份書寫規范、質量上乘、及時更新的開發者文檔是至關重要的——它能幫助開發者快速入門，檢視代碼邏輯，提升開發效率，從而吸引更多開發者加入，繁榮開源生態。 作為由開放原子開源基金會孵化及運營的開源項目，OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）在誕生初期也曾面臨開發者文檔太少、質量不夠高等窘境。經過 OpenHarmony 工作委員會、各家共建單位的開發者們一年多的努力，我們很欣喜地看到開發者文檔一點點變得豐富，系統能力不斷構建，代碼也在不斷完善。 華為翻譯及本地化工程師王莉，正是這些參與文檔共建的開發者中的一員。 在近期 OpenHarmony PMC（Project Management Committee 項目管理委員會）舉行的 2022 年 2 月份代碼貢獻者評選中，王莉因為在開發者文檔領域的突出貢獻，成功被評為“代碼貢獻月度之星”，成為代碼貢獻 Top10 的兩位女性開發者之一。 王莉和她所在的團隊，主要貢獻點在于社區的英文化和本地化。加入 OpenHarmony 項目后，他們和資料團隊一起學習和研究了業界主流的 SIG，組建了自己的 SIG docs；制定了社區行為準則、貢獻流程、優化問題反饋和處理機制；制定了代碼規范和寫作模板，植入了 CI 門禁工具、自動提交翻譯 Issue 的 bot，并輸出了 OpenHarmony 各個子系統的相關指導文檔，幫助開發者們更加輕松、愉快地使用 OpenHarmony。 本期 OpenHarmony 開發者故事，我們與王莉一起聊了她和她所在的團隊、參與 OpenHarmony 項目的初心、代碼貢獻如此突出的心得、SIG docs 運營過程中的趣事，以及開源過程中遇到的技術難題、對 OpenHarmony 未來的期待等話題?，F將專訪內容整理如下，希望對你有所啟發。

Q1

請簡要介紹下自己，以及所在開發團隊

大家好，我是來自華為的王莉，是一名翻譯及本地化工程師，目前主要從事 OpenHarmony 相關文檔的翻譯及本地化工作。目前我們團隊主要活躍在 SIG docs，負責 OpenHarmony 項目所有文檔的中到英翻譯工作，常見的比如 API 參考、readme、操作指導等翻譯，外籍輸出件的 PR，以及輸出相關的本地化貢獻指導、規范和 FAQ。

此外，我們還攜手近 10 名資料工程師以及數百位開發工程師，結對優化中文資料。希望能夠通過我們的工作，讓更多的開發者高效地了解和使用 OpenHarmony。

Q2

作為一名翻譯及本地化工程師，您最初為什么會選擇加入OpenHarmony生態、參與開源共建呢？您認為，OpenHarmony項目最吸引人的點在哪里？

我在加入 OpenHarmony 項目之前，曾經做過計算的產品，從我對口的產品一開始清一色的 Intel 處理器，到我們自己的鯤鵬和昇騰處理器，再到生機勃勃的鯤鵬生態、方興未艾的 OpenHarmony 生態……一路走來，我們清楚地知道 OpenHarmony 項目的重要性，更明白開源的重大意義。

OpenHarmony 是一項偉大的事業，我能通過自己的專業能力為社區貢獻一份力，讓我覺得這個工作是非常有價值的。

Q3

這次您被OpenHarmony PMC委員會推舉為“代碼貢獻月度之星”，意味著您對OpenHarmony項目的貢獻已經屬于業界頂尖水平，十分了不起！加入OpenHarmony這么短的時間卻達成了這樣好的效果，請問您的“秘訣”是什么？您是否方便從業務角度具體介紹一下，怎么才能讓開發者更加滿意，把開源共建做得更好呢？

我和我所在的團隊，對社區的主要貢獻點在于社區的英文化和本地化，與代碼貢獻者還是有所區別的。所以能在 OpenHarmony 這次評選中獲得“代碼貢獻月度之星”，我其實覺得十分意外，同時又倍受鼓舞。

一開始加入項目組，我感覺挑戰還是挺大的。雖然我是一名語言工作者，但并不熟悉開發語言；對于 OpenHarmony 所涉及的眾多子系統和技術，也覺得 gap 很大；對于 SIG docs 的運作也一無所知……

好在興趣是最好的老師，缺什么就補什么，這個過程必定是先苦然后慢慢一點一點地甜。作為開發者文檔最認真的讀者，我們必須要理解文檔的每一話。同時，作為最初的體驗者，我們也能站在讀者的角度上，發現一些問題，對文檔提出一些優化建議。對于 SIG 的運作，我們的小團隊也和資料團隊一起，在不斷地探索和改進……

我們的目標，從小了說是讓資料好用、易用、開發者喜歡用，從大了說是提供一個知識、能力分享的平臺，點亮更多開發者。這一目標的達成，也和開源生態的建設一樣，需要大家一起貢獻自己的智慧和力量。

Q4

您和您的團隊小伙伴，在參與OpenHarmony項目貢獻的過程中，一定有一些刻骨銘心/印象深刻的經歷，比如組建和參與SIG docs運營之類?？梢越o我們分享一下嗎？

我之前完全沒有接觸過開源項目，對于開源的理解也僅限于字面意思。

在加入到 OpenHarmony 這個項目以后，我們團隊和資料團隊都在這方面下了很多工夫。我們學習和研究了業界主流的 SIG，組建了自己的 SIG docs；制定了社區行為準則、貢獻流程、優化問題反饋和處理機制；制定了代碼規范和寫作模板，植入了 CI 門禁工具、自動提交翻譯 Issue 的 bot，并輸出了 OpenHarmony 各個子系統的相關指導文檔。目前，SIG docs 已成為 OpenHarmony 社區最活躍的 SIG 之一，關注量和 Fork 數量都遙遙領先。

與以前翻譯工作不同的是，我們需要在 Gitee 上處理文檔，為此我們專門學習了 markdown 語法、Gitee 的常見操作命令等。

一開始由于不了解 Gitee 文檔的運作機制，感覺整個操作流程很是復雜；在提交 PR 的時候，也遇到過各種問題，最初的時候，經常有挫敗感。

在不斷的試錯過程中，我們把工作中的經驗和教訓都記錄下來，形成了我們的《開源項目翻譯操作指導書》，這樣可以固化下來的東西就成了我們的操作規范，也方便更多的愛好者可以很快地上手為社區做貢獻。

Q5

在整個開發進程中，您和您的團隊遇到過哪些技術上或其他方面的難題？這些難題又是如何被逐一解決的？在這些難題被解決的過程中，您總結了哪些寶貴的經驗or教訓？

我們的合作伙伴，是十多位資料同事和上百位來自不同團隊甚至是不同公司的開發同事，如何在社區提供高質量的文檔真的不是一件容易的事。

舉一個很小的例子來說，僅是文檔中的圖形就可能有各種顏色和風格。為了幫助眾多的開發者撰寫合格的文檔，我們的資料團隊組織了社區寫作賦能線上課程、推廣社區寫作模板和規范；我們也和資料團隊一起，參與原稿案例推廣和宣傳。

針對社區文檔類型多，格式比較亂的問題，資料團隊有計劃地對文檔進行純凈 markdown 格式轉換。一開始在 Gitee 提交文檔和翻譯的時間比較長，閉環率較低。通過各種數據輔助分析，我們也想了很多辦法，比如有效地識別同一文檔的 Issue 合并處理，提升處理效率和閉環率。

生態的繁榮離不開廣大生態伙伴、每一位開發者的共同努力，每一個 Issue、PR 都是構建生態繁榮的養分。所以我們的小目標，就是要把這一磚一瓦搭建好。

Q6

加入OpenHarmony生態以來，您最大的驚喜是什么？或者有哪些具體的收獲？

加入 OpenHarmony 生態以后，最大的驚喜是開闊了眼界，學習到了更多的知識。

傳統的文檔反饋機制，是通過官網在線反饋文檔問題、等待文檔工程師確認，再周期性更新發布?；?Gitee 的開放式討論和 Issue 反饋機制，使文檔更新更及時。

我們最大的收獲就是，依托 SIG docs 為 OpenHarmony 提供翻譯和本地化服務，提供了更為豐富的文檔和更為有效的反饋和處理機制，幫助全球開發者更加輕松、愉快地使用 OpenHarmony。我相信后續我們還可以更多地利用工具來提升一些效率，SIG docs 會越來越好。

Q7

您期待未來OpenHarmony哪些方面能夠得到改善、提供更多支持？

作為一名文檔工作者 & 技術小白，我的關注點可能更多還是在資料方面。

我希望我們的資料可以根據不同的讀者進行分層，比如小白級（可以提供一些科普文檔，類似深圳衛健委公眾號那樣的）、初級開發者、高級開發者；入口清晰，更為體系化。

我們整個體系的術語，感覺還可以再完善再清晰一些。很多時候，術語就像一條鏈接各個子系統的脈絡；如果術語這個脈絡做得好，會非常方便初學者上手。同時，如果能有更多動手體驗方面的嘗試，就再好不過了。

我們衷心希望 OpenHarmony 能吸引到更多的開發者，后續我們能有機會提供更多語種的服務。

Q8

OpenHarmony目前仍處在開發探索階段，很多共建單位和生態伙伴還不清楚開源項目的玩法，或不知該如何著手進行開發。可以請您給大家分享一條，您認為最值得分享的心得，或最想說的一句話嗎？

我最想說的是，Do it 永遠比 Say it 更重要。歡迎大家一起來開源共建，OpenHarmony 是一個開放、共享的大舞臺，加入我們，你也有機會成為閃耀的代碼貢獻之星！

Q9

請問您還有什么話想告訴大家？

我非常幸運能從事我喜歡的工作，更是非常非常地幸運能夠加入 OpenHarmony 項目，能在這種大環境背景下，貢獻自己的微薄之力，我覺得是我平凡的職業生涯中很幸福的一件事。

從 2020 年到 2021 年，我見證并參與了 OpenHarmony 的成長，也對未來充滿希望。我希望能有更多的開發者加入我們，一起為 OpenHarmony 做出自己的貢獻。

編輯：黃飛