20180207 會議記錄

小聚籌備

bil: 需要發感謝函嗎

hazel: 我來訂潤餅

bil: 目前人大概 12 個

hazel: 還要手動邀請人嗎
現在有誰咧

Mrorz: FB 再貼就好？

bil: 這次有什麼優惠嗎
來就送貼圖嗎

hazel:
我想問如果寫一篇新的文章然後 tag 來過的人會不會很擾人？
超像直銷

bil: 第一次不會
可以 tag 來過，但不是那麼熟的人

hazel:
行啊我跟大家都不熟啊

hazel 會寫文 tag 人
hazel 會準備食物

貼圖

GGM: 我去追殺一下

hazel: 貼圖不像完整的圖的話，加陰影是不是就好了？

Lucien: 就沒有描邊。

像這個貼圖是奇異筆的風格，我們的是水墨
但沒有奇異筆的部分，還是可以把邊弄出來
背景佔很大的，應該用個方法把整個背景填滿

「最新詐騙手法」已經不規則了，但邊緣還有白白的
「我剛剛看到這個」是邊的問題，袖子的陰影超怪的
either 是紙張拉大，不然「這個」位置很尷尬

「每一分鐘過去」這個已經滿版，填滿背景就好
「緊急通知」感覺也可以做滿版，或是不要地板
「認同請分享」是很標準的形式，但我不知道水墨邊在貼圖上要不要處理，但這是目前比較 acceptable 的
「朋友傳來的訊息」

orz:
我覺得「朋友傳來的訊息」與「這東西有毒」的邊緣都在角色上，做不規則邊緣就可以了
像是猴子貼圖「沒天理啊」的色塊那樣

那「一定要存起來」怎麼辦

Lucien: 那看得出來「這一定要存起來」是手臂嗎
Gore: 什麼，是手臂！顏色要更皮膚一點
Hazel: 其實我沒有看出來耶

orz:
水墨也是可以有顏色，只是看有沒有要像猴子的那麼重
猴子的真的很重

Gore: 幫手臂帶隻錶好了 XD
orz: 不畫手掌就看不出來是手臂

Orz:
貓咪那套貼圖的白邊很不錯
而且水墨風格跟我們比較接近

不過貓咪貼圖的灰色影子是單色色塊
我們的是真的水墨有漸層
顏色變少比較像貼圖

我們灰色影子改單色色塊他們會瘋掉嗎

Hazel：
可以問一下。

今天我們不知道他背景長怎樣
所以可以問問他們的看法

orz:
那就把我們的投影片給他們看

GGM 再去催 LINE
Hazel 與工作室溝通

編輯工作量（減少文章數）

Latest statistics

	2017/8 ~ 2017/9E	2017/10 ~ 2017/11E	2017/12 ~ 2018/1E
平均每週新文章	160	197	250
平均每週新回應	416	279	268
月底 LINE 使用者量	21536	22011	25947
平均每週傳送者	129	167	213
平均每週編輯者	12	13	12

先前「限縮發文權利」的 proposals

注意這些 proposal 都沒有提到實質的「剝奪發文權利」要怎麼做。

使用者發送過的文章列表

先前討論

Hazel
編輯沒什麼問題，使用者的資料我們會顯示在前端嗎

Bil:
我們有跟他講會送出文章

Hazel: 但沒有意識到，會公開說是「誰會送出來」

orz:
只會寫說是哪一個作id進來

gore:意義呢？

orz:投票機制做了，我有一些觀察，連續三邊或是資安新聞，每篇都闢謠，就會想為什麼有人對這個有意見，我會好奇是不是同一個人發
這個幾乎同一天傳進來三個url，但進去是同一個文章的

orz:老實講把文章連起來就是我覺得會有用的東西

hazel: 但可能會有使用者覺得不舒服
bil: 會要改一下說詞
gore: 但我還是不太清楚，感覺是會被定位到。不講沒有人會知道就是了。
bil: 像 dcard 有學校跟性別，但大致上匿名。跟這個一樣，只有 ID。
hazel: 我覺得不用那麼多
bil: 只要同一個來源的會被記錄，可以說方便我們整理資料。
hazel: 說法是可以的，因為我們有做到去識別化。但理由要想一下

[reference]: http://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252FrJdVIeuGG 2017/12/20 會議記錄

〖TODO〗
若要實作，則決定 priority。

目前預計開發項目：

Mappings refactor（75%）
提供「送出理由/爭點」
解析 URL 內容、放進資料庫一起 index

MrOrz:
我們之前有 po 過教學文
如果不照教學文，
要有實質的阻擋機制

GGM:
那是不是要實做「我傳過的文章」

Gore:
使用者可能不知道自己被 ban

GGM:
傳失敗的話就會知道
知道的話就會吐你傳過的文章
所以要有這個功能，你要看別人還是自己都看得到

Orz:
當初的脈絡是，想要公開編輯邊過的文
那要不要把使用者發過的文也發出來

Bil:
好

GGM:
所以要有這個才能做黑名單

Bil:
對

MrOrz:
我們有兩種黑名單 proposal：直接對文章，或對文章的理由

我想要先收理由再做這個

看到理由很瞎，就點這個人看

GGM:
也有可能大家的理由都不怎麼樣
「我很懷疑」「跟我想得不一樣」就送出

MrOrz:
那就 downvote 然後 ban 掉吧

GGM:
先做爭點跟先做文章都可以

如果先做文章的話，那之前有要做的是通知文章有被回應之類的
我們可以在 rich menu 裡面加個按鈕說「我之前傳過的文章且已被回應的」
先做文章列表有這個好處

MrOrz:
那先做個「列出一個人傳過的文章」API

〖結論〗

API 放在「送出理由/爭點」之前

高重複度文章處理方式

高相似度案例蒐集：https://github.com/cofacts/rumors-line-bot/issues/53

〖TODO〗
Proposal 1, proposal 2 選一個並決定 priority，或兩者皆採、或兩者皆不參採。

目前預計開發項目：

Mappings refactor（75%）
提供「送出理由」
解析 URL 內容、放進資料庫一起 index

這坡貼圖已經不想再回了

URL preview 是一個處理大量文章的比較好的方式，因為很多文章 URL 其實是一樣的
有 preview 比較協助判別是正面一樣還是負面一樣

Proposal 1: 新增「不送出文章」的相似度

目前 LINE bot 裡實作的是「直接視為同一篇文章」的相似度。

我們或許可以新增一個「超相近 threshold」，在高過這個 threshold 時，還是可以選擇搜到的文章，但無法送出文章。

Orz:我在想那個高相似度到底要多高，放寬的話要考慮，比如謠言列表。
貼圖有三種，我們那個可以稍微放寬，但不能寬到不同的文章標成同一種。
除了這個我可以再放一個，他跟某篇文章相近，但覺得他真的很近，我們就列出搜尋結果，可是不讓他可以送出新增文章。
這時候這兩個差在哪，如果資料庫只有一篇文章，另外1篇很相近，就算沒有一樣，bot還是直接幫她選這篇。
那什麼時候會不一樣哪，下面這種。

文A跟文B有點像，如果同時落在文A跟文B之間，跟文A跟文B都購進，所以我不會顯示可以新增到資料庫這件事情。

GGM:
那如果列出的文章有相似度 8 成、5 成、 3 成的文章
假設 threshold 是 8 成
那使用者就不能把文章送入資料庫
是這個意思嗎

MrOrz:
對

Proposal 2: 新增手動「關鍵字規則」

參考 https://hackernoon.com/more-than-a-million-pro-repeal-net-neutrality-comments-were-likely-faked-e9f0e3ed36a6 抓造樣造句的做法

作者除了統計之外，基本上是用了這些關鍵字來做分群。

提案：

由我們這裡建立「關鍵字規則」，符合關鍵字規則（同時有 N 個關鍵字、長度在多少以內），就回傳設定好的現有 reply。
因為關鍵字規則而擋住發文的時候，公布這些規則（可能直接指到 github 上某個檔案）。
另外提供一個管道（google form / email 之類的），當使用者覺得這文章可以進來的時候填寫。
「關鍵字規則」本身可能是個 yml 或 markdown 之類的容易編寫的格式，方便任何人直接在 github 上編寫並且送 PR。
要有 script 自動驗證「關鍵字規則」，在 CI 上執行，列出資料庫內符合「關鍵字規則」的文章，供 PR reviewer 審閱。

Gore:
其實是滿即時性的

我覺得感覺會需要在網站上有個視窗邊寫這個

但我可以理解要發 PR 的需求

如果不是 PR，
我要怎麼過濾重複性
如果即時上傳關鍵字，
就是網址、關鍵字，
這樣去做關鍵字串連
需要人工審核

Orz:
因為你要有足夠多篇才能看規則
放個一兩天累積我覺得 ok

GGM：
可以解決過往發生很多的資訊
以及短期內大量出現的文章
PR 比較沒那麼急時，晚一天兩天
但可以解決未來的問題

只是關鍵字規則會不會不容易寫成 YML
因為關鍵字可能是五個形容詞中存在三個就中
在 YML 裡面比較難表現

BTW:
可以用 whitelist / blacklist 並行
「全部出現就擋住」「但如果有這些出現就可以」

GGM:
還是寫成 regex

BTW:
regex 是比較 general 的做法

orz:
我舉的例子其實就是 regexp

YML 我想到的是類似 elasticsearch
訂個 must / should 還有 minimum_should_match 的語法（"5<70%"）
寫個文件就可以定下來

GGM：
我在想是不是可以做成 middleware
大家送 PR 是送個 middleware
XXXrule.js，回傳要不要篩掉
那所有 rule 就是所有 middleware 串起來，看最後會剩下什麼

orz:
當然這樣會最彈性
只是你還是要訂 middleware 的 API
要有個機制是「被擋住沒道理的時候要送意見」就行

台北捷運的貼圖，我們設定說「看到這個url就是正確訊息」
有沒有故意放不實訊息，配上這個url，問說確實有這個東西？
bil:
我們沒有能力來做這個事情

他是謠言的變形
像我今天看到的謠言，他說是真的
所以我都要打開來測試看看是不是假的
這其實是很耗費人力的

如果是謠言的變形，就變成人力一個一個審核

ggm:
假設台北捷運有五個好了
假設前四個有被回應了
第五個沒辦法找到前面的答案

Orz: 即使能找到前四個，使用者依然不會想選

R: 「相似度」可以調整，讓他比較想要選

Hazel: 例如說給他「高」「中」「低」

Bil: 如果把相似度藏起來呢

Hazel: 那會更不會選

Bil: 可能只能擋起來

GGM:
如果關鍵字那個

R: 我們可以先試試看，把相似度的數字調高，看看會不會就能減少

MrOrz: 可以先把相似度開根號 * 10

R: 說不定這樣就可以讓大家不傳進來

Gore: 如果是惡意變造
他一定是附上一個正確的網址，加上他想被確認為正確的
如果回應顯示的夠清楚，
例如說「此則貼圖是有的」
那被惡意加註的文章就沒被回答到
使用者也會覺得怪怪的

orz:相似度的辦法這個有效或無效我們有辦法調整嗎？
看之前點擊相似度的機率，爬log，相似度到幾使用者會點？

bil: 如果說相似度到個 30 就不讓他送出呢

orz: 就是 proposal 1 得值是 30

lucien：我覺得有看過很高但不一樣的

bil: 那如果顯示哪一則有回過呢？

orz: 顯示「有回過」會增加他選擇文章的意願嗎

bil: 會。

ggm: 好處是什麼

orz: 大家會想要選

ggm: 壞處是他選了個相似度低，但有回應的，
他就會按叉叉

如果他看不到是否有回應，就會選相似度高的那個

orz: 我們就會多一個 request

ggm: 如果他選了相似度低的，那我們就收不到那個 request，而且會投錯叉叉

orz:
相似度 log 就是

相似度

蝴蝶做分析相似度：

判斷「下列哪一篇是你查詢的文章」時

選 0 的使用者，當時使用者看到的最高相似度是多少
選了文章的使用者，他按的相似度是多少

這也可以算 hit rate，(選了文章 / (選文章+選新增))

Proposal 1

GGM 先做
Threhsold sample 參考
https://github.com/cofacts/rumors-line-bot/issues/53

編輯去識別化（提升編輯意願）

hazel: 現在編輯幾乎都是用人名、連動 ID 名稱，讓編輯選擇自我要去識別化。可以預設連動。

我覺得小東西啦。

[reference]: http://beta.hackfoldr.org/cofacts/https%253A%252F%252Fhackmd.io%252Fs%252FrJdVIeuGG 2017/12/20 會議記錄

Hazel: 其實我不介意用本名

Bil: 會覺得如果可以改名字會比較輕鬆嗎

Hazel: 忘記當初的 context 是什麼
匿名到底會不會比較踴躍
還是比較不負責任

但我們知道是誰，所以我們還是找得到這個人
那就開放

Bil:
我覺得要公平
既然文章是匿名
那回應也要給他機會
不然回應要把自己的資料公開到這個程度比較不公平

Hazel:
我覺得這個功能不是最重要的，如果有其他重要的事情可以先把它完成

Bil:
小聚有人為了這個
換了帳號來回

Hazel:
我覺得這是個人選擇

Bil:
基於關心編輯，
可能有人顧慮說自己怎麼在幫爭議文章寫回應
會不會有這樣的情況這樣

MrOrz:
看改名字要排在哪裡
網站跟 API 都要改
API 是不太難

結論：蝴蝶實做 API
https://github.com/cofacts/rumors-api/issues/64

提案：API server + website 讓使用者能更換 display name

〖TODO〗
若要實作，則決定 priority。

目前預計開發項目：

Mappings refactor（75%）
提供「送出理由」
解析 URL 內容、放進資料庫一起 index