DevStream 社區貢獻者英雄榜上線啦！

何謂"英雄榜"？

廢話不多說，不扯那些所謂的"提高貢獻者榮譽感"、"讓貢獻被所有人看到"，直接上圖！

這就是"排場"，這就是"面子"，這就是"英雄榜"！

• 感謝我們的設計，設計出如此有質感的頁面，漂亮！
• 感謝我們的前端，完美實作了頁面設計，而且支持動態添加徽章型別，優雅！

本文導讀

概要

主要分為兩大部分，第一部分是 DevStream 英雄榜的簡單介紹，第二部分是對 DevStream 的貢獻者、證書管理體系及自動化的介紹，

適合的閱讀群體

• 開源社區運營者：文中詳細地介紹了 DevStream 對貢獻者資訊管理、證書發放等內容的探索心路，以及是如何實作近乎全自動化的，希望能給開源社區的運營作業者們帶來些啟發，盡量減少無意義的重復性作業，
• 編程愛好者們：自動化流程的實作思路（飛書多維表格、GitHub Actions、腳本等），以及實作技術細節的思考，或許你會感興趣，附有 GitHub 倉庫鏈接，
• DevStream 的社區伙伴們：這里是我們的主場——英雄榜！

英雄榜介紹

誰能上榜?

所有獲得過證書的 DevStream 的貢獻者們，

DevStream 目前共有開源貢獻者、布道師、演說家、TopN幾大類證書（徽章），每種證書的每個細分型別都使用一個單獨的頁面來展示貢獻者們，

英雄榜的組成

英雄榜主要由證書的圖示、介紹、貢獻者陣列組成，

實時展示每個"英雄"的 GitHub 頭像，點擊可以跳轉到 Credly 證書頁面以校驗，

DevStream 的貢獻者、證書管理體系介紹

視頻版

建議先看視頻一睹為快，再看文章了解整個自動化體系的發展歷程、設計思路、技術細節，

點擊圖片觀看演示與講解視頻：

緣起

DevStream 的貢獻者證書管理體系來源于一個很不起眼的需求，

五月份左右的時候，DevStream 處于新貢獻者的爆發期，幾乎天天有新貢獻者加入，我們準備了很多 "good first issue", 往往一出現就被一搶而空，

隨著貢獻者越來越多，我們需要判斷某 GitHub 用戶是否已經成為了貢獻者，以防止 "good first issue" 的重復申領，

這時候只需要一個簡單的表格就能實作，

新證書體系

隨著 DevStream 推出新的證書體系，我們有了十多種細分證書，而且一位貢獻者可以被授予多個證書，

每個證書都有其編號、頒發日期、禮物發放細節，傳統的單表格模式已無法滿足新的需求，

貢獻者與證書管理表格設計

我們基于飛書多維表格來完成了復雜的需求實作，將個人資訊與證書頒布資訊拆分成兩個表格，二者采用多對多的關聯形式，

使用方式：

1. 填寫新貢獻者基本資訊：在個人資訊表登記名字、微信、GitHub等資訊方便聯系；
2. 頒發證書：在證書表里把這個人關聯進來，并補充頒發日期等資訊即可，

以下為操作演示，假設我們要給"張三"頒布"Talented-Speaker Professional"證書，可在10秒內完成：

快捷視圖

在觀看演示的時候，你可能會發現，螢屏左側有非常多的"表"，

其實那些都只是"視圖"，即設定不同的統計策略、篩選規則、排序方式，自動渲染，以不同的資料維度展示出來，

下面列舉一些常用的視圖：

1. 每月新增貢獻者，自動統計每月新增的貢獻者，獲得過一次證書即視為貢獻者，若多次獲得證書，自動識別第一次獲得證書時間，

2. 每月新增證書，證書維度的每月新增統計，

3. 統計面板，以餅圖、條形圖等方式展現統計資料，

4. 是否是貢獻者，自動檢索登記的所有人員資訊，獲得過一次證書即視為貢獻者，用來防止 "good first issue" 的重復申領，

5. 證書分組，按型別分組展示所有證書，

6. 單證書視圖，只展示某特定型別的證書，如這里只展示 "Contributor - Professional" 型別的證書的頒發情況，

7. 禮物未寄送，篩選出頒布了證書但未寄送禮物，每個人的每種證書，禮物發放記錄是相互獨立的，

自動化資訊收集

傳統運營模式下，貢獻者資訊表格只能由內部人員編輯，需要使用社交媒體收集了貢獻者的資訊后，再將資訊復制到表格中，溝通程序是"同步"的，成本很高，

DevStream 利用了多維表格的"表單視圖"，根據表格的欄位自動生成表單，將表單發送給"準貢獻者"，填寫完畢后資訊自動保存到表格中，

同時，我們還通過飛書的"自動化"功能，配置了訊息提醒，每當有貢獻者提交了表單，飛書會自動提醒運營人員，不需要再反復詢問或確認是否完成了表單的填寫，采用異步溝通的形式提高了效率，

接下來就是頒發 Credly 證書，這部分參照 Credly 官網教程即可，

以上的多維表格，已經整理成了模板，可以一鍵使用：開源社區貢獻者與證書管理-模板，

資訊同步與自動化

資訊同步

原先我們只有內部的貢獻者資訊和證書資訊管理表格，后面又有了 Credly 證書，現在又有了那么酷炫的英雄榜，以及需要能從英雄榜跳轉到特定的 Credly 證書驗證頁，

加上之前的證書發布狀態管理、禮物寄送狀態管理，需要一個自動化且可信的資料處理、同步機制，

DevStream 借用了 Single Source of Truth 的理念，將證書表格作為唯一的、標準的資訊來源，各種資訊的管理和記錄都在表格上進行，Credly 頒發完成后證書鏈接也先填回表格，再匯出到官網英雄榜，

自動化

多維表格是"表格“形式，可以匯出成 csv 格式； 而DevStream官網倉庫渲染英雄榜貢獻者使用的格式是 json，

還有很多細節，如：

1. 表格收集的是中文姓名，官網英雄榜展示的是英文名，
2. 部分貢獻者希望用自己的英文名而不是中文拼音來展示，
3. 英雄榜會展示頭像，表格里沒有相應欄位（可以使用 GitHub ID 獲取 GitHub 頭像），
4. Credly 管理頁面復制得到的證書鏈接需要登錄才能查看，需要進行格式轉換，

DevStream 做了個資料格式轉換倉庫, 讀入 csv 資料，轉換成英雄榜需要的 json 資料，并處理中文轉拼音等細節，

于是，我們的操作流程就變成了這樣：

1. 更新完貢獻者與證書表格，把飛書表格以 csv 格式下載至本地，并將其移動到資料轉化代碼的相應目錄中；
2. 運行程式，自動執行資料格式轉換，得到官網英雄榜需要 json 格式；
3. 使用得到的 json 檔案覆寫官網倉庫的對應檔案；
4. git add && git commit && git push；
5. 提 pr 至官網倉庫；
6. review && merge pr，

能不能再簡化一些呢？尤其是每次手動提要點開 GitHub 網頁提交 pr 好麻煩！

當然可以！—— 我認為絕大多數重復的、可被精確定義或描述的操作，都可以使用代碼自動化，

我們可以使用 GitHub Actions 來完成部分自動化，每次提交最新的含有貢獻者和證書資訊的 csv 檔案，由 Actions 完成"程式運行（資料處理）、復制 json 至官網倉庫、提 pr 到官網倉庫"的操作，

然后流程就變成了：

1. 更新表格，下載成 csv ，移動到相應目錄；
2. git add && git commit && git push （之后由 GitHub Actions 自動執行程式，復制 json、提 pr 到官網倉庫）；
3. review && merge pr，

還能再簡單點嗎？我只想點點滑鼠！

當然！可以！

第二步已經把執行的命令都寫出來了，為什么不直接放到 shell 腳本里？

第一步呢？"下載表格成 csv"本就是個滑鼠操作，"移動到代碼目錄" 不就是個 mv 嗎？

（具體的 GitHub Actions 作業流定義和 shell 腳本，前面的資料格式轉換倉庫中均已給出），

最終流程

當貢獻者或證書資訊更新后：

1. 滑鼠點一下飛書多維表格頁的 "下載為 csv"
2. 滑鼠點一下桌面的腳本

泡杯茶，等半分鐘，通知 website 倉庫管理員 review pr 并 merge，

一些自動化的探討

自動化環節，很多地方可以做得更好，以及很多地方是多次權衡過的結果，簡單分享一下：

Q1. 為什么最后還要人工 review？

其實理論上能做到直接合并不需要 review，但最后人工校驗一下更安全，

Q2. 為什么最后要依靠腳本來在本地操作 Git，而不是建個 web 服務器？

雖然這樣看起來很美好，而且所有人都能很簡單地操作且沒有任何環境依賴，

同時飛書的多維表格的自動化是支持在表格變動了之后發送 http 請求的，理論上完全可以做到在表格變動之后，通知后端服務，主動拉取表格資料、渲染、pr ，

但這樣有以下幾個問題：

1. 需要一個服務器，消耗資源，以及自己建的 web 服務器的穩定性大概率不如 GitHub Actions 穩定，
2. 沒有必要去為了這一個小功能去申請一個飛書機器人，然后設定復雜的登錄邏輯，得不償失，

其實建不建 web 服務器，很大程度取決于如何從飛書端獲取匯出的資料，DevStream 采用了"推"的方式主動將資料發送給程式，而不是使用"拉"的方式由程式來請求飛書，雖然后者理論上更安全可靠等，但是實際操作起來會更麻煩，

目前這套流程最終也只需要點兩次滑鼠就能完成，操作上已經幾乎達到最簡，

Q3. 檔案的安全性如何保證？

目前貢獻者敏感資訊主要是手機號、微信、識訓地址等，

我采取的方式是建個新視圖 ——"下載專用（脫敏）"，屏蔽所有敏感資訊，只展示渲染英雄榜需要的關鍵資訊，之后下載 csv 都從這個視圖里下，
（這就是寫博客輸出的好處了，建立新視圖來屏蔽敏感資訊的方式是輸出的程序中想到的），

也可以采取以下方式，更保險：

• 倉庫私有
• 將下載下來的帶有敏感資訊的 csv 檔案上傳到可信的或自建的檔案存盤服務器，然后在 GitHub Actions 里面下載，同時將網路檔案存盤服務的密碼存至倉庫的 Secret 中，
• 修改部分邏輯，在本地執行 csv 到 json 的轉換，GitHub Action 只完成 pr 操作，

一些運營上的想法

寫著寫著，想到了博客以外的一些內容，想分享一下，

為什么會有這篇博客，或者說，為什么會有這個自動化系統？

前段時間 DevStream 的全職運營離職，所以我們進行了一個非常大膽的創新：每個開發都分擔一部分運營的任務，

原以為這會成為開發的一個負擔，但運作到現在，事情變得有意思了起來：

搞技術的人天生受不了重復性的操作，如果讓搞技術的來做運營，那么我們會想方設法地去簡化整個流程，提高整體的效率，

所以，對于一個無技術背景的運營來說，管理這樣一個復雜的貢獻者資訊——禮物發放——證書發放——英雄榜更新體系是一件非常耗時的作業：

需要一個個地去溝通、收集、復制、編輯、再復制...... 每有一個新的貢獻者起碼耗時20分鐘，是非常折磨人的，

但這個運營作業落到了技術人員身上，流程就變成了：

1. 和貢獻者互相吹吹牛，然后甩過去一個表單
2. 貢獻者填完表單，飛書收到通知
3. 點兩下滑鼠，頒發一下證書
4. 再點兩下滑鼠，用腳本更新一下官網

愈發覺得 DevStream 這個模式是成功且高效、有一定推廣意義的，無論是技術人員輔助做些運營作業并提高整個團隊的作業效率，還是運營人員自身去學些技識訓者利用工具提高效率，

如果開源社區的運營者們不用每天身陷于重復性的無聊的作業，而是能有更多的時間去做些創造性的作業、有趣的作業，那一定非常酷！

鏈接集合

• 英雄榜
• DevStream 新證書體系介紹
• 開源社區貢獻者與證書管理-模板
• DevStream官網倉庫
• 資料格式轉換倉庫

標籤：其他

上一篇：百萬獎池角逐，華為云IoT邊緣帶你看懂“邊緣計算開發者大賽”

下一篇：【二分查找】演算法