20171206 會議記錄 ====== ## 貼圖開會待討論事項 * 說明貼圖使用時間:在Line對話中解任務獲得貼圖、原規劃中的24張貼圖會如何使用 * 任務型貼圖: * Marketing:加好友,限時使用 * 商城販售: * [素材們](https://hackmd.io/s/HkBaYwrbM) * 製作時程: * 製作團隊提出時程: * 風格設定 (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的入口 :::warning 〖TODO〗 - Feedback on the slides - 還有什麼沒做的宣傳嗎 ::: ## 限縮發文權利 ### 黑名單機制 與懶人包搭配使用,作為「不按照懶人包服用」的懲罰機制 > 我想提一個 throttle 進來留言的提案如下,裡面的數字是憑感覺抓的,都可以再討論: > 1. 每個 LINE user 在 1 個月內最多只能送出有 3 則沒人回應的文章。在送出文章的時候,API server 會檢查這個時間點往前 1 個月內,這個使用者送出的文章裡,到底有幾篇還沒人回應,如果 >= 3 就禁止發文,並列出還沒回應的 article IDs。 > 2. LINE bot 遇到 API server 禁止發文的狀況,就跟使用者說: ``` 您過去這一個月內發的這些文章都還沒有人回應唷。請將資料庫資源留給其他需要的人: (列出文章連結) ``` > 3. 如果一個 LINE user 在 1 個月內發出的文章中,有 N 則被標為「不在查證範圍」,那麼該使用者 1 個月內能送出的沒人回應的文章量就減 N。例: 例ㄅ:使用者 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: 像是蘭姆酒吐司 ##### 解法二:只開放知道要送「轉傳訊息」、而且是送來「進行事實查證」的人送出新文章。 > 實務上,這或許可以透過檢視或追蹤一個使用者傳送過哪些句子、對這些句子做分析或設下明確規範(例:沒有送過[過短訊息](https://github.com/cofacts/rumors-line-bot/issues/39)等)來達成。 這類的人即使沒有能力闢謠,也有能力幫忙篩選出「該進行事實查證」的文章傳進來。 對於這樣的合作對象給予信任,送了訊息就會整理。 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](https://docs.google.com/spreadsheets/d/1mt_qSDYTKtCd8BMZNICjRaIvcEzpYiY3BphQq5BTrn8/edit#gid=1515239237&fvid=700614709) 試試看。 Lucien: 「綜合報導」可以擋調 17 個 「即時新聞」10個 還有一種做法是擋關鍵字 (做了一些嘗試,新聞稿之類的) :::warning 〖TODO〗 - Discuss on the observations and solutions - [Article submission data](https://docs.google.com/spreadsheets/d/1mt_qSDYTKtCd8BMZNICjRaIvcEzpYiY3BphQq5BTrn8/edit#gid=0) to aid discussion - 是否真的有「好使用者」、「壞使用者」的區隔? - 那些只傳一篇進來的人,他們都傳了什麼? ::: :::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 〖結論〗 要做。 - Lucien 實作預設 filter 修改。 ::: ## LINE bot improvement:按鈕作用 主頁裡有使用者發問: https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512138396000628 > 應該可以改按鈕吐的資料,讓 LINE bot 知道這是哪一步的按鈕回應 > :::warning 〖TODO〗 - Shall we take this issue to issue tracker - If so, what's its priority ::: ## 資訊佈達:懶人包圖檔 > [前次會議記錄](https://hackmd.io/s/S1myozixz#welcome-message)說可以用在主頁貼文與 welcome message See: https://g0v-tw.slackarchive.io/cofacts/page-26/ts-1512064315000566 :::warning 〖TODO〗 討論形式、執行 ::: ## Review DB mappings [2017/12 版本](https://hackmd.io/s/BkxbQ8ZbM) > 拆掉了原本規劃的 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? :::