社群流程
這個頁面的目的是讓 Play Framework 中的決策過程變得透明。這不是管理 Play 專案的一組法律,這份文件中的內容也不是新的,它只是承認現有的流程,並記錄其內容。
此頁面的目標是透過執行下列事項來增加社群貢獻和對 Play 專案的所有權意識
- 對 Play 社群的新手來說,清楚且透明地說明決策是如何做出的、誰做出這些決策,以及新手如何獲得任何決策制定權責。
- 提供 Play 中決策制定流程的具體定義,以便在需要時可以參考和改進。
專案所有權
Play 專案原始碼已取得 Apache 2 授權。專案的產品決策和技術決策由指導委員會最終決定。
儘管指導委員會對任何決策都有最終決定權,但 Play 社群(超過 400 位核心 Play 社群貢獻者,以及數百位更廣泛的 Play 生態系貢獻者)的重要性無庸置疑,甚至可能比 Play 專案本身更重要。
因此,指導委員會與 Play 專案的關係最適合描述為管理,指導委員會管理 Play 專案,但須對 Play 社群負責。
有關指導委員會的更多詳細資訊,請參閱 贊助商頁面。
定義
貢獻者
貢獻者是指對 Play 做出貢獻的任何人。這不一定是程式碼貢獻,它可能表示下列任何一項
- 程式碼修正、改進和新功能
- 文件修正、改進和新功能
- 將文件翻譯成其他語言
- 為 Play 編寫或維護外掛程式、模組或函式庫
- 在 GitHub 中進行程式碼審查
- 提出、分類並新增其他資訊,以協助解決問題
- 在討論論壇中參與設計和功能討論
- 在討論論壇和 Stack Overflow 中回答問題
- 執行、演講或貢獻專注於 Play Framework 的使用者群組
- 在研討會中演講、撰寫部落格文章或以其他方式推廣 Play Framework
整合者
整合人員是指擁有 Play 專案或 playframework GitHub 組織中專案的原始程式碼和文件寫入權限的任何人。所有整合人員的最新清單可以在 程式碼和貢獻者 頁面中找到。
請注意,您不必成為整合人員才能為 Play 做出貢獻,而且事實上,在被認為是貢獻的事項清單中,沒有任何事情是整合人員才能做而貢獻者不能做的。實際上,整合人員可以做而貢獻者不能做的唯一事情是管理類型的工作,例如合併其他貢獻者的貢獻,以及問題追蹤器中的內部管理工作,例如關閉已修正或無效的問題。
決策制定
Play 專案中的決策可分為兩大類別
- 實作決策,包括拉取請求是否達到合併標準,以及功能或改進應如何實作。
- 設計和內部管理決策,也就是其他所有事項。這包括重大的設計決策、路線圖、版本時程、關於專案應如何執行和管理的決策、應使用哪些工具等。
實作決策
實作決策主要發生在拉取請求中。它們是由拉取請求本身發起,並透過審查和反覆運算,形成關於應如何實作特定變更的共識。
鼓勵所有有興趣的相關人員參與審查拉取請求,並對審查討論做出貢獻。
拉取請求是否合併所需的共識量取決於拉取請求的影響程度。對於微不足道的變更,例如文件修正,整合人員可能會在未獲得任何其他整合人員回饋的情況下直接合併它。對於較大的變更,至少應由一位熟悉正在修改的程式碼部分的人員審查,最好是更多人。對於大型重構,拉取請求應在合併之前由至少 2 或 3 位其他整合人員審查。
拉取請求是否合併取決於許多因素,包括
- 適當的測試範圍和文件,在必要時
- 遵守編碼標準和其他程式碼品質因素
- 遵守 Play 的一般架構準則,例如 Java 和 Scala API 之間的功能同等性
- 遵守外部規範,例如 RFC
- 與 Play 專案的方向和哲學一致
設計和家務決策
討論 Play 設計和 Play 專案執行方式的主要場所是 Play Framework 論壇。所有主要的全新功能、重構或專案變更都應首先在此論壇中討論。討論的目的是達成共識,了解是否會執行任務,以及如何執行。當張貼新主題時,鼓勵有興趣的參與者發表評論,表達他們的肯定或疑慮。
雖然指導委員會最終對所有決策擁有最終決定權,但我們將盡可能努力在社群中達成共識。
整合器選擇
整合器選擇由指導委員會執行。指導委員會將根據以下標準提供貢獻者整合器狀態
- 貢獻者對 Play 做出重大貢獻。什麼構成重大貢獻是主觀的,但例如,最近的新整合器每週會檢閱 3 個以上的 pull request,每週提出一個以上的 pull request,以及每週分類 3 個以上的議題。
- 貢獻者是 Play 的 行為準則 和 貢獻者指南 的典範。
- 貢獻者受到 Play 社群其他成員的尊重。
- 貢獻者同意指導委員會為整合器設定的以下規則。
如果整合器停止定期為 Play 做出貢獻,可能會移除其寫入存取權,但仍會保留其在 Play GitHub 組織中的會員資格。
整合器規則
所有整合器都應遵循此頁面中概述的流程,並應成為 Play 的行為準則和貢獻者指南的追隨範例。以下也概述了一些特定規則
- 整合器絕不能直接推送到 GitHub 組織中的儲存庫。所有貢獻,無論大小,都必須透過 pull request 進行。唯一的例外是回溯變更,以及從發布版本中產生的變更。
- 通常,pull request 應從整合器的個人 fork 進行,而不是從推送到 playframework GitHub 組織中儲存庫的分支進行。
- 整合器絕不能合併自己的 pull request。所有 pull request 都必須由另一位整合器審查並合併。
- 文件變更可以依需要在版本之間回溯,但所有其他變更都必須經由指導委員會核准。
- 在關閉問題或 pull request 時,請記住我們正在與人打交道。請保持友善和樂於助人,指引人們正確的方向。例如,如果有人提出一個實際上是問題的問題,請在關閉問題時,將他們導向Play Framework 論壇,並在可能的情況下簡要回答問題。