20180725 會議記錄

檢討「送出文章理由」

初衷

提案：20180110 https://hackmd.io/OsA3T197TYmye6INymxOGQ#Proposal-LINE-bot%E3%80%8C%E8%A9%A2%E5%95%8F%E7%88%AD%E9%BB%9E%E3%80%8D%E5%8A%9F%E8%83%BD 討論：20180124 https://hackmd.io/s/SyivqlIrf#%E8%AC%A0%E8%A8%80%E5%9B%9E%E4%B8%8D%E5%AE%8C

這可以：

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

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

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

[name=Johnson Liang]

數據

「減少送出」有顯著效果。

資料庫裡的所有送出文章理由

:::info 送出文章理由： https://docs.google.com/spreadsheets/d/1v7H4QMBrHHX9S9dpi3Lkuz0s53fQCpPPekY47W80_q0/edit#gid=0 :::

好/瞎：

亂輸入時所送的資料

:::info

Log + 理由 (非公開，含個資) https://docs.google.com/spreadsheets/d/1vvnPv6EWmfndWd1foHER-LBBcFmpB_2WOIiryW_yP9Y/edit#gid=0 :::

1.所有手動輸入的理由都會放在這個篩選器 2.但你看這些理由是另一篇文章，他就不是手動 3.第二個是chat bot log 過去七天，使用者打了什麼state還有user id都會和其它對在一起，還有log的時間表，artical replied created LINE BOT裡面查的訊息，從這邊看得到pattern，這些就是亂填的狀況呢，我最後有一個調查的column，最右邊下面的調查我去看訊息他的傳進來的時候，一定是停在輸入理由的state，使用者又直接輸出了。所以我在這裡寫說，原文停下來的地方是它傳一則訊息然後放置，他停在請填寫理由的state，然後又直接走了。再之後又傳一篇近來，他問你是這個理由嗎，文字很長他不看，他又直接送進來。可以看到他的天數可能是好幾天以前，或是兩分鐘前傳進來，不想填理由，又轉一篇進來。

orz:調查有東西的值大概是下面這一些。 但如果好好打的理由，大部分又其實還不錯。我們需要排除這種誤送的狀況。

Gore: 傳進來被當成理由，他看起來也沒有要查一次 使用者似乎沒有在看字。

桓： 一個 filter 的狀況是 大部分用手打的 不會有 new line 但不知道要怎麼處理手打的，但是又分成好幾行的那一種

文武： 問理由功能是不是要繼續放在 line bot 上 因為

  1. 放了理由之後，假訊息進來的時間就會往後延
  2. 一開始做功能是因為編輯覺得很煩，使用者亂送。但使用者有沒有亂送一眼就看得出來。網頁端做一些標籤也還行。

Gore: 分辨是不是亂送的。 高達 6 成是亂送的，是不是證明了使用者心態上就是在亂送

文武： 素質吧，有按鈕就按

orz:LIＦ可以做一個使用者按下去就讓他有個表單的功能 我們在這裡寫一些按鈕，那就不用作重送confirm的動作 至少有這四成訊息編輯會比較有方向學習媒體識讀。 可以考慮一點是，不送的話是真的沒有價值還是。

有一種辦法是把理由變成選填。

gore: 我自己傳進來就是想知道，所以不會想到什麼理由。

桓： 但這還是不能解決轉傳訊息進來變成理由的問題

Orz: 嗯這是兩個分開的問題

  1. 轉傳訊息會被誤認為理由。這只要 bot 裡有複數個可以 free form 輸入的 state，就會被搞混。我目前只想到 LIFF 這個解法。
  2. 有沒有幫到使用者或這功能有沒有用的問題。或許可以改成選填，可以比較避開「訊息被延後送進來」的問題。

Bil: 我希望有寫理由再送進來。 或者是如果有「我覺得這是謠言」「我覺得這不是謠言，需要澄清」的 sample

我會希望這個東西被傳進來是因為這是謠言有必要傳進來，而不是跟朋友分享的東西都被傳進來。

我們沒對理由做限制，但不要。

關乎公眾利益

Gore: 現在大家都是放棄

Bil: 如果是不想打字，那可以幫他打

桓： 放棄的是真的不想想，還是不想打字

文武： 就算有選項，可是他傳進來大部分都覺得是假的？

Bil: 但現在確實就是有「哇這個好美，俄羅斯舞曲有這麼驚人的表演」等等

文武： 但他們還是有可能還是覺得這是假的，然後送進來

Bil: 那我們就可以說這個人是在亂玩我們的系統，可以封鎖他。 確實現在沒有色情訊息了。

文武： 那我們可以直接把過去傳進來的人做封鎖就可以了？

Bil: 我們也有說亂寫理由要封鎖，可是還沒封鎖，嚇嚇大家。

Orz: 如果要做選項， 我們可以看看現在的理由裡面有沒有什麼可以用的

文武： 這不就跟我們直接做標籤給他是一樣的道理？ 例如說「我覺得這是謠言」「只是玩玩」這種

Orz: 「謝謝您這麼誠實，訊息沒有送出。」 用 URL scheme 可以做到 按一個按鈕幫他填：我覺得……

文武：

因為做按鈕太方便 送出新文章

如果理由這邊要做「你真的要送出」 讓他自己輸入文字去跟 LINE bot 互動，就不會有文字都不看就送出的問題。

就是把「放棄送出理由」的門檻調高一點

Orz: 但如果他不會看字「請問您確定這個是理由」 那不管我們叫它做什麼，例如說回答 1+2 是什麼 他也會照著回答 3

Gore: 終於發現了一個使用者有嚐試第二次了！ 感覺像是沒有傳達好，讓大家卡在那個狀態

所以這個人是真的有在看字，所以傳錯之後還會再傳一次。

文武： 也可以先放著看看誤傳率會不會下降

gore: 放棄的人可能也會變多 只是現在還沒有看到很惡意的人。

桓： 如果什麼都沒找到，那我們就會問他們要不要送出。 但如果是新手，他根本不會知道現在停在 submit 的狀態，他就會不管。

今天如果她送東西沒找到，我們一次送很多 message 給他 他不會再往上捲把東西看仔細一點 會不會是因為送的東西太多了？

Orz: 如果是字太多，我們也可以用 flex message

我在想如果這個成立，那我們或許可以在進入 free form text 輸入之前，先問他們「要不要輸入理由」，那沒有看字的人就會卡在這個步驟，若接下來傳進來的是很長的文字，我們就能確定這是新訊息。

只是我還是覺得，使用者可能會按下「好我要填理由」但又停這個 state，直到下一次把東西轉傳進來。

如果只是要解決誤傳，那 LIFF 可能比較合理。

而且如果做成 LIFF，那我們也可以在 LIFF 裡面給他預填的選項。

Orz: 我們其實是問使用者「為何您會覺得這是一則謠言」 是有問題的

Gore: 然後使用者就 「我不知道耶」 然後按 home 鍵 下一次就會又把東西傳成理由 放棄人生

做這個機制只有在擋嗎？

Orz: 其實是希望使用者反思， 而且我們真的很想知道理由

Gore: 所以如果有選項讓他不填，就會失去意義

文武： （看手機螢幕）但在手機上看，「為何您會覺得這是一則謠言」藏在文字裡面，太不明顯了。

Gore: 他會以為這是規則，所以就不看 唯一的按鈕是「要放棄嗎」但他絕對不會按放棄 就停下來了

第一眼看真的有點抓不太到

文武： 而且「以下是您傳送的理由」會被推到螢幕上面看不到 只會看到最後的「確定送出」按鈕 他就按了。

Gore: 所以是 UX 的問題呀！！

Orz: 那感覺可以用 flex message 調整 wording 再看狀況 這比 LIFF 好多了

可以做成「這是您想送出的文章：（節錄 10 字）這是您的理由：（節錄 10 字）請問要送進資料庫嗎？」

文武: 他自己填的理由就在上面，應該不用復述？

Orz: Flex message 像這樣

Code: https://gist.github.com/MrOrz/8ff98577f64d7376302ae0be88041a26

Gore: 紅字可以短一點。只要這樣就好：

若您送出的訊息或理由意味不明、造成闢謠編輯的困擾，未來您將無法送出文章。

https://gist.github.com/MrOrz/4e8518b28742ec2e2c1e4b87ac759b55

「傳理由給我們」可以用 URL scheme 做

桓： 也可以按「傳理由」之後打開 LIFF app

Orz:

但 LIFF 要花比較多時間開發，如果傳 url 還是沒改善，最後大絕再用 LIFF

好好填的理由要花使用者多久時間

https://cofacts.g0v.tw/article/13798inzeluww

這篇花了 3 分鐘寫理由。

Cancel submit 時所送的資料

Log 40 則（非公開）： https://docs.google.com/document/d/1EKJa-CPKHzOokBxBhx0SqMQADHLurIgJk5QAzWQweT0/edit

討論解法

Consider LIFF when receiving “reason”?

:::success 決定先按照上面的討論，改 flex message + url scheme 看看是否能改善。

By: 桓 :::

OGP updates

By Bil

NDI 想給錢讓Cofacts做facebook messenger的版本，有沒有人可以全職投入做呢？

桓誠： 可以~

Bil: 耶咿謝謝~~~我去跟阿端說

桓：時程？

Bil: 還在確認意願的階段，時間都還不確定。 對方有經費而且想做。

桓： 現在的目標是 line bot 複製到 messenger 但只有 1 個月

Bil: 我有分享 cofacts，法國與巴西都想做，所以會有一些「你們的開發者能不能飛過來」之類的想法。

Other dev items

Orz: 覺得可以最後加一句

建議可以把上面的回應分享回您的聊天室唷！

做在使用者覺得回應「有用」的回覆。

https://github.com/cofacts/rumors-line-bot/issues/88

對外聯絡

Matters

By Hazel

1500 字（Lucien） https://hackmd.io/e0b7VM2STlSNx8XpLVU9Yg 比鄰稍微加了一些歡迎補充更正

翻譯

合約進度

By Hazel

翻譯狀況

By Hazel

貼圖進度

By Hazel

送貼圖的標準：200/400/800

第一波想上的圖

按照之前的計畫： https://hackmd.io/xgMy4PTaTyGzuMdmOUPMkA 第一批 8 個

這種貼圖的標題設為「真的假的」可以嗎？或是你們有特別指定的名稱？

可以可以

「貼圖說明」是否有可用的文案？

現在有了: :::info Cofacts真的假的 是一個開源專案。OPEN DATA、群眾協作，想要獲得查證結果就從自己開始努力。 鼓勵大家都能主動查證謠言，貢獻一己之力到公共領域，如果有人傳送可疑訊息給你，不妨試試用這個貼圖一秒回應他們呀！ 看看SyndAvant把圖畫得這麼漂亮。 成為闢謠編輯就是現在：

https://cofacts.g0v.tw/articles :::

「創意人名稱」可否填「SyndAvant」？

可以可以

「版權」可否填「SyndAvant & 真的假的」？

可以可以

The Splice Newsroom

By MrOrz 採訪共筆需要協作： https://docs.google.com/document/d/1GVC0PVTeAX0xt_WClcSx6bgKdNPz7S4uuzn7ROAAUzY/edit?usp=sharing

貼了小聚的照片給 @kirsten

Deutsche Welle Brasil

By MrOrz “article about how fake news on WhatsApp could influence this October Brazilian presidential elections and on how to deal with this issue”

已經解釋採訪共筆運作。

對方已經發送共筆： https://docs.google.com/document/d/1uelEPp3TkGjLYXjxpx5W5P7y78h9YWYaVVUt7s3CpGk/edit?ts=5b5869c7