20180207 會議記錄
====

## 小聚籌備

bil: 需要發感謝函嗎

hazel: 我來訂潤餅

bil: 目前人大概 12 個

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

Mrorz: FB 再貼就好？

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

- - -

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

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

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

:::success
* hazel 會寫文 tag 人
* hazel 會準備食物
:::

## 貼圖

GGM: 我去追殺一下

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

Lucien: 就沒有描邊。

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

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

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

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

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

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

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

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

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

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

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

Hazel：
可以問一下。

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

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

:::success
* 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
1. [LINE user 黑名單、白名單機制](https://hackmd.io/s/S1zuSP--G#%E9%BB%91%E5%90%8D%E5%96%AE%E6%A9%9F%E5%88%B6)
2. [對文章做 downvote，若 downvote 太多就 ban 發文 LINE user](http://beta.hackfoldr.org/cofacts/https%253A%252F%252Fdocs.google.com%252Fdocument%252Fd%252Fe%252F2PACX-1vQTgQtH5W-Co4UX--1bV8CBRbklr\_kSYppCIlLpJ0W3x0BnPET0zJN50lx0P\_MyyK-KHVCYuO2RkWyG%252Fpub)
3. [詢問爭點，若被認為理由不充分就剝奪發文權利](https://hackmd.io/s/HJEGZfmVM#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)

注意這些 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 會議記錄

:::warning
〖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

:::success
〖結論〗

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

### 高重複度文章處理方式

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

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

目前預計開發項目：

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

R:

這坡貼圖已經不想再回了

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 抓造樣造句的做法

作者除了統計之外，基本上是用了[這些關鍵字](https://pastebin.com/YvR0zjXy) 來做分群。

提案：
1. 由我們這裡建立「關鍵字規則」，符合關鍵字規則（同時有 N 個關鍵字、長度在多少以內），就回傳設定好的現有 reply。
2. 因為關鍵字規則而擋住發文的時候，公布這些規則（可能直接指到 github 上某個檔案）。
3. 另外提供一個管道（google form / email 之類的），當使用者覺得這文章可以進來的時候填寫。
4. 「關鍵字規則」本身可能是個 yml 或 markdown 之類的容易編寫的格式，方便任何人直接在 github 上編寫並且送 PR。
5. 要有 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 就是

:::success

### 相似度

蝴蝶做分析相似度：

判斷「下列哪一篇是你查詢的文章」時
- 選 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 是不太難

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

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

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

目前預計開發項目：

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