【真的假的】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:透過圖片把資料揉在一起。 (討論暫停了)之後再來看設計怎麼做