2017年8月24日 星期四

實驗心得:提案闖天關—— Open Data 與審議民主怎麼 Combo?以司改國是會議資料為例

最近一直在逃避寫測試,所以不知不覺就開了新分支(喂)... 這次的題目是 open data 結合審議的小實驗,拿 總統府司法改革國是會議 的資料當白老鼠,想說親自從上游的資料內容產生、到下游的衍生應用開發整個生產鏈走一遍,感受一下 open data 從理論到實做中間可能遇到什麼瓶頸。

結果就是這個簡單的小網頁《司改國是 2017 - 提案闖天關》,把歷次會議中所有的提案整理成結構化資料後,用視覺化的方式呈現,看能不能方便委員們追蹤(a.k.a. 找出哪些提案被搓掉 XD)

原本叫「議題履歷」,但「提案闖天關」應該比較好記 XD

前陣子 開放政府圈業力引爆 後,吟遊詩人我側面觀察這議題,感覺開放資料的推動大概有兩種門檻。第一種門檻是議題本身太抽象、不好理解,不理解就無從評判政策好壞,於是政治人物只要堆砌關鍵字,就可以輕鬆唬爛過去。第二種門檻是目前可以參考的案例似乎不太夠,即使有心想做,可能也很難想像具體來說該怎麼開始做,或者做完到底對人類世界有什麼幫助。

這個月初 北市資訊局長在 COSCUP 分享他們的開源計畫,從 演講的內容 看來,政府的程式碼開源這件事情,目前處於從無到有、開疆拓土的階段,講者會後提到 現階段需要的是「累積成功案例」——開放資料看起來也剛好處在類似的情況。這種時候,如果能做一些具體的、從上游資料產生到下游應用開發的完整案例,也許就可以幫助其他人理解「如果做好 data,那可以產生什麼應用」或者「要看到這樣的應用產生,必須先怎樣做 data」,同時也可以慢慢累積實做經驗,讓有心想做的人瞭解「所以有什麼是我可以做的」。


實驗涵蓋的範疇


雖然說,所謂的 open data 在 資料生命之旅 裡面只是一個下游的環節,但因為台灣代管當局的現狀是上游資料輸入的機制也還沒建立,這種情況下,官方沒辦法提供現成的高品質的資料給你。也就是說,要做 open data 應用的話,必須連上游一起做,自己照顧資料源頭的品質,才不會淪落到 garbage in garbage out 的下場。所以實驗涵蓋的範疇,除了末端應用外,也同時包括一點點生產鏈源頭的資料輸入。

至於生產鏈中間段的隱私保護、資料數位化管理、政府資訊公開等,由於司改國是的資料中剛好沒什麼個資,且主辦單位跟外包廠商也已經下了不少苦功,把所有資料以數位化方式儲存、放在公開網站上,因此我只要撿現成的就好了,實驗的內容就先略過這些環節 lol

實驗步驟


開發 open data 應用的第一件事,就是先搞清楚有哪些 data 可以玩。

步驟一、資料大盤點


司改國是會議雖然有把所有資料放在官網上,但並沒有一個集中的資料清單,如果想搞清楚總共有哪些 data,要先把整個官網翻過一遍用工人智慧下去盤點,才能把資料清單整理出來... 總之是件曠日廢時的苦差事。好在 whisky 因為擔任第四組委員的關係,已經先 把全部組別的資料都盤點過 了,我就樂得當伸手牌,直接 A 來用 XD

第二件事,是把這些清單上列出的資料變成機器可讀的格式,才可以直接餵給程式。這個步驟,也就是所謂的資料結構化。

那麼,這個結構化的資料該長啥樣勒?要拆成幾張資料表?每張表有哪些欄位?欄位要取什麼名字?裡面要存成 hash 還是 array?動手做資料結構化之前,得先釐清這些具體的規格。

換句話說,要做資料結構化,得先設計出一套合身的 data model 來。

步驟二、設計資料模型


data model 是人類用來描述世界的其中一種方式。

詩詞文章是人類用文字來描述世界,繪畫是人類用圖像來描述世界,歌曲是人類用聲音來描述世界... data model 則是人類用資料解構的方式來描述世界。設計一套好的 data model,就跟寫一篇好文章、畫一張好圖、寫一首好歌一樣,必須先瞭解我們想描述的東西,本質到底是什麼。所以,設計司改國是會議的 data model 之前,要先花點心思摸清楚司改國是會議的本質。

司改國是會議的組成有兩塊:一是司法改革,屬於一種專業領域、議題;二是國是會議,屬於一種審議、討論的形式。這兩件事物本質截然不同,互不隸屬、也互不影響,因此描述它們的時候,需要兩套獨立的 data model。

國是會議的 data model 相對單純,畢竟不管什麼形式的審議,都會有場次、主題、發言紀錄、參考資料等共通的內容。當然,站在審議技術的立場來看,不同審議形式的用途跟功能差異極大;但站在資料解構的立場來看,國是會議跟憲動盟草根論壇兩者的資料形態是大同小異的。因此 data model 的設計方式,就直接參考之前草根論壇的作法,簡單講,把會議記錄裡面出現的內容分門別類整理好,就可以了。

至於司法改革的 data model 就難了。這種 domain knowledge 類型的事物,要先理解該領域的知識樹大概長什麼樣子,才有辦法掌握到它的本質,也才能進一步解構它、用資料模型描述它。在 whisky 提供的資料海中泡老半天以後,決定借用 五力分析 的視角來替司法改革的知識地圖打底。

在各式各樣的產業分析方法中,五力分析側重的是影響整體動態平衡的各種因素,用一個軸向看生產鏈內部環境(上游供應商、下游購買者),另一個軸向看生產鏈外部環境(同業競爭者、異業替代品),視野涵蓋的範圍寬廣且完整。用五力分析的概念看司法改革議題的話,司法體系生產鏈的內部除了業界本身以外,還包括上游的司法養成教育、以及下游的受影響民眾,外部環境則包括上游的公民意志(在極權國家,公民意志要替換成獨裁者的意志)、以及下游的社會效應。在這個近似於五力分析的視角之下,司改知識地圖的底稿長這樣:


底圖出來後,先是試著把司改國是會議各組的主題對應上去:

結果聽 whisky 講才知道,這五個分組主題只是參考用,有些沒人要的議題會被丟包去別組(額)所以實際上要看這 21 個細部的子議題:

結果一大票子議題都在中間跟右邊,擠成這樣幾乎等於沒分類 www 還好 whisky 又掏出一張 英國人做的神圖 ,把司法業務的每個環節攤開來,各自對應到體制內外的組織和使用者,換句話說,剛好可以把底圖裡面的「司法業界」跟「受影響民眾」這兩區再切細:

到這邊,司法改革議題的知識地圖浮現,差不多就是我的偽五力分析圖加上 whisky 找的英國人神圖。

有知識地圖以後,終於可以來做司改議題的 data model 了。我目前是沿用英國人神圖的形式,以業務群組為基本單位,每個業務群組會對應到多個單項服務、體制內使用者、體制外使用者、以及組織。詳情可參考這個 json 格式的檔案 ,裡面的中文是我亂翻的,如果有人要拿去用的話,記得先請專業的校對 w

步驟三、產品企畫


data model 有了,但要做成什麼應用,才能讓大家有感勒?跟 whisky 亂聊產生兩個 idea:第一個是《議題導遊》,使用者只要在知識地圖上到處點,就可以看到各種相關的會議資料,用來協助一般人瞭解議題。第二個是《議題履歷》,使用者只要在選單上到處點,就可以看到自己組別的議題狀態,用來協助委員們追蹤議題。

雖然對大會來說,做《議題履歷》可能比較有實際的幫助,但當時距離 8/12 週六的總結會議剩下不到一個禮拜,data model 雖然有了,但還要按圖施工才能真的結構化,而產品除了 idea 外還沒有 user journey 或 wireframe 等任何具體的進展... 各種不確定因素下,菜鳥我完全不覺得自己能在幾天內做出可以動的 prototype,所以就很乾脆地放棄這題目了。畢竟,委員們如果要追蹤提案,直接手動做一份文件可能還比較快。

總之,我就以《議題導遊》為目標,開始做資料結構化跟做網站企畫。

那幾天 whisky 把我跟雨蒼拉到一個聊天群組,就順便約了禮拜四去司改會 cowork。結果去了司改會,遇到 miffy,她現場掏出連雨蒼都不知道的 google spreadsheet,裡面有大把現成的結構化資料(驚)原來各組的所有提案,miffy 她們都有手動製表註記狀態... 看了看,發現雨蒼之前提供的資料,加上 miffy 現場掏出來的資料,湊起來做《議題履歷》剛剛好耶 OwO

所以我就在司改會當場畫好 wireframe,改做《議題履歷》啦 \^o^/

步驟四、程式開發


有現成資料後《議題履歷》做起來飛快,隔天早上就先推了一版到 github pages 上。原本打算推完就去睡覺,結果看到布丁在臉書上指出配色問題,忍不住動手去改一下,改一改想說那順便把功能做完好了... 結果做完以後,就到下午了,好久沒熬夜成醬子,有種瀕死的感覺 ((O_O))

做完隔天,司改國是總結會議轟轟烈烈地開始,然後轟轟烈烈地結束了。看著臉書上的各種烽火連天,我相信《議題履歷》在這場會議中是完全沒用武之地的,哈哈。

後來發生一樁悲劇,就是雨蒼試圖把《議題履歷》demo 給別人看的時候,網頁在手機上打不開,一載入就卡死 www 我才想到那不到一天寫出來的爛 code 完全沒有考慮效能,所以這禮拜又花了三四天研究,總之,現在用手機開應該沒問題了,桌機的載入速度應該也會快很多才是。

題外話,網站名稱不叫《議題履歷》是因為三年前做過一個很類似的東西,追蹤立院議案進度用的,叫做 《議案闖天關》 ,名字很可愛(自己說!)但最後沒上 production 感覺有點可惜,想說就讓這名字在這邊復活好了,因此網站名稱就變成 《提案闖天關》 啦 lol

實驗心得


這次最大的收穫,是似乎發現了一條推廣 open data 的蹊徑 XD

百年一見的 open data 練武奇才:審議


前面說過,一般的政府資料,從源頭產生到最後結構化釋出,要經過層層關卡,在這中間,拿任一個環節做實驗,都可能給相關工作人員帶來麻煩。

但這次拿司改國是會議的資料做實驗,除了隊友 whisky、雨蒼、miffy 以外,完全沒有影響到其他任何人喔!揪瞇 ^.< 因為審議資料的生命旅程,有幾個特別的地方。首先,這些資料大多數情況下生來就不涉及隱私,因此不需做去識別化之類的額外加工,就可以直接釋出;其次是資料本身全都是人類可讀的內容,不像數據形態的資料可能要處理統計偏誤的問題,或者需要額外的解釋才能呈現出有意義的資訊,資料裸身見客,需要 debug 的環節也跟著變少;再來是每場審議都會在一定時間內結束,不需要常態性維護任何文件或流程,因此,在審議會議中嘗試新的作法,沒有和之前的場次不相容的問題,也不會造成後續場次的包袱。

也就是說,審議的資料一來處理難度低、好入門,二來處理自由度高、好把玩,用來做 open data 的示範案例蠻適合的。未來,如果有人想做輕量的 open data 範例,拿審議當主題也許是個不錯的主意。

歷久彌新的國民編輯後台:google spreadsheet


幾年前菜鳥我做 HackFoldr 2.0,人生中第一次接資料就接 google spreadsheet。原本想說俺進步了,應該要從更厲害的地方接資料才對!

結果前陣子發生了一件讓我十足意外的事情,就是先前做的 OCF 官網 ,維護人員決定把資料編輯介面從 yml 改回 google spreadsheet。無獨有偶,這次司改國是會議 miffy 跟雨蒼她們整理的大量資料也都是用 google spreadsheet 編輯,我才驚覺自己太小看它了。

仔細想想,gsheet 可能是目前市面上最友善的資料編輯介面了。功能齊全服務穩定不說,任何稍微會文書處理的人都可以無痛上手,而且這年頭幾乎每個人都有現成的 google 帳號,不用特別設定,連結打開就可以開始作業。此外,欄位間的移動比 web form 快,呈現方式比 yml 或 markdown 直覺,可以大量編輯又不用特別記什麼語法,各種方便。

不過 gsheet 的死穴是長內容,一大篇文章塞在儲存格裡面會很難閱讀也很難排版。如果遇到長內容的話,可能把本體放在別處,讓 gsheet 存連結會比較方便。

司改國是 data model 的未來發展


實驗最重要的成果,莫過於這個 接資料專用 - 司改國是 2017 gsheet 裡面的資料欄位了。

這些欄位把 whisky 跟司改會 miffy 雨蒼他們整理的資料,都歸納進來,涵蓋範圍算是蠻完整的。底線開頭的欄位是 unique id,reference 到別張工作表用的。司改會替每一場會議、每個議題、每點討論事項,都設計了 unique 的編號,這些命名規則也很有參考價值。unique id 欄位中的「、」字元則是編輯人員約定的分隔符號。

總之,下次有類似會議的話,希望可以一開始就建一個像這樣的表格、然後約定一個類似的編輯規則。這樣把資料接出去做成應用的時候,會快很多,可以直接從 gsheet 匯出資料就好了,就不需要像這次這樣,寫程式前要先花許多時間手工收集資料、整理資料。

前面講過我們有做兩組獨立的 data model,這個 gsheet,就是國是會議的 data model。至於那個千辛萬苦設計出來的、司改議題知識地圖的 data model 勒?因為後來改題目了,所以完全沒用到啊哈哈 XD

其實會改題目,也跟這個知識地圖 data model 的應用難度有關。原本 whisky 想到一個很屌的 idea,用這個知識地圖上的各種詞彙,去替每一筆會議資料下標籤。這能幹嘛呢?你看現在《提案闖天關》的選單,只能依組別分類,但其實,不同組的主題之間並不是壁壘分明,實際上可能同時有好幾組都討論到同一個對象。比方說,如果我想看所有組別裡面討論「檢察官」的提案,要怎麼辦呢?這在目前的《提案闖天關》裡面是做不到的。

這種時候,如果每一筆會議資料都有下標籤,那麼利用標籤,就可以把所有「檢察官」相關的資料撈出來,這樣的結果,應該會比直接對 raw data 做全文搜尋來得乾淨。但後來發現這個工人智慧下標籤的任務實在太過費時費力,一來要下標籤的人本身要懂法律,二來這個人要花時間看完內文,門檻實在太高了,完全不是我能力範圍內做得到的。(這同時也是 Debater 小編的難處:下標籤太苦力了)

踢過這個鐵板後,我們目前的想法是,將來如果有人要做跨組、跨場次的資訊彙整,或者類似《議題導遊》之類的東西,也許可以試試看用知識地圖上的標籤做全文搜尋,也許單純搜尋的結果會很雜亂,也許需要搭配一些語意的工具,或者人工手動調整,但不管怎樣,應該都比完全由人工登錄標籤來得實際。

小結


整體來說,這次的實驗心得有兩個方向可以給大家參考:

1. 如果你是規劃審議活動的人,在籌備階段、討論資料彙整方式的時候,可以參考我們這份 接資料專用 - 司改國是 2017 gsheet 來制訂編輯規則,這樣的話,輸入資料的同時就可以很即時地產生各種網頁呈現,不僅會議期間的資料查閱可以更便利,會後的整理工作也會輕鬆很多。

2. 如果你是專精在特定議題的工作者,平時在彙整議題資料的時候,可以考慮根據該議題的知識地圖,隨手替收集到的資料下標籤,這樣長期累積下來,應該會變成一個很棒的資料庫,將來不管要做成什麼樣的應用,對工程師們來說都會方便很多。

實驗成本


整個實驗過程,加上事後的效能調整,也才不到兩個禮拜,看起來輕鬆寫意,但這其實完全是站在巨人肩膀上才可能擁有的速度。如果有人想做類似的實驗,記得先觀察一下整體的前置作業進行到什麼程度,再來決定怎麼配置資源。

實驗所需的前置作業


命名規則設計、編輯流程設計、資料輸入與校正:N 個月(主辦單位、各組委員與記錄人員、官網廠商、whisky、司改會)

實驗本身投入的資源


分析議題:兩天(whisky、et)
資料結構化、《議題導遊》產品企畫:三天(whisky、et)
《提案闖天關》產品企畫、雛形實做:一天(雨蒼、miffy、et)
事後調整效能:三天(et)

這邊要特別提醒,《提案闖天關》網頁雖然可以動,但就只是可以動而已,完全沒有做一般網站正式上線該做的事情(三層測試、瀏覽器相容、響應式設計、無障礙、效能最佳化 etc.),且功能也極盡陽春,連站內搜尋都沒有。現在正在看這篇文章的你,如果本身不是網站開發者的話,請記得千萬不要拿本文的時程規格去要求你的 RD 部門或者外包廠商,那樣絕對會激怒他們,而且會害我被打 o_O 專案的時程、經費、人力,一向只有該專案的開發團隊說的才算數,千萬不要道聽途說,更不要拿我的文章道聽途說,拜託拜託 m(_ _)m

後記


不知不覺間,g0v 社群也 五歲 了。五年前我看到的景象是許多人很憤怒,但多數人動嘴說、少有人動手做,事情原地打轉,怒氣也無從發洩。當時的氛圍下,g0v 以動手做事為號召,彷彿指出一條明路,顯得格外吸引人。

參與社群幾年後,身邊的景象漸漸反轉,舉目所及,動手的已經比動嘴的多,「talk is cheap, show me the code」成為基礎的美德。身為一個討厭社交的實力至上主義者,這樣的小圈圈是很舒適的,畢竟我對大話的人一向不太有好感。

318 後,跨界專案越來越多,社群 slogan 從「寫程式改造社會」漸漸變成「不只是寫程式改造社會」,動手做事的定義也越來越多元了。寫程式是動手,畫圖是動手,做設計是動手,提企畫也是動手,參與腦力激盪是動手,穿針引線溝通協調是動手,讀資料做研究也是動手——到底怎樣算動手、怎樣算動嘴?中間的界線好像越來越模糊了。

後來因為開發動民主的關係參與了幾次 NGO 的會議,文化衝擊之下,才開始跳脫資訊人立場,找到一個比較宏觀的視角來看待彼此的定位。

老早聽說 NGO 的會議非常可怕。跟資訊人習慣的 30 分鐘 standup 相比,傳說中的 NGO 會議可說是超級冗長,一次可以開好幾個小時,而且還不見得有結論(抖)抱著萬全的心理準備參加憲動盟內部會議後,卻大感意外。兩三個小時的會議時間雖然不算短,但一點都不拖泥帶水,按照事先準備好的議程共筆,交換情報、確認論述、選定作戰方針、制訂行動計畫、工作分配... 一路過關斬將,他們並沒有浪費任何時間。會議所產出的擲地有聲的論述,或者瞻前顧後的政治戰略,絕對是 30 分鐘 standup meeting 無法達成的。

那麼,這些 NGO 的會議,到底算是動手,還是動嘴呢?

為了釐清各種跨界產生的矛盾,去年跟 ipa 一起做了 Blupa 量表 ,裡面幾張圖借用了行銷管理的概念,把產品或專案的生命週期,歸納成分析、規劃、實做、維護四個階段。在 g0v 社群裡,最常見的網站設計、前端工程、後端工程,都屬於實做階段;至於社群裡比較少見的使用者分析、商業模式、資訊架構、框線圖等,屬於企畫階段;而 NGO 們最常做的特定領域的議題研究,則屬於分析階段。

NGO 熟悉的前期工作,往往需要大量溝通討論,而軟體開發者熟悉的後期工作,則多半可以分頭獨立完成——

從這個角度來看,可以發現,重點不在於工作的形態為何,只要讓事情往前推進,不管是需要動嘴巴的收集情報、指出問題、發想概念、提出觀點,或者是需要動手的做文件、做圖、寫程式,都是在 hack,都是在做事情。

前幾天在臉書上看到 一段話
談邏輯,必然伴隨著「好辯」,對統治者不利,得予以醜化、壓制、否定掉才行。現在,都已經2017年了。如果說,你仍然認為好辯、高談邏輯,很讓人討厭。那就表示,你已經被成功毒害了。
你是某種很成功的「中華式產品」。

想到之前的自己,也曾在心裡偷偷輕視那些愛動嘴的人,不禁覺得心驚。也許,在軟體開發實做的世界裡,大部分的時候,talk is cheap;但在論述思辨倡議的世界裡,大部分的時候,talk is valuable。

思想,是有價值的。

但很現實的是,如果價值沒被看見,就不會產生影響力。那要怎麼讓思想的價值被看見呢?我目前想得到也做得到的,就是當翻譯機,把議題工作者的思想,轉換成對外行人來說容易吸收理解的形式。翻譯家華的思想後,產生了 Blulu ,翻譯 whisky 的思想後,產生了《司改國是 2017 - 提案闖天關》以及這篇實驗心得文。

如果說水桶的容量取決於最短的木片,那麼,在這波公民運動的資訊化浪潮中,基礎思辨與資訊技術的整合,或許正是那根最短的木片吧?

接下來,希望可以跟更多資訊人,一起愛上思辨,一起往殖民者最害怕的地方走去——雖然在這陌生的混沌世界裡,肯定會跌跌撞撞、或者鬧出許多笑話來,但只要堅持下去,我們的公民社會肯定會越來越強壯,我們的思想武器,也肯定會發展得越來越精良。

希望台灣國旗在凱道上升起的那天,我們已經把自己鍛鍊成合格的國家主人。

專案資訊


名稱:提案闖天關
副標題:司改國是 2017
程式授權:MIT
資料授權:(要看原本司改國是會議的資料授權是什麼)
文件授權:CC BY-NC 4.0
資料模型授權:CC0
指導:司改國是會議第四組張委員網兇 whisky
協力:司改會雨蒼、miffy

上線網址
程式碼
資料表
協作文件
開發手札
心得報告

對專案有想法的話,歡迎到 OpenData / Taiwan 臉書社團 或者 Talking Data G+ 社團 討論 ^^



本文授權:CC BY-NC 4.0 / ETBlue

這篇心得文竟然寫了五天... (倒地

沒有留言:

張貼留言