COSCUP 小記：科技社群如何參與科技政策規劃（我們需要更多 Pizza！）

Yun Chen

Published in

sense.tw

13 min readAug 17, 2018

一群開放原始碼的同好晚上一起吃披薩，要聊什麼呢？出乎意料地，有超過八十個人跑來討論「科技社群如何參與科技政策規劃」，我們只好緊急加訂到二十幾張 Pizza，我們本來以為只有會不到十人。

Yen-Wen Chen

原本以為只有五個人會來的BoF/工作坊，結果出現了十六倍的量，在會場上，針對不同政策及議題熱烈的討論。突然發現，原來有這麼多在地工作者，深切的關注自己國家的政策規劃而不是只關注自己的日子，令人覺得超感動。...

www.facebook.com

這是在 2018 COSCUP 開源人年會 — 開放原始碼技術社群的年度大拜拜 — — 第一天晚上的 BoF。這個慣用語是格言「物以類聚（Birds of a feather flock together）」的簡化，指的是同類或是有相同興趣（of a common feather）的人（birds），喜愛聚集（flocking）在一起，通常就是好久不見的三五好友一起隨性聊天講幹話和認識新朋友。這次 BoF 是 hychen 找了在推 Public Money, Public Code 的高雄開源 Linux 社群 KaLUG（超級感謝 KaLUG 幫忙），拿了 g0v 的旗來插，稍微正式了一點訂了主題：

政府很大、很慢。在科技變化如此迅速的年代，過去的政策規劃週期往往跟不上外界改變，也未能從科技社群大規模地萃取有用的意見，結果產生的政策卻可能對社會產生巨大影響。我們如何改變這個情況？
如果把自由軟體圈習慣的開放協作流程應用到科技政策規劃，是否能讓政策能更容易迭代學習，更貼近民間真實的需求？
白話文1：在政策搞到我們之前，我們有沒有機會提早把聲音送進政府，讓政策制定跟得上時代。白話文2：大腸花 `o`

BoF 來了各式各樣的人，有工程師、高中生、公務員、工會成員、區塊鍊社群、無人機社群等；激烈討論了各種主題（共筆在此）：

民間和政府如何接軌
社群代表性問題
如何釐清議題、找到不同立場的人共識與爭點
Public Money Public Code by lawrance：想要讓納稅人的錢所開發的程式可以開源（雖然每個人的定義都不太一樣）；所有採購都 open source 不切實際，會有額外的成本。也許可以從採購轉移到學術補助的程式是不是開源；openAPI 可能是比較可行的方向。
性別主流化 by 依瑪貓：科技不是中立的，都需要把性別影響評估納進入政策執行的制定還有階段。
跨專業領域的人應如何對談 by Christine：PM、工程師考慮方式不同，不只是技能，還有文化上的差異需要互相理解。
無人機修法專章引起的爭議 by Gavin
社群意見要如何影響政策 by Rex：從登山社群出發談要如何彙整同溫層內的意見
立法建置單一公聽會公告平台，各級政府公聽會都應該要上這個公告平台。讓有興趣的按照分類訂閱 by 馬克泡。
中小學資訊教育
為什麼內政部自然人憑證這麼難用
開放資料如何用在自己的大學裡

當晚真的太混亂討論了，歡迎補充共筆，與留下聯絡資料，希望大家都有所收穫。

洪朝貴老師在分享的時候，針對將開源文化導入科技政策制定中，他說：「很難指定某個水分子蒸發，但可以慢慢加溫整鍋水，總有一天整鍋水會滾。我們有很多讓公民參與的平台像 Join，如果[開源]工具能夠讓更多人使用，這鍋水總有一天會沸騰。我相信那個文化。開放政府使用的這些工具、流程已經挺成熟了，或許分享到民間企業，可以有所幫助和改善。」

工作坊：怎麼拆解議題長出有料的論述

這次 COSCUP 正式議程有一軌是談網路治理與數位隱私（共筆），從網路透明度報告、區塊鍊治理談到 AI 倫理。 sense.tw 則是開了一軌「科技社群如何參與科技政策規劃」的工作坊，除了在 BoF 吃吃喝喝交流之外，希望幫助社群能有足夠的論述能力影響政府的政策，就從精確定義知識理性討論和議題釐清開始。（共筆）

hychen 先簡單介紹了科技社群從議題出發與政府從政策框架出發的溝通落差，和社群在網路上要凝結共識與行動的三大問題：時間跟資訊碎片化、討論四散、不知怎麼行動。因此工作坊會從拆解議題的知識和建立論述整理出問題、解法、利害關係人開始，讓社群與政府對焦可以變成下面那張圖。（簡報連結、議題整理工具 sense.tw）

維基寫作式工作坊：從客觀事實出發討論政策

長期參與維基百科社群的 Reke ，想透過維基百科式的書寫，讓網路論戰的書寫者冷靜檢視自己的論證，而且使不同意見觀點必須在同一場域展示，並透過書寫維基百科上的知識能使理念更容易擴大影響力。（多少幕僚和助理是會先 Google 然後看維基）

Reke 先邀請參與者分享他們想要討論的政策，再擇一進行討論，有一場選定的主題是中小學資訊教育，然後根據主題拆開成為了什麼 {目的} 要對什麼{對象}採取怎樣的{動作}。例如針對

國小4–6年級學童(對象)
希望引發對於資訊工具的使用興趣(目的)
可以設計遊戲給學生玩(動作)。

接下來要為大家想採取的動作和達成的目的中，提到比較專業性的名詞，練習寫作解釋內涵。例如想讓老師更熟悉開源的協作平台，「協作平台」就是一個需要進行解釋的名詞。接下來，就分工針對需解釋名詞，上網去搜尋文獻並編寫進行「協作平台」的解釋。

可是哪些文獻是適合被維基百科引用的呢？Reke 畫了一個九宮格，解釋維基在評估所引用的參考文獻希望是可靠、獨立、非一次性的文獻。（中文維基百科方針 — 維基百科:可靠來源）

可靠/不可靠：這個文獻來源的品質可不可靠，例如是有經過同儕審查的學術出版會被認為較有權威性與可靠。
一次/非一次：一次性文件是直接提供證據的人或是文獻，有可能是記者報導、某個人的部落格。維基文獻希望能採納的是總結了一個或者多個一次文獻或者二次文獻的二次文獻。
獨立/非獨立：所引用的參考文獻是否彼此獨立評閱校驗產出、不能夠相互合作。例如不同新聞媒體稍微改寫中央社發出的通訊，就不能算是彼此獨立。

Reke 並有提到維基寫作在內容上要儘量納入入衝突性觀點。

於是針對「協作平台」，還有與協作平台相關的「版本管理」，分別試寫了短文進行解釋。

議題釐清工作坊：從互相回應做議題釐清

議題釐清工作坊則是 hychen 想要跑一次回應-建構-論述的社群可以在線上非同步，也可以在線下討論的模型，希望透過問題、解法、有資料來源的補充資訊、名詞解釋、利害關係人的方式，建構對議題比較完整的論述與議題釐清。

以討論 Public Money Public Code 為例，有線下使用便利貼也有線上的非同步討論。

線下

這一場有三位長期參與開源專案的工程師（Shawn、宗翰、Tim）、一位資通訊產業協會的前輩（Vincent）、一位前公務員（Weilun）。我們將便利貼分為四種顏色：

問題（紅色）
解法/回答（藍色）
補充資訊（綠色）
利害關係人（黃色）

請大家對這個主題提出相關的問題（紅色）
結果就必須去作名詞定義、釐清、回答（藍色）
在名詞定義過程中需要補充資訊（綠色）：補充國內法規、國外作法、政府補助方式。加上問題和解法會牽涉到的利害關係人（黃色）
讓參與的人意識到提出他的解法會是別人的問題，因此引導預想可能會被質疑的面相。
討論過程中覺得是誰的發言很重要，所以也把發言人的名字標上去。

討論內容：

- （名詞定義）開源軟體與自由軟體差別：不是公布原始碼就有達到 Public Code 的標準
- （問題）Public Money Public Code 指的是政府採購既有軟體產品還是政府出資開發的程式？
- （回答）確認 PMPC 的意思，今天宗翰、Tim、Shawn 認為是政府花出去的請業者開發的錢，所寫的新開發的軟體/程式碼需要開源。而不是指政府都需要採購開源軟體。
- （問題）什麼是 Public Code？
- （回答）public code 對於非工程師，會想到資料安全性和隱私權的問題。這邊有釐清 public code 不等於 open data，code 跟 data 是分開的。
- （問題）那 Public Code 要由誰管理和維護和訂定標準？
- （補充資訊）美國有 code.gov
- （補充資訊）台灣目前是 open data 標準由國發會制定，但是地方政府可以參考但不定要遵循
- （問題）什麼是 Public Money？
- （回答）需要釐清 Public money 是什麼意思，哪些經費來源所開發的程式碼需要開源。本來工程師覺得定義很簡單，就是納稅人的錢，但維倫和 Vincent 有提到政府收入有很多種來源，並非全部都來自稅收，而且政府有許多補助研究案，會採取政府 49%，企業 51 % 的方式出資，因為鼓勵創新，研究成果歸企業主。

因為時間不夠，很多關鍵問題釐清了但很可惜沒又繼續討論下去，於是我們有將這個討論結果整理到線上的工具，希望能夠延續討論。這可以回答工作坊有些參與者質疑為什麼需要開發線上工具做議題釐清，因為線上可以：

非同步協作重複這個線下的討論 cycle，使討論可以延續
比線下更容易加 reference 跟補充資料

線上：在 sense.tw 上回應-論述

sense.tw 還在 Beta 版持續開發中，但想要延續這樣問題（questions/concerns/problems）、解法（answers/solutions）、利害關係人（stakeholders）、名詞定義（definition）、立場（statements/claims）的討論。利害關係人對於非公共行政、專案管理背景的人來說是個新的思考事情的維度，但熟悉網路治理多邊利害關係人模式的社群參與者馬上可以抓到這個概念。名詞定義則是在網路上特別需要去聚焦的部分，以及跨專業時需要去確認的東西，才能建立共同語彙，推進實質討論。

有人很難想像線上要怎麼進行這樣的思辨討論。這邊以 hychen 和 kevin 在 sense.tw 吵 Public Money Public Code 為例。

上面的截圖中，Hychen 先盤點了 Public Money Public Code 的一些大點，在公共採購軟體開源這個保加利亞的政策下，hychen 列了幾個問題，包括 — — 軍事軟體適合 open source 嗎？商業公司認為開源授權灰色地帶太多，易引起法律糾紛。並且都附上資料來源。kevin 就針對這兩個問題補充了資訊，也附上連結，hychen 則進一步針對 kevin 的回答提出問題。

在下圖中，他們也用 tag 互相標注對方的卡片「來源請求」、「缺少 SaidBy」，要求對方的論證品質，或進一步根據對方提供的資料修改自己的論述。hychen原本的紅色卡片是說開源軟體容易被駭，但 Kevin 覺得是假議題，是在開源圈裡早就被廣泛澄清的資訊；於是 hychen 修正為，開源容易被有心人針對撰寫攻擊程式。

sense.tw 想要用這樣回應的方式讓社群可以在同溫層裡面意見徵詢，透過同溫層滾同溫層的模式，去做到論點交換，對話迴圈要雪球滾起來，找到同溫層內的共識。當彼此可以看到彼此的資料來源的時候，才能知道為何得出那樣的論證。

但還是有一些我們也還沒有很好答案的問題，例如代表性、利害關係人怎麼盤點（boundary analysis）、怎麼知道收到足夠完整的意見等等，但第一步先知道科技社群對於科技政策是很有興趣想要討論的。

不只寫程式改造社會 — 技術社群怎麼行動

我們在 COSCUP 也有擺攤，跟 KaLUG 和樹黨的朋友一起（再次感謝來幫忙的社群夥伴）。在講完 Public Money, Public Code 和政府想要封 Airbnb IP 的網路中立性議題後，許多人都很有興趣，問所以下一步要怎麼行動。我們這次在 COSCUP 比較像是先種下種子，希望能分享這個經驗給想要推動議題的人，如果有行動策略，就會有更多人想要參與。

有興趣的人可以上 sense.tw 加入科技政策的討論，目前還沒有辦法顯示是誰發言，發言的時候打個 id 或名字讓人知道是誰吧，或是創建你關心議題的 Map（sense.tw 功能介紹）