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