Try   HackMD

20171206 會議記錄

貼圖開會待討論事項

  • 說明貼圖使用時間：在Line對話中解任務獲得貼圖、原規劃中的24張貼圖會如何使用
    • 任務型貼圖：
    • Marketing：加好友，限時使用
    • 商城販售：
  • 素材們
  • 製作時程：
    • 製作團隊提出時程：
      • 風格設定 (3-5個工作天)：我們會先繪製初步的風格基礎做討論，12/12先確立了風格再往下進行。
      • 草稿繪製 (10-15個工作天)：風格確定後再針對各別的表情符號發想、繪製，發想的過程希望可以大家一起進行，如此一來更符合聯名的合作方式，也更能豐富圖的可能性。(12/31)
      • 貼圖繪製 (10-15個工作天)：草稿確定後會直接開始繪製至完成，但仍會保有些微修改的空間。(1/15)
      • 貼圖完稿 (2-3個工作天)：一旦圖面最終確認過後，我們會把檔案都弄到可上架使用的狀態。(1/20)
    • 推廣與使用時程：
  • 圖像使用的權利義務
  • 報價與合約

小聚

與人權有關的 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的入口

〖TODO〗

  • Feedback on the slides
  • 還有什麼沒做的宣傳嗎

限縮發文權利

黑名單機制

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

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

  1. 每個 LINE user 在 1 個月內最多只能送出有 3 則沒人回應的文章。在送出文章的時候，API server 會檢查這個時間點往前 1 個月內，這個使用者送出的文章裡，到底有幾篇還沒人回應，如果 >= 3 就禁止發文，並列出還沒回應的 article IDs。
  2. LINE bot 遇到 API server 禁止發文的狀況，就跟使用者說：
您過去這一個月內發的這些文章都還沒有人回應唷。請將資料庫資源留給其他需要的人：
（列出文章連結）
  1. 如果一個 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個

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

〖TODO〗

  • Discuss on the observations and solutions
  • Article submission data to aid discussion
    • 是否真的有「好使用者」、「壞使用者」的區隔？
    • 那些只傳一篇進來的人，他們都傳了什麼？
  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

〖TODO〗
Any feedback?

網站 improvement：預設 Filter

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

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

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

〖TODO〗
討論要做 / 不要做

〖結論〗
要做。

  • Lucien 實作預設 filter 修改。

LINE bot improvement：按鈕作用

主頁裡有使用者發問：

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

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

〖TODO〗

  • Shall we take this issue to issue tracker
  • If so, what's its priority

資訊佈達：懶人包圖檔

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

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

〖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]

〖TODO〗
Any feedback?

Last changed by 
 
Johnson Liang
0
780
Published on HackMD