大家好，我是皮丘。
今天要和大家介紹的是一個開始二十幾天，累計了兩百多個貢獻者以及八千多個 Commit
的開源專案。
因為我是從半路才加入這個專案的，所以可能有些人更知道整件事情的全貌，
如果是這樣的話再請幫忙指正一下，感謝。
想要介紹這個專案主要是這個專案可以說是某種程度上的「奇蹟」
GitHub 上面星數多的專案不少，但是貢獻者到三位數的專案就真的不多了，
尤其是不到一個月衝到兩百多的更少。
今天如果是公家機關開放了一組 API, 例如藥局資訊，其實有做足宣傳的話大致上可以
看到不少專案，
可是大多數的專案常常會像是大學專題一樣，變成少數幾個人有在做，其他人可能不確
定應該要如何進行。
或者是工程師一多意見就容易分歧，那麼要成功組成這麼大的團隊那就更困難了。
如果說可以從這個專案中學習到什麼經驗的話，將來要進行專案開發或者是跨國的開發
時應該可以提昇不少來自台灣資訊界的能量。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
首先，我會跳進來這個坑一開始是從不知道哪裡來的 Google Sheet 翻譯表開始的。
到底是哪裡來的我真的忘記了，注意到的時候已經是改掉了不少明顯是直接簡轉繁的翻譯，
後來點到 Contributors 看到上面一排 #TaiwanCanHelp 之後我就把自己的名字放上去，
然後繼續把後面的翻譯都翻完了這樣。
剛開始我的主要貢獻是這樣，在混亂的 Google Sheet 裡面把新的日文字串翻譯成繁體中
文，然後幫忙檢查其他人的翻譯有沒有不對的地方，真的要說有什麼需要專業的部分大概
是知道要把 Placeholder 保持原樣
像是 {advisory}による相談結果 這樣的東西 {advisory} 要保持半形全形一模一樣這樣。
後來因為來自台灣 (大多數應該是g0v) 的人其實不少，大概有17名，所以很快就翻完了，
因此我就到 GitHub 上面的 Issue 列表看有沒有可以幫忙送 Pull Request 的項目。
Pull Request: 簡稱PR, 意思是把修改好的程式碼推回原本的倉庫，
讓專案擁有者合併進來。
當時是找到了一個把 PageHeader 裡面寫死的日文文字改成 i18n 的格式的 issue
Issue: 問題，可以說是Bug, 或者是Feature
他需要做的事情有兩件事
1. 找到沒有被 {{ $t(` `) }} 圍繞的字串，把他用這東西圍繞起來
2. 在下面新增 <i18n></i18n> 方塊，然後把 Google Sheet 的翻譯結果轉換成 JSON 貼上去。
基本上同類型的修改很多，所以依樣畫葫蘆就行了，我自己是把它 clone 下來之後修改
好再推上去，基本上是用命令列的模式（習慣）不過其實也有不少貢獻者是直接使用
GitHub 的網頁介面進行的。
在參加這個專案以前，其實沒有受過什麼發送 PR 相關的專業訓練 (應該沒有哪所學校
或是公司會特別教這個的吧？)
所以改好之後就像是以前推去其他開源專案類似的做法，直接就按 New pull request
下去了
按下去之後因為他有設定 .github/PULL_REQUEST_TEMPLATE.md 的緣故，所以會看到類似
這樣的畫面：
我個人認為這樣其實有助於減少混亂，等於是修改大方向的東西是在 Issue 討論，
程式碼層面的東西是在 PR 討論這樣。
總之，我就把原本關聯的 Issue 號碼填上去後就去休息了，然後沒多久負責 i18n 的
MaySoMusician 就通知我說
Thank you for your contribution!
Unfortunately we have already a pull request #718, that solves #689
感謝您的貢獻
不幸的是我們已經有解決掉 #689 的 PR #718 了
QQ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
因為以前遇過的開源專案通常是人數不多的專案，然後幫忙解掉 Warning 或者是讓他
可以在某個平台上編譯。
這種可能幾個禮拜才會出現一次 PR 的，沒想到居然有這種發 PR 結果已經被解掉的事故
發生。
於是我只好去看一下這個專案本身有沒有什麼機制在避免這類型的問題
（終於打算認真看說明了）
大多數的專案像是 CODE_OF_CONDUCT.md 之類的文件通常都是用抄的，就是有份公版然後
複製貼上這樣。
不過這個專案的 CODE_OF_CONDUCT.md 的內容看起來是有些修改，所以我就很認真的把
他們都讀完了，
順便還做了翻譯，開個 issue, 送個 PR 這樣。
翻譯過後的檔案有興趣的話在這邊：
https://github.com/tokyo-metropolitan-gov/covid19/tree/development/docs/zh_TW
比較重要值得大家參考的部分是在 CONTRIBUTING.md 這份
這邊列出幾個重點
1. PR 一定要有對應的 issue
2. 發 issue 之前避免重覆，要先搜尋
3. 因為是掛東京都的名字，所以有些東西要改很麻煩，不一定能改，這時候就會被
掛上 waiting 標籤 (目前是 need-official-confirmation )
通常問題 (issue) 的生命週期如下
1. 如果有問題的話，例如有字體使用的不好，或是顏色有問題之類的都可以開 issue
2. 通常開的人通常看起來都像是有口袋解法了
舉例來說像是這個 UI 爆掉的案例
https://github.com/tokyo-metropolitan-gov/covid19/issues/2305
https://user-images.githubusercontent.com/12812934/77534530-2cb2d780-6edc-11ea-98c6-e64ea0381164.png
https://user-images.githubusercontent.com/12812934/77534558-3a685d00-6edc-11ea-961d-590ce3e5ee60.png
大致上已經有修改方向了，所以通常提出來之後提的人自己就會另外做一個 PR 指到這個 issue 上把它解掉。
或者是像是這個我這邊提的Issue
https://github.com/tokyo-metropolitan-gov/covid19/issues/1718
其他人如果有興趣觧的話也可以直接認領然後把它解掉
3. 在解 issue 的時候基本上都是從 development 分出來，然後改好再發 PR 放回去
4. 發 PR 之後基本上專案已經有設定好 CI/CD 了，所以大致上需要其他人幫忙 Code Review 之後就可以等專案擁有者進行合併
5. 合併完成之後假如沒有其他問題就可以 Close 掉這個 issue 了
以上算是比較簡單的 Issue, 像是這種我認為比較算是熟悉參與開源專案的節奏，例如幫忙做 Code Review, 回應 LGTM 等等。
那也有一些是比較複雜的 Issue
以這個修改圖表對比色的案例為例
原本的圖表顏色是這樣：
https://user-images.githubusercontent.com/1301149/76443440-bf944200-6405-11ea-855b-07aa4d90023b.png
經過可用性的專家們討論出來的建議是這樣
https://user-images.githubusercontent.com/1301149/76443450-c458f600-6405-11ea-8ff3-4695683d1201.png
原意是希望表達東京都的「動態、繁榮、滋潤、和平」所以不希望因為可用性來修改原始設計
然後可想而知的就被罵翻了...
像是這種 issue 就是在做開源專案時可以多學到的東西，因為原本公司可能沒有這類型
的人才。
如果本身沒有可用性設計思維的人，免試的時候根本很難面進有可用性設計思維的人。
順帶一提，後續的討論在此：
https://github.com/tokyo-metropolitan-gov/covid19/issues/2364
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
大致上是這樣，然後再來是介紹一下目前這個專案的最新概況
因為某天我們觸發了 Google Sheet 同時最多寫入上限，因此目前要從 Google Sheet
入門這個專案應該是有點難了。
Google Sheet 人數上限被觸發後翻譯的工作就移動到了 Transifex 上面。
然後除了東京都以外，在日本其他地區的團體
（類似 g0v 這樣，通常會以 Code for <地名> 的形式）開始了各地的版本。
其中北海道版應該是東京都以外次大的。
台灣的部分之前做口罩地圖的 Kiang 有把他架起來過，然後我這邊也有架一個版本，如果不太熟悉英文或日文的朋友可以試試看在這邊
開 issue 或是發送 PR 等等的，疫情結束網站收掉之前我應該都會回應就是。
https://github.com/pichuchen/covid19
另外是也有些人提出了關於維護的問題，所以目前在 CI / CD 以及自動更新資料的流程
上面也在改善中。