COSCUP Volunteer 志工平台歡迎來貢獻！

在參與 2022/06/18 g0v hackath50n 之後，目前 COSCUP 志工平台是呈現可以被貢獻的狀態了！

大概在五月份開始，把專案盡可能的調整看起來像是 Open Source 的專案狀態。在找資料的時候好奇如何才可以算是一個 Open Source 專案，發現原來 Github 有特別為這個主題建立一系列的指引手冊「Open Source Guides」

這個指引手冊寫的很棒，覺得應該要有人來帶個讀書會之類的一起導讀或是分享！

那這兩個月一直到 g0v 活動前，有哪些完成的事項呢？

首先第一個是改用 Poetry 取代 pip，雖然這個取代法有另外一個副作用（等等後面補述），但整體來說為了讓其他貢獻者能夠不要在為套件管理搞得很麻煩，尤其是近幾年大家對 pipenv 的失望！

接下來是使用 Github Actions 來跑 pytest, pylint, mypy 或是試 build images。

Coding Style

Coding style 的部分是用 pylint, autopep8 來處理，這裡有另外一套 black 常常會拿來比較，而且 vscode 也預設使用 black，這樣就有點尷尬了，之後可能要來評估一下轉移使用 black 的差異，雖然我是比較喜歡 ' 大於 "

mypy 是用來輔助作型別檢查的工具。目前在 ./models, ./module 底下的文件都補上 typing hints，Python 也特別註明 typing hints 的註記不會影響 runtime，也就是你亂標也沒差，雖然有些人可能會覺得標成這樣就不像是 python 這個語言的特點，但 Open Source 的專案是希望越多人貢獻越好，程式碼的可讀行性越清楚越好。

Development Docs

最後是文件的產生，選擇使用 MkDocs，並套用熱門的 Material for MkDocs 樣式。mkdocs-material 這樣式真的好用到沒話說，樣式內建的套件也都相當實用。之前用過很老牌的 sphinx，但 reStructuredText 這語法每次都寫的好不順手。

在文件的部分有一章節是引導如何在本地端建立開發環境，在本地端的開發會使用 docker compose 的方式建立環境，在本地端建立開發帳號。

Poetry 的副作用

在 production 的環境中會先包一個 base image，這裡會把必要的套件先安裝好，提供給 application 或是 celery 使用。但改用 Poetry 的時候會多出約 200 MBs 的容量，必須手動刪除一些放置在 _vendor 底下用不到其他版本的 python。在 Github 上面也有類似的處理方式。

目前還是與 pip 比較還是增長約 100MBs 的差異，這個之後再來研究 poetry 內部運作的方式。

後續

今年的目標還是希望能夠多找一些貢獻者協助開發，但不單單只是程式碼的貢獻，像是蒐集志工使用的狀況或是其他組別的需求訪談。希望能多協助其他組別在志工平台上達成每次辦活動時、把重複的服務項目抽出來自動化處理。（像是目前還在協助財務組開發的請款流程。）

總之，有興趣的可以參考文件的章節順序，補充了解志工平台的架構與服務！