20171206 會議記錄

貼圖開會待討論事項

小聚

與人權有關的 case study 討論 (Rosalind)

https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512298893000025

我在想李來希和同婚的一些謠言來講好嗎？ 會有的論點大概是

  1. 這些闢謠會牽涉到法律上的權利維護程序，錯誤或正確的資訊都能傷害或幫助人。
  2. 有些錯誤的認知本身就是傷害人權。
  3. 就算是高度爭議性的議題，辯證本身就能夠促進我們對話，往真實更靠近一點。

[https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512298893000025]

勞基法新聞、同婚、年金改革，都是與實際法律變動相關的議題，可以說所謂的謠言其實也是不同的利益競逐下的論辯。

[https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512491843000187]

Slide: https://g0v-tw.slack.com/files/U191A9CHM/F89B7DW56/dec_case_study.pdf

教學 slide review (Hazel)

https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512148457000304

想請大家看一下，之前去參加南非Media Indaba的活動時，有整理一份簡報，說明如何協助新手編輯闢謠，這邊我把它整理成文字版，請大家看看有沒有問題喔！（草稿，請勿流出） [https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512148457000304]

比起新手，我覺得已經有過查證經驗的人更容易看懂這篇文章喔 「找關鍵字」其實是個很進階的能力 [https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512148457000304]

我把新手編輯定位在：看到文章覺得超級荒謬，這樣就可以了。 [https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512148457000304]

MrOrz: 可以跟現有的編輯入口看一下要怎麼整合

Hazel: 「文字基礎教學」與 medium 的文字比較重複，可能要處理一下

Bil: 發在 Medium 上還不錯

Rosalind: 從 medium 台灣社群可以獲取新的編輯

Hael:會在Medium的文章上增加Hackfolder的入口

:::warning 〖TODO〗

限縮發文權利

黑名單機制

與懶人包搭配使用，作為「不按照懶人包服用」的懲罰機制

我想提一個 throttle 進來留言的提案如下，裡面的數字是憑感覺抓的，都可以再討論：

  1. 每個 LINE user 在 1 個月內最多只能送出有 3 則沒人回應的文章。在送出文章的時候，API server 會檢查這個時間點往前 1 個月內，這個使用者送出的文章裡，到底有幾篇還沒人回應，如果 >= 3 就禁止發文，並列出還沒回應的 article IDs。
  2. LINE bot 遇到 API server 禁止發文的狀況，就跟使用者說： 
    您過去這一個月內發的這些文章都還沒有人回應唷。請將資料庫資源留給其他需要的人：
（列出文章連結）
  3. 如果一個 LINE user 在 1 個月內發出的文章中，有 N 則被標為「不在查證範圍」，那麼該使用者 1 個月內能送出的沒人回應的文章量就減 Ｎ。例： 例ㄅ：使用者 A 在 1 個月內發出 3 篇文章，其中有 2 則被標為「不在查證範圍」，1 則還沒被回應，那麼 (a) 這個使用者在 1 個月內最多只能送 1 篇文章；但 (b) A 已經有 1 則還沒被回應的文章了，所以他現在不能發文。LINE bot 會跟他說： ``` 您過去這一個月內發的這些文章都還沒有人回應唷。請將> 資料庫資源留給其他需要的人： （列出未回應文章連結）

另外，您這個月的這些訊息被認為不在查證範圍，這已影響您的發文權利： （列出不在查證範圍的文章連結）

> 例ㄆ：使用者 B 連續亂試了 3 次「這真的假的？！」，然後被編輯通通標為「不在查證範圍」。此時這個使用者在這個月就都不能發任何訊息，一旦發送， 就會收到 LINE bot 這樣的回覆：

您這個月的這些訊息被認為不在查證範圍，這已影響您的發文權利。 （列出不在查證範圍的文章連結） ```

[https://g0v-tw.slackarchive.io/cofacts/page-25/ts-1512045378000255]

白名單機制

觀察到的現象

說到油炸食物，無非就會想到肥胖、不健康甚至影響環境。但最近卻有研究報告指出⋯⋯ https://cofacts.g0v.tw/article/AWALFQp6yCdS-nWhukA7

多10倍花青素！蝶豆花茶減脂抗發炎，1種人別喝 鮮豔的藍色來自於「蝶豆花」富含的花青素，不僅不是人工色素⋯⋯ https://cofacts.g0v.tw/article/AWAguYDjyCdS-nWhukRx

近日因中部空氣紫爆，空汙問題成為網友焦點。雖然專家建議民眾最好別外出⋯⋯ https://cofacts.g0v.tw/reply/AWAkYBoYyCdS-nWhukUV

相當多類似的、整篇報導貼上來的文章充斥在資料庫「含有正確訊息」的內容中。 https://cofacts.g0v.tw/replies?before=&after=&filter=NOT_RUMOR

有什麼感受

討厭這些文章，覺得他們根本不該被送進資料庫。

這些文章就像是複製貼上的，覺得不像轉傳訊息，也沒有第二個人傳一樣的訊息進來。

回覆的時候，也只能找到原出處回應，搞不懂使用者到底想看什麼。這類「新聞檢索」的 task 讓編輯相當挫折。

看到辛苦回的文章再也沒有別人查詢過的樣子也覺得很傷心啊。

對這些現象的個人詮釋

覺得問題在於，太多人把這裡當成「知識加」了。

這些人傳這樣的文章進來，是在喊著「我是使用者，你們要解決我的問題呀！」

然而，已經開放「所有人」來問問題開放了一年，忍了一年已經夠了。

近期(3個月內)對傳進資料庫的建議或是抱怨，看起來集中在以下幾種： 1.覺得工具不好用(沒有關鍵字搜尋、自然語言機制或談話應用功能=超出開發團隊對工具的想像太多) 2.自己的問題得不到解答(使用者想知道的事情偏離謠言範疇太遠、需要的是客服人員、無法即時性回饋) 3.不想被騙，所以想讓line bot核實過所有自己收到的連結與資訊(限制在個人化的服務，尤其是抽獎或是購物優惠、主流媒體報導)

我可以理解使用者真的有疑問所以送出文章，不過使用者的”疑問”跟我們想像中的”懷疑”可能不太一樣。

自己有問題需要解決，跟找對了真的能解決這個問題的人其實是兩回事。 就像假如我睡太晚上班要遲到了，早餐店的阿姨借我車騎可以避免遲到的困擾，但他真正的工作仍然是早餐店，而我也不能一來不及就想著去早餐店借車。(?????) [https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512363529000124]

提出的解決方案

限縮「送出新文章功能」給白名單內 LINE bot 使用者作為「合作對象」。

其他 LINE bot 使用者只能查詢，找不到就只說找不到。

解法一：只開放編輯（在網站上回應過）的人能透過 LIEN bot 送新文章進來。

實務上，這可以透過在網站上實做 LINE login、取得 LINE user ID in channel 解決。>

希望能透過這層門檻，落實「不轉嫁成本」與「活化編輯系統」的理想。

Bil: 像是蘭姆酒吐司

解法二：只開放知道要送「轉傳訊息」、而且是送來「進行事實查證」的人送出新文章。

實務上，這或許可以透過檢視或追蹤一個使用者傳送過哪些句子、對這些句子做分析或設下明確規範（例：沒有送過過短訊息等）來達成。

這類的人即使沒有能力闢謠，也有能力幫忙篩選出「該進行事實查證」的文章傳進來。

對於這樣的合作對象給予信任，送了訊息就會整理。

Bil: 對於沒有能力或不想闢謠，但有謠言 source 的人，可以成為合作對象。

如果你認為有能力做到這件事情，跟我們聯繫我們發權限給你。

Hazel: 所以是透過 LINE 或網站

Bil: 可以，就是透過 LINE 或者是網站上可以做。

蝴蝶： 像 stackoverflow 累積積分嗎？

Bil: 累積積分要判斷他過去的文章，有點難做。 我們可以看資料庫，開給。

我們可以先關起來，不要讓他們輕易的送出文章。

查詢歸查詢，新增的人確保他有能力可以做到這件事情。

GGM: 我們可以偷偷記錄他茶的東西，不要讓他們上架在編輯那邊

蝴蝶： 這可以變成我們才可以看得到的判斷依據

GGM: 事後可以撈進來。

R: 白名單有點會降低我們的 credibility，因為查不到又傳不進來，使用者可能會下降。

Bil: 但傳進來還是不知道答案

R: 至少可能未來有。

GGM: 我們也可以說我們有新增，但其實沒有新增。這樣有沒有解決到 R 之前的問題？

R: 不能直接口頭警告說「你確定要上傳嗎？亂上傳會影響你的權益」

Hazel: 擔心的是，如果今天有一個事情在熱點上，會不會傳不進來。因為開放的人應該都是同溫層，這樣會導致其他人進不來。

Gore: 如果搭配剛才的，2 篇同樣的進來才觸發

6 篇回覆才有一篇會被 2 次查 被 2 次 request 的，就有 50% 的機會在被第三次茶 那我覺得 2 次查是不錯的

MrOrz: 網站上可以改成

R: 如果我們有使用者可以評價回應的功能 編輯可以看得到 那有沒有可能編輯也能對謠言做評價（OOXX）

Hazel: 現在是不是在擔心大家會隨便傳進來？ 如果傳進來的數量超過幾次，是被編輯被認定為不在查證範圍，那這個人就會被限制。

Lucien: 我們其實是想找 feature ban 掉不適合的文章。 然後我們想的 feature 有：人、傳進來的次數，還有編輯的評價。

DB migration 應該要有 hit rate

白名單有點嚴格，用的話會進入一個 maintain 期，等一些機智做完之後再來開放 像是進入緊縮期的 solution

Gore: 把網站的基準定成 2 篇以上 如果我們要求的效益是大量流通，這樣就完成了

另一個是，可能有人會去看「只有一則回報」的 一個可行的時機就是建黑名單 另一個是可能是找漏網之魚。

這樣好像就解決了大部分的問題

Lucien: 如果他 hit 已經回報但是沒有答案

MrOrz: 那他就會變成兩人回報。

MrOrz: 想確認一下 bil 的感受部分，最強烈的是什麼？

bil: 上面感受都在講同一件事，就是這些東西根本不會被查第二次。

MrOrz: 所以 Gore 提的

Lucien: hit rate 真的要用 analytics 做嗎？ 因為想要拉近資料庫，這樣才能知道編輯的努力是不是有成果的。

Replyrequest 其實只是「這則訊息有多急想要被知道」 但其實有可能 bi 有拯救一些人，只是你不知道。

還是另外蓋一個更簡單的 db，這種 record 類的

Bil: 另一個想法。 airtable 的時候，分類只有 3 個。 謠言、不是謠言、not article。

但現在的「含有正確訊息」可大可小 例如聯合報底下

Lucien: 新聞確實大多數的 幾乎都是事實陳述 可以是真的 但社論或娛樂就不一定

Bil: 一般新聞陳述事實就不會是謠言 但裡面有自己的想像、自己的想法，才會有可能變成謠言

Lucien: 但我們找不到一個好的 feature 來界定這個東西 例如說我們能不能用網址 但很明顯就是有 false negaive

如果把這些東西隔離出來呢

Gore: 例如說新聞的就抽成獨立的，不會在主列表裡面

Lucien: 然後判斷的基準是新聞網址嗎

Bil: 新聞有一種是採訪、即時訊息、

Lucien: 即時新聞、綜合報導，應該全都可以擋掉 ex: https://cofacts.g0v.tw/article/AWAQb2PMyCdS-nWhukGc

MrOrz: 那個像是複製的，不像是轉傳訊息。 所以可以擋掉

Luien: 以剛才的 case 來說，這種新聞的可以在 bot 就不讓他進來。

MrOrz: 那可以去 spreadsheet 試試看。

Lucien: 「綜合報導」可以擋調 17 個 「即時新聞」10個

還有一種做法是擋關鍵字 （做了一些嘗試，新聞稿之類的）

:::warning 〖TODO〗

:::success

  1. 網站（預設 filter）可以解決目前的問題
    • 見下面「預設 Filter」
  2. 需要 search result 的 analytics（hit rate），才能判斷一篇被回過的文章是否有第二人傳入。
    • 蝴蝶會做一份 article id -> search hit 數、article id -> impression 數的表 :::

網站 improvement：編輯小幫手

By Gore

https://g0v-tw.slack.com/archives/C2PPMRQGP/p1512477291000208

:::warning 〖TODO〗 Any feedback? :::

網站 improvement：預設 Filter

預設顯示 >= 2 人回報的文章，落實「優先處理高公益性」，讓編輯不要壓力山大。

MrOrz: 預設 filter 就像是網站的基本立場，就是我們不處理那些不是在 LINE 上面傳的、只處理 LINE 上會被重複傳播的。

MrOrz: 例如說官網現在的勾勾變成「顯示只有 1 人回報的文章」

:::warning 〖TODO〗 討論要做 / 不要做 :::

:::success 〖結論〗 要做。

LINE bot improvement：按鈕作用

主頁裡有使用者發問：

https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512138396000628

應該可以改按鈕吐的資料，讓 LINE bot 知道這是哪一步的按鈕回應

:::warning 〖TODO〗

資訊佈達：懶人包圖檔

前次會議記錄說可以用在主頁貼文與 welcome message

See: https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512064315000566

:::warning 〖TODO〗 討論形式、執行 :::

Review DB mappings

2017/12 版本

拆掉了原本規劃的 parent/child，通通用 nested object + 紀錄 count 之類的 cache field（denormalization）解決。 也因為拆了 nested field，所以原本的 replyconnection 就被吸納進 article 裡了 articles 現在變得無比巨大 XD 之後加上 URL preview 的網頁文字，應該會再更大

[https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512492395000360]

:::warning 〖TODO〗 Any feedback? :::