【React Native】文件翻譯閱讀紀錄 - 貢獻 - 維護人員可以期待什麼

by - 上午9:00

Facebook Open Source React Native


維護人員可以期待什麼

因此,您已閱讀撰稿人指南,並準備發送您的第一個拉取請求。也許你在React Native中發現了一個問題,並希望與維護人員一起解決問題。以下是您在打開問題或發送拉取請求時可能發生的情況。

以下內容改編自GitHub的優秀開源指南,反映瞭如何鼓勵React Native的維護者處理您的貢獻。

處理問題

我們每天都會看到幾十個新問題。為了幫助維護人員專注於可操作的內容,維護人員要求貢獻者在打開新問題之前做一些工作:
  • 新問題應遵循問題模板。
  • 問題應提供清晰,易於遵循的步驟以及示例代碼以重現問題。理想情況下,提供
  •  Snack.
以立即關閉不符合上述標準的問題,並鏈接到 contributor's guide.

新問題Runbook

您已收集了打開新問題所需的所有信息,並且您確信它符合貢獻者指南。一旦發布問題,這就是我們的維護者在決定如何繼續前進時會考慮的問題:
  • 此問題是功能請求嗎?
    某些功能可能不適合核心React Native庫。這通常是Facebook在生產中不使用的*新模塊的情況。在這種情況下,維護者會解釋這應該作為一個單獨的模塊發佈到npm,允許用戶輕鬆地在他們的項目中拉入模塊。

    即使該功能確實屬於核心庫,添加它也意味著維護它。維護者會鼓勵您提交拉取請求或以其他方式將您的請求發布給Canny。

    可以對提案和長期討論進行例外處理,但這些應該很少見。如果您已經為項目做出了足夠長的貢獻,那麼您可能已經可以訪問React Native Core Contributors Facebook Group,通常會進行此類討論。
  • 這個問題是請求幫助嗎?
    絕對應該在Stack Overflow而不是GitHub上提出問題。在關閉問題之前,維護者應該鼓勵貢獻者詢問Stack Overflow。隨意回答Stack Overflow上的一些問題,你會得到代表!
  • 問題模板是否用於填寫問題?作者是否對頂部的兩個問題都回答了“是”?
    如果沒有,維護者會要求您通過填寫問題模板提供更多信息,然後他們將關閉該問題。
  • 該問題是否與現有的未解決問題重複?
    維護者將添加註釋,#123的副本,這將把問題標記為問題#123的副本。然後他們將結束這個問題。
  • 問題是否包含Snack或重現問題的步驟列表?
    問題應該相對容易重現。有時問題會影響特定的應用程序,但是沒有提供最小的repro,也許在日誌中看到崩潰,作者不確定它的來源,也許問題是零星的。

    碰巧的是,如果維護者不能輕易地重現問題,那麼就無法合理地期望他們能夠解決問題。維護者會告訴您這種情況,您的問題將被關閉。

    如果多個人似乎受到該問題的影響,則可以例外,尤其是在切換新的React Native版本之後。
  • 是舊版React Native的問題嗎?
    如果是這樣,期望被問及是否可以在最新的候選版本中復制該問題。
  • 問題可以可靠地再現嗎?
    可能會關閉僅在特定項目上發生但未提供最小重現的暫時性問題或問題。
  • 問題需要更多信息嗎?
    有些問題需要額外的信息才能重現。在添加“需要更多信息”標籤後,維護人員應解釋需要哪些其他信息。

    可以關閉在沒有作者回复的情況下打開超過一周的“需要更多信息”標籤的問題。
  • 問題已在評論中得到解決嗎?
    有時,另一位撰稿人已在評論中提供了解決方案。在這種情況下,維護人員可以解決問題。
重新打開已結束的問題:有時需要重新打開問題。例如,如果一個問題被關閉等待作者,那麼作者回复並且事實證明這確實是一個錯誤,維護者可以重新打開該問題。
有效的錯誤報告和良好的重複步驟是一些最好的問題!維護者應該感謝作者找到問題,然後解釋React Native是一個社區項目並詢問他們是否願意發送修復程序。

分類問題

如果在完成上述所有檢查後問題仍然存在,它將繼續進入分類階段。然後維護者將執行以下操作:
  1. 添加相關標籤。
  2. 發表評論說該問題已被分類。
  3. 標記相關人員。
您通常可以通過查看CODEOWNERS文件來確定誰可能與給定問題相關。

陳舊的問題

“需要更多信息”狀態中的問題可能會在一周後關閉,而作者沒有後續跟進。過去兩個月沒有活動的問題可能會定期結束。如果你的問題以這種方式結束,那就不是個人的了。如果您堅信問題應該保持開放,請告訴我們原因。

簡單地評論一下該問題仍然存在並不是非常引人注目(對於關鍵的,發布阻止問題而言,兩個月內沒有活動的情況很少見!)。為了重新解決問題,您可能需要做一些工作:
  • 問題可以在最新的候選版本上複製嗎?使用您測試的版本發表評論。
  • 如果是這樣,錯誤報告中是否缺少任何信息?發布評論,其中包含問題模板所需的所有信息。
  • 是否存在解決此問題的拉取請求?發布PR編號的評論,以便我們跟進。
一些好的案例的貢獻者可能只是重新打開這個問題所需要的。

處理拉取請求

核心團隊將監控拉取請求。當我們得到一個時,我們將首先在它上面運行一些特定於Facebook的集成測試。從這裡開始,我們需要讓另一個人簽署更改,然後合併拉取請求。對於API更改,我們可能需要修復內部使用,這可能會導致一些延遲。我們將盡最大努力在整個過程中提供更新和反饋。

我們如何確定拉取請求的優先級

我們使用Contributors Chrome擴展程序來幫助我們了解發送拉取請求的人員。具有合併PR歷史的貢獻者打開的拉取請求更有可能首先被查看。除此之外,我們嘗試按時間順序完成拉取請求。

我們如何審核拉取請求

檢查PR有時需要維護人員花費更多時間來編寫代碼。維護者需要考慮將補丁導入代碼庫的所有後果。它是否可能引入重大變化?添加新依賴項的性能考慮因素是什麼?文檔是否也需要更新?這屬於核心,還是更適合作為第三方軟件包?
打開拉取請求後,您可以期待維護人員查看它:
  • 拉取請求是否缺少信息?
    需要測試計劃!添加標籤'需要修訂版'和'需要作者回复'。然後,您可以跟進如下響應:
    嘿@author,感謝發送拉取請求。您能否添加模板中指定的所有信息?這對於人們能夠理解和審查您的拉取請求是必要的。
  • 代碼樣式是否與樣式指南相匹配?
    如果沒有,請鏈接到樣式指南並添加標籤“需要修訂”。
  • pull請求是否添加了一個我們不想添加到核心並維護的全新功能?
    請作者將其單獨的npm模塊發布並關閉拉取請求。
  • pull請求是否同時執行多個不相關的操作?
    請作者分開。
  • 拉請求是否舊,需要變基?
    問作者“你能 rebase 嗎?”並添加標籤'需要來自作者的回复'。
  • 是拉請求等待作者的回复嗎?
    像這樣的拉取請求通常都有“需要作者回應”的標籤。如果在過去30天內沒有回复,請通過以下回復關閉它:
    感謝您提出拉取請求,但由於不活動,我們正在關閉它。如果您想要合併您的建議更改,請使用master重新分支您的分支並發送新的pull請求。
  • 拉請求是否舊並等待審核?
    查看或抄送可能能夠審核的人。找到合適的人來審查拉取請求有時候會很棘手。拉取請求可以同時觸摸iOS,Java和JavaScript代碼。如果拉取請求等待審核一段時間,您可以通過查看您正在觸摸的文件的責備歷史記錄來提供幫助。有沒有人在PR觸及的代碼庫中看起來知識淵博?

關閉拉動請求

有時維護者可能會決定不接受拉取請求。也許拉取請求超出了項目的範圍,或者想法很好,但實施很差。無論什麼原因,當關閉拉取請求時,維護者應該保持對話友好:
  • 感謝他們的貢獻。
  • 解釋為什麼它不適合項目的範圍。
  • 如果您有相關文檔,請鏈接到相關文檔。
  • 關閉請求。

消除情況

有時當維護者對拉取請求說不,或者關閉問題時,貢獻者可能會感到不安並批評您的決定。 維護者將採取措施化解局勢。

如果貢獻者變得敵對或不尊重,他們將被提及行為準則。 將阻止負面用戶,並刪除不當評論。

Facebook GitHub Bot

Facebook GitHub Bot 用於允許社區成員執行管理操作,例如標記和關閉問題。 機器人不再是必需的,因為維護者將被授予管理問題的必要權限。 如果您有興趣維護回購,請聯繫GitHub上的HéctorRamos(@hramos)。



You May Also Like

0 意見