K60至尊版剛預熱 一加Ace2 Pro正面硬剛
Redmi這邊剛如火如荼的宣傳了K60 Ultra的各種技術和硬件配置，作為競品的一加也坐不住了。一加中國區總裁李杰發布了兩條微博，表示在自家的一加Ace2上早就已經采用了和PixelWo
今天這篇文章將給大家分享，也可以借此學習社區的運作模式。
在官方資料《Proposing Changes to Go》中，給出了一系列的提案指導意見、流程規劃以及目標。
Go 語言項目，開發過程以設計為驅動。
有以下的要求：在實施重要的語言、庫或工具更改（包括 Go 主倉庫和所有 golang.org/x 倉庫中的 API 更改，以及 go 命令的命令行更改）之前，必須首先進行討論，有時還需要正式文檔化。
提案（proposal）過程指的是對提案進行審查并決定是否接受或拒絕提案的過程。
整個提案的流程是使用 GitHub 中的 Label（標簽）來做流程規范的，在此也可以稱其為分類的欄目。
第一步，提案作者需要創建一個簡要的問題描述提案。一般對應提 issues 時的對應分類：
圖片
而對應的不同的分類，會給出不同的 issues 模板：
圖片
基本上要滿足社區所要求的模板才會有核心團隊的人交流，否則一開口就會讓你去補充內容。
此時是不需要設計文檔的。
第二步，需要對提案進行問題討論和標簽分類、跟蹤。一般會將提案分為以下三種結果之一：
如果提案被接受或拒絕，則這一項完成。否則，預計需要基于更詳細的設計進行進一步的問題討論。
第三步，提案作者編寫和提供設計文檔，以詳細說明提議的設計并解決初始討論中提出的問題。也就是提出提案者需要給出設計解決自己提出的問題。
完成第三步后，社區會結合設計文檔和問題進行討論，需要提案作者進行及時的修訂。再進行多輪討論。
最終確定提案的走向，兩種結果之一：
在提案被接受或拒絕后，下一步的實施工作將按照常規的貢獻代碼的方式進行。
Go 核心團隊大約每周召開一次 proposal review meetings（提案審查會議），審查和討論待決定的提案。
這個會議會就已達成共識的提案，將流程推進到下一步（通過標記提案已被接受或拒絕，或要求提供設計文檔）。
每周會議結束后，會議記錄會發布到 golang.org/s/proposal-minutes[1]，任何對哪些提案正在審議的小伙伴都可以關注這個 issues。
圖片
新提案會被添加到 "Incoming" 這一欄。
每周的提案審查會議會優先審查 "活動"、"可能接受 "和 "可能拒絕" 欄中的所有問題。
如果還有剩余時間，則會選擇將 "Incoming" 中的提案移至 "活躍" 欄。
圖片
Incoming 欄中的提案被相關成員識別、討論后，很快就會轉挪動到 Proposal 欄下。但由于官方文檔未有提及，因此主要做此補充說明。
圖片
在每周的提案會議上，都會對 "活躍" 欄中的問題進行審查，以觀察討論中是否出現了共識。
提案審查小組還可以發表評論、提出建議、提出澄清性問題，并嘗試重述提案，以確保每個人都同意討論的具體內容。
圖片
如果議題討論似乎已達成接受提案的共識，提案審查小組會將該議題移至 "可能接受" 欄，并張貼評論，指出這一變化。
圖片
再繼續等待一段時間，一般可能是數周。觀察后續的新的討論情況和內容。再繼續推進下一步流程。
如果提案討論似乎已達成拒絕提案的共識，提案審查組就會將該問題移至 "可能拒絕 "欄。
如果提案審查小組認為不可能達成一致意見，因此默認不接受該提案是合適的，則也可將該提案移至 "可能否決 "欄。
等待時間和動作與 “可能接受” 會是一樣的。
提案轉到 "可能接受" 欄一周后，如果共識沒有改變，提案審查小組就會將提案轉到 "已接受" 一欄。
如果在這一周內進行了大量討論，提案審查小組可能會將提案在 "可能接受" 欄中再保留一周，甚至將提案移回 "活躍" 欄。
一旦提案被標記為 "已接受"，就會貼上 "提案-已接受" 標簽，它就會從 "提案" 里程碑移到 "工作" 里程碑中，問題也會被重新使用，以跟蹤提案的實施工作。
圖片
在提案轉為 "可能已被否決" 一周后，如果共識沒有改變，提案審查小組會將提案轉到 "已被否決" 一欄。
如果在這一周內進行了重要討論，提案審查小組可能會將提案在 "可能拒絕 "欄中再保留一周，甚至將提案移回 "激活" 欄。一旦提案被標記為 "拒絕"，該提案即被關閉。
圖片
否決還會分為四種情況，處理流程類似，分別歸類為：
如果討論提案需要修改設計或補充信息，而這些信息在幾周或更長時間內都無法獲得，提案審查小組就會將提案移到 "擱置" 欄，并注明等待的內容。
圖片
一旦準備就緒，任何可以編輯問題跟蹤器的人都可以將提案移回 "激活 "欄，以便在下一次提案審核會議上進行審議。
圖片
Go 提案的整體流程規范是比較明確的，但其并不是每個標簽（欄）都一定會用到。從實際的情況來看，會根據 issues 討論的激烈和復雜度還決定是否使用 “可能接受/可能拒絕” 等場景。
我們在官方提案文檔上也會有提到提案的討論一定是能得到適當、公平、及時、有記錄的評估，能得到明確的答復。且要求在 “proposal review meetings” 上審查和記錄。
圖片
同時會發現，這套流程打標簽挪欄目的動作，非常依賴人的行為。大部分的行為都相當的主觀。
結合上次的已接受、已合并提案被 rsc 突然一句話撤銷來看，規范也僅僅是規范。話事人的行徑一旦有所缺失（例如：離職、生病等），這套流程就很有可能會跑不通了。
本文鏈接：http://www.www897cc.com/showinfo-26-15719-0.html給 Go 提問題？充分了解 Go 提案流程
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 語雀停機事件后，你也在找替代方案嗎？
下一篇： 作為前端開發者，你沒有必要學 Rust
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號