大家好，我是皮丘。
今天要和大家介绍的是一个开始二十几天，累计了两百多个贡献者以及八千多个 Commit
的开源专案。
因为我是从半路才加入这个专案的，所以可能有些人更知道整件事情的全貌，
如果是这样的话再请帮忙指正一下，感谢。
想要介绍这个专案主要是这个专案可以说是某种程度上的“奇蹟”
GitHub 上面星数多的专案不少，但是贡献者到三位数的专案就真的不多了，
尤其是不到一个月冲到两百多的更少。
今天如果是公家机关开放了一组 API, 例如药局资讯，其实有做足宣传的话大致上可以
看到不少专案，
可是大多数的专案常常会像是大学专题一样，变成少数几个人有在做，其他人可能不确
定应该要如何进行。
或者是工程师一多意见就容易分歧，那么要成功组成这么大的团队那就更困难了。
如果说可以从这个专案中学习到什么经验的话，将来要进行专案开发或者是跨国的开发
时应该可以提升不少来自台湾资讯界的能量。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
首先，我会跳进来这个坑一开始是从不知道哪里来的 Google Sheet 翻译表开始的。
https://imgur.com/a/bViBf4X
到底是哪里来的我真的忘记了，注意到的时候已经是改掉了不少明显是直接简转繁的翻译，
后来点到 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 的缘故，所以会看到类似
这样的画面：
https://imgur.com/WAAbmAc
我个人认为这样其实有助于减少混乱，等于是修改大方向的东西是在 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
其他人如果有兴趣觧的话也可以直接认领然后把它解掉
https://imgur.com/a/1uVfXuM
3. 在解 issue 的时候基本上都是从 development 分出来，然后改好再发 PR 放回去
4. 发 PR 之后基本上专案已经有设定好 CI/CD 了，所以大致上需要其他人帮忙 Code Review 之后就可以等专案拥有者进行合并
5. 合并完成之后假如没有其他问题就可以 Close 掉这个 issue 了
以上算是比较简单的 Issue, 像是这种我认为比较算是熟悉参与开源专案的节奏，例如帮忙做 Code Review, 回应 LGTM 等等。
那也有一些是比较复杂的 Issue
以这个修改图表对比色的案例为例
原本的图表颜色是这样：
https://imgur.com/a/JAVwru7
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 以及自动更新资料的流程
上面也在改善中。