---
tags: cofacts, meeting note
---
20181219 會議記錄
====
> 前次會議記錄：https://g0v.hackmd.io/s/H1Ty4PRkE
## Dev items
### Chatbot issue: Puppeteer 斷線
https://github.com/cofacts/url-resolver/issues/9
處置包含：
- url-resolver 內置 rollbar
- chrome 斷線後重新啟動 puppeteer
- 已有處置：docker memory limit + always-restart
觀察：
12/19 又出現一次 disconnect @@
### LIFF
PR: https://github.com/cofacts/rumors-line-bot/pull/116
已經上 [staging](https://line.me/R/ti/p/%40nkq3195z)
需要測試的路徑有：
- 轉傳資料庫沒有的東西 -> 打開 LIFF -> 放棄送出
- 轉傳資料庫沒有的東西 -> 打開 LIFF -> 填寫理由送出
- 轉傳資料庫沒有、但有類似的訊息 -> 選擇「這裡沒有我的訊息」 -> 打開 LIFF -> 放棄送出
- 轉傳資料庫沒有、但有類似的訊息 -> 選擇「這裡沒有我的訊息」 -> 打開 LIFF -> 填寫理由送出
- 轉傳資料庫裡有、但沒人回應的訊息 -> 打開 LIFF -> 放棄送出
- 轉傳資料庫裡有、但沒人回應的訊息 -> 打開 LIFF -> 填寫理由送出
- 轉傳資料庫裡有、也有人回應的訊息 -> 按「沒有幫助」打開 LIFF -> 放棄送出
- 轉傳資料庫裡有、也有人回應的訊息 -> 按「沒有幫助」打開 LIFF -> 填寫理由送出
發現：如果使用者 user consent window 按取消，其實也不會 403，
下一次還是會跳出 user consent window
- - -
問題 1：使用者可以打開 LIFF 兩次，
送兩個理由，第二個理由會變成新訊息送出。
解法：
最好是在 LIFF 裡面就能打 API 得知目前使用者是否可以繼續送出理由，如果不行，就把 form 藏起來。
--> new ticket: https://github.com/cofacts/rumors-line-bot/issues/117
問題 2：LIFF 內的「放棄送出」其實可以拿掉。
沒有異議，可以拿掉。
問題 3：wording 改成「請查證」，又必填，會不會就讓他們不送了？現在連 replyRequest 也要先查證。
文武：
如果是我可能就不填了
Bil:
你覺得你可以處理多少這樣的文章
文武
有時候其實不用查
Bil
現在好友有 70000 人
文武
如果增加門檻，那謠言會比較晚進來
Bil:
謠言會晚不是擋的問題，當超過 50000 人，scale 不一樣，就應該要有不一樣的做法
Lucien:
我也覺得太嚴格了
如果是必填的狀況下，扣掉下一篇理由送出的 case，這樣還有很多的量嗎？
Bil:
一週 300 篇，一個月 1200 篇
Lucien:
如果變成表單的話，下一篇就不會是理由
現在的狀況是，下一篇會被當成理由，這篇訊息才會進入資料庫
如果改成表單，那他就會連送都不送
所以理論上會低於 300 篇。
一個簡單的 case 是，他一樣是打理由好了，它問理由送出來，說不定數字就下降了
Bil:
但好友一直上升所以不行
Lucien
要分群，可能不是這些使用者都會送
Bil
新的 user 似乎都會寫
Lucien
所以如果先上 LIFF 然後用理由來觀察狀況，看看數量會變怎樣
有表單之後，理由可以在設計成有樣版的
比鄰在想的有兩個議題
一個是傳錯
另一個是隱含說想要在 ＬＩＮＥ初步查證、減低編輯查資料的負擔
這兩個問題是不重複又涵蓋最大的嗎
如果理由裡面有他初步查證的結果，對編輯帶來的幫助是什麼？
Bil
這個跟編輯沒有關係
Ｅｌｖｉｓ很想知道除了登入網站有沒有幫忙查證
他就誤會了用法，但這做法還不錯
因為不用登入到網站，就能在 LINE bot 闢謠
這可能是另一個問題，因為網站的介面不是很可親，大家看到就嚇一跳不會用
如果他很熟悉，知道 LINE 介面
Lucien
那他們怎麼知道現在有什麼謠言？
Ｂｉｌ：
使用的方式是，它看到謠言，傳進來，然後在理由填澄清
Lucien
那感覺是 ＬＩＮＥ 要多個查證的 flow
orz:
如果現在請他們填理由，卻會有查證，那我們繼續寫「請填理由」應該就可以，優秀的使用者會繼續用這個查證
Lucien:
或許需要分開的 flow
Bil:
我其實比較想要做媒體識讀
「我就是想知道」這不是媒體識讀
「我看不懂這篇文章所以請幫我看」
文武
所以是因為看到這種理由覺得生氣
因為我看到這種也是很不想回
但我可以原諒他
Bil:
我們希望填理由就是希望使用者先做反省
但如果他只填「理由」二字
文武
另外就是它有阻止她隨便送文章進來
填個理由是有用的
上一次改版之後 UX 的問題
另外還有就是把理由很爛的先標記他
有些人是看到新聞就傳進來
什麼英國研究傳進來真的假的，我看一下就不會想理他
如果做個標記，看完會被放到 low priority
Ｏｒｚ
讓理由被 downvote 的訊息放到其他地方
或者是讓理由太爛的人不要新增
都可以
:::info
1. 先做完 https://github.com/cofacts/rumors-line-bot/issues/117
2. 拉新的 log 來判斷
:::
### Other Cofacts dev items
#### Cofacts organization 功能
MVP：手動塞 organization
#### LINE user 往回卷可以按按鈕
> LINE user 目前不缺，所以往後
#### Cofacts 網站
### 我愛家我解惑
處理 URL，做到「搜尋 URL 後，如果資料庫內有逐字稿，就回傳逐字稿」的功能
## 開會時間修改
Bil:
近半年來出席率不太理想
現在的組成也跟開始的不一樣，可以重新討論禮拜三
說不定現在有大家更有空的時間
或者是大家不喜歡每週，會不會兩個禮拜一次、一個月一次
目的是既然要開會就要有效率
希望開會時間減短、盡量讓更多人參加
不然對出席率高的人來說有點浪費時間
既然要開會的話會希望大家都來
禮拜三其實一直都是撞 vtaiwan，如果不在禮拜三，說不定會有更多可能性
8pm 開會 9pm 才到的話，會變成是要等他
這是沒有效率的一件事情
希望可以在 1~2hr 內結束
Orz:
今天內容確實比較多，但之前確實比較少
Lucien:
要不要拆會
分成收集需求的 & 開發的 & 採訪、活動類
每個都很短，或是線上討論
Orz:
開發的會比較需要 face-to-face
但現在都是我做完之後大家測一測
Lucien:
這隱含了 motivation 的部分
Orz
另外一種做法可能是變成萌典松的形式
一個月一次很長的，半天的時間，半天空下來就可以做點事情
可能會變慢，但也可能有不一樣的地方
bil:
多久見一次、多長、哪一天
這個可以線上投票決定
希望有固定的時間，見到最多人，達到會議的目的
現在雖然每個禮拜見一次，但成果跟每個月見一次差不多
如果每一次人都不一樣那溝通成本會比較高
因為不是每次都會有人看上一次的會議記錄
Lucien
可能 leader 會需要跟每個人 1-on-1 比較好
最後什麼時間見一次那些是偏向 what 的層級，是最後的決定
做公益類的狀況是，leader 確實會沒有約束大家的能力
HackNTU 的部分是因為名氣，可以寫進履歷
Cofacts 是有機會的
但其他做法會有點 manipulative
Orz
萌典松的狀況是，大家一個月就是空出一段時間做事情
沒做完的事情，可能接下來幾天會補完，然後就沒他的事情了。
這樣的缺點可能是決策會比較慢，一個月才能做一次
Lucien
但要做決策其實可以線上處理
編輯的部分很難
選舉給我的感覺是，要有拿聖經去傳教的人
但我們最多就只是個做聖經的人
可能性還是很多，還是有個勢
會有操作的方法
編輯方向比較像是
organization 應該是主力，其他事散戶
對我們來說，我們能把 dark social 的東西浮現出來是有價值
有一些高爭議謠言比較高爭議，可以吸引散戶下去回
bil:
婚姻平權的謠言很多，大家看到都很生氣，但不會回就是不會回
大家會覺得做這件事情不是自己，大家對回這個沒有自信
lucien:
臉書上大家會回嗎
bil:
不太會
Lucien
開發的方面就是
覺得有不有趣、能不能得到東西，
data scientist 看能不能有什麼外包
設計的話，出一個 functional css style set，可以先直接用
:::info
1-on-1 聊參與情況與形式
- 小松
- 跟 vtaiwan 併
:::
## 小聚
1/19 補班
2/2 ~ 2/10 過年
2/23 補班
3/9 大松
- 1/26, 27 or 2/16, 17
大松 3/9
## RightsCon Proposal
- Lightning talk
## 12/21 電腦公會
## 12/22 座談會 by 永社
https://www.facebook.com/events/528329937666399/
- Bil