Rust創造者Graydon Hoare對Rust的發展,表達了兩個具體需要注意與改善建議的部分,一是必須要共享技術文件與成品(Artifacts)特別是語言定義本身,再來則是要把注意力放回人身上,關注參與工作社群個人的壓力,Graydon Hoare提到,這些必須要及早控制,以有計劃的方式進行。

Graydon Hoare認為,任何事物因缺乏控制機制,而發展過快,最終都會導致不好的結果,並列舉了幾種,Rust專案對變化率與成長率進行限制的程序控制形式,他提到,這對於專案的成功是有很大幫助的,像是Bors Queue通常是用來對程式範圍內的正確性進行修改,而Crater Runs則是用來修正整個生態系的正確性,而基於時間的版本發布也是流程控制之一,用來決定放棄時間表抑或是閹割功能。

另外,Rust還增加了一些機制化較低,但仍然重要的社群結構,以管理參與專案的人員成長,例如RFC流程,包括關於形式、內容、時間、參與者組合以及討論重大變化時討論的規則,另外,治理模型也是其中一種控制,畫分責任區塊、必要時的階層授權、參與者的角色和期望等。

Graydon Hoare認為,目前Rust仍有兩大領域缺乏功能性的管理,第一是語言的發展本身,需要有更多規範,第二是人,也就是社群成員。Graydon Hoare提到,當社群成員過於疲憊,就可能做出糟糕的決定,而且社群也可能因成員擁有的資源不均導致發展偏斜,具有特權、精力充沛、收入豐厚或是其他優越條件的人,才能跟上社群的發展。人們也常為贏得爭論,使得話語發展變得狹隘,成員也會因為倦怠、表現不佳而離開專案,社群或因為惡意指責、仇恨語言或挫折而分裂。

Graydon Hoare提出了幾項建議,他認為Rust專案現在應該暫停、反思、集思廣益並實施一些控制措施。他認為最重要的是,社群要學會擁抱負面的語言,試著接納消極、負面的意見,像是Rust永遠不會有某功能這樣的話語,沈住氣忠實地思考,才能獲得長遠的視野。

另外,也要設定一些限制機制,針對諸如編譯器編譯程式碼行數、Bootstrap總時數、每日AWS執行個體的成本花費、類別系統中推理規則數量等,找出有意義的指標,制定機制以限制發展速度。再來是基於個人時間預算的活動限制,計算出在不疲憊的情況下,每個團隊有多少可用時數,或是每個版本釋出需要多少個人力時數,並移除超過這個時間範圍可以做的工作。

主持團隊應在特定討論上加以限制速率或是提供冷靜期,因為有時從外部看來,社群整體討論過於激烈,而限制討論是簡單可以降溫的方式,能讓討論焦點重新回到主題上,而不會被個人行為影響。也應該設置一個額外的專案團隊,負責審核其他團隊的預算以達負載平衡,Graydon Hoare認為這對於團隊是有幫助的,讓第三方來判斷事情的進展,而不是大多數在參加團隊時,預設立場對大多數的事情都說好。


Advertisement

更多 iThome相關內容