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 時,還是可以選擇搜到的文章,但無法送出文章。 ![圖解](https://docs.google.com/drawings/d/e/2PACX-1vRRhF88fGKNwkpn6I_rKIdGojl8KZudOSfzHaJexIjQbINHFGQypZMhMOxGKu59yhuTcbtOqWjhmpFb/pub?w=742&h=667) 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 :::