如何衡量一個開源社區的健康度
作為一個經常管理軟體開發團隊的人,多年來我一直關注度量指標。一次次,我發現自己領導團隊使用一個又一個的項目平台(例如 Jira、GitLab 和 Rally)生成了大量可測量的數據。從那時起,我已經及時投入了大量時間從記錄平台中提取了有用的指標,並採用了一種我們可以理解的格式,然後使用這些指標對開發的許多方面做出更好的選擇。
今年早些時候,我有幸在 Linux 基金會遇到了一個名為 開源軟體社區健康分析 (CHAOSS)的項目。該項目側重於從各種來源收集和豐富指標,以便開源社區的利益相關者可以衡量他們項目的健康狀況。
CHAOSS 介紹
隨著我對該項目的基本指標和目標越來越熟悉,一個問題在我的腦海中不斷翻滾。什麼是「健康」的開源項目,由誰來定義?
特定角色的人認為健康的東西可能另一個角色的人就不會這樣認為。似乎可以用 CHAOSS 收集的細粒度數據進行市場細分實驗,重點關注對特定角色可能最有意義的背景問題,以及 CHAOSS 收集哪些指標可能有助於回答這些問題。
CHAOSS 項目創建並維護了一套開源應用程序和度量標準定義,使得這個實驗具有可能性,這包括:
- 許多基於伺服器的應用程序,用於收集、聚合和豐富度量標準(例如 Augur 和 GrimoireLab)。
- ElasticSearch、Kibana 和 Logstash(ELK)的開源版本。
- 身份服務、數據分析服務和各種集成庫。
在我過去的一個程序中,有六個團隊從事於不同複雜程度的項目,我們找到了一個簡潔的工具,它允許我們從簡單(或複雜)的 JQL 語句中創建我們想要的任何類型的指標,然後針對這些指標開發計算。在我們注意到之前,我們僅從 Jira 中就提取了 400 多個指標,而且還有更多指標來自手動的來源。
在項目結束時,我們認定這 400 個指標中,大多數指標在以我們的角色做出決策時並不重要。最終,只有三個對我們非常重要:「缺陷去除效率」、「已完成的條目與承諾的條目」,以及「每個開發人員的工作進度」。這三個指標最重要,因為它們是我們對自己、客戶和團隊成員所做出的承諾,因此是最有意義的。
帶著這些通過經驗得到的教訓和對什麼是健康的開源項目的問題,我跳進了 CHAOSS 社區,開始建立一套角色,以提供一種建設性的方法,從基於角色的角度回答這個問題。
CHAOSS 是一個開源項目,我們嘗試使用民主共識來運作。因此,我決定使用 組成分子 這個詞而不是利益相關者,因為它更符合我們作為開源貢獻者的責任,以創建更具共生性的價值鏈。
雖然創建此組成模型的過程採用了特定的「目標-問題-度量」方法,但有許多方法可以進行細分。CHAOSS 貢獻者已經開發了很好的模型,可以按照矢量進行細分,例如項目屬性(例如,個人、公司或聯盟)和「失敗容忍度」。在為 CHAOSS 開發度量定義時,每個模型都會提供建設性的影響。
基於這一切,我開始構建一個誰可能關心 CHAOSS 指標的模型,以及每個組成分子在 CHAOSS 的四個重點領域中最關心的問題:
在我們深入研究之前,重要的是要注意 CHAOSS 項目明確地將背景判斷留給了實施指標的團隊。什麼是「有意義的」和「什麼是健康的?」的答案預計會因團隊和項目而異。CHAOSS 軟體的現成儀錶板儘可能地關注客觀指標。在本文中,我們關注項目創始人、項目維護者和貢獻者。
項目組成分子
雖然這絕不是這些組成分子可能認為重要的問題的詳盡清單,但這些選擇感覺是一個好的起點。以下每個「目標-問題-度量」標準部分與 CHAOSS 項目正在收集和匯總的指標直接相關。
現在,進入分析的第 1 部分!
項目創始人
作為項目創始人,我最關心:
- 我的項目對其他人有用嗎?通過以下測量:
- 隨著時間推移有多少復刻?
- 指標:存儲庫復刻數。
- 隨著時間的推移有多少貢獻者?
- 指標:貢獻者數量。
- 貢獻凈質量。
- 指標:隨著時間的推移提交的錯誤。
- 指標:隨著時間的回歸。
- 項目的財務狀況。
- 指標:隨著時間的推移的捐贈/收入。
- 指標:隨著時間的推移的費用。
- 隨著時間推移有多少復刻?
- 我的項目對其它人的可見程度?
- 有誰知道我的項目?別人認為它很整潔嗎?
- 指標:社交媒體上的提及、分享、喜歡和訂閱的數量。
- 有影響力的人是否了解我的項目?
- 指標:貢獻者的社會影響力。
- 人們在公共場所對項目有何評價?是正面還是負面?
- 指標:跨社交媒體渠道的情感(關鍵字或 NLP)分析。
- 有誰知道我的項目?別人認為它很整潔嗎?
- 我的項目可行性程度?
- 我們有足夠的維護者嗎?該數字是隨著時間的推移而上升還是下降?
- 指標:維護者數量。
- 改變速度如何隨時間變化?
- 指標:代碼隨時間的變化百分比。
- 指標:拉取請求、代碼審查和合併之間的時間。
- 我們有足夠的維護者嗎?該數字是隨著時間的推移而上升還是下降?
- 我的項目的多樣化 & 包容性如何?
- 我們是否擁有有效的公開行為準則(CoC)?
- 度量標準: 檢查存儲庫中的 CoC 文件。
- 與我的項目相關的活動是否積極包容?
- 指標:關於活動的票務政策和活動包容性行為的手動報告。
- 我們的項目在可訪問性上做的 好不好?
- 指標:驗證發布的 文字會議紀要。
- 指標:驗證會議期間使用的隱藏式字幕。
- 指標:驗證在演示文稿和項目前端設計中色盲可訪問的素材。
- 我們是否擁有有效的公開行為準則(CoC)?
- 我的項目代表了多少價值?
- 我如何幫助組織了解使用我們的項目將節省多少時間和金錢(勞動力投資)
- 指標: 倉庫的議題、提交、拉取請求的數量和估計人工費率。
- 我如何理解項目創建的下游價值的數量,以及維護我的項目對更廣泛的社區的重要性(或不重要)?
- 指標:依賴我的項目的其他項目數。
- 為我的項目做出貢獻的人有多少機會使用他們學到的東西來找到合適的工作崗位,以及在哪些組織(即生活工資)?
- 指標:使用或貢獻此庫的組織數量。
- 指標:使用此類項目的開發人員的平均工資。
- 指標:與該項目匹配的關鍵字的職位發布計數。
- 我如何幫助組織了解使用我們的項目將節省多少時間和金錢(勞動力投資)
項目維護者
作為項目維護者,我最關心:
- 我是高效的維護者嗎?
- 指標:拉取請求在代碼審查之前等待的時間。
- 指標:代碼審查和後續拉取請求之間的時間。
- 指標:我的代碼審核中有多少被批准?
- 指標:我的代碼評論中有多少被拒絕或返工?
- 指標:代碼審查的評論的情感分析。
- 我如何讓更多人幫助我維護這件事?
- 指標:項目貢獻者的社交覆蓋面數量。
- 我們的代碼質量隨著時間的推移變得越來越好嗎?
- 指標:計算隨著時間的推移引入的回歸數量。
- 指標:計算隨著時間推移引入的錯誤數量。
- 指標:錯誤歸檔、拉取請求、代碼審查、合併和發布之間的時間。
項目開發者和貢獻者
作為項目開發者或貢獻者,我最關心:
- 我可以從為這個項目做出貢獻中獲得哪些有價值的東西,以及實現這個價值需要多長時間?
- 指標:下游價值。
- 指標:提交、代碼審查和合併之間的時間。
- 通過使用我在貢獻中學到的東西來增加工作機是否有良好的前景?
- 指標:生活工資。
- 這個項目有多受歡迎?
- 指標:社交媒體帖子、分享和收藏的數量。
- 社區有影響力的人知道我的項目嗎?
- 指標:創始人、維護者和貢獻者的社交範圍。
通過創建這個列表,我們開始讓 CHAOSS 更加豐滿了,並且在今年夏天項目中首次發布該指標時,我迫不及待地想看看廣泛的開源社區可能有什麼其他偉大的想法,以及我們還可以從這些貢獻中學到什麼(並衡量!)。
其它角色
接下來,你需要了解有關其他角色(例如基金會、企業開源計劃辦公室、業務風險和法律團隊、人力資源等)以及最終用戶的目標問題度量集的更多信息。他們關心開源的不同事物。
如果你是開源貢獻者或組成分子,我們邀請你來看看這個項目並參與社區活動!
via: https://opensource.com/article/19/8/measure-project
作者:Jon Lawrence 選題:lujun9972 譯者:wxy 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive