動民主 @ g0v 解除戒嚴 hackath8n
Tommy Pai
等動民主小松約 hcchien, ddio, walkingice ... etc.
嗚嗚我本來要來談動民主的社會參與面的.......
只好先寫 hackpad 惹…沒辦法我今天回母艦補給 =w=bbb
follow 這個 pad 的夥伴們，ddio 要揪團開小松了！大家方便在什麼時段呢？來這邊填表吧！動民主半定期松
有關於改進動民主「提案，表決」的部分的提案
我幫大家把今日hackthon的東西key一下，請大家幫忙改
好喔，我覺得是討論的過程在網路上如何發生(討論提案)
討論人麻煩簽到一下
- Kiwi (kiwi0530)
- 小耿(pioneerlike)
- ben(ben196888)
- peiyu kuo
- Peri Lai
- kiang （網路討論也要簽？）
- 怡真(chenijane)
- Truman: Hackath8n 沒看到ET B，找walkingIce & Simon 聊了一下，然後跟著沃草加入另一組。後來才發現動民主的立牌和其它三、四個放在一起。所以就變成網路討論了。如果有假日的小松再參加。
參考資料
- 架構
- 討論
- 審議
- 服貿協議 | 審議平台
- 一個loomio 的範例 https://www.loomio.org/d/WxOZPh04/
- loomio 使用問題
- LiquidFeedback 堅持「公開透明」就一定與「秘密投票」原則衝突嗎？
- 開發
討論民主的精神
PeiYu Kuo的發言：
------
pioneerlike的發言：
-----
KIWI 的發言：
- 自由人權
- 所有人皆有天賦人權（參考自然法），主要的認知有生存權，言論自由權，發展權（當然其他還有，請參考資料）
- 剝奪他人的生存權者，其生存權終會被眾人剝奪
- 剝奪他人的言論自由權者，其言論自由終被眾人剝奪
- 剝奪他人的發展權者，其發展權終被眾人剝奪
- （這些權利也會互相影響，所以需要民主）
- 民族擁有自決的權利，而大國併吞小國，試圖影響小國自決權利者，終遭到小國決定分裂
- 獨裁國家：生存與發展優先於言論
- 民主國家：生存與言論優先於發展
- 民主
- 民主是在維護所有人人權的前提下，以一定的議題討論，審議與妥協機制，決定眾人的方向，否則僅是多數決
- 尊重人權的民主，形成的體制，才是憲政體制，才能形成法治。否則就是虛偽憲政，虛偽法治。
- 科技與民主
- 系統無法影響人，系統做的怎樣再好，人沒有觀念一樣行不通
- (同理體制無法完全影響人，總是有人能夠架空體制)
- 民主的系統，要在社群內，以不使用軟體的方式進行，而在其中吸收瞭解過程，才能實做成系統
-------
討論民主的軟體系統
架構上的釐清（參考新民主架構的自我循環)
我只有找到Google Drawing，拜求連結。
- (A): 「事件，經驗」「情緒，想法」「論述，思想」「知識，輪廓」維持不變
- 這一個過程是議題關注與討論(大亂鬥)
- 人人有案提比較像是這邊的專案
- (B): 今日討論在「策略」「具體行動」「新制度，規則」上有所改善
- 這一個過程是審議和直接民主
針對議題討論(A)的想法
- 無論使不使用資訊系統，都需要有機制來讓人參與
- 使用：藉助動民主開發的系統
- 不使用：藉助NGO帶領議題討論與表決，再將結論合併到動民主的系統
- 需要讓人在不完全實名制的系統下討論，例如reddit，或BBS，這樣才有彈性
推 reddit 只因為民主應該要內化到生活中，而不是像開會般正式，因為大家都不喜歡開會 ;)
絕對同意啊！橫豎都需要這個的（此外disp bbs好像沒鎖程式碼，反組譯中...嘿嘿）
不是開會般正式，代表很多言論上的贅述。人少還無所謂。人多沒完沒了。
我想讓你瞭解到，這個「討論」的目的就是因為不要像開會般正式。你需要議論機制，來讓你很清楚地得到答案，但你無法阻止他人需要一個地方可以沒完沒了。
- 同意既有有關「議題討論」的動民主軟體產品繼續以他們的步調發展
- 有可能跟disp bbs要原始碼來改嗎？XD -- Kiwi
disp.cc 應該是靠放廣告來取得收入，所以難度應該有點高？
針對審議民主(B)的想法
- loomio已經有基本的功能，但不完整
- 無法凸顯言論的支持度，只是單方面表達個人的意見
- 群組有300人限制
- 相對困難貼入參考資料，字數也有250的限制
- 需要加入群組審核才能投票，違反直接民主的精神
- 從loomio的介面進行改善如下：
- 將單排「討論串」改善為多排討論串，可凸顯「贊成」「反對」「棄權」「阻擋」
- 所有的言論要和reddit相同，可以推或噓
- 實名制的問題
- 一定要先實名登入
- 代議制的問題
- 應該要允許代議制，這個機制也包含讓沒能力線上參與的人也可以參與
- 但還是強烈地建議進行直接民主
- 討論案的問題
- 建立提案的機制：誰可以提案？
- 討論並建立解決方案的機制
- 提案程序性的問題
- 發起人必須解決自己議案內的爭議問題，提出程序案
- 程序案的目的在有爭議的提案上，進行切割或合併其他提案
- 對於「歸納」的想法
- 討論案與提案會不斷地被眾人建立又否決，也會因為程序案而產生分割和合併
- 最後通過一定門檻同意進入表決案，即為歸納
- 議題之間關係性的功能
- 多選模式：建立議題的表決通過模式，以多選的方法：「選項1」「選項2」...「棄權」「阻擋」
- 是非模式：建立議題的表決通過模式，「贊成」「反對」「棄權」「阻擋」
- 多選+排序模式：不僅可多選，並可另加排序。
- 投票機制
- 需要支援自然人憑證？
- 另有凸顯個人言論過程與紀錄的功能，這個功能還需討論
實名制如何確定?
我覺得光靠Google或FB登入即可，因為不是真的要投票，目前沒有必要做到拿身份證出來。
代理人長遠來看會降低民眾對於公共議題參與度。這是德國海盜黨面臨的問題之一。
如果有其他對該議題感興趣但不認同該議題的切割方式如何解決
針對軟體開發的想法
- Kiwi所屬的公司可以提供開發資源與伺服器資源（但人力僅限一人XD），如下：
- 目標：高效能訊息交換系統及應用，這是符合我的公司的開發目標
- 參與介面討論，或從既有的系統改善設計，可以協助部分專案管理
- 提供16~24核心的CPU，48~96GB的記憶體，數個TB硬碟空間的運算資源(可再談)
- 提供20Mbps的對外頻寬(目前最多，未來有機會擴充)
- 進行以Python, Ruby(或任何可能的後端程式語言)平台改寫或重新撰寫，需要社群伙伴協助
- 部分前端撰寫(以Javascript為主)，需要社群伙伴協助
- 以Hadoop為資料儲存架構，Redis為資料緩衝，Hadoop MapReduce為主要運算架構
- 次要運算，資料介面整合使用原來的系統或重新撰寫
- 軟體測試驗證需要社群伙伴協助
- 根據主管同意，公司的協助原則是先待社群討論出合理可執行，並符合公司系統方向的架構才能投入實做
- 軟體需求來自社群，公司盡力以有限人力支持
- 版權形式需再討論
- 實體概念與定義（有階層關係）
- 參與者：實名制的可投票人員，可創建議題，討論案，意見
- 投票：一個參與者對一個提案的決定，以贊同，反對，棄權，阻擋四個概念為主。在投票時間內，都可給予或收回。投票時間過，系統會自動認定為棄權。簡易投票，即為推和噓。
- 委任投票：可以在全域，議題，子議題，各種提案上，設定自己要委任給誰。投票時間截止，被委任者的投票即自己的投票。
- 議題：問題
- 子議題：可具備子議題概念，表示此議題的細項
- 討論案：一種簡單模式的提案，提出的解決方法，尚待討論辯證。通過總人數5/1000以上人數推（這數字尚待討論），即可成為提案。
- 提案：通過討論案門檻的，即為提案，發起人需將討論結果整理為具體執行流程。需通過總人數1/100的贊同（這數字尚待討論），才能成為連署案。
- 程序案：一種提案，提出提案合併，分開，移動，至其他子議案，修改屬性（延長投票時間...等）的提案。
- 修正案：一種提案，對於已經決議的案子，所提出的修改具體方法
- 連署案：提案到決議前的中間模式，包括其具體方法。需通過總人數1/10以上的人贊同(就是連署，數字尚待討論)，才能成為議案。
- 議案：提案的最終模式，進入最終決議的表決，需全體參與進行直接民主，投票率需達一定比例以上
- （所有的提案一直到議案都可以用一次一組的方法進行投票）
- 意見：可以是長篇的議論，可以是短篇的意見。所有意見都必須符合以下：
- 贊同，反對，棄權（中立），阻擋等四種意見分類
- 這四種意見可以任選2~4欄進行交叉比對
- 可推，可噓。可依照推數，最多人看，新舊排序。
- 彈性地貼入參考資料並且使使用者可以輸入作者時間等參考資料以鑑別來源正確性
- 可以標籤其他意見作為「正方參考」「反方(互斥)參考」
以下拜託pioneerlike一定要進來補完，我描述的並非全合邏輯
隨著人數的上升，相對稀釋議題討論人數的情況下，這數字要考慮一下。一百個人要五十個人關注討論一個問題很簡單。十萬個人要五萬個人對該議題有感很難。
不瞭解問題的邏輯。如果系統上有十萬人，其中五萬對某討論案沒有興趣，那或許可能就代表該組織希望這樣的人數不要被認同是有興趣的議題，所以沒有你講的稀釋問題，因為這樣可以清楚地表現此討論案有或無人討論。我認為照比例是正確的，但該組織必須自行決定要怎樣的比例。自由的國家/組織可能少數比例就可以發起討論案，但獨裁國家/組織可能就不太希望太多人提案而降低比例。但我想，讓該組織自行決定，並且自行承擔後果，才是正確的作法。
- 決議：決定的議案，及所有留言，投票記錄，產生一份快照
- 標籤：所有參與者皆可以對任何實體概念（參與者，議題，提案，意見，決議）打上自己的標籤
- 關注：一種標籤，類似訂閱
- 意見可以標籤意見，參考上面
- 權限：所有人，我的社群(多選)，我的朋友，我選定的人(多選)，只有我
洗版如何解決?當討論刷的太快讚數呸數將失去意義。因為沒幾個願意慢慢爬文。有否限制言論長度?有否管制漫罵?有否禁止陰謀論?
洗版可以照推數排序來解決。新增「最多人看」來與洗推噓制衡。沒有限制言論長度，但我有在思考到底發言需不需要captcha避免有人覺得不能洗版不好玩，乾脆就用程式攻擊。沒有限制發文內容，也無法判定謾罵，沒人可以刪留言，要讓罵人的可以被清楚地看見被紀錄，可以修改發言但有紀錄。如何判定陰謀論？
可用關鍵字來建立過濾器filter
有些議題有地域性，可以用地圖來區隔呈現
使用者提供概略地址的話，有地域性的議題和他的實體距離，可以用Leaflet的distanceTo計算出來，並依此排序
何時開始進入決議?誰決定討論是否已經達到充分情況?
決議是一種快照，投票時間到即以簡單多數決來產生決議，作為當時執行的依據。雖然建議議題者有權利決定初始的時間（而初始時間也必須根據該組織的建立者），但實務上，參與議題者有權力提出再次決議或是程序案，並且在這其中將自己原本的選擇投到其他的議案。
- 功能群組（有階層關係）
- 設計大綱：如同FB般的縱向時間軸為UI主體
- 登入/個人設定/通知（編輯中）
- 實名制社群服務登入：Google/Facebook
- 即時動態（編輯中）
- 關注的議題，提案狀態及進度時間軸：
- 關注的參與者及言論時間軸：
- 搜尋欄：以關鍵字搜尋後，會出現符合關鍵字的各實體概念（標籤，參與者，議題，提案，意見，決議...）
- 議題/子議題內容：列出提案及目前參與者
- 提案內容
- 提案大綱，描述
- 時間及狀態
- 各種分析數據：投票率，目前決議圓餅圖...
- 贊同，反對，棄權，阻擋等四直排言論軸，具有可排序交叉比對等功能(參考上述「意見」實體概念)
- 我的/其他參與者內容
- 言論及時間軸：
- 關鍵字與外部連結：
- 我的社團，使用的社群服務及已連結的社團：
- 我的朋友，使用的社群服務及已連結的朋友：
- 前情提要：所有參與者已經先在議題關注與討論，簡易表決上，取得一定的共識，與正反各方的觀念釐清。其結論與想法才能成為討論案的主體。
- 參與者：你，我...已經用FB或Google登入
- 主議題：是否同意廢核，包含擁核或廢核的執行方案
- 討論案
- 同意廢核
- 不同意廢核
- (好幾輪之後，在此真實案例中應該只會有同意廢核變成議案XD)
- 議案
- 同意廢核
- 子議題：是否同意廢除，繼續營運現有核電廠的各種執行方案
- 討論案
- 贊同廢除現有核電廠，方案Y1：炸掉所有核電廠，連結至同意廢核
- 不贊同廢除現有核電廠，
- 方案N1：不要核四，但要核三一直跑下去，核一和二廢除，連結至同意廢核
- 贊同廢除現有核電廠，方案Y2：等到所有核電廠滿役即停止，連結至同意廢核
- 不贊同廢除現有核電廠，
- 方案N2：救台灣經濟，核四啟動，其他三廠也一直跑下去，連結至不同意廢核
- 贊同廢除現有核電廠，方案Y3：立即以合法手段停止核電廠，連結至同意廢核
- 不贊同廢除現有核電廠，方案N3：救台灣現有經濟，不要核四，但要其他核三一直跑下去，連結至不同意廢核
- (好幾輪之後逐漸變成)提案
- 贊同廢除現有核電廠，方案Y2：等到所有核電廠滿役即停止，連結至同意廢核
- 贊同廢除現有核電廠，方案Y3：立即以合法手段停止核電廠，連結至同意廢核
- 不贊同廢除現有核電廠，
- 方案N2：救台灣經濟，核四啟動，其他三廠也一直跑下去，連結至不同意廢核
- 不贊同廢除現有核電廠，方案N3：救台灣現有經濟，不要核四，但要其他核三一直跑下去，連結至不同意廢核
- (好幾輪之後逐漸變成)連署案
- 贊同廢除現有核電廠，方案Y2：等到所有核電廠滿役即停止，連結至同意廢核
- 贊同廢除現有核電廠，方案Y3：立即以合法手段停止核電廠，連結至同意廢核
- 不贊同廢除現有核電廠，
- 方案N2：救台灣經濟，核四啟動，其他三廠也一直跑下去，連結至不同意廢核
- (連署通過變成)議案，進入最後決議
- 贊同廢除現有核電廠，方案Y2：等到所有核電廠滿役即停止，連結至同意廢核
- 不贊同廢除現有核電廠，
- 方案N2：救台灣經濟，核四啟動，其他三廠也一直跑下去，連結至不同意廢核
- 決議後
- 贊同廢除現有核電廠，方案Y2：等到所有核電廠滿役即停止，連結至同意廢核
- 子議題：是否同意開發替代能源並且取代核能
- (這個例子比較像是否決的比較容易不通過，而是在多種開發替代能源的方案上表決，討論案提案的部分就略過不key了)
- 連署案
- 贊同開發替代能源，方案Y1：開發風力，無視影響戶，連結至同意廢核
- 贊同開發替代能源，方案Y2：開發風力，並且每人收1000塊協助影響戶搬遷，連結至同意廢核
- (...以下同樣)
- 議案
- 贊同開發替代能源，方案Y2：開發風力，並且每人收1000塊協助影響戶搬遷，連結至同意廢核
- 贊同開發替代能源，方案Y4：開發水力，連結至同意廢核
- 贊同開發替代能源，方案Y5：開發太陽能，連結至同意廢核
- 決議後
- 贊同開發替代能源，方案Y2：開發風力，並且每人收1000塊協助影響戶搬遷，連結至同意廢核
- 贊同開發替代能源，方案Y3：開發太陽能，連結至同意廢核
- 決議
- 贊同廢核
- 贊同廢除現有核電廠，方案Y2：等到所有核電廠滿役即停止，連結至同意廢核
- 贊同開發替代能源，方案Y2：開發風力，並且每人收1000塊協助影響戶搬遷，連結至同意廢核
- 贊同開發替代能源，方案Y3：開發太陽能，連結至同意廢核
根據概念的例子(編輯中，需要將一個大型的特定議題以上述概念驗證到比較清楚才能當例子)
大議題會否洗版?或者讓沒什麼內容的討論充斥了大部分。如何讓新加入的參與者了解目前討論問題的狀況及核心?
決議模式是投票表決?隨時公開票數還是不公開?是半數淘汰決議篩選?
下一步討論的方向
- 先與既有動民主2.0專案釐清與合併，期待下一次他們的hackthon
- 在loomio的範例中繼續建立一些例子來驗證
#動民主