【真的假的】2017/6/28 紀錄 ====== ## Bot 使用者調查：找出誰傳送訊息？他們的期待是什麼？（進行Line上的問卷調查） 接觸 LINE bot 使用者的渠道： 1. 官方帳號於「主頁」貼文 2. 發送「群發訊息」 > 尚未指定 actionable item owner ## 使用功能優化執行/順序討論： - 邏輯謬誤的按鈕 > Will implement "opinionated" > need discussion on design > 執行順位： reply 編輯功能之後，與求助按鈕相同順位 - https://github.com/cofacts/rumors-site/issues/22 - https://github.com/cofacts/rumors-line-bot/issues/17 - https://github.com/cofacts/rumors-api/issues/38 :::success Done ::: - 查證資料安排的先後順序，會影響讀者理解資訊的正確性，怎麼做最好？依照資料來源排序？ > 需要 reference time stamp，自動化不可靠、編輯手動 key 時間的效益也不高。 > Billion「編輯自己邊過的東西」功能比較實在，因為提出這個要求，背後的動機是發現自己的 reply 不對、想要修正。 > > 執行順位：因為沒有替代方案，希望優先實做。 - https://github.com/cofacts/rumors-api/issues/36 - https://github.com/cofacts/rumors-site/issues/17 :::success Implemented deletion instead ::: - 編輯追蹤系統（編輯想知道自己編過的東西有沒有別人寫的新回應） > blocked by schema refactor, cannot have action for now - 手動貼到FB上面求助會不會很難？是否可以增加一個求助按鈕，就可以自動連結到社團貼文？技術上可行嗎？ > Random people: Cotact us + email > For editors: floating action button to FB 懶人包 > 執行順位：跟 opinionated 差不多 > 就算不做 contact us 也需要註冊 google groups 來回信 （GGM 會研究） - https://github.com/cofacts/rumors-site/issues/23 :::success Done ::: - 當一則新謠言被查證，是否要主動推播訊息給先前查詢的人？有一則查證就推播還是？ > LINE bot server 要記錄哪些問過沒得到答案 > 執行順位：因為可以自己回來看，所以最後最後做 - https://github.com/cofacts/rumors-line-bot/issues/18 ## 編輯社群成長觀察：目前有哪些數字可以輔助理解？GA中可以區分闢謠編輯與一般使用者嗎？ 統計資料：https://docs.google.com/spreadsheets/d/1h9YAmi5i_dpYGYG5xUBBiW2Q_W0-ylJocb-MKY2nffc/edit#gid=1009818490 統計使用的 Elastic search query: https://github.com/cofacts/rumors-site/issues/19#issuecomment-312291955 ### 編輯成長的人數 分成「每週網站註冊人數」、「reply connection 的 unique 作者數」兩塊。前者不一定是註冊之後就立刻進行編輯的人，而後者等於是周活躍編輯者數量（活躍的定義 = 有建立 reply connection）。 #### 每週網站註冊人數（累積） <iframe width="100%" height="384" seamless frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/1h9YAmi5i_dpYGYG5xUBBiW2Q_W0-ylJocb-MKY2nffc/pubchart?oid=2009840429&amp;format=interactive"></iframe> #### reply connection 的 unique 作者數（週活躍編輯數） <iframe width="100%" height="371" seamless frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/1h9YAmi5i_dpYGYG5xUBBiW2Q_W0-ylJocb-MKY2nffc/pubchart?oid=646860534&amp;format=interactive"></iframe> ### 有被查證的文章數 由於 reply connection 建立時，`articles` 沒有更新 timestamp，因此只能做出「每週 reply connection 建立數量」表，來趨近被查證的文章數。 <iframe width="100%" height="371" seamless frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/1h9YAmi5i_dpYGYG5xUBBiW2Q_W0-ylJocb-MKY2nffc/pubchart?oid=1772591583&amp;format=interactive"></iframe> 5 月中～ 6 月底的 1.5 個月中，約有 1000 個 reply connection 被建立。 ### 推訊息進來的次數 新文章建立的周分佈（累積） <iframe width="100%" height="371" seamless frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/1h9YAmi5i_dpYGYG5xUBBiW2Q_W0-ylJocb-MKY2nffc/pubchart?oid=1199381741&amp;format=interactive"></iframe> 圖中的 2 次文章數快速上升，分別是： - 2017/1/9: 謝頓危機發生 - 不小心曝光給媒體，導致大量 LINE 使用者湧入。當時 LINE bot 的設計是只要沒找到就會進 Airtable 資料庫，因此有大量文章被寫進資料庫 - 2017/3/底：[LINE bot 被惡意攻擊塞垃圾資料](https://hackmd.io/s/SkHt8JZ6l)，被寫進約 1000 篇無意義文章。 5 月中～ 6 月底的 1.5 個月中，約有 1000 篇新文章被建立。 > MrOrz will check that before 6/30 > 之後做成 cronjob 之類的 ## 編輯準則：邏輯問題（滑坡、稻草人：解決個別事證都對，加起來結論邏輯有誤的問題）（要放在同一個平台上嗎？） Lucien 邏輯謬誤是一種「含有不實訊息」 Lcn:邏輯錯誤是錯的，等於從訊息本身回去看。 Lcn:比如若A則B，若B則C，推出若A則C Orz：比如南非與同性婚姻 Lcn：邏輯錯誤表示有推論句 Orz：結論應該不會被其他文章再用 Lcn：因此推論就可以自己被框起來 Orz:就算個別事證都對，還是可以對那句結論說含有不實資訊。 Lcn：主觀意見沒有任何陳述，把話說一半，暗示背後某個結果跟推論。 Orz:這裡可能需要例子 可以用opinion也可以用不實資訊，但可以用引導說，遇到這個狀況可以選不實資訊還是....(一個編輯準則) hazel：這個東西是要確認要不要放成一個項目(來自社群的意見) Orz:如果要寫進準則，就要告訴編輯平台上長什麼樣子，所以的確需要例子。 hazel：暫時性的這些以後會變成分類嗎？ Lcn：需要給他一個特殊TAG，大方向表示他是錯的，是邏輯謬誤，而不是內容事實的問題。含有不實訊息這件事情有很大解讀空間，推論錯可能是因為邏輯謬誤。 Lcn：目前給予比較大的裁量權，編輯覺得錯就可以選。 ## 查證工具使用教學：Google 進階搜尋的教學文、video查證教學（辨識可查證範圍、記錄在哪裡？）、英文查證技巧、 - existing tutorials on Google Search Bil: 文字 + 影片，可以用文字找影片，但也可以不處理。 影片留言範例與困擾： https://g0v-tw.slackarchive.io/cofacts/page-9/ts-1498237271947418 * 文字 + video 連續在 2 則訊息中一起轉傳：https://github.com/cofacts/rumors-line-bot/issues/11#issuecomment-310719476 * 純圖片 or 純文字轉傳：https://github.com/cofacts/rumors-line-bot/issues/7 ## 未來小聚規劃：主題性（法律、政治體制、醫療） - 先不做，下次還是一般的。主題有必要，但是要等分類做好。 --- ## 討論過程雜記 ### 回應顯示的順序 編輯有沒有可能照資料來源的時間看？ 有點困難，因為資料來源的時間不可靠。 ### 主動推播訊息給先前查詢的人 主動推播很貴3888-8888，群眾推播免費但是不能主動推播曾經傳入的謠言解答。 ### 求助按鈕 希望協助編輯說，查完謠言社群社團裡面可以提問。 解決方法，多給一個連結或是指示標語。 如果今天是random的人進來真的有心，其實留個email聯絡我們 小編本身有疑問因為有登入，可不可以推 Lcn:floating action bottom，像是FAQ的功能 Lcn:不是回訊息，而是回到小編教學 btf:像是傳送門 Orz:比如轉回fb的小編教學 ### 編輯社群成長觀察 編輯社群的資料，切時間點去看增加的人數或文章。 回應的資料回去找一找撈資料大松前更新 ### 標為 "opinionated" 而不只是標記「非關真假」 Orz:大部分fact checking做的事實查證只做到attribution check， 如果現在的人是想要看到不同的消息，給予不同的訊息很好。 一般fact checking不做是因為評論主觀意見像是在帶風向。(btf:有助於維持權威性) 但是collabrating的fact checking應該可以做到不同的效果。 btf:目前有事實和非事實，如果要加上主觀遇見會有點多 hazel:全部放一起有點難懂 Orz:rumor和non-rumor已經夠亂了 hazel:如果能在line上提示說本則有主觀意見，有關聯性。有沒有邏輯謬誤會影響到編輯，這是個功能。 hazel:LINE上面的呈現不應該跟真假放在一起，而是講完真的跟假的，再提出裡面的主觀意見。 Orz:可以把它連結到這個網頁。有多少人認為有主觀訊息，請按以下連結。 Orz:現在的投票制已經把含有真實跟不實分開了 ggm:要加上主觀意見的話如果讓不實跟真實放在同一條，會有點亂。 Orz:另外還有多少人說這則有主觀意見，請點連結觀看全文。 ggm：bot只能講五句話 Lcn:可以做成圖片 ggm:放字跟放圖片一樣啊，排版好就好 Lcn：透過圖片把資料揉在一起。 (討論暫停了)之後再來看設計怎麼做