2013 年擔任網頁課 ( http://ntu-ccsp.github.io ) 大助教時，在社群共同好友的牽線下與 g0v 合作開課，希望將全班 80 為同學 (含旁聽) 一起推進 g0v 的坑中。但穆然回首，現在在坑裡的似乎只有我。
參與過「你被服貿了嗎」( https://vita.tw/你被服貿了嗎-上網就知道-e35488dd8aa1 ) ，隨後發起自經區比較表、台北市長選舉承諾一覽表、政治承諾追蹤網(斷尾中)以及總統大選承諾一覽表專案。
以他人發起的(你被服貿了嗎)與我自己發起的(真的假的 Line bot)為例。
專案主 nchild 專業：法規解讀、跟立委要資料、專案管理與規劃 minimal viable product。
我的角色：前端工程師。
開發過程為，nchild 與 UI designer 討論功能後 ，UI designer 出 mockup，BE engineer 架網站後端與整體結構，然後我加入來實作網頁前端，把 UI designer 的圖做成網頁。
基本上就是一般軟體專案的開發模式，裡面會有個 PM (product manager) 打理各種事務、如找資源、拉時程、規劃需求、確認產品是否有符合預期等等，周圍則是文案撰寫者、設計師、工程師等等技術人員。並不覺得這算是什麼「領導小組」或是「非階層式」，就是個隨處可見的軟體開發團隊。
我覺得更值得注意的是，在 g0v 專案貢獻不像一般軟體開發，貢獻者沒有義務在踏入後就要持續參與到結束。像是 UI designer 畫完圖之後就沒出現了好一陣子；我很後面才加入，然後也只有在 hackathon 前後幾天會動程式碼而已；某一天有個這個專案之前的後端工程師當完兵回來，順手就在專案裡加了個功能等等。這種協作模式讓人參與時比較沒有承諾壓力，很適合時程寬鬆、缺人而且無償的志工型公益專案。但也因為如此，這個專案雖然只有幾頁，但實際上執行時間橫跨了好幾次的黑客松；如果 318 沒有爆發、激起大家想快快做完的鬥志，那這個專案或許還會再做個一年吧 XD。
專案主（我）專業：網頁前端為主，後端普普。
我的角色：規劃技術與初始實做的工程師。
原本計畫也是類似「你被服貿了嗎」那樣，我慢慢找人找資源來緩慢的進行開發，默默做個一年半載這樣。
不過由於加入了 g0v 公民獎助金計畫，有了 deadline，所以最後做的其實就更像有中心化「領導小組」這樣了——由於名字被寫在計劃書裡了，因此這個「領導小組」會更頻繁地開會討論、更有要完成事情的 obligation。
我這裡能做的就是盡量讓決策過程都公開出來，例如說盡量在 slack 上對話（我們有 FB messenger 但有時討論到一半，就會說「我們應該到 slack 公開討論」），並且對 slack 對話做備份。一方面是讓大家都可以有參與討論的機會（slack channel 大家都可以加），另一方面是希望可以完整保存決策的脈絡與討論，讓其他想要做類似事情的人可以參考我們為什麼會做哪些決策。
優勢
問題
需要長時間關注的慢熱型議題，因為沒有 obligation 所以大家會做很慢 XD
基礎建設與黑客松組織都沒有，頂多是去年 g0v summit 網頁沒人寫，我幫做了一點點。
一種來做 Coding 志工，購買赦罪券的心態 (欸)
好幾年以前就有聽說 Code for America 在「寫程式改造社會」。後來實際接觸與參與在 g0v 專案之後，覺得這種「哪裡看不順眼就自己做一個」的(自我)感覺相當良好，可以比只提出批評時政還要看到更多待解決的難處。就算最後發現自己終究無能為力，但也比光說不練還要有更多的一些經驗——至少至少也練習了更多的程式設計嘛 XD。
後來如果想到什麼主意，讓我覺得「若有一個這樣的東西的話，對社會應該很好，可是還沒有人做，而且肯定賺不了錢 XD」，我就會到 g0v 提案然後試著做出來。上述一系列的比較表計畫、政治承諾追蹤網 (已斷尾) 乃至於 Line bot 都是抱著這種想法做的。選擇實作技術的時候，也會選擇自己有興趣但不熟悉的 solution，這樣一來就算專案失敗，至少還是有練到功。
其實自由 / 開源軟體不一定就是沒有一個「中心」在的；有可能會像 Linux 那樣，從一個大學生開始開枝散葉到不同的發行版（但發起人 Linus 仍然在 Linux 核心開發中產生）有不同的公司開發，也有向 React.JS 社群，由 Facebook 發起之後，持續地吸收聘用周邊生態系專案發起人，持續扮演開源專案火車頭的角色。
我個人認為 g0v 的主幹其實是「開幹」。去中心化、開源協作則是為了讓「開幹」變得更加周延、更有機會活得下去，希望能透過開源來增加各個專案的價值。有了明確的授權條款以及完全開放的原始碼與討論過程，即是產品最後沒有做出來，其討論能保存在網路上供後人存取，也是有價值的，是下一批人「開幹」的土壤。
Crowd-sourced:
開朗政治獻金、萌典啄木鳥、阿美語萌典。
產出：鄉民 ocr 結果。
用工具把又大又無聊的工作拆分成很小很小的小塊。
適合低技術門檻作業，用工具把作業變得易於完成。
有趣的是，即使每個人都只做一小部分，操作的人應該也不有異化的感受，因為這個作業是均質的(不像生產線上有人做耳朵有人畫鞋子)，而每個人也知道自己的東西在整體的大方向。
公務員開放資料 Lesson 1、2 / vtaiwan 計畫
產出：訪談結果 / vtaiwan 平台
與其說是「與政府合作」，不如說專案主本身就是站在政府的角度向社群尋求解答。
與 NGO 合作方面我想不到什麼例子，應該是本來提案人就是屬於該 NGO / 與 NGO 比較熟吧？
我參與的專案比較沒有反對的聲音耶。
不同意見是有的，例如說真的假的應該要如何定義小編的標示，就有過三種版本。這些討論會在線上與線下進行，最後當然還是會 pick one 然後繼續前進。
有時候最後決定權是專案發起人說得算，這在一般開源專案也屢見不鮮。由於開源專案鼓勵人 fork (從現有基礎上分支出去進行自己想要的改作)，因此允許單一專案的武斷選擇，讓專案進程不要卡住。真的無法接受的人就會把專案 fork 出去，改成自己想要的樣子，藉由推出競品與原專案競爭，來實際演示自己當初的堅持，可以產出什麼樣不同的可能，並且讓世人決定哪一個好用。一個與我所在的領域比較接近的，大概就是 io.js 從 node.js 分家之後大鳴大放，最後 node.js 官方又與 io.js 合併的故事。
至於中立性的部分，在進行「你被服貿了嗎」專案時我就有一些感受。那個時候我還在唸書，指導教授認為「你被服貿了嗎」在「你被服貿了」與「你沒有被服貿」這兩項回應上的用語以及視覺設計（你被服貿了有打雷閃電、紅色背景），其實就隱含了「服貿會造成負面影響」的價值觀；不過當時專案主 nchild 認為我們就是在真實呈現服貿附件內容，產品內的文字全是客觀事實；設計上的選擇，是為了喚起民眾關注。
後來我個人的想法是：人不可能沒有立場，從人的角度出發，設計出來的東西就是會有立場。
或許有些 g0v 專案會希望自己站在中立的立場，但我們必須承認，g0v 並沒有辦法約束所有專案的所有面相（包含 UI design 與細節所隱含的價值批判）都完全中立。但 g0v 所能做的就是 stick to code of conduct，透過規範讓 g0v 本身是一個任何聲音都可以進來的場合。
例如說，在 2014 年的時候有反核團體常常出席黑客松提案電力相關的專案，他們的專案就會對核電帶有強烈的批判立場。g0v 當時可以做的，就是若有朝一日擁核團體也一同參與了活動，雙方都必須尊重彼此，不應該因為彼此立場不同就出言侮辱或嘲笑對方。
不過，據我所知擁核團體似乎還是沒有來參與過。或許因為反核團體的存在，讓他們認為這個場域對擁核團體是相對不友善的，導致參與的興趣缺缺吧。
我覺得嚴守 code of conduct 已經是 g0v 身為平台能做的最大努力了。g0v 永遠無法箝制外面的世界對 g0v 的想像是什麼，只能要求自身貫徹 code of conduct。
只有參與遊行，沒有加入黨派與 NGO，沒有舉辦讀書會，張老師從來沒有帶書給我們看。
時政消息來源就是 Facebook 同溫層推播，看到很認同的就偶爾自己轉發一下，「關注程度」方面請直接參考我的 Facebook 公開動態的 Po 文頻率 XD
至於我個人對性別例題乃至於轉型正義的立場方面可以參考這篇公開貼文。文末有提到 fact checking。
「真的假的 Line bot」並不定義假新聞。基本上我們不會用假新聞這個詞唷，最多只到用到 fact checking 這個字而已。
在「真的假的」，我們讓小編回應時標記「含有真實資訊」以及「含有不實資訊」，撰寫理由並且附上出處。由於一個文章可以有多個回應，如果一個文章裡有真實也有不實的訊息，我們鼓勵小編撰寫兩個回應，分別指出真實與不實的是哪個地方。
「子虛烏有」的謠言通常有「含有不實資訊」的地方可以回應。
ex: https://rumors.hacktabl.org/article/5577246351788-rumor 就整篇都不實 ._.
陰謀論能抓數字的不實之處標記「含有不實資訊」，但也可以將陰謀論文章刊載的數字標成「含有真實資訊」，然後提醒讀者數字部分真實，不代表可以下那樣的結論等等。
目前有回應的陰謀論文如下，尚算可以回應：
ex: https://rumors.hacktabl.org/article/5597638794104-rumor 連數字都錯了，這陰謀論有點弱。
ex2: https://rumors.hacktabl.org/article/5610304044369-rumor 算法錯誤。
ex3: https://rumors.hacktabl.org/article/5537275897256-rumor 有官方澄清。
如果真的不知道怎麼回應，也可以貼到 Facebook 上集思廣益，發出像是這樣的貼文：
https://www.facebook.com/groups/cofacts/permalink/1936489449916208/
我同意這些訊息是很頭疼的 issue。畢竟，fact-checking 是要抵銷不實訊息帶來的外部性，因此不實訊息的外部性越大，要查證就越費力。
我覺得，如果我們把查證通通攬在學者自己身上，那學者真的會壓力山大。但又何必要把這些事情通通攬在自己身上呢？
我們沒有學者的包袱，想到什麼就可以做做看，不成功就算了也沒損失，成功了大家一起分享。我們的想法並不新奇，就是將 13 年前的那套 web 2.0 的思維，拿來用在 fact-checking 身上。既然開放編輯的 Wikipedia 正確性能逼近百科全書，或許就代表著 collaborative fact checking 值得一試。
一則被回報到平台上的轉傳訊息，在小編簡短回應之後，若其他使用者再次查詢到了同一篇文章，他就會收到當時小編的回應，以及小編填寫的參考資料。
bot 會告訴使用者，「這則訊息有 N 人回報含有不實訊息，M 人認為含有真實訊息」，然後請使用者選擇要看哪一篇回應。
小編的回應主要是作為參考資料的導讀，希望能引導使用者去閱讀 reference link. Reference 可能是 fact checking journal, 可能是當事者澄清新聞稿，可能是其他新聞報導等等。
我們不會自己產製 Fact checking journal 等等內容性的東西, 但如果有相關的闢謠文，小編們就能用它的 URL 作為闢謠的佐證資料。「真的假的」只是一個把謠言與闢謠文章「連結」起來的平台而已。
因此，雖然我們打著「fact-checking」的名號，其實完全與現在主流討論的、由第三方進行專業查證的「fact-checking」不相同。我們不保證查出來的是 scientific fact，但希望透過開放協作與一篇文章允許多則回應，能讓有價值的答案有機會出現在平台上，與被回報的轉傳訊息給「連在一起」。
至於漢語圈的 Fact checking journalism，傳說中的「網路謠言追追追」不算嗎 XD 我覺得淡水河與濁水溪都是優秀的探員呀。
如果是僅限於政治領域的 Promise tracking 或 fact checking 的話，華語圈確實沒看過，或許是因為華人文化裡「政治」被認為是骯髒而不該碰觸的吧。
- - -
· CC BY 4.0 g0v contributors at
· 由 g0v 貢獻者以創用 CC 姓名標示 4.0 授權，網址： (url)
全文以上述授權釋出，如不同意請勿編寫