20180110 會議記錄

01/13 大松分工

:::warning 目標：編寫 http://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252FrJOTedf4M

（目前內容為上次大松的內容） :::

有要做landing page 可以徵到

Proposal: LINE bot「詢問爭點」功能

### 客觀觀察

資料庫裡有這些文章：

  1. 內文就有出處：https://cofacts.g0v.tw/reply/AWBfG4NFyCdS-nWhulMy 、 https://cofacts.g0v.tw/article/AWBtW4WUyCdS-nWhulY1
  2. Replies list 查詢「新聞 報導」 https://cofacts.g0v.tw/replies?before=&after=&q=%E6%96%B0%E8%81%9E%20%E5%A0%B1%E5%B0%8E 約有 500 篇之譜，佔 3.8%
  3. 人氣拉票 https://cofacts.g0v.tw/reply/AWCOD5QkyCdS-nWhul0a
  4. 各種美景表演食譜經驗分享 https://cofacts.g0v.tw/replies?before=&after=&q=%E5%88%86%E4%BA%AB 約有 250 篇，佔比 1.9%

個人情緒反應

為什麼他們會傳這種東西進來？！ 有出處的那些，不是都寫來源了嗎？他們真的想問來源嗎？ 其他分享文章的爭點在哪，不知道爭點又該怎麼回應？

主觀詮釋

處理這些東西，這有點脫離 Cofacts「連結文章與不同意見」的範疇。闢謠編輯要處理的應該是更複雜的東西才對。

話說回來，使用者傳這個進來到底是想問什麼？我們回原本的來源，真的有回答到他的問題嗎？

提出解法

使用者在 LINE bot 選擇把文章送進資料庫的時候，多一步詢問「為什麼您會對這篇訊息起疑？請留言以對闢謠編輯說明，您對這篇訊息的疑問或覺得有爭議的地方。」

若不輸入，就不讓他傳進來 or 再多一步確認，並且告知這可能會影響他的送出文章權利。

文章記錄在 ReplyRequest 中，不同人可以有不同的傳送理由。

編輯如果覺得理由太瞎，可以針對 reply request downvote；downvote 太多的 LINE 使用者，將會喪失傳送資料進來的權益。

這可以：

  1. 墊高發文門檻。 從訪談來看，使用者可能會單純只是想傳進來玩玩看。多一個詢問作為 sanity check，在 Facebook group 上看來是可用的，那我們應該也可以用在 LINE bot 上。反正他們會轉傳，也一定會打字。 我們可以透過 LINE bot 的 log 收取「因為填不出理由所以放棄送出」的文章，統計被放棄的文章裡，是否都是我們認為不該查證 / 沒有爭議點的東西，並且評估是否有需要查證的資訊因此被放棄。

  2. 明白使用者到底想知道什麼，然後劃定闢謠邊界。 如果真的只是想查來源，那我們接 ronny wang 的新聞 API ，由 bot 自動回應掉所有能查到來源的新聞。如果使用者其實是在懷疑一則（有受 NCC 管控的）新聞沒公信力，那去查新聞小幫手，沒人回報就直接回說目前沒人覺得這新聞有問題，想回報請去新聞小幫手、或投訴 NCC。無論如何，編輯都不該花時間在這種文章上。 與其想破頭列出我們該查證的白名單 / 不想查證的黑名單，不如讓使用者來說服我們說這個該查。 Don’t guess. Just ask.

  3. 實作了對 reply request 的 downvote，就不用實作 20171213 討論到的、對文章的 downvote。這樣的設計也類似於，我們現在對 article-reply 連結能做 upvote / downvote 而不針對 reply 本身做 upvote / downvote。

  4. 透過反問 LINE 使用者「爭議在哪」，希望能促進使用者開始思考並且表述自己認為這則訊息的問題點在哪裡、並且開始對自己看到的資訊產生懷疑。這是媒體識讀的第一步，也是專案一直以來努力的方向。

[name=Johnson Liang]

:::info

過去的相關討論紀錄

GGM： 實做要改的是，要多一個「文章傳送進來理由」

Mrorz: 網站要顯示每個人的理由 但如果文章已存在但還沒被回答，那送出 reply request 之前也會問使用者一樣的問題。 我想要讓每個使用者都去思考這個問題。

GGM: 如果正常使用，也會被問嗎？

MrOrz: 如果已經有解答就不會。是 article 或 reply request 插入資料庫的時候才會。

GGM: 是要送出 Y/N 之前問嗎？

Orz：Y/N 之後問。或者是直接取代掉 Y/N，變成「我們即將把他送進公開資料庫給編輯們看。請問你認為他的爭議點在哪裡呢」也行。

GGM: 那如果打「這是謠言」也可以嗎？

Orz: 大家覺得太瞎就 downvote。但如果覺得這真的有道理，也 ok

GGM: 那就會 upvote 呢。

GGM：好哇我覺得可以。 可是那舊的文章就沒有回報的理由囉。

Orz: 嗯對。

Orz: 那可能就先開 API。 Priority 因為要收資料所以可以在 URL preview 之前做。

GGM: LINE bot 也要顯示理由嗎？找到文章的時候，要不要寫當初被傳進來的理由。這樣會不會很擠？

Orz: 不用。他就是一個說服編輯、告訴編輯的資訊。

GGM：理由有字數限制嗎？不然會打空白鍵。

Orz: 先不要有好了，讓 downvote 處理。

btf: 相信群眾。

Bil: 就跟 FB group 的審核一樣，太差就會被拒絕掉。

Orz: 但我覺得要設計一下 wording 與順序。

例如說，如果使用者選擇一篇還沒人回過的文章，我們要先問「你覺得這篇文的問題在哪裡」，然後才會送出 reply request 並且告訴使用者「你是第幾個送出這篇文章的人」。

在我開完 API 再開始做就可以。

:::success 〖結論〗

Do it.

時機：Before URL preview (因為要收資料，越早越好), after schema migration.

Should implement its API then the LINE bot. :::

Mappings refactor progress

Pending review: https://github.com/cofacts/rumors-db/pull/11

TODO: Change API server to read / write docs with the new schema

二月小聚

Bil: 二月時間有點少（過年）所以要趕快處理。 好像只有前兩週。第三週過年。第四週接近二二八。

Orz: 第四週我不在 XD

Bil: 前兩週的話今天就要決定好。然後請 Lucien 畫畫。 3 號還是 10 號？

Orz: 10 號感覺可以多一週準備，10 號好了

10 or 11，保留一個彈性。

那有需要弄個主題嗎

Bil: 尾芽芽芽 狗狗年來惹恭喜恭喜

:::success 〖結論〗

2/10 Sat (preferred) / 2/11 Sun (備案) :::