這次寫系列文章時，查了很多 PixiJS 的說明文件與原始檔
因此發現了一些說明文件上的問題，也發了幾次 PR 與發 Issue 參加討論

第一次勘誤與發 PR：

發現說明文件的註解與實際上設定的值有誤差

發了 Issue，回報有問題
開發者回覆：很好，有要發個 PR 來改嗎？

當下的心情是：「喔喔喔，我要成為貢獻者了嗎！！！」
接著的心情是：「啊啊啊，要怎麼發PR 啊？是我喜歡的專案，做錯了的話好丟臉啊！！！」

這邊有份教學：

與其它開發者的互動 - 使用 Pull Request（PR）

順利發 PR，開發者也收了，自己成為貢獻者

好開心

第二次勘誤與發 PR：

也是文件的問題，看起來是在不同類別複製相似註解的時候，漏改了類別的名字
這次我選擇直接發 PR，因為只是小錯誤，覺得沒有必要先讓開發者知道這邊有的問題再開始改

這時遇到了不同的問題：

1. 沒有發 Issue，直接發 PR，開發者會不會沒收到？

多想了。

2. 啊...我 fork 回來的版本比當下 PixiJS 的版本舊很多，要怎麼把 fork 的版本同步到新的版本啊?

這邊還有一篇教學，而且就在剛剛那篇的下一篇：

【狀況題】怎麼跟上當初 fork 專案的進度？

發完 PR，作者更新，結束這個回合

有一種好像走出 發PR 新手村的感覺

第三次，發起了一串討論：

前篇提到的問題：在 PixiJS 說明文件裡沒有提到 removeListener() 等移除事件監聽的方法

這次我發 Issue

問題描述：

在 PIXI.DisplayObject類別 或 PIXI.utils.EventEmitter類別 的說明文件裡，沒有 on() 或 off() 的說明
範例上有 on() ，可是並沒有 off() 的說明，會讓人有些困惑

可能的解決方法：

PIXI.utils.EventEmitter類別 繼承自另一個專案 eventemitter3，
我可以幫忙直接複製 EventEmitter 說明到 PixiJS 的專案裡
如果這樣的做法可行，我會發個 PR 執行

作者的回覆看來，
eventemitter3 是另一個 API，
直接加入會有問題
也知道目前的情形不適合剛來 PixiJS 的開發者
目前暫時不會處理

小心得：

這次雖然沒有發 PR 協助專案的什麼，但覺得發起了討論，也是挺開心的

小補充：在 GitHub 上成為貢獻者會發生什麼事？

1. 會列在 contributors 裡：

2. 在更新的檔案上會有自己的頭像

3. 說不定會在 Release 名單上看到自己
覺得不一定，應該是看開發者

自己成為自己喜歡專案的貢獻者，感覺很好
不是為了炫耀...就是一種開心的感覺

英文不好?

問題描述讓對方可以懂就好。
除非是說明文件上使用的文字可能需要較正確的文法與與意外，其實不用太過在意

本日心得： 參與專案的方法不一定要改套件的原始檔、加功能改功能或是除錯
協助更新說明文件、範例都是可參與的方向
可以更接近原開發者、知道開發者的個性與風格