提案到 2/3 多數(shù)通過的四階段機(jī)制)
jj 項目治理臨時投票流程解析從社區(qū)提案到 2/3 多數(shù)通過的四階段機(jī)制【免費(fèi)下載鏈接】jjA Git-compatible VCS that is both simple and powerful項目地址: https://gitcode.com/GitHub_Trending/jj/jj導(dǎo)讀本文基于 jjJujutsu一個與 Git 兼容、兼具簡潔與強(qiáng)大的版本控制系統(tǒng)倉庫中的治理文檔完整解讀該項目為工作組的政策提案設(shè)計的臨時投票流程temporary voting process。該流程用于讓社區(qū)成員參與、影響并表決治理工作組提出的永久性治理政策如正式治理結(jié)構(gòu)governance.md、技術(shù)設(shè)計審批流程、代碼評審流程等是 jj 社區(qū)在建立正式治理體系前獲取廣泛社區(qū)認(rèn)可widespread community approval的核心機(jī)制。讀完本文你將掌握該流程的四個階段、關(guān)鍵時間約束提前一周預(yù)告、至少 72 小時評審、1~2 周投票、2/3 多數(shù)通過規(guī)則以及它在 jj 現(xiàn)有治理框架GOVERNANCE.md、docs/governance/GOVERNANCE.md中的定位與銜接方式。為什么需要一套臨時投票流程jj 項目的治理工作組governance working group由 Martinjj 的原始作者、當(dāng)時的唯一維護(hù)者推薦任命并未經(jīng)過更廣泛的 jj 社區(qū)推薦或批準(zhǔn)。這本身不是問題但它意味著工作組在為整個 jj 項目制定政策之前必須先獲得某種形式的社區(qū)認(rèn)可——否則就有被社區(qū)視為對項目施加過度控制的風(fēng)險。為此社區(qū)引入了一套臨時流程它只用于批準(zhǔn)更永久的流程與政策一旦永久性治理政策落地臨時流程即停止使用。換句話說這是一套用來批準(zhǔn)流程的流程meta-process其適用范圍包括但不限于governance.md描述本項目正式治理結(jié)構(gòu)的文檔技術(shù)設(shè)計審批流程technical design approval process代碼評審流程code review process。這套流程同時承載兩個目標(biāo)收集反饋、批準(zhǔn)與認(rèn)可來自投入的 jj 社區(qū)成員且應(yīng)保證現(xiàn)有社區(qū)成員無需付出過大代價即可參與投票作為普通社區(qū)成員影響治理政策的主要途徑流程刻意走到社區(qū)成員所在的地方——GitHub 與 Discord因為所有開發(fā)、大部分支持和技術(shù)討論都發(fā)生在這兩個平臺上。需要特別強(qiáng)調(diào)的是這不是一個追求全體一致同意的流程社區(qū)規(guī)模過大不現(xiàn)實而是一個追求廣泛社區(qū)認(rèn)可的流程。誰有資格參與社區(qū)成員的界定流程的參與者是社區(qū)成員文檔給出了明確列舉包括代碼提交者code committers代碼評審者code reviewers提供用戶支持的人提供高質(zhì)量、可操作反饋的人提供文檔的人第一方或第三方j(luò)j 兼容工具與插件如 GUI、IDE 擴(kuò)展的開發(fā)者提供設(shè)計輸入與反饋的人。如果你自認(rèn)是社區(qū)成員但不在上述分類中可以聯(lián)系工作組任一成員請求擴(kuò)展這份名單。這份社區(qū)成員定義也與倉庫中 GOVERNANCE.md 對 Contributor 的描述相呼應(yīng)——后者將貢獻(xiàn)者寬泛定義為積極參與項目的人包括回答問題、參與討論、提交高質(zhì)量 bug 報告、提交補(bǔ)丁、評審他人 PR、參與測試與 QA 等。四階段流程詳解提案從構(gòu)思到落地共經(jīng)歷四個階段預(yù)告、評審、投票、實施。階段 1提前預(yù)告Advance Notice of Effort工作組在正式分享政策草案前必須提前告知社區(qū)時間要求為進(jìn)入階段 3 之前至少一周且越早越好。此階段工作組的職責(zé)說明工作組認(rèn)為該政策為何必要說明政策應(yīng)實現(xiàn)的基本目標(biāo)說明正在考慮的實現(xiàn)細(xì)節(jié)如有在 GitHub 創(chuàng)建討論帖discussion thread并從 Discord 鏈接過去。該 GitHub 討論帖是唯一的正式討論渠道將隨提案走完整個流程生命周期。此階段社區(qū)受邀推薦額外目標(biāo)或討論工作組已提出目標(biāo)的細(xì)節(jié)推薦實現(xiàn)細(xì)節(jié)。工作組會以善意in good faith考慮這些建議但可以選擇不采納。階段 2提案評審期Proposal Review Period本階段持續(xù)到工作組認(rèn)為主要顧慮已解決、提案可以進(jìn)入投票為止。硬性約束是提案發(fā)布與投票開始之間必須至少間隔 72 小時以便全球各地的社區(qū)成員有時間閱讀和評論。通常本階段應(yīng)持續(xù)至少一周。此階段工作組的職責(zé)將提案全文作為 GitHub Pull RequestPR分享將該 PR 鏈接到既有的 Discord 通知線程與 GitHub 討論帖在提案內(nèi)或提案旁的評論中解釋提案如何滿足階段 1 聲明的目標(biāo)。此階段社區(qū)受邀在 GitHub 上分享建設(shè)性建議修改提案文本或討論措辭細(xì)節(jié)在 GitHub 上分享**攔路虎級別的擔(dān)憂**showstopper concerns包括該擔(dān)憂為何特別嚴(yán)重、以及如何/為何如此嚴(yán)重的細(xì)節(jié)。文檔特別把這一階段類比為代碼評審目標(biāo)是產(chǎn)出一份代表社區(qū)意愿的提案。反饋應(yīng)可操作、建設(shè)性例如這一條款會排斥 X如果我們把它表述成foo bar baz就可能不那么有排他性——遠(yuǎn)比很明顯工作組不想要 X更有價值。最終由工作組根據(jù)討論結(jié)果酌情決定提案進(jìn)入投票或被放棄。階段 3投票期Proposal Voting Period當(dāng)工作組認(rèn)為主要顧慮已解決、對提案文本滿意時即開啟投票。核心規(guī)則如下投票方式在 GitHub 上使用投票功能poll feature進(jìn)行并在投票期間通過 Discord 廣泛宣傳無法使用 GitHub 的成員可通過 Discord 或郵箱聯(lián)系 nasamuffinEmily Shaffer手動提交投票。只列出一名工作組成員是為了避免意外重復(fù)計票反對票說明投反對票的成員應(yīng)在帖子下評論說明原因并描述做出何種修改后他們會改為棄權(quán)或贊成投票可見性一般假設(shè)投票結(jié)果可能公開可見或日后被公開投票時長至少開放 1 周必要時最長 2 周截止后 GitHub 投票將被鎖定。截止時間必須在投票開始時就宣布投票一旦開始不得更改延長投票的情形工作組可延長投票期以覆蓋兩個周末方便有日常工作的人參與、用于緊急程度較低或較復(fù)雜的提案或計入投票期間假期投票選項贊成或反對參與者即文檔開頭列舉的社區(qū)成員群體。通過標(biāo)準(zhǔn)投票期結(jié)束時贊成票達(dá)到或超過 2/3 的提案即獲批準(zhǔn)。投票結(jié)束后有三種結(jié)果結(jié)果后續(xù)動作提案獲通過進(jìn)入階段 4 實施提案被否決可由工作組酌情修訂后從階段 2 重新開始提案被否決可被放棄是否修訂還是放棄由治理工作組裁量。文檔還要求工作組在提案未獲通過后重新檢查提案所要達(dá)成的目標(biāo)本身是否仍然可取——這體現(xiàn)了對目標(biāo)層的反思機(jī)制。階段 4實施Implementation通常實施就是把包含政策的文檔合并進(jìn) jj 代碼庫并在后續(xù)討論中持續(xù)遵循該政策。這正與 GOVERNANCE.md 的定位一致該文檔本身就是正式治理文件任何對其的修改都受其自身決策流程約束。某些情況下實施還可能涉及向某個小組或委員會提名個人。此時被提名的政策應(yīng)說明這些個人將如何被提名——包括初始提名和未來的持續(xù)提名。文檔也誠實地預(yù)見到一種罕見情況實施過程中可能出現(xiàn)障礙導(dǎo)致政策實際行不通。若發(fā)生這種情況工作組應(yīng)對社區(qū)保持透明并可能部分或全部復(fù)用本流程來決定如何推進(jìn)。與正式治理流程的銜接從臨時到永久本文所解讀的臨時投票流程與 jj 倉庫中的正式治理文檔 GOVERNANCE.md倉庫根目錄與 docs/governance/ 下各有一份存在清晰的分工臨時流程本文主題社區(qū)全員GitHub Discord參與針對批準(zhǔn)永久政策這一元層任務(wù)要求 2/3 多數(shù)正式治理GOVERNANCE.md定義了 Maintainer 與 Contributor 兩類角色。日常決策采用提議 2 至 4 周討論期限的機(jī)制每位 Maintainer 投 Support / Reject / Abstain 三選一票贊成票超過參與投票數(shù)不含棄權(quán)的一半即通過增刪 Maintainer 采用至少 2/3 多數(shù)同時規(guī)定單一公司付費(fèi)維護(hù)者不超過 1/3以降低單一公司控制項目方向的風(fēng)險。從倉庫結(jié)構(gòu)看這兩個文件在 mkdocs.yml第 173~174 行中作為相鄰的導(dǎo)航條目出現(xiàn)Temporary voting for governance 與 Governance可以推斷網(wǎng)站文檔體系中二者互為上下文——臨時投票流程正是通向正式治理的過渡橋梁。此外docs/contributing.md 中記錄的評審實踐如不要合并僅由同一組織成員批準(zhǔn)的 PR以及 docs/paid_contributors.md 要求記錄支付貢獻(xiàn)的公司名單以暴露利益沖突與治理文檔中的單一公司影響力限制互為印證共同構(gòu)成 jj 社區(qū)治理的完整圖景。社區(qū)成員如何參與實操要點(diǎn)綜合全文普通社區(qū)成員參與這套流程的關(guān)鍵動作可以總結(jié)為階段 1關(guān)注 GitHub 討論帖Discord 會同步鏈接對政策的目標(biāo)與實現(xiàn)細(xì)節(jié)提出補(bǔ)充建議階段 2在 GitHub PR 上做代碼評審式的評論——提出可操作的文本修改建議或陳述攔路虎級別的擔(dān)憂階段 3通過 GitHub 投票功能投票無法使用 GitHub 時聯(lián)系 nasamuffin 手動計入投反對票時說明原因與可改變態(tài)度的條件階段 4跟蹤政策落地為代碼庫中的文檔并在后續(xù)討論中共同遵守。對貢獻(xiàn)者而言可以先從 docs/contributing.md 了解項目的貢獻(xiàn)規(guī)范CLI 快照測試、nightly rustfmt、MSRV 等再依據(jù) GOVERNANCE.md 中的提名機(jī)制申請成為 Maintainer——這同樣是社區(qū)治理參與的一部分。小結(jié)jj 的臨時投票流程是一套精心設(shè)計的元治理機(jī)制以提前一周預(yù)告 → 至少 72 小時評審 → 1~2 周投票 → 2/3 多數(shù)通過 → 實施為主線把社區(qū)認(rèn)可嵌入到永久政策誕生之前。它明確了參與者范圍、時間約束、投票規(guī)則與失敗后的回退路徑并與 GOVERNANCE.md 的正式治理結(jié)構(gòu)形成臨時過渡 → 永久治理的清晰演進(jìn)關(guān)系。對研究開源治理模型或有意參與 jj 社區(qū)的開發(fā)者而言這套流程既是可操作的參與指南也是理解 jj 項目如何平衡維護(hù)者權(quán)威與社區(qū)意愿的關(guān)鍵文檔。【免費(fèi)下載鏈接】jjA Git-compatible VCS that is both simple and powerful項目地址: https://gitcode.com/GitHub_Trending/jj/jj創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 jj 項目治理臨時投票流程解析：從社區(qū)提案到 2/3 多數(shù)通過的四階段機(jī)制
jj 項目治理臨時投票流程解析從社區(qū)提案到 2/3 多數(shù)通過的四階段機(jī)制【免費(fèi)下載鏈接】jjA Git-compatible VCS that is both simple and powerful項目地址: https://gitcode.com/GitHub_Trending/jj/jj導(dǎo)讀本文基于 jjJujutsu一個與 Git 兼容、兼具簡潔與強(qiáng)大的版本控制系統(tǒng)倉庫中的治理文檔完整解讀該項目為工作組的政策提案設(shè)計的臨時投票流程temporary voting process。該流程用于讓社區(qū)成員參與、影響并表決治理工作組提出的永久性治理政策如正式治理結(jié)構(gòu)governance.md、技術(shù)設(shè)計審批流程、代碼評審流程等是 jj 社區(qū)在建立正式治理體系前獲取廣泛社區(qū)認(rèn)可widespread community approval的核心機(jī)制。讀完本文你將掌握該流程的四個階段、關(guān)鍵時間約束提前一周預(yù)告、至少 72 小時評審、1~2 周投票、2/3 多數(shù)通過規(guī)則以及它在 jj 現(xiàn)有治理框架GOVERNANCE.md、docs/governance/GOVERNANCE.md中的定位與銜接方式。為什么需要一套臨時投票流程jj 項目的治理工作組governance working group由 Martinjj 的原始作者、當(dāng)時的唯一維護(hù)者推薦任命并未經(jīng)過更廣泛的 jj 社區(qū)推薦或批準(zhǔn)。這本身不是問題但它意味著工作組在為整個 jj 項目制定政策之前必須先獲得某種形式的社區(qū)認(rèn)可——否則就有被社區(qū)視為對項目施加過度控制的風(fēng)險。為此社區(qū)引入了一套臨時流程它只用于批準(zhǔn)更永久的流程與政策一旦永久性治理政策落地臨時流程即停止使用。換句話說這是一套用來批準(zhǔn)流程的流程meta-process其適用范圍包括但不限于governance.md描述本項目正式治理結(jié)構(gòu)的文檔技術(shù)設(shè)計審批流程technical design approval process代碼評審流程code review process。這套流程同時承載兩個目標(biāo)收集反饋、批準(zhǔn)與認(rèn)可來自投入的 jj 社區(qū)成員且應(yīng)保證現(xiàn)有社區(qū)成員無需付出過大代價即可參與投票作為普通社區(qū)成員影響治理政策的主要途徑流程刻意走到社區(qū)成員所在的地方——GitHub 與 Discord因為所有開發(fā)、大部分支持和技術(shù)討論都發(fā)生在這兩個平臺上。需要特別強(qiáng)調(diào)的是這不是一個追求全體一致同意的流程社區(qū)規(guī)模過大不現(xiàn)實而是一個追求廣泛社區(qū)認(rèn)可的流程。誰有資格參與社區(qū)成員的界定流程的參與者是社區(qū)成員文檔給出了明確列舉包括代碼提交者code committers代碼評審者code reviewers提供用戶支持的人提供高質(zhì)量、可操作反饋的人提供文檔的人第一方或第三方j(luò)j 兼容工具與插件如 GUI、IDE 擴(kuò)展的開發(fā)者提供設(shè)計輸入與反饋的人。如果你自認(rèn)是社區(qū)成員但不在上述分類中可以聯(lián)系工作組任一成員請求擴(kuò)展這份名單。這份社區(qū)成員定義也與倉庫中 GOVERNANCE.md 對 Contributor 的描述相呼應(yīng)——后者將貢獻(xiàn)者寬泛定義為積極參與項目的人包括回答問題、參與討論、提交高質(zhì)量 bug 報告、提交補(bǔ)丁、評審他人 PR、參與測試與 QA 等。四階段流程詳解提案從構(gòu)思到落地共經(jīng)歷四個階段預(yù)告、評審、投票、實施。階段 1提前預(yù)告Advance Notice of Effort工作組在正式分享政策草案前必須提前告知社區(qū)時間要求為進(jìn)入階段 3 之前至少一周且越早越好。此階段工作組的職責(zé)說明工作組認(rèn)為該政策為何必要說明政策應(yīng)實現(xiàn)的基本目標(biāo)說明正在考慮的實現(xiàn)細(xì)節(jié)如有在 GitHub 創(chuàng)建討論帖discussion thread并從 Discord 鏈接過去。該 GitHub 討論帖是唯一的正式討論渠道將隨提案走完整個流程生命周期。此階段社區(qū)受邀推薦額外目標(biāo)或討論工作組已提出目標(biāo)的細(xì)節(jié)推薦實現(xiàn)細(xì)節(jié)。工作組會以善意in good faith考慮這些建議但可以選擇不采納。階段 2提案評審期Proposal Review Period本階段持續(xù)到工作組認(rèn)為主要顧慮已解決、提案可以進(jìn)入投票為止。硬性約束是提案發(fā)布與投票開始之間必須至少間隔 72 小時以便全球各地的社區(qū)成員有時間閱讀和評論。通常本階段應(yīng)持續(xù)至少一周。此階段工作組的職責(zé)將提案全文作為 GitHub Pull RequestPR分享將該 PR 鏈接到既有的 Discord 通知線程與 GitHub 討論帖在提案內(nèi)或提案旁的評論中解釋提案如何滿足階段 1 聲明的目標(biāo)。此階段社區(qū)受邀在 GitHub 上分享建設(shè)性建議修改提案文本或討論措辭細(xì)節(jié)在 GitHub 上分享**攔路虎級別的擔(dān)憂**showstopper concerns包括該擔(dān)憂為何特別嚴(yán)重、以及如何/為何如此嚴(yán)重的細(xì)節(jié)。文檔特別把這一階段類比為代碼評審目標(biāo)是產(chǎn)出一份代表社區(qū)意愿的提案。反饋應(yīng)可操作、建設(shè)性例如這一條款會排斥 X如果我們把它表述成foo bar baz就可能不那么有排他性——遠(yuǎn)比很明顯工作組不想要 X更有價值。最終由工作組根據(jù)討論結(jié)果酌情決定提案進(jìn)入投票或被放棄。階段 3投票期Proposal Voting Period當(dāng)工作組認(rèn)為主要顧慮已解決、對提案文本滿意時即開啟投票。核心規(guī)則如下投票方式在 GitHub 上使用投票功能poll feature進(jìn)行并在投票期間通過 Discord 廣泛宣傳無法使用 GitHub 的成員可通過 Discord 或郵箱聯(lián)系 nasamuffinEmily Shaffer手動提交投票。只列出一名工作組成員是為了避免意外重復(fù)計票反對票說明投反對票的成員應(yīng)在帖子下評論說明原因并描述做出何種修改后他們會改為棄權(quán)或贊成投票可見性一般假設(shè)投票結(jié)果可能公開可見或日后被公開投票時長至少開放 1 周必要時最長 2 周截止后 GitHub 投票將被鎖定。截止時間必須在投票開始時就宣布投票一旦開始不得更改延長投票的情形工作組可延長投票期以覆蓋兩個周末方便有日常工作的人參與、用于緊急程度較低或較復(fù)雜的提案或計入投票期間假期投票選項贊成或反對參與者即文檔開頭列舉的社區(qū)成員群體。通過標(biāo)準(zhǔn)投票期結(jié)束時贊成票達(dá)到或超過 2/3 的提案即獲批準(zhǔn)。投票結(jié)束后有三種結(jié)果結(jié)果后續(xù)動作提案獲通過進(jìn)入階段 4 實施提案被否決可由工作組酌情修訂后從階段 2 重新開始提案被否決可被放棄是否修訂還是放棄由治理工作組裁量。文檔還要求工作組在提案未獲通過后重新檢查提案所要達(dá)成的目標(biāo)本身是否仍然可取——這體現(xiàn)了對目標(biāo)層的反思機(jī)制。階段 4實施Implementation通常實施就是把包含政策的文檔合并進(jìn) jj 代碼庫并在后續(xù)討論中持續(xù)遵循該政策。這正與 GOVERNANCE.md 的定位一致該文檔本身就是正式治理文件任何對其的修改都受其自身決策流程約束。某些情況下實施還可能涉及向某個小組或委員會提名個人。此時被提名的政策應(yīng)說明這些個人將如何被提名——包括初始提名和未來的持續(xù)提名。文檔也誠實地預(yù)見到一種罕見情況實施過程中可能出現(xiàn)障礙導(dǎo)致政策實際行不通。若發(fā)生這種情況工作組應(yīng)對社區(qū)保持透明并可能部分或全部復(fù)用本流程來決定如何推進(jìn)。與正式治理流程的銜接從臨時到永久本文所解讀的臨時投票流程與 jj 倉庫中的正式治理文檔 GOVERNANCE.md倉庫根目錄與 docs/governance/ 下各有一份存在清晰的分工臨時流程本文主題社區(qū)全員GitHub Discord參與針對批準(zhǔn)永久政策這一元層任務(wù)要求 2/3 多數(shù)正式治理GOVERNANCE.md定義了 Maintainer 與 Contributor 兩類角色。日常決策采用提議 2 至 4 周討論期限的機(jī)制每位 Maintainer 投 Support / Reject / Abstain 三選一票贊成票超過參與投票數(shù)不含棄權(quán)的一半即通過增刪 Maintainer 采用至少 2/3 多數(shù)同時規(guī)定單一公司付費(fèi)維護(hù)者不超過 1/3以降低單一公司控制項目方向的風(fēng)險。從倉庫結(jié)構(gòu)看這兩個文件在 mkdocs.yml第 173~174 行中作為相鄰的導(dǎo)航條目出現(xiàn)Temporary voting for governance 與 Governance可以推斷網(wǎng)站文檔體系中二者互為上下文——臨時投票流程正是通向正式治理的過渡橋梁。此外docs/contributing.md 中記錄的評審實踐如不要合并僅由同一組織成員批準(zhǔn)的 PR以及 docs/paid_contributors.md 要求記錄支付貢獻(xiàn)的公司名單以暴露利益沖突與治理文檔中的單一公司影響力限制互為印證共同構(gòu)成 jj 社區(qū)治理的完整圖景。社區(qū)成員如何參與實操要點(diǎn)綜合全文普通社區(qū)成員參與這套流程的關(guān)鍵動作可以總結(jié)為階段 1關(guān)注 GitHub 討論帖Discord 會同步鏈接對政策的目標(biāo)與實現(xiàn)細(xì)節(jié)提出補(bǔ)充建議階段 2在 GitHub PR 上做代碼評審式的評論——提出可操作的文本修改建議或陳述攔路虎級別的擔(dān)憂階段 3通過 GitHub 投票功能投票無法使用 GitHub 時聯(lián)系 nasamuffin 手動計入投反對票時說明原因與可改變態(tài)度的條件階段 4跟蹤政策落地為代碼庫中的文檔并在后續(xù)討論中共同遵守。對貢獻(xiàn)者而言可以先從 docs/contributing.md 了解項目的貢獻(xiàn)規(guī)范CLI 快照測試、nightly rustfmt、MSRV 等再依據(jù) GOVERNANCE.md 中的提名機(jī)制申請成為 Maintainer——這同樣是社區(qū)治理參與的一部分。小結(jié)jj 的臨時投票流程是一套精心設(shè)計的元治理機(jī)制以提前一周預(yù)告 → 至少 72 小時評審 → 1~2 周投票 → 2/3 多數(shù)通過 → 實施為主線把社區(qū)認(rèn)可嵌入到永久政策誕生之前。它明確了參與者范圍、時間約束、投票規(guī)則與失敗后的回退路徑并與 GOVERNANCE.md 的正式治理結(jié)構(gòu)形成臨時過渡 → 永久治理的清晰演進(jìn)關(guān)系。對研究開源治理模型或有意參與 jj 社區(qū)的開發(fā)者而言這套流程既是可操作的參與指南也是理解 jj 項目如何平衡維護(hù)者權(quán)威與社區(qū)意愿的關(guān)鍵文檔。【免費(fèi)下載鏈接】jjA Git-compatible VCS that is both simple and powerful項目地址: https://gitcode.com/GitHub_Trending/jj/jj創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考