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