為 Foundation 貢獻程式碼

術語

• 社群是指在議題上發表評論或開啟拉取要求的任何人。這包括您！
• Yetinaut 是 Foundation 的核心團隊，擁有儲存庫的寫入權限。

我們的一群精選貢獻者被稱為Yetinauts。他們有權直接寫入程式碼庫，並在基金會團隊中負責架構的開發。您有興趣在基金會架構中留下自己的印記嗎？不論您只是提交錯誤報告或協助我們撰寫新功能，都有許多方法可以為基金會做出貢獻。

修正您的小抱怨

如果您想修正基金會或任何基金會支援生態系統中的某個部分，有很多機會可以參與。為了讓您更容易上手，我們在 GitHub 上建立了一個「徵求協助」標籤。

找出我們已標示為適合新貢獻者的錯誤。

基金會有許多面向，這讓具備不同技能組的人都有機會參與。為了讓您更容易上手，我們在 GitHub 上建立了一個「徵求協助」標籤。我們使用標籤來標示問題是錯誤、功能或各項問題的難度等級。

下表說明我們在 GitHub 上使用的標籤

類型 標籤	說明
	這些是現有元件的強化或新功能的提案。新功能令人興奮且開發起來很有趣，而且可以改善基金會的可用性或效能。
	文件或基本的 HTML/CSS 問題，是入門的好地方。
	您的技能正在提升，您已準備好更進一步。這些問題包括 Sass 問題除錯、新增或變更 Sass 變數，以及輕微的 JS 錯誤修正。
	您可能正在尋找挑戰。這些問題非常適合有能力成為英雄並克服挑戰的人。這可能包括進階的 Sass 修正或強化、Gulp 或 ZURB Stack 中的工作流程更新，以及更棘手的 JS 錯誤修正。

別擔心 - 如果您不確定如何處理特定問題，請在問題中詢問我們，我們將會指導您。

找出可以處理的事項

如果您有興趣為基金會做出錯誤修正以外的貢獻，以下是我們希望看到完成的事項清單，以擴大基金會網站的觸及範圍或讓它更容易使用。

架構元件徵求協助

• 排版：垂直節奏
• 鑽取：動態高度
• 標籤：深度連結
• 標籤：雜湊支援
• 媒體查詢：方向檢查
• 固定：處理短頁面
• 固定：定義開始固定的時機
• 下拉式選單：微調對齊
• 下拉式選單：垂直節奏
• 下拉式選單：防止自動調整大小
• 揭露：返回按鈕
• 交換：頻寬偵測

為 Foundation 生態系統做出貢獻。

如果您撰寫或移植了套件、外掛程式、工具、Yeoman Generators 等，且您認為其他人也會受益，請考慮將其發布到社群。如果您發布一個許多人覺得有價值的套件，您將能獲得網際網路的集體讚賞。部落格文章、學習資源、翻譯和開源程式碼也十分歡迎；您可以透過使用 @zurbfoundation 發推文或在 Foundation 論壇發文來獲得回饋並分享您的作品。

願望清單

如果您有興趣為 Foundation 做出更多貢獻，除了修正錯誤之外，我們整理了一份清單，列出我們希望看到完成的工作，以擴展 Foundation for Sites 的使用範圍，或讓它更容易使用。

以下是我們非常希望在 Foundation 生態系統中看到的特色。此清單沒有優先順序。我們非常歡迎實作這些事項的貢獻。

• UMD 支援
• Joyride 作為獨立的外掛程式
• Clearing 作為獨立的外掛程式
• ZURB Stack 的 Yeoman 產生器
• Visual Studio 範本
• Foundation 的 Polymer 元件
• Foundation 外掛程式的 Angular 2 版本
• 從 Bootstrap 指南移轉

您可以在 GitHub 上找到 Foundation for Sites 路線圖。

隨時歡迎提交請求

最常見的程式碼貢獻是提交 GitHub 上的提交請求。您只需要一個 GitHub 帳戶！如果您在您的專案中解決了一個問題，請與其他人分享！

如何提交提交請求

Foundation 是數千個（數萬個）漸進式改善的成果。沒有我們的許多貢獻者的投入，它不會成為現在的產品。雖然貢獻可以改善任何開源產品，但有些變更比其他變更更有幫助。以下是如何對開源產品做出成功的貢獻或提交請求，並成為偉大的一部分。

我們透過 GitHub 接受程式碼調整和一般想法。此版本控制服務讓我們可以追蹤對 Foundation 的變更（我們執行的任何專案），以防止許多開發人員意外覆寫彼此的工作。

什麼是提交請求？

拉取請求是您對專案的副本（而非原始專案）所做的變更。進行變更後，您可以提交變更供專案所有者審查。如果您的變更獲得核准，專案所有者將會將其「合併」到專案本身。

該核准程序至關重要。當您對 Git 儲存庫進行變更時，拉取請求會告訴人們您執行了什麼動作以及何時執行。拉取請求並非「老大哥」情況，它能協助所有人了解在特定時間點發生了什麼事，進而發現「啊哈，昨天的變更影響了我現在嘗試執行的動作。」

有 許多 有關拉取請求技術層面的 指南。接下來，我們將討論如何撰寫一篇好的拉取請求。

進行變更

以 Foundation 為例，進行拉取請求的程序為

1. 從 GitHub 分岔 Foundation 的副本。

「分岔」是將專案複製到您的 GitHub 帳戶中。如果您有多個帳戶，系統會詢問您要使用哪個帳戶。就我們的目的而言，您的個人帳戶即可。如果您不小心將專案分岔到錯誤的帳戶，或稍後想要移除它，請別擔心。刪除分岔不會損害原始專案。

您需要 Foundation 的分岔副本
• Foundation for Sites
• Foundation for Emails

2. 克隆分岔。

這是「將副本下載到您的電腦」的時髦說法。雖然您可以直接在 GitHub 中變更檔案，但通常使用您最愛的程式碼編輯器進行變更會比較容易。

3. 對已克隆的副本進行變更。

我們建議每次提交只進行一項變更，亦即，每個變更只有一個描述性摘要。我們將在稍後介紹這一點。

最好為您的變更或修正建立一個分支。每個問題或功能使用一個分支。提交您的變更，將其推回儲存庫以供審查。（如需有關設定 Git 的更多資訊，請查看官方說明。)

提升您的機會：如何撰寫一篇很棒的 PR

當您向專案提交拉取請求時，它必須詳盡且具描述性，但又不能過於繁瑣。您需要描述您的意圖以及您的程式碼變更。這並不總是容易做到的。

一個好的標題很重要。

標題需要描述正在更新的元件以及變更的內容。由於是標題，因此不需在此寫成小說。重點是，描述得夠清楚，讓任何讀到標題的人都能對發生的事情有初步了解。

良好	「垂直置中左右下拉箭頭」
良好	「將按鈕變更為開啟新的模式視窗，讓使用者保持在同一頁面。」
良好	「讓標籤的 active 類別名稱可設定。」
良好	「新增 (flex-)grid-row 大小修改器」
不佳	「焦點狀態和輸入轉場」
不佳	「連結說明。」
不佳	「修正 #8409」

參照公開議題

如果有一個公開議題與您提交的 Pull Request 直接相關，您應該參照它。這可以在 Pull Request 的標題或說明中完成。這有助於釐清您要解決的目的或使用案例，並會加快它的接受速度。

議題會分配一個號碼給它們。如果您貼上相關議題或號碼的連結，GitHub 會將兩者連結在一起。這不僅可以加強您的說明，還可以自動關閉您參照的議題並在上面發布更新。

下列關鍵字會在您的 pull request 中透過參照關閉議題
• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

範例

如果可能，請包含範例。

一行實際的程式碼勝過十行說明。或多或少。

說明如何重現問題。

能夠分解問題並測試解決方案對於在不讓問題惡化的情況下修復問題至關重要。

說明問題存在的位置。

在 Foundation 的情況下，這表示命名有問題的元件。

不要提交許多只有一個說明的檔案。

在單一 pull request 中，包含變更的數十個檔案難以解讀（和說明）。

每個請求應相對較小且專注。最好在多個 Pull Request 中處理具體變更，而不是一個涵蓋許多不同組件的大變更。這樣，如果專案的所有者必須撤銷變更（一個稱為「回滾」的程序），他們不必完全清除您所做的每個變更。

有用的 PR 範例

以下是我們儲存庫中顯示如何處理和關閉問題的一些問題

• 新增靜態網格間距 #8508
• 修正迴圈錯誤
• 修正：取消合併時彈性網格嵌套列的邊距
• 清除滑塊邏輯並修正頂端錯誤
• v6.2.2 修正僅需要一個無線電按鈕時遵守無線電檢查

程式碼標準

好的 PR 是遵循我們的程式碼標準的 PR。我們希望程式碼庫使用一致的命名、類別結構和語法。

您可以在我們的 GitHub 上的程式碼標準儲存庫 中找到 Foundation 的程式碼標準。

當我提交 Pull Request 時會發生什麼事？

太棒了！簡單來說，當您向 Foundation 提交 PR 時，團隊成員將審查變更，如果有效，則將其合併到主分支中。

合併 pull request 需要測試。Foundation 核心團隊或 Yetinaut 的成員將測試組件以確保 Pull Request 解決問題，並確保沒有回歸。這就是為什麼描述重現錯誤的步驟至關重要的原因。

幫助 Pull Request 更快合併的方法之一是協助測試它們。特別是如果您在專案中遇到相同的挑戰，查看 Pull Request 以確認它修復了問題，這真的有助於合併 Pull Request。

Foundation 核心團隊或 Yetinaut 的成員可能會提出問題、提供回饋或拒絕 pull request 並說明理由。Foundation 非常歡迎 Pull Request，因此您可能會看到建議或指導，以修改您的 Pull Request 以便準備合併。

一旦您的 Pull Request 合併，GitHub 將會通知您。恭喜，您剛剛幫助了數千人並為開放原始碼做出了貢獻！我們一定會大聲讚揚，因為您太棒了！

分支很重要：瞭解 Foundation 的專案結構。

Foundation 使用特定的工作流程來管理程式碼更新。這決定了 Pull Request 和程式碼更新應該去哪裡。它有助於確保更新的程式碼在一個地方進行測試以進行增量版本發布，同時為新功能提供一個地方。

開發

這是 Foundation 的預設分支，也是消除錯誤的地方。這也是 github 將「預設」鎖定 PR 的地方。對於每個次要版本，都會測試 Develop 分支，然後合併到 Master。所有錯誤修正都應導向 Develop 分支。

主幹

從此處部署（設定為公開）程式碼更新的主要分支。不影響 Foundation 程式碼的文件更新應指向主幹分支。

v6.3

這是 Foundation 的下一個主要版本。所有新功能、新元件和增強功能應導向到下一個主要版本分支（目前為 Foundation for Sites 的 v6.3 和 Emails 的 v2.3）

回報問題

發現已確認的錯誤？針對您對架構的任何問題開啟一個問題。如果您的問題缺少任何內容，例如額外的背景、程式碼範例等，團隊成員會在留言中要求提供更多資訊。

將其記錄在 GitHub 上，以便有人有機會修復它。如果您在論壇上看到一個有解決方案的問題，請留言並將它們連結在一起。這肯定會隨著時間幫助到數千人。

您也可以從文件頁面本身記錄問題或修改文件。

• 編輯此頁面： 在 GitHub 中開啟頁面，讓您可以編輯文件頁面。當您提交變更時，它會在主幹分支上建立一個 Pull Request。
• 回報錯誤： 帶您前往 GitHub 中的問題建立。

支援請求通常更適合 Foundation 論壇，而 GitHub 更適合回報錯誤。如果您不確定您的問題是否為錯誤，別擔心！在 GitHub 上發布您的問題，團隊將會協助您。預期每位參與者都應遵循專案的 行為規範，因此請保持禮貌和尊重。