#cofacts
2017-03-01
更新一下現況
1. https://g0v-tw.slack.com/archives/rumors/p1487180573000168 這個實作完成了。已經更新 seed script。
2. API server 已接好 Facebook, twitter 與 github login
3. API server 也寫完了現階段會用到的 mutation API
3/4 大松前預計的時程：
* 3/1 晚上：將 LINE bot 接上 mutation API，然後更新 production DB、API server 與 bot server。這樣一來，我們會從 airtable 完全斷開，通通上 elastic search！（反正現在 airtable 太大了，應該沒有人會在上面協作⋯⋯）
* 3/2 晚上：將 mutation API 接上協作介面。實作 elastic search 本機備份。（異地備份目前還沒想法 @@）
* 3/3 晚上：寫投影片。
1. https://g0v-tw.slack.com/archives/rumors/p1487180573000168 這個實作完成了。已經更新 seed script。
2. API server 已接好 Facebook, twitter 與 github login
3. API server 也寫完了現階段會用到的 mutation API
3/4 大松前預計的時程：
* 3/1 晚上：將 LINE bot 接上 mutation API，然後更新 production DB、API server 與 bot server。這樣一來，我們會從 airtable 完全斷開，通通上 elastic search！（反正現在 airtable 太大了，應該沒有人會在上面協作⋯⋯）
* 3/2 晚上：將 mutation API 接上協作介面。實作 elastic search 本機備份。（異地備份目前還沒想法 @@）
* 3/3 晚上：寫投影片。
Johnson Liang
所以我想要把現在 articles 裡面儲存 `replyIds[]` 的做法 (has-and-belong-to-many)
更新成 articles 裡面儲存 `replyConnections[]`
(一樣是 has-and-belong-to-many)
每個 connection 會是個 object `{replyId: "要連結的 reply ID”, userId: “哪個小編建立的連結", feedbacks: [{評價 good / bad, 使用者 ID}]}`
舊版本有，但新版本還沒放進去所以會暫時失效的東西包含
1. 新聞小幫手 integration：原本 line bot 會去問新聞小幫手，但新版的還沒實作這個部分。
2. 查詢爬蟲結果：⋯⋯就還沒寫。
1. 新聞小幫手 integration：原本 line bot 會去問新聞小幫手，但新版的還沒實作這個部分。
2. 查詢爬蟲結果：⋯⋯就還沒寫。
投影片是不是要分工一下
你是做招募小編嗎？然後我來做招募爬蟲手？
3分鐘報告捏
超趕
你有想講的東西嗎
我本來打算把專案現況講一講就好
然後徵求的人會包含前端工程師
我明天晚上應該沒辦法把 rumors-site 寫完
只能讓他會動
但小編們必須要具備閱讀 JSON 的能力才能進行協作之類的⋯⋯
只能讓他會動
但小編們必須要具備閱讀 JSON 的能力才能進行協作之類的⋯⋯
本來是想禮拜五才寫 slide 的說 ._.
我先寫 code
從早寫到晚的 mrorz
2017-03-02
噢
好啊
2017-03-01 17:37:11.769 173 <190>1 2017-03-01T17:37:11.460065+00:00 app web.1 - - 54.251.34.67 - - [01/Mar/2017:17:37:11 +0000] "GET /ping HTTP/1.1" 200 4 0.0022 2017-03-01 17:37:17.897 289 <158>1 2017-03-01T17:37:17.713579+00:00 heroku router - - at=info method=GET path="/ping" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=e2af8950-e739-4e9c-9fc6-2b18d4b9dd4a fwd="50.112.95.211" dyno=web.1 connect=27ms service=31ms status=200 bytes=195 2017-03-01 17:37:39.534 175 <190>1 2017-03-01T17:37:39.162001+00:00 app web.1 - - 54.248.250.232 - - [01/Mar/2017:17:37:39 +0000] "GET /ping HTTP/1.1" 200 4 0.0096 2017-03-01 17:37:59.749 422 <134>1 2017-03-01T17:37:21+00:00 app heroku-redis - - source=REDIS sample#active-connections=1 sample#load-avg-1m=0.055 sample#load-avg-5m=0.085 sample#load-avg-15m=0.085 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12666692.0kB sample#memory-cached=998776kB sample#memory-redis=283088bytes sample#hit-rate=0.86988 sample#evicted-keys=0 2017-03-01 17:39:47.895 287 <158>1 2017-03-01T17:39:47.594153+00:00 heroku router - - at=info method=GET path="/ping" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=82ce6174-54b1-4ae0-99b6-98a678a40d74 fwd="50.112.95.211" dyno=web.1 connect=1ms service=7ms status=200 bytes=195 2017-03-01 17:43:03.802 421 <134>1 2017-03-01T17:42:16+00:00 app heroku-redis - - source=REDIS sample#active-connections=1 sample#load-avg-1m=0.055 sample#load-avg-5m=0.095 sample#load-avg-15m=0.09 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12666452.0kB sample#memory-cached=998788kB sample#memory-redis=283088bytes sample#hit-rate=0.86988 sample#evicted-keys=0 2017-03-01 17:44:02.284 422 <134>1 2017-03-01T17:43:30+00:00 app heroku-redis - - source=REDIS sample#active-connections=1 sample#load-avg-1m=0.155 sample#load-avg-5m=0.115 sample#load-avg-15m=0.095 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12666464.0kB sample#memory-cached=998780kB sample#memory-redis=283088bytes sample#hit-rate=0.86988 sample#evicted-keys=0 2017-03-01 17:44:48.026 174 <190>1 2017-03-01T17:44:47.659926+00:00 app web.1 - - 50.112.95.211 - - [01/Mar/2017:17:44:47 +0000] "GET /ping HTTP/1.1" 200 4 0.0023 2017-03-01 17:44:48.026 287 <158>1 2017-03-01T17:44:47.658746+00:00 heroku router - - at=info method=GET path="/ping" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=1079daf0-fe05-44ba-8769-afae13e900ff fwd="50.112.95.211" dyno=web.1 connect=0ms service=7ms status=200 bytes=195 2017-03-01 17:47:17.891 287 <158>1 2017-03-01T17:47:17.618557+00:00 heroku router - - at=info method=GET path="/ping" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=f2b89edb-a80b-4e51-81f7-3207c0c53bbd fwd="50.112.95.211" dyno=web.1 connect=0ms service=3ms status=200 bytes=195
現在 API、LINE bot 與 database 都是最新的資料了，可以在 http://rumors.hacktabl.org/ 看到最新的 rumor 資料～～
Airtable 的編輯權限已經全數收回，明天晚上來實做編輯界面。
known issue of new LINE bot:
Airtable 的編輯權限已經全數收回，明天晚上來實做編輯界面。
known issue of new LINE bot:
1. 訊息裡面如果有 emoji 的話好像會過不了 LINE signature check。我是看網路範例的，但大概網路範例沒有處理 emoji 吧⋯⋯ @@
2. 對同一篇文章送兩次 reply request 好像會讓 bot 回「糟糕，bot 故障了。可以再傳一次嗎？ QQ」。
上面 1, 2 修掉惹
TODO:
a. LINE bot 的 message drain (把使用者 log 塞進 s3)
b. elasticsearch 的 backup
c. 確認透過 LINE bot 蓋出來的 article, reply request 的 `from` property 是 `RUMORS_LINE_BOT`
a. LINE bot 的 message drain (把使用者 log 塞進 s3)
b. elasticsearch 的 backup
c. 確認透過 LINE bot 蓋出來的 article, reply request 的 `from` property 是 `RUMORS_LINE_BOT`
投影片需要幫忙嗎
我應該明天晚上才會做 slide 唷
會從過去的 Slide 來改
會從過去的 Slide 來改
基本上介紹現在 line bot 的操作流程 ( 有很多步 ) 就會花到一半的時間
剩下來要講超快
剩下來要講超快
一張 slide 15 秒的話只能講 4~6 張
所以不用為大松準備太多 slide
反正我也講不完，所以我 prefer 自己處理，講得比較順
反正我也講不完，所以我 prefer 自己處理，講得比較順
倒是 3/6 的 slide 你們可以想想要如何處理
你們應該會需要數字
要由我這裡開權限，例如說 line official account 的使用數字等等
你們應該會需要數字
要由我這裡開權限，例如說 line official account 的使用數字等等
好喔
上面 1, 2 修掉惹
2017-03-03
沒問題 我是還沒有想 grant 要報什麼 不過應該是還好 XD
所以 mrorz 你明天會去大松麻
yep
早上會上台
yep
晚點才會來弄 crawler 的東西
然後其實 grant
```每組將有 3 分鐘介紹自己的提案， 15 分鐘的 Q&A 時間，不需要做影片。
期待您的提案！```
期待您的提案！```
也是要講超快 哈哈
不過應該是還好 XDD 我覺得要準備一些東西等著 Q&A
啊靠杯 我發現
這篇的權限是錯的 XDDD
大家都看不到
算了 哈哈
3 分鐘根本就是
介紹現況
given $$，未來會怎樣
end
這樣 XDD
介紹現況
given $$，未來會怎樣
end
這樣 XDD
晚一點再修
現在先弄個大綱
一張只能講 13 秒
我在想需不需要法律諮詢
主要有下面這些問題：
1. 如果 article 來源是網路文章（輸入到系統，未來才能做「回應 segment」），那附網址全文轉貼是 ok 的嗎？可以主張合理使用嗎？
2. 承上，如果有文章被標記「禁止轉載」呢？
3. 如果有人轉傳了私密訊息到資料庫裡面，受害者要求刪除，我們的步驟是什麼呢？
4. 如果有利害關係人因為假訊息被踢爆而名譽受損，利害關係人要求刪除平台上闢謠文章，那我們要如何處理呢？（亦即求職天眼通日前的狀況的加強版）
主要有下面這些問題：
1. 如果 article 來源是網路文章（輸入到系統，未來才能做「回應 segment」），那附網址全文轉貼是 ok 的嗎？可以主張合理使用嗎？
2. 承上，如果有文章被標記「禁止轉載」呢？
3. 如果有人轉傳了私密訊息到資料庫裡面，受害者要求刪除，我們的步驟是什麼呢？
4. 如果有利害關係人因為假訊息被踢爆而名譽受損，利害關係人要求刪除平台上闢謠文章，那我們要如何處理呢？（亦即求職天眼通日前的狀況的加強版）
好像需要耶 … 我可以幫問
```UberEATS 3月6日南港正式開動！
誰說南港是美食沙漠！？
您的美食外送首選 - UberEATS ，進駐南港！
南港的朋友有福啦！3/6-3/10 整週免服務費！
多間精選餐廳，豐富美食任君挑選！
UberEATS 將於 ( 3月6日 ) 在南港正式開動！
37分鐘內，美食火速送達！```
誰說南港是美食沙漠！？
您的美食外送首選 - UberEATS ，進駐南港！
南港的朋友有福啦！3/6-3/10 整週免服務費！
多間精選餐廳，豐富美食任君挑選！
UberEATS 將於 ( 3月6日 ) 在南港正式開動！
37分鐘內，美食火速送達！```
所以明天可以叫了 XD?
2017-03-04
http://rumors.hacktabl.org 的登入遇到了怪問題
理論上根據我這裡的實做 https://github.com/MrOrz/rumors-api/blob/master/src/auth.js#L141
api.rumors.hacktabl.org 在做 FB 登入時，會先造訪 /login/facebook
此時我會在 cookie session 寫入 `appId` 與 `redirect` 兩筆資料
但奇怪的是，從 facebook redirect 回來之後，https://github.com/MrOrz/rumors-api/blob/master/src/auth.js#L167 這裡卻讀不到 cookie session （印出 `ctx.session` 是 `{}`）
但登入在 localhost 卻會 work⋯⋯ orz
理論上根據我這裡的實做 https://github.com/MrOrz/rumors-api/blob/master/src/auth.js#L141
api.rumors.hacktabl.org 在做 FB 登入時，會先造訪 /login/facebook
此時我會在 cookie session 寫入 `appId` 與 `redirect` 兩筆資料
但奇怪的是，從 facebook redirect 回來之後，https://github.com/MrOrz/rumors-api/blob/master/src/auth.js#L167 這裡卻讀不到 cookie session （印出 `ctx.session` 是 `{}`）
但登入在 localhost 卻會 work⋯⋯ orz
Hello 我是第一個報告者
抱歉今天早上會遲到好一陣子 (現在才在頂溪捷運站 orz)
請先到的坑主先報告 QAQ
- 😉1
@ggm crawler 想要徵什麼樣的人呢？
@lucien 我們有需要其他 UX designer 嗎
@lucien 我們有需要其他 UX designer 嗎
應該不用吧，如果我有正常生產力的話，FE人力應該也不會差太多
https://docs.google.com/presentation/d/1qCEoiVJBBfDwsNqTDKUF2RnCv3LQmvzdesNsVTTZqq0/edit?usp=drivesdk
Slides done
但還沒整理 Github issue
Slides done
但還沒整理 Github issue
你們在哪邊啊
@ifengc has joined the channel
@quad has joined the channel
@lucien 這邊
😄
呃啊抱歉我今天不會過去 … 我現在在上吐下瀉中 orz
- 😱3
保重啊
我晚上或明天跟大家 sync 一下狀況 我先來去看醫生 orz
- 💊4
Where is the credential of rumor-api @mrorz ?
我發了 2 個 pull request, 再麻煩有空時 reivew 看看
我也發了兩個PR：
感謝 linekin 與 quad ：Ｄ
剛才回覆囉
剛才回覆囉
@mrorz 剛才回覆你回答
Merged! Thank you
Hi all,
I have updated README for
https://github.com/mrorz/rumors-line-bot
https://github.com/mrorz/rumors-api
https://github.com/mrorz/rumors-deploy
hoping to iron out the bumps we ran into today.
Thanks for the help from you guys. You are awesome!
I have updated README for
https://github.com/mrorz/rumors-line-bot
https://github.com/mrorz/rumors-api
https://github.com/mrorz/rumors-deploy
hoping to iron out the bumps we ran into today.
Thanks for the help from you guys. You are awesome!
- 👍1
@foucault has joined the channel
2017-03-05
ggm身體有好點嗎@@
有歐謝謝ＱＱ
Take care QQ
今天行程比較少，如果回飯店後有網路的話我應該會做 rumors-site 的外觀
把 JSON 弄掉這樣
把 JSON 弄掉這樣
@quad 請問 rumors-site 還有沒有 ummerged changes 呢？
2017-03-06
@ggm uploaded a file: Slack for Android Upload
嗨各位我們有糧草囉！
@lucien uploaded a file: Image uploaded from iOS
@lucien uploaded a file: 有點亂的 after grant 討論
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 比鄰的那個分類方式我從來沒有想過，是個新的靈感
我原本的分法確實是「如果未經證實，就不能說他是假的」
比鄰的分法有不同預設，是「如果未經證實，就不該說是真的」
如果我們的目標是要讓使用者不要輕易地相信東西，那後者預設為假會是一種更富科學精神的做法
我原本的分法確實是「如果未經證實，就不能說他是假的」
比鄰的分法有不同預設，是「如果未經證實，就不該說是真的」
如果我們的目標是要讓使用者不要輕易地相信東西，那後者預設為假會是一種更富科學精神的做法
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 如果我們的系統是想要讓不同立場的人能標記錯誤之處然後狠狠打臉，那我的分法可以確保他打臉可以打得又狠又腫
但當然，要能狠狠打臉並不容易，所以就變成會有很多 non-rumor。
但當然，要能狠狠打臉並不容易，所以就變成會有很多 non-rumor。
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 然後我在想，這兩者混合的話會有什麼副作用嗎？
像是有三種分類
1. 已被證實
2. 未經證實
3. 已被證實不是真的
像是有三種分類
1. 已被證實
2. 未經證實
3. 已被證實不是真的
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 對小編來說這樣分會不會有很大負擔？
「未經證實」跟「小編看過了但找不到」跟「還沒有小編看過」的差別又在哪？
「未經證實」跟「小編看過了但找不到」跟「還沒有小編看過」的差別又在哪？
@ooookai commented on @lucien’s file 有點亂的 after grant 討論: 也許 *已被證實* 下可分成 真的 or 假的 ？
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: Hmm我想我知道分成三種會有什麼問題了
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 原本比鄰的分法 (真的 vs 沒人說他是真的)
還有我的分法 (假的 vs 沒人說是假的)
的預設值(沒人說是 xxx) 其實有著強烈的預設立場
還有我的分法 (假的 vs 沒人說是假的)
的預設值(沒人說是 xxx) 其實有著強烈的預設立場
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 比鄰的分法告訴使用者不要隨便相信網路文章
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 我的分法鼓勵精確打臉，不亂燒稻草人
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 但兩個方法混在一起
那就什麼效果都達不到
那就什麼效果都達不到
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 大家只會看那些被標記為真或假的消息
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 那些沒被標記的，大家既不會預設他錯而進行批判性思考，也不會覺得我要努力證明他是錯的(不然別人會信以為真)，就是個無感
@ooookai commented on @lucien’s file 有點亂的 after grant 討論: 意思是這樣分嗎？🤔
1. 已證實已標記 (真or假)
2. 未被證實 或 不明確(含半真半假)
1. 已證實已標記 (真or假)
2. 未被證實 或 不明確(含半真半假)
2017-03-07
我記得之前有針對 Reply 的 taxonomy 有做過討論，我覺得這邊要把分類名訂得清楚並文件化起來
像是還有 not used 其實意思是根本不是來問謠言的
看起來總共有四種：
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假
現在討論的是需要把 `未辯真假` 跟其他人 merge 嗎？
Ex. `已証為假` ＋ `未辯真假` = `沒人說是真的`
我直覺的想法是乾脆就讓 `未辯真假` 的東西不要有回應
反正沒人有答案，編輯的回答幫助很有限
如果
使用者看到的回應是
1.有不實資訊
2.找不到不實資訊（會有隱含訊息可信的暗示嗎？像是在幫訊息背書一樣@@"）
3.資訊正確
4.資料庫找不到任何相關訊息/未辨真偽
5.有相關的文章，提供參考（搜尋引擎模式？）
哪一種是你們想看到的@@
使用者看到的回應是
1.有不實資訊
2.找不到不實資訊（會有隱含訊息可信的暗示嗎？像是在幫訊息背書一樣@@"）
3.資訊正確
4.資料庫找不到任何相關訊息/未辨真偽
5.有相關的文章，提供參考（搜尋引擎模式？）
哪一種是你們想看到的@@
2 跟4哪裡不一樣？
我的想法是，會使用這個功能是因為我覺得我得到的資訊未辨真假，所以才要問問機器人。
如果他也告訴我資訊未辨真假他不知道，我會有點無助QQ
如果他也告訴我資訊未辨真假他不知道，我會有點無助QQ
應該說沒有資訊可證真假時
那資料庫有沒有相關資料給使用者的價值是什麼呢？
1. 有資料但說我不知道真假
2. 沒資料
當我說：A的話不是錯的
通常代表A說的是對的
當我說：我沒聽過/我不知道B的話對不對
我真的不知道，有問題你去問B
通常代表A說的是對的
當我說：我沒聽過/我不知道B的話對不對
我真的不知道，有問題你去問B
喔喔 不是三分法而是預設二分法
我覺得可以描述清楚一點就可以規避 不是錯的 = 可能對 加 不知道真假
我的想像是資訊會隨著時間累積，所以偏好1
會提供資訊連結，但表示說
「有人有不同的看法」「訊息尚未獲得足夠的資料或支持」
會提供資訊連結，但表示說
「有人有不同的看法」「訊息尚未獲得足夠的資料或支持」
也就是鼓勵大家多回應，即使還沒有完整資訊的情況下，但希望可以透過資訊慢慢更新來得到答案
是的
我的概念是，既然是謠言就表示有人覺得「可能對」
所以你期待的分類是什麼呢？
就是4種嗎？
不一定
只要你的分類可以涵蓋所有情況就好，可以 merge
1.聊天測試
2.已證為真
3.不足採信
2.已證為真
3.不足採信
也就是 merge `已証為假` 跟 `未辯真假`
是的，當然這只是我的偏好
原因是我覺得我在這個過程是需要選擇其中一個價值的@@
嗯嗯那我們現在有三種，可以再討論三種的好壞以及預設立場，看看怎麼樣比較適合
謝謝lucien~
今天辛苦了
`不足採信` 這類有涵蓋 `未辯真假` 有個問題是會找不到參考資料
因為 `未辯真假` 這類狀況，也就代表沒有文章有答案。
沒有一個明確立場的文章，通常就不會寫出來，因為目前網路文化偏好有強硬立場，給人簡單好懂的答案，而不是還沒有答案的保守立場。
不知道小編們實際經驗如何呢？
是的，所以我才會認為
a.訊息可靠，不是謠言
b.不足採信（請當成網路謠傳）
和
A.是謠言
B.找不到不實資訊(請當成真有其事）
兩個價值要選一個來當作編輯的原則
a.訊息可靠，不是謠言
b.不足採信（請當成網路謠傳）
和
A.是謠言
B.找不到不實資訊(請當成真有其事）
兩個價值要選一個來當作編輯的原則
hmm… 我的問題是小編選了 b ，但是最後沒有 reference ，也沒有辦法解釋說是因為你沒查證完還是你真的找不到資料，這樣會讓 `不足採信` 給人感覺的效力變低
當選了 b 之後，那理由跟引用要寫成什麼樣子呢？
也就是說，可信的效力很低呀@@
那你跟使用者說不足採信的理由跟引用會是什麼呢？
會不會變成都會是 「找不到相關資料」 、「引用為空」？
這裡應該是讓我最擔心的地方
如果無法被證實是真的，是不是也代表很難找到引用資料去證實是假的？
回應：沒有足以證實這則消息可靠的文章資訊，請謹慎看待網路謠言，不要輕信。
理由：找不到/找了提供關鍵字有的文章
引用：空的/
理由：找不到/找了提供關鍵字有的文章
引用：空的/
是的，所以我的提案是 `未辯真假` 直接移除，當做還沒有答案，但代價是會有很多謠言沒有答案，把回應門檻拉高了。
lucien: 移除 `未辨真假` 後，代替它的會是？
沒有
就是還沒有答案就不應該回應
bot 感覺ㄧ定要給使用者一些回應吧？
Bot的回應是還沒有人回應或是有答案
沒有人回應 = `未被證實` = `不足採信` ？
我的版本不是
就是未辨真假
未被證實 = 已證為假 + 未辨真假
這樣分同樣會有 `沒有內容的回應` 的結果不是嗎？
（未辯真假的部分）
（未辯真假的部分）
我覺得你誤會了什麼
我的分類為：
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假（沒有資料能證明謠言為真或為假）
我的提案為：
只使用以下三個分類
- 只是閒聊
- 已証為真
- 已証為假
當有未辯真假的情況，編輯不應該回應，所以最終在 bot 會因為沒有資料變為 `此謠言還沒有人回答`
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假（沒有資料能證明謠言為真或為假）
我的提案為：
只使用以下三個分類
- 只是閒聊
- 已証為真
- 已証為假
當有未辯真假的情況，編輯不應該回應，所以最終在 bot 會因為沒有資料變為 `此謠言還沒有人回答`
所有 `未辯真假` 的情況代表編輯沒有能力找到答案，編輯能給的答案效力很低，那不如不回答。
瞭解～
我應該是誤會了 `回應` 是在討論 編輯給的回應，而不是 bot 給 user 的回應。
我應該是誤會了 `回應` 是在討論 編輯給的回應，而不是 bot 給 user 的回應。
是呢@@
我覺得 @bil 的方案可以讓討論變得比較容易，但會很容易產生大量一樣的 `不足採信` 回應，一直看到一樣沒有內容的回應，我覺得會下降大家對 bot 的信用
其中也有一種可能是編輯者還沒有認真查證，就選了 `不足採信` ，結果讓後續編輯，就認為他已經被回答，就沒有更深入查證了。但其實說不定有答案。
咦，可是我以為目前的做法是有反駁的文章比較多@@所以不足採信比較好用，提供了不實的部分與連結
喔喔
lucien: 移除 `未辨真假` 後，代替它的會是？
如果能證實，多數不足採信的文章其實都是 `已証為假` 那我覺得可以阿
沒有
就是還沒有答案就不應該回應
bot 感覺ㄧ定要給使用者一些回應吧？
Bot的回應是還沒有人回應或是有答案
沒有人回應 = `未被證實` = `不足採信` ？
我的版本不是
就是未辨真假
未被證實 = 已證為假 + 未辨真假
這樣分同樣會有 `沒有內容的回應` 的結果不是嗎？
（未辯真假的部分）
（未辯真假的部分）
我覺得你誤會了什麼
我的分類為：
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假（沒有資料能證明謠言為真或為假）
我的提案為：
只使用以下三個分類
- 只是閒聊
- 已証為真
- 已証為假
當有未辯真假的情況，編輯不應該回應，所以最終在 bot 會因為沒有資料變為 `此謠言還沒有人回答`
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假（沒有資料能證明謠言為真或為假）
我的提案為：
只使用以下三個分類
- 只是閒聊
- 已証為真
- 已証為假
當有未辯真假的情況，編輯不應該回應，所以最終在 bot 會因為沒有資料變為 `此謠言還沒有人回答`
所有 `未辯真假` 的情況代表編輯沒有能力找到答案，編輯能給的答案效力很低，那不如不回答。
我在想，如果除了 `已證為真` 以及 `已證為假` 之外的那些還沒有處理的、或是沒人找得到的文章，在給使用者的敘述上採取懷疑的角度，是否就能達到比鄰版 `不足採信` 「預設為假」的效果呢？
給使用者的回應例子：
```
目前沒有人證實此訊息的真實性，請保持懷疑態度對待其內容。
```
給使用者的回應例子：
```
目前沒有人證實此訊息的真實性，請保持懷疑態度對待其內容。
```
瞭解～
我應該是誤會了 `回應` 是在討論 編輯給的回應，而不是 bot 給 user 的回應。
我應該是誤會了 `回應` 是在討論 編輯給的回應，而不是 bot 給 user 的回應。
是的
以及，進來的文章其實沒有分過
fact & opinion
比如像是心情小語人生建議或是相信神等等，比起謠言或是事實真假，更像是作家個人意見抒發或是信仰之類的。我覺得有需要做一個區別，這些事情跟non rumor可能還是有點不一樣@@
以及，進來的文章其實沒有分過
fact & opinion
比如像是心情小語人生建議或是相信神等等，比起謠言或是事實真假，更像是作家個人意見抒發或是信仰之類的。我覺得有需要做一個區別，這些事情跟non rumor可能還是有點不一樣@@
2017-03-08
@danielhsu has joined the channel
心情小語、早安問好(今天有好多婦女節訊息)、反諷
都是不處理的東西呢
如果有人對他下這樣的標記，其他小編進可以考慮跳過他們
都是不處理的東西呢
如果有人對他下這樣的標記，其他小編進可以考慮跳過他們
這類能跟聊天測試合併成新的一類嗎？
我覺得可以，就是類似 don't care 這種種類
可是我覺得don't care 名字不好，但還想不到好名字
gossip ? 😂
我覺得好像也不錯
發現有一些進來的訊息有時間性敘述
例如：「十年來最強烈冷氣團第二波報到，週五以後特別寒冷」「今年.....」
這種訊息在特定時間過了之後，它的真實性就失效了，或是之後其實在不同的時間，卻都被判斷相似的文章，感覺好像會有一些問題 （？
例如：「十年來最強烈冷氣團第二波報到，週五以後特別寒冷」「今年.....」
這種訊息在特定時間過了之後，它的真實性就失效了，或是之後其實在不同的時間，卻都被判斷相似的文章，感覺好像會有一些問題 （？
這類能跟聊天測試合併成新的一類嗎？
True
我覺得可以，就是類似 don't care 這種種類
@mrorz uploaded a file: 有人在試 production server 嗎 @@
可是我覺得don't care 名字不好，但還想不到好名字
2017-03-09
gossip ? 😂
@wjwang has joined the channel
我覺得好像也不錯
2017-03-10
嗨 3/18 有個 g0v grant kick-off 的活動 有誰要一起的嗎？必帶： ggm, @mrorz @lucien
還有他有問我們有沒有希望邀請的人（或組織）他們可以幫忙橋
嗯嗯
botawards.line.me
An open competition of LINE chatbot, offering up to JPY 10 million in prize money.
似乎明年可以來申請這個
今年的結束了吧
今年初也有一屆
有什麼成果嗎
噢我是在社團看到 gotaix 入圍
我也不知道有什麼成果
HackMD
# 3/18 g0v Grant Kick-off 工作坊說明 ### for 獲獎團隊 本次 Kick-off 工作坊最重要的幾個部分，包括讓贊助單位認識各位獲獎的提案、請大家拿著大支票拍照（超
2017-03-13
@aelcenganda has joined the channel
hi 我是小班
歡迎大家來 318 g0v grant kick-off 工作坊，我剛剛看了一下上面的討論紀錄，想問你們會不會有興趣跟維基社群的人聊？
嗨嗨 好啊好啊我覺得適合！我有看到你們的 hackmd 上面有列
2017-03-14
@sttw has joined the channel
@ggm 是說我們在本週六 kickoff workshop 之前要討論些什麼嗎
想了一下 318 workshop 前還沒做的東西好像有
1. 看看 318 有哪些專家會被請到場進行交流，要問他們什麼問題
2. 看看當初提案報告裡列出的 KPI，列出 TODO，拉時程
3. 專案管理（不只是程式協作，還有現下小聚等等其他東西籌備的專案管理）方式：Trello？現在的 github issue + github project？要開放還是僅限工作人員使用？後者的話會不會很難跟工作人員之外的人 sync？
4. 現有 FB group 定位：定時對外揭露進度要誰來做、多久做一次？其他人可以貼什麼樣的文章
1. 看看 318 有哪些專家會被請到場進行交流，要問他們什麼問題
2. 看看當初提案報告裡列出的 KPI，列出 TODO，拉時程
3. 專案管理（不只是程式協作，還有現下小聚等等其他東西籌備的專案管理）方式：Trello？現在的 github issue + github project？要開放還是僅限工作人員使用？後者的話會不會很難跟工作人員之外的人 sync？
4. 現有 FB group 定位：定時對外揭露進度要誰來做、多久做一次？其他人可以貼什麼樣的文章
嗯嗯這幾天晚上來討論一下？
約出來 or 在 slack 留言？
https://hackmd.io/s/rkUEDmgse#rundown-draft 突然覺得 318 似乎是個社交場合
# 3/18 g0v Grant Kick-off 工作坊說明 ### to 獲獎團隊, 本次 Kick-off 工作坊最重要的幾個部分，包括讓贊助單位認識各位獲獎的提案、請大家拿著大支票拍照（超
那這樣好像只有 1 是比較需要在 318 前討論的 @@
其他就順便討論 XDD
對呀 似乎是個社交吸收 feedback 的場合
是呢
@hazelwei has joined the channel
- 💯2
請問 @sayuan elasticsearch 想在有資料的狀況下更新 mapping，要寫 migration script 的話，有沒有什麼推薦的工具呢
還是就是透過 client 先把資料複製下來、清掉上 mapping，然後再把資料 insert 回去 QQ？
還是就是透過 client 先把資料複製下來、清掉上 mapping，然後再把資料 insert 回去 QQ？
2017-03-15
沒有能直接修改 mapping 的方法 (若新增欄位不算的話)，所以如果不想 dump, re-insert 的話只能寫在其他 index，
這可以搭配 index alias，讓對外的 query 都是透過 alias 進行，藉此來達到 no downtime
這可以搭配 index alias，讓對外的 query 都是透過 alias 進行，藉此來達到 no downtime
@monaludao has joined the channel
我這邊應該要出：
1. JWT on Koa2
2. 詳細 site wireframe，但是上次討論的東西還沒有結論，我覺得把上次的討論總結一下，見面做個決定會比較好。
1. JWT on Koa2
2. 詳細 site wireframe，但是上次討論的東西還沒有結論，我覺得把上次的討論總結一下，見面做個決定會比較好。
2 可以在 1 出來之前先做完嗎 XD
2 要先把討論事項確定吧
不如明天或後天約一下
2017-03-16
但我週六以前晚上都沒有空 orz
或許可以線上討論的事情就先討論一下？
關於 FB group 的討論規範
https://www.facebook.com/groups/1847232902175197/
最近有越來越多來問真的假的的 orz
我覺得可能要更新一下規範與置頂文。
想要新增這樣的規則：
```
版面以這些貼文為主：
1. 使用問題回報：請附上操作的步驟，還有遇到什麼樣的問題。
2. 不知道如何回應文章，尋求討論：必須附上 (a) 已經投稿至 rumors 網站的連結、(b) 自己找了哪些來源。另外，如果能附上自己對答案的草擬或想法，就更好了
3. 討論版規：反應關閉留言機制等等。
4. 討論現有功能或建議新功能。
5. 公告更新消息。
程式實作方面的討論，還有新知分享與閒話家常，請移駕 g0v slack 的 #rumors channel。
其餘將會視情況關閉留言，將版片留給協作相關的討論。
```
或許可以線上討論的事情就先討論一下？
關於 FB group 的討論規範
https://www.facebook.com/groups/1847232902175197/
最近有越來越多來問真的假的的 orz
我覺得可能要更新一下規範與置頂文。
想要新增這樣的規則：
```
版面以這些貼文為主：
1. 使用問題回報：請附上操作的步驟，還有遇到什麼樣的問題。
2. 不知道如何回應文章，尋求討論：必須附上 (a) 已經投稿至 rumors 網站的連結、(b) 自己找了哪些來源。另外，如果能附上自己對答案的草擬或想法，就更好了
3. 討論版規：反應關閉留言機制等等。
4. 討論現有功能或建議新功能。
5. 公告更新消息。
程式實作方面的討論，還有新知分享與閒話家常，請移駕 g0v slack 的 #rumors channel。
其餘將會視情況關閉留言，將版片留給協作相關的討論。
```
關於 2，我們期待的發文像是這樣：
https://www.facebook.com/groups/1847232902175197/permalink/1926790640886089/
或是 https://www.facebook.com/johnsonliang/posts/1305915869491364
https://www.facebook.com/groups/1847232902175197/permalink/1926790640886089/
或是 https://www.facebook.com/johnsonliang/posts/1305915869491364
btw 如果要討論這個闢謠的話，就直接在 FB 回應給大家看就好囉～
裡面變成謠言討論集散地了lol
btw 如果要討論這個闢謠的話，就直接在 FB 回應給大家看就好囉～
裡面變成謠言討論集散地了lol
不好意思插個話，一點點有關編輯與社群的經驗。
因為一個人要完成一整則客觀、內容正確的闢謠文，有難度。而且每個人可能會有不一樣的詮釋，要給出最佳解，可能蠻需要多人共同修正。
記得維基社群就是這樣的運作方式，他們有共同修正、給credit的機制，或許也適合用在這裡？可能你們已經有相關規劃了，只突然想到好像有點適合
因為一個人要完成一整則客觀、內容正確的闢謠文，有難度。而且每個人可能會有不一樣的詮釋，要給出最佳解，可能蠻需要多人共同修正。
記得維基社群就是這樣的運作方式，他們有共同修正、給credit的機制，或許也適合用在這裡？可能你們已經有相關規劃了，只突然想到好像有點適合
真的假的在給出客觀闢謠文這裡的門檻比維基低一些唷，因為維基最後的產出是一個詞條，但真的假的可以同時給使用者看很多不同的回應，將判斷交給讀者。
另外補充，同樣是讓使用者看很多的回應，真的假的跟 Yahoo 奇摩知識 + / Quora 不同的地方則是不會選出「最佳解答」。覺得「是流言」與「不是流言」的解答在 LINE bot 會同時呈現，鼓勵不同立場的人來回應。
不過 3/18 我們也確實有請 OCF 邀請維基社群來與我們交流，我們想了解維基社群的線下小聚～
欸~想請問一下，目前的使用對象有沒有設定好的persona呢?
「使用對象」是指闢謠的人還是查詢的人呢？
查詢的人（在 LINE 操作）persona：
1. 原本就對訊息存疑的人，在 LINE 盛行之前就熟稔 google 的使用方式，對 LINE 上面轉傳的假訊息影響親友情緒而感到困擾，但又沒空幫慢慢 google 來抽絲剝繭，也沒空寫闢謠文。
2. 不熟悉查詢與查證，在親人朋友的介紹與教學下使用此 LINE bot 來查詢消息
查詢的人（在 LINE 操作）persona：
1. 原本就對訊息存疑的人，在 LINE 盛行之前就熟稔 google 的使用方式，對 LINE 上面轉傳的假訊息影響親友情緒而感到困擾，但又沒空幫慢慢 google 來抽絲剝繭，也沒空寫闢謠文。
2. 不熟悉查詢與查證，在親人朋友的介紹與教學下使用此 LINE bot 來查詢消息
闢謠的人 persona：
1. 同查詢的人 1，在空檔時間願意抽空對他覺得困擾的 LINE 流言做一點小小的改變。
2. 特定議題的利害關係人（例如說政府相關謠言之於政府，或婚姻平權謠言之於同性戀者），尋求能有效回應流言、散佈自身回應的工具。
1. 同查詢的人 1，在空檔時間願意抽空對他覺得困擾的 LINE 流言做一點小小的改變。
2. 特定議題的利害關係人（例如說政府相關謠言之於政府，或婚姻平權謠言之於同性戀者），尋求能有效回應流言、散佈自身回應的工具。
哦哦哦，謝謝 @mrorz 的說明！！！
2017-03-17
真的假的在給出客觀闢謠文這裡的門檻比維基低一些唷，因為維基最後的產出是一個詞條，但真的假的可以同時給使用者看很多不同的回應，將判斷交給讀者。
另外補充，同樣是讓使用者看很多的回應，真的假的跟 Yahoo 奇摩知識 + / Quora 不同的地方則是不會選出「最佳解答」。覺得「是流言」與「不是流言」的解答在 LINE bot 會同時呈現，鼓勵不同立場的人來回應。
不過 3/18 我們也確實有請 OCF 邀請維基社群來與我們交流，我們想了解維基社群的線下小聚～
這裏也不好意思插個話，就是 NCC 在 3/30 （四）下午兩點有個「推動網路新聞真實查核機制之諮詢會議議程」，這邊會有社群的夥伴想要出席參加嗎？
` 壹、會議時間：106年3月30日(星期四)14時整
貳、會議地點：交通通訊傳播大樓第2003室
叁、會議主持人：本會陳委員憶寧
肆、出席單位：
(一)大型網路平臺/通訊軟體/社群媒體：Facebook、Google、LINE、Yahoo!奇摩
(二)公民團體：g0v零時政府、財團法人台灣媒體觀察教育基金會、財團法人卓越新聞獎基金會、財團法人吳舜文新聞獎助基金會、財團法人新聞公害防治基金會、台灣新聞記者協會、PeoPo公民新聞平台
(三)政府部門：行政院政委吳政忠辦公室、國發會
伍、討論議題：
(一)如何查核網路上的不實新聞
1.大型網路平臺/通訊軟體/社群媒體如何判斷及查核網路上的不實新聞？
2.大型網路平臺/通訊軟體/社群媒體現階段針對新聞真實查核所提出的運作機制為何？
3.可作為我國推動之借鏡、作法及推動時程？
(二)如何推動第三方團體協助健全查核機制
1.第三方團體在健全查核機制可扮演之角色？
2.現有可提供協作之團體、資源或平臺?
3.建置新聞真實查核平臺之可行性及困難之處？
4.新聞真實查核機制建立後如何宣導推動？
(三)政府部門如何協助推動
1.何種網站問答集資料格式，有助第三方團體快速自動接取？
2.政府部門可提供之協力事項？`
貳、會議地點：交通通訊傳播大樓第2003室
叁、會議主持人：本會陳委員憶寧
肆、出席單位：
(一)大型網路平臺/通訊軟體/社群媒體：Facebook、Google、LINE、Yahoo!奇摩
(二)公民團體：g0v零時政府、財團法人台灣媒體觀察教育基金會、財團法人卓越新聞獎基金會、財團法人吳舜文新聞獎助基金會、財團法人新聞公害防治基金會、台灣新聞記者協會、PeoPo公民新聞平台
(三)政府部門：行政院政委吳政忠辦公室、國發會
伍、討論議題：
(一)如何查核網路上的不實新聞
1.大型網路平臺/通訊軟體/社群媒體如何判斷及查核網路上的不實新聞？
2.大型網路平臺/通訊軟體/社群媒體現階段針對新聞真實查核所提出的運作機制為何？
3.可作為我國推動之借鏡、作法及推動時程？
(二)如何推動第三方團體協助健全查核機制
1.第三方團體在健全查核機制可扮演之角色？
2.現有可提供協作之團體、資源或平臺?
3.建置新聞真實查核平臺之可行性及困難之處？
4.新聞真實查核機制建立後如何宣導推動？
(三)政府部門如何協助推動
1.何種網站問答集資料格式，有助第三方團體快速自動接取？
2.政府部門可提供之協力事項？`
Cool
Please count me in
@mrorz 可以請問你的本名嗎？NCC 那邊要出席名單。也可以給我 email 我把 email 轉給你
欸~想請問一下，目前的使用對象有沒有設定好的persona呢?
@ipa has joined the channel
「使用對象」是指闢謠的人還是查詢的人呢？
查詢的人（在 LINE 操作）persona：
1. 原本就對訊息存疑的人，在 LINE 盛行之前就熟稔 google 的使用方式，對 LINE 上面轉傳的假訊息影響親友情緒而感到困擾，但又沒空幫慢慢 google 來抽絲剝繭，也沒空寫闢謠文。
2. 不熟悉查詢與查證，在親人朋友的介紹與教學下使用此 LINE bot 來查詢消息
查詢的人（在 LINE 操作）persona：
1. 原本就對訊息存疑的人，在 LINE 盛行之前就熟稔 google 的使用方式，對 LINE 上面轉傳的假訊息影響親友情緒而感到困擾，但又沒空幫慢慢 google 來抽絲剝繭，也沒空寫闢謠文。
2. 不熟悉查詢與查證，在親人朋友的介紹與教學下使用此 LINE bot 來查詢消息
- 👍1
闢謠的人 persona：
1. 同查詢的人 1，在空檔時間願意抽空對他覺得困擾的 LINE 流言做一點小小的改變。
2. 特定議題的利害關係人（例如說政府相關謠言之於政府，或婚姻平權謠言之於同性戀者），尋求能有效回應流言、散佈自身回應的工具。
1. 同查詢的人 1，在空檔時間願意抽空對他覺得困擾的 LINE 流言做一點小小的改變。
2. 特定議題的利害關係人（例如說政府相關謠言之於政府，或婚姻平權謠言之於同性戀者），尋求能有效回應流言、散佈自身回應的工具。
- 👍1
NCC 的活動我也 ++
NCC 想加一
哦哦哦，謝謝 @mrorz 的說明！！！
我等等上面 小編回文方式 還有下 tag 什麼的（真不知道怎麼歸類）的東西整理一下，覺得明天會用到
這個部分之前比鄰有複製貼上過唷
你可以接手整理一下
例如說 thread 裡面的回應，就還沒放進去
http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252Frk1KHEgsg
你可以接手整理一下
例如說 thread 裡面的回應，就還沒放進去
http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252Frk1KHEgsg
ok
還有整理社群小聚要怎麼辦比較好 明天也可以拿來問大家
2017-03-18
ohoh
這個部分之前比鄰有複製貼上過唷
你可以接手整理一下
例如說 thread 裡面的回應，就還沒放進去
http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252Frk1KHEgsg
你可以接手整理一下
例如說 thread 裡面的回應，就還沒放進去
http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252Frk1KHEgsg
ok
@ggm 你們會被第一個頒獎
五分鐘內要出現啊
真的假的
@mrorz 人勒
電梯
趕到了
對不起 QQ
我們一整個大意了😖
不好意思角度沒辦法全部拍到 QQ
- 💪1
@darkbtf has joined the channel
GitHub
「真的假的」是一個快速驗證謠言的 ChatBot 系統，透過群眾協作查證社群上不知道『真的假的』的分享訊息。現在「真的假的」需要一個英文名字，用在登記 github organization、 line ChatBot 帳號 ID 、網域上。 子曰：「名不正，則言不順；言不順，則事不成」 「真的假的」需要一個簡潔有力、朗朗上口、深入人心的好名字，以便於大眾找到我們！ 在此我們向大家徵集「...
我完全忘了我之前打了什麼 … XDD 小木偶嗎
https://github.com/MrOrz/rumors-api/issues/9 Check here
需要與大家討論什麼 ID 好～ 除了 Line ID，英文名字還會用在哪裡： 域名 line ID Github 的 organization 名 「真的假的」與其他闢謠網站不同的地方： 不做內容生成，而是 curator / 查詢 / 入口 群眾協作 未來除了謠言查證，說不定也會做讓網友回報「爭議性言論」然後附上「反駁論述連結」。但或許要先把謠言查證的搜尋先專心做好，樹立口碑 (謠言...
在裡面挑一下你想 propose 的名字貼到 issue 28 吧
金欸給欸
@shangkuanlc has joined the channel
moe.kktix.cc
萌典松是隔月舉辦的 g0v 零時政府中型黑客松，在 Bookshow 說書會舉行。除了坑坑相連的討論實作、成果發表，也穿插同步腦波的短講分享、輕鬆愉快的吃喝閒聊，歡迎大小專案自由加「萌」。
關於給編輯者的小聚，剛才跟 @bil 討論了一下
他覺得一次不要超過 2.5 小時，固定一或兩周一次，開在週間晚上、不佔用週末大家寶貴的時間，是一個不錯的形式。
不知道今天與維基社群交流比較多的 @ggm 覺得如何呢
他覺得一次不要超過 2.5 小時，固定一或兩周一次，開在週間晚上、不佔用週末大家寶貴的時間，是一個不錯的形式。
不知道今天與維基社群交流比較多的 @ggm 覺得如何呢
嗯 他有提到他們之前協作翻譯的群組 一個禮拜一次線上會議 1h
大家可以新增一下今天 kick-off 的心得與討論
https://hackmd.io/BwNgpgjAxgRgTFAtFEBWCiAsBDADGRbKATgzAHYwBmYgE3Igt0yA?both
https://hackmd.io/BwNgpgjAxgRgTFAtFEBWCiAsBDADGRbKATgzAHYwBmYgE3Igt0yA?both
我等等寫一下跟阿孝老師的討論，未竟之處還請 @hazelwei 協助補完
Ok
Done，請 Hazel 看一下我「新聞所阿孝老師」底下的紀錄是否有誤讀或闕漏，「文章分工、小編分類」那裡與「真的／假的」的三種分類方式（Reply type）那裡我分心了、記不清楚，需要幫補 QQ
http://bit.ly/2nyOnnX
http://bit.ly/2nyOnnX
@mrorz 我補完了，你再看看喔
我粗略打一些慢慢補上去
我覺得編輯者的小聚可以每週 1 小時線上
技術小聚我覺得可以長一點，我覺得可以一起寫扣，這樣效率很高，大家在技術上遇到的問題要改架構馬上討論馬上實作
- 👍3
另外我想確認一下我們晚餐時，對於 Reply type (分類方式、taxonomy) 的結論 （之前討論的脈絡請見：https://hackmd.io/s/rk1KHEgsg ）
```
* 採用「含有不實資訊」「含有真實資訊」「個人意見」3 種
如果沒填寫就是未辨真假
* 如果一則訊息有「不實資訊」又有「真實資訊」，那小編就要一個人 reply 兩次，一次填真實的是哪些部分，另一次填不實的是哪一些部分。
```
Pros:
1. 之後如果決定了這個平台要預設「請懷疑真實性」與「在沒人拿證據打臉錢請當成真的」的話，這種分法比較好把「未辨真假」合併到其他選項。
2. 將部分真實、部分不實分開，之後要切換到 segment 或許也比較容易。
（ segment 概念請見：http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252FrJQaJ9wwl ）
Cons:
一則 article 可能會有很多回應，眼花撩亂。
如果使用者新聞都只看標題、LINE 訊息也不點連結，那這對使用者是否有幫助，仍然需要評估。（雖然會來跟 LINE bot 做好朋友的 TA 應該不太介意啦）
OK 的話我把上面的寫進 https://hackmd.io/s/rk1KHEgsg
```
* 採用「含有不實資訊」「含有真實資訊」「個人意見」3 種
如果沒填寫就是未辨真假
* 如果一則訊息有「不實資訊」又有「真實資訊」，那小編就要一個人 reply 兩次，一次填真實的是哪些部分，另一次填不實的是哪一些部分。
```
Pros:
1. 之後如果決定了這個平台要預設「請懷疑真實性」與「在沒人拿證據打臉錢請當成真的」的話，這種分法比較好把「未辨真假」合併到其他選項。
2. 將部分真實、部分不實分開，之後要切換到 segment 或許也比較容易。
（ segment 概念請見：http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252FrJQaJ9wwl ）
Cons:
一則 article 可能會有很多回應，眼花撩亂。
如果使用者新聞都只看標題、LINE 訊息也不點連結，那這對使用者是否有幫助，仍然需要評估。（雖然會來跟 LINE bot 做好朋友的 TA 應該不太介意啦）
OK 的話我把上面的寫進 https://hackmd.io/s/rk1KHEgsg
分類方式討論 @ g0v slack #rumors === ### 討論記錄 ggm 有沒有實作在手機上面闢謠 mrorz 喔就還沒做，not first priority ggm 我們希望
哎呀我想到一件關於分類方式的事情
我在想，如果除了 `已證為真` 以及 `已證為假` 之外的那些還沒有處理的、或是沒人找得到的文章，在給使用者的敘述上採取懷疑的角度，是否就能達到比鄰版 `不足採信` 「預設為假」的效果呢？
給使用者的回應例子：
```
目前沒有人證實此訊息的真實性，請保持懷疑態度對待其內容。
```
當我們要回給使用者說，sorry 這則沒人回過、「未辨真假」的時候
其實是可以對使用者說說話，傳達我們希望大家如何看待「沒人回過的訊息」
其實是可以對使用者說說話，傳達我們希望大家如何看待「沒人回過的訊息」
嗯嗯我覺得應該是沒有答案的基礎回應
我等等寫一下跟阿孝老師的討論，未竟之處還請 @hazelwei 協助補完
ggm
大家可以新增一下今天 kick-off 的心得與討論
https://hackmd.io/BwNgpgjAxgRgTFAtFEBWCiAsBDADGRbKATgzAHYwBmYgE3Igt0yA?both
@darkbtf https://github.com/MrOrz/rumors-line-bot/issues/3 這個我認領囉
rumors-line-bot - Line bot that checks if a message contains internet rumor.
還是你想要試著照 README 申請 line bot account + 架架看環境呢
然後 https://github.com/MrOrz/rumors-db/issues 3, 4 可以麻煩 @darkbtf 嗎 QQ
Ok
2017-03-19
reindex !!
Done，請 Hazel 看一下我「新聞所阿孝老師」底下的紀錄是否有誤讀或闕漏，「文章分工、小編分類」那裡與「真的／假的」的三種分類方式（Reply type）那裡我分心了、記不清楚，需要幫補 QQ
http://bit.ly/2nyOnnX
http://bit.ly/2nyOnnX
@mrorz 我補完了，你再看看喔
- 👍1
關於如何打造社群，週六在南港中研院的Sitcon也有個日本的JAWS-UG的創辦人分享了，覺得蠻值得大家參考的： https://www.slideshare.net/hide69oz/20170318-community-leadersopen
slideshare.net
Presentation at Community Leadership Camp in Taipei on March 18th 2017.
- 👍2
剛剛我也補充回應一些內容。
大家可以新增一下今天 kick-off 的心得與討論
https://hackmd.io/BwNgpgjAxgRgTFAtFEBWCiAsBDADGRbKATgzAHYwBmYgE3Igt0yA?both
- 👍2
@mrorz
OK 我拿 issue 3,4
linebot 給你 trace 應該比較方便 XD
2017-03-20
@lucien @ggm
@darkbtf @bil 我剛剛在 github 開了 rumors-* 的 repo collaborators 給你們囉
請收信接 invitation
請收信接 invitation
- 👌4
@mrorz 請問是否有目前文章回報清單呢？想看一下整理目前回報內容涵蓋的領域，先定義出要找的編輯類型。
感謝！！！
@feifeirun has joined the channel
@lucien 你如果要出席 NCC 3/30 的會議，可以給我你的本名和 email手機嗎
好喔
行為科學對於人們對於新聞相信程度的研究
http://whogovernstw.org/2017/03/19/austinwang23/
http://whogovernstw.org/2017/03/19/austinwang23/
菜市場政治學
當世界各地開始出現類似的立法措施，目的是想要對抗「假新聞」！ 本文以為，莫單純把大眾都當作無知、而不去思考人們，否則會讓正確資訊的傳播事倍功半。政府或臉書可以做的，也許是試著尋找激勵每一個人們更願意表態、更願意分享事實的誘因，透過更多事實來壓下假新聞，而不是由上而下的想直接跟它對抗。 追根究底，對抗「假新聞」終究會是每個人對每個人之間的戰爭，而社群網站只是提供了戰場，可能並非假新聞出現的…
關於 18 日大家覺得應該要增加的「標籤」功能，我在 github 寫了個 RFC
不知道如果我這樣實做下去的話，大家有沒有什麼想法？
不知道如果我這樣實做下去的話，大家有沒有什麼想法？
3/18 聚會中，維基社群以及阿孝老師都曾經建議要讓不同知識領域的人可以分工回應文章。實作 user generated label 似乎是一個不錯的方式。 RFC：在 rumors-api 實作一個類似 hackpad / niconico 的 label，符合： 使用者可以自由對 article 標記 label 輸入 label 時會會用現有 label 進行 autocomplet...
例如說，我這樣實做的話，有辦法即時 query 出所有標籤來做標籤列表 / 文字雲嗎～？
如果 elasticsearch 有做 inverted index 那這應該不成問題，但沒在 API 上看到過 Orz
直接用 terms aggregation 就行了
Dotcms.com 
2
2
2- 💯1
另外關於「我想回答」標記的預計實作方式，也請大家過目：
https://github.com/MrOrz/rumors-api/issues/34
https://github.com/MrOrz/rumors-api/issues/34
3/18 會前討論 中提到，目前未回答的謠言太多，使小編沒有動力。 如果可以讓小編對文章標記「我想回答」，然後在文章列表多兩個 filter：「我想回答」與「我回答過」，那小編就可以建立自己的 TODO list，不會說找不到之前看過的想回答的謠言，也因為 TODO 更明確而增加回答動力。 另外，編輯者小聚這類的場合裡，有「我想回答」的計數可以幫助小編避免重工的問題。 RFC： 實作方式想要...
@mrorz 「我想回答」需不需要有則數限制？或者是時效限制？
因為累積太多反而會造成回覆效率的低落（大家都覺得有人要回，但標記要回覆的人其實是pending的元兇）。
如果給個則數上限（例如上限五則，回答完/取消回答意願，才能再抓新的進來候選list，不過立刻送出的回答不在此列），在候選清單的也可以給個時限（像是博客來的下次再買就是只能放90天的樣子，但我們可能不能放那麼長）
因為累積太多反而會造成回覆效率的低落（大家都覺得有人要回，但標記要回覆的人其實是pending的元兇）。
如果給個則數上限（例如上限五則，回答完/取消回答意願，才能再抓新的進來候選list，不過立刻送出的回答不在此列），在候選清單的也可以給個時限（像是博客來的下次再買就是只能放90天的樣子，但我們可能不能放那麼長）
『在文章列表，可以列出「10 分鐘前有人表示想要回答」小字，告知其他小編說有人在多久之前說他要寫回答。』
我想如果文章列表上面寫著「10 天前有人表示想要回答」，但卻沒人答的話，那小編應該可以安心進去回答了 XD
如果小編能快速判斷這則訊息到底有沒有人要回，這樣應該就不用加上則數限制了？
我想如果文章列表上面寫著「10 天前有人表示想要回答」，但卻沒人答的話，那小編應該可以安心進去回答了 XD
如果小編能快速判斷這則訊息到底有沒有人要回，這樣應該就不用加上則數限制了？
2017-03-21
@mrorz 請問是否有目前文章回報清單呢？想看一下整理目前回報內容涵蓋的領域，先定義出要找的編輯類型。
@mrorz 「我想回答」需不需要有則數限制？或者是時效限制？
因為累積太多反而會造成回覆效率的低落（大家都覺得有人要回，但標記要回覆的人其實是pending的元兇）。
如果給個則數上限（例如上限五則，回答完/取消回答意願，才能再抓新的進來候選list，不過立刻送出的回答不在此列），在候選清單的也可以給個時限（像是博客來的下次再買就是只能放90天的樣子，但我們可能不能放那麼長）
因為累積太多反而會造成回覆效率的低落（大家都覺得有人要回，但標記要回覆的人其實是pending的元兇）。
如果給個則數上限（例如上限五則，回答完/取消回答意願，才能再抓新的進來候選list，不過立刻送出的回答不在此列），在候選清單的也可以給個時限（像是博客來的下次再買就是只能放90天的樣子，但我們可能不能放那麼長）
『在文章列表，可以列出「10 分鐘前有人表示想要回答」小字，告知其他小編說有人在多久之前說他要寫回答。』
我想如果文章列表上面寫著「10 天前有人表示想要回答」，但卻沒人答的話，那小編應該可以安心進去回答了 XD
如果小編能快速判斷這則訊息到底有沒有人要回，這樣應該就不用加上則數限制了？
我想如果文章列表上面寫著「10 天前有人表示想要回答」，但卻沒人答的話，那小編應該可以安心進去回答了 XD
如果小編能快速判斷這則訊息到底有沒有人要回，這樣應該就不用加上則數限制了？
- 👍1
感謝！！！
哥倫比亞有一個team在做類似的事喔，他們是用在WhatsApp上
http://www.niemanlab.org/2017/03/to-slow-the-spread-of-false-stories-on-whatsapp-this-colombian-news-site-is-enlisting-its-own-readers/?utm_content=buffer79b29&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
http://www.niemanlab.org/2017/03/to-slow-the-spread-of-false-stories-on-whatsapp-this-colombian-news-site-is-enlisting-its-own-readers/?utm_content=buffer79b29&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
Nieman Lab
Have a WhatsApp chain message you want factchecked? La Silla Vacía's WhatsApp Detector first wants you to commit to spreading the factcheck to your friends.
- 👍6
大體上，這是一家哥倫比亞的新聞網站的專案，他們原先就有一個營運多年的lie detector 的查實網站，查實方式是有只要範圍符合條件（像是公眾利益的議題等），他們記者會去查實，而WhatsApp 是這個網站的extension ，增加謠言導入的channel。
他們會讓用戶把他們的核查結果寄給朋友們，還要screenshot為證 XD 那樣會不會嚇退用戶
Wow
screenshot XDDD
2017-03-22
這篇有寫到他們的分類方式：
“True,” “False,” “True but…,” “Debatable,” “Rushed,” “Exaggerated,” or “Misleading.”
看起來包含了明確為真或假、部分真、可在辯論、推論粗糙、過分誇大和有誤導嫌疑等類型。
感覺大家可以參考看看？
“True,” “False,” “True but…,” “Debatable,” “Rushed,” “Exaggerated,” or “Misleading.”
看起來包含了明確為真或假、部分真、可在辯論、推論粗糙、過分誇大和有誤導嫌疑等類型。
感覺大家可以參考看看？
@hazelwei 由於他們是記者查證的樣子，我覺得能比我們給一般人查證的工具更細微的分類，我們必須要教育一般人使用查證的工具和方法，使用門檻必須要低一點。
嗯嗯，這個確實是個考慮點。我只是擔心這樣的分類，會不會讓「讀者」在閱讀上比較難一眼看出來問題點？問問大家意見～～
一擊必殺指出問題是很重要的呢
蠻有趣的，他分類其實沒有很MECE，像是 True but... 跟 Exaggerated 是會有重疊的，那這邊編輯者會怎麼判斷呢
我自己是覺得越多分類對小編的 loading 就越重
最老牌闢謠網站 snopes.com 也很多分類
⋯⋯他們改版了 @@
http://www.snopes.com/change-channel-on-inauguration/ “Mostly False"
Snopes.com
A Facebook message urges viewers not to watch Donald Trump's inauguration, but that form of protest likely won't affect the event's ratings.
https://github.com/MrOrz/rumors-api/issues/26 我們自己則是在考慮是否要加 `Sarcasm` 分類 @@
未來預計讓小編回應時，標記一篇 article 為「含有不實消息」、「不含不實消息」或「非轉傳訊息」三種 type 的其中之一。在 LINE bot 回應時，如果一篇 article 有複數個小編回應，會顯示「這則訊息被 3 個人標記為『含有不實訊息』、1 人標記為『不含不實訊息』」。 由於有些流言其實是屬於諷刺性言論 / 挖苦、或是笑話， 其中或許真的「含有不實訊息」，但目的不是要讓人信以...
Segment 機制看起來能解決很多問題啊，像是這種混合問題
true but屬於內文正確錯誤資訊混雜（像是某段為真、某段為假）
但是Exaggerated算是在事實上，誇大影響，所以故事都正確，但會有形容詞造成的感受增強
我稍微瞄了一下我們現在的提報內容類型，跟他們的取向有點不一樣。
因為他們著重在公共議題與政治的查證，true but、Exaggerated這兩種情況比較常出現。
如果我們現在多數還是健康、民生消費議題的話，好像這種情況比較少。
但是一種讓讀者在閱讀上，比較直覺理解這則訊息問題點的分類方式。
我記得華盛頓郵報的分類方式也比較趨近於這個類型
https://www.washingtonpost.com/graphics/politics/2016-election/fact-checker/?tid=a_inl
但是Exaggerated算是在事實上，誇大影響，所以故事都正確，但會有形容詞造成的感受增強
我稍微瞄了一下我們現在的提報內容類型，跟他們的取向有點不一樣。
因為他們著重在公共議題與政治的查證，true but、Exaggerated這兩種情況比較常出現。
如果我們現在多數還是健康、民生消費議題的話，好像這種情況比較少。
但是一種讓讀者在閱讀上，比較直覺理解這則訊息問題點的分類方式。
我記得華盛頓郵報的分類方式也比較趨近於這個類型
https://www.washingtonpost.com/graphics/politics/2016-election/fact-checker/?tid=a_inl
Washington Post 
- 💯1
- 👍1
健康相關訊息還滿多誇大療效的唷
例如說「一定要每天做才有效果」「病痛就通通消失」之類的
例如說「一定要每天做才有效果」「病痛就通通消失」之類的
true but 給我的感覺是「在某前提下為才真，但他沒寫」吧
病童就通通消失算是不實還是誇大呢
那個界線爭議會怎麼解決呢？
越多分類就有越多界線
所以我自己是覺得「含有真實資訊」「含有錯誤訊息」這種都只講部分的 statement 最明確，也最能跟 segment 接軌 @@
所以我自己是覺得「含有真實資訊」「含有錯誤訊息」這種都只講部分的 statement 最明確，也最能跟 segment 接軌 @@
至於是否誇大我覺得有點主觀
說人家誇大應該要用事實佐證
例如說愛滋花了超多健保資源的「超多」
你可以直接把排名列出來然後標成「含有錯誤訊息」
之類的
20170318 g0v grant kick-off === ## 會前討論 ### 1. 看看 318 有哪些專家會被請到場進行交流，要問他們什麼問題 * Wikipedia，怎麼處理編輯權
okok，那就依據之後比較好切Segement的方式進行～～
大體上，這是一家哥倫比亞的新聞網站的專案，他們原先就有一個營運多年的lie detector 的查實網站，查實方式是有只要範圍符合條件（像是公眾利益的議題等），他們記者會去查實，而WhatsApp 是這個網站的extension ，增加謠言導入的channel。
@hazelwei 由於他們是記者查證的樣子，我覺得能比我們給一般人查證的工具更細微的分類，我們必須要教育一般人使用查證的工具和方法，使用門檻必須要低一點。
哥倫比亞那個應該是記者來查證喔，用戶專業度不太一樣
嗯嗯，這個確實是個考慮點。我只是擔心這樣的分類，會不會讓「讀者」在閱讀上比較難一眼看出來問題點？問問大家意見～～
除非我們能找一批 @hazelwei 大軍，要不然太細微的分類標準不好學習跟統一
或是小編要經過workshop 學習才能參與查證
另外一個想問的問題。
雖然現在查證的訊息數量還很少，但我想要考量一下大眾查證的「一擊命中」的比率。會不會回覆很多但是都沒有戳到重點
雖然現在查證的訊息數量還很少，但我想要考量一下大眾查證的「一擊命中」的比率。會不會回覆很多但是都沒有戳到重點
自己製作 @hazelwei 大軍的意思，但這要有一個很強連結的編輯社群營運呢
這個我可以幫忙想辦法連結（本人好像也只有這個功用orz）
因為我本來就是想其實很多訊息光是貼新聞報導，還是難以解惑。
所以有必要還是需要由專業一點的社群幫忙處理，編輯社群的連結感覺是需要的～
其實是想問大家覺得有沒有這樣的必要？還是先累積回覆的數量？
因為我本來就是想其實很多訊息光是貼新聞報導，還是難以解惑。
所以有必要還是需要由專業一點的社群幫忙處理，編輯社群的連結感覺是需要的～
其實是想問大家覺得有沒有這樣的必要？還是先累積回覆的數量？
一擊必殺指出問題是很重要的呢
一個方式是：如果是新手編輯只有比較少的分類，經過認證或是訓練後，可以有比較高的權限做細緻的分類。
但是據我所知 @mrorz 一直希望社群是很平坦沒有權限以及管理的機制。
但是據我所知 @mrorz 一直希望社群是很平坦沒有權限以及管理的機制。
就是專業社群的答案跟一般人的答案會放在一起
不希望用非民主(?)的方式來標出「完美回答」之類的
不希望用非民主(?)的方式來標出「完美回答」之類的
Stack Overflow 害了工程師？扭曲的「聲望值」文化，讓這個工程師庇護所不再美好
https://buzzorange.com/techorange/2017/03/21/stack-overflow/
https://buzzorange.com/techorange/2017/03/21/stack-overflow/
TechOrange
【我們為什麼挑選這篇文章】Stack Overflow 是工程師界的重要社群，關於編程的任何問題都能在那邊得到解答，也同時是編程潮流的風向標。不過，近來，卻有人開始反思 Stack Overflow [...]
這篇還蠻不錯的 有些點可以借鏡（工程師面和協作面）
我是覺得一開始要比較平坦，比較少標籤，比較好入門，等量多了再來處理。（Lean Startup 精神，快速失敗快速迭代 XD ）有累積量之後專業社群進入，才有真正的價值，當然專業社群可以當一般小編參與。就我意思是不要太快導入有專業社群有的完善（完整）機制，可以先把機制設想好，但是一開始不實作。
好喔！感謝大家分享！
2017-03-23
*提個 Reply 方案* ~
採用星等評價而非強迫用標籤分類，也許可減輕專業編輯的負擔，並讓更多非專業人士，但有正常判斷力的大眾參與編輯。規則上設定各星等的條件，高低星等須提供來源，提高專業度，中間星等則可接受常識判斷，最後再透過加權運算應可提出一個公平的參考星等。
而若不受限於一定需要來源的標籤，也可以讓大眾透過與 bot 的簡易對話來用中間星等評價謠言訊息，讓大家可隨時參與編輯，加速闢謠。
⭐ *可信度星等* 舉例：
1 星等（證實為假）[須提供來源]：「各位不要再買殘留農藥的韓國海苔了！」
2 星等（常識上為假）：「海苔吃太多，大便會變成黑色的」
3 星等（非真非假，不易考證的訊息）：「今天ＯＯ海苔特賣，限時下殺 11 折」
4 星等（有來源）[可Google到來源]：「現代人容易缺乏 鈣與碘等礦物質可以從海苔大量補充，特別適合兒童與孕婦食用。」
5 星等（證實為真）[須提供可信來源]：「海苔是一種由藻類製成的食品」
_可信來源如：Wiki, 政府, 企業, 財團法人, 基金會, 研究期刊_
`各星等的定義只是個概念，待討論`
採用星等評價而非強迫用標籤分類，也許可減輕專業編輯的負擔，並讓更多非專業人士，但有正常判斷力的大眾參與編輯。規則上設定各星等的條件，高低星等須提供來源，提高專業度，中間星等則可接受常識判斷，最後再透過加權運算應可提出一個公平的參考星等。
而若不受限於一定需要來源的標籤，也可以讓大眾透過與 bot 的簡易對話來用中間星等評價謠言訊息，讓大家可隨時參與編輯，加速闢謠。
⭐ *可信度星等* 舉例：
1 星等（證實為假）[須提供來源]：「各位不要再買殘留農藥的韓國海苔了！」
2 星等（常識上為假）：「海苔吃太多，大便會變成黑色的」
3 星等（非真非假，不易考證的訊息）：「今天ＯＯ海苔特賣，限時下殺 11 折」
4 星等（有來源）[可Google到來源]：「現代人容易缺乏 鈣與碘等礦物質可以從海苔大量補充，特別適合兒童與孕婦食用。」
5 星等（證實為真）[須提供可信來源]：「海苔是一種由藻類製成的食品」
_可信來源如：Wiki, 政府, 企業, 財團法人, 基金會, 研究期刊_
`各星等的定義只是個概念，待討論`
- 👏2
請問 @ooookai 的意思是，
1. chatbot 裡面可能會有人回「這不符合常識吧，應該是 XXXX」但沒有貼消息來源 —> 系統會把對話納入 reply，增加 reply 數，但可性度星等是中間的不真不假
2. 小編寫完之後又有貼消息來源 —> 系統會把此 reply 標成更具有鑑別度的星等
1. chatbot 裡面可能會有人回「這不符合常識吧，應該是 XXXX」但沒有貼消息來源 —> 系統會把對話納入 reply，增加 reply 數，但可性度星等是中間的不真不假
2. 小編寫完之後又有貼消息來源 —> 系統會把此 reply 標成更具有鑑別度的星等
這樣嗎？
我的想法是～
編輯時可以直接只給星等，然後在給特定星等的時候，必須附上來源佐證。
使用者在 chatbot 做查證時，bot 給出的回應也只是 可信度星等 ，若有來源則附上。
編輯時可以直接只給星等，然後在給特定星等的時候，必須附上來源佐證。
使用者在 chatbot 做查證時，bot 給出的回應也只是 可信度星等 ，若有來源則附上。
嗯嗯這種分類方式是我們之前沒有討論過的，不過我覺得 Likert scale 比較適合在一個維度且連續的表現上，譬如說疼痛上面，我 5 分痛，或者是 1 分痛，或者是遊戲好不好玩、餐點貴不貴。
而我們會處理一些文章會有些是沒有客觀事實的，譬如說：服貿對台灣是好還是壞、世界上到底有沒有神，這些可能就沒有辦法落在某個星等上面。這樣可能就會變成有兩種類型，一種是無法判別的，一種是有真偽等級的。
而我們會處理一些文章會有些是沒有客觀事實的，譬如說：服貿對台灣是好還是壞、世界上到底有沒有神，這些可能就沒有辦法落在某個星等上面。這樣可能就會變成有兩種類型，一種是無法判別的，一種是有真偽等級的。
我想了一下，可能還有另個狀況是，一般來說 Likert scale 是可以被算的，就像是你說的算出一個加權數值，譬如某個遊戲 8 個人給 5 顆星，2 個人給 3 顆星，就可以算 4.6 顆星。那如果 8 個人給 [證實為假]，2 個人給 [證實為真]，就會變成 [常識上為假]，但實際上可能是個有爭議的文章，或是文章部分真的部分假的，這時候分數的作用可能就不大了。
換個角度說好了，就是
5 個人給 [證實為假]，5 個人給 [證實為真]
和
10 個人給 [非真非假，不易考證的訊息]
其實意義上是不同的，如果量化成分數的話就會遺失一些訊息，不然就是不量化成分數，完整呈現之類的（但那好像就失去了使用分數的好處）
5 個人給 [證實為假]，5 個人給 [證實為真]
和
10 個人給 [非真非假，不易考證的訊息]
其實意義上是不同的，如果量化成分數的話就會遺失一些訊息，不然就是不量化成分數，完整呈現之類的（但那好像就失去了使用分數的好處）
我沒有想過說 scale 可以加權這件事 XD
之前只覺得這個 scale 只是在現在的「含有不實訊息」與「含有真實訊息」中間再加上兩個軟性的、不用付出處的回應
之前只覺得這個 scale 只是在現在的「含有不實訊息」與「含有真實訊息」中間再加上兩個軟性的、不用付出處的回應
如果還沒有人先正式用有附上出處的回應回過，可以先吐出沒出處的那種
雖然我也在想，沒有出處的那種回應的預期效果會是什麼
維度上我覺得是呈現 *可信度* ，而隱含的原則會是「不可輕信、無罪推定、公平評價」，因此我有一些假設概念：
*a.* 上面寫的加權運算指的是如，1個 5星等，跟 10 個 3星等，計算出來應該還是 5星等，是假設因為 5星等有得證，所以應該價值最高，而 1星和 5星都有的，就是回歸到 3星了 。
*b.* 是想直接用星等去模糊標籤的定義，統一成可信度，是假設查證的使用者更需要簡單的答案，且有爭議時，量化的星等可能會是一個比 多元標籤 更能客觀呈現的方式。
*c.* 我認為 3星等 會是一個公平的平均值，呈現 `不易判別` ，加權上也要讓遇到爭議時，都回歸到 3星等，假設的是只要出現 `真偽等級` 的 爭議，公平的評價應會等同於 `無法判別` 。
*a.* 上面寫的加權運算指的是如，1個 5星等，跟 10 個 3星等，計算出來應該還是 5星等，是假設因為 5星等有得證，所以應該價值最高，而 1星和 5星都有的，就是回歸到 3星了 。
*b.* 是想直接用星等去模糊標籤的定義，統一成可信度，是假設查證的使用者更需要簡單的答案，且有爭議時，量化的星等可能會是一個比 多元標籤 更能客觀呈現的方式。
*c.* 我認為 3星等 會是一個公平的平均值，呈現 `不易判別` ，加權上也要讓遇到爭議時，都回歸到 3星等，假設的是只要出現 `真偽等級` 的 爭議，公平的評價應會等同於 `無法判別` 。
針對 1 星與 5 星，我覺得這兩者如果標記成「證實為真」還是「證實為假」的話，依然是一個二分法耶
遇到 https://www.facebook.com/groups/1847232902175197/permalink/1926790640886089/ 的話，如果手邊有資料，應該標成幾星等的呢？
遇到 https://www.facebook.com/groups/1847232902175197/permalink/1926790640886089/ 的話，如果手邊有資料，應該標成幾星等的呢？
順道一提現在的處理方式是
可以發一篇「含有真實資訊」的 reply，針對
```
學時間就有人發送免費試吃的糖果還是零食\n但那不是真的行銷試吃活動\n而是毒品零食\n\n大家提醒提醒孩子\n別因無知走上不歸路
```
的部分，附上警局以及檢察署的發言人回應的新聞證實說現在政府確實有查獲到這樣的事情在做宣導，
然後發一篇「含有錯誤資訊」的 reply，針對
```
漸漸的\n這位乖兒子生活提不起勁、成績也一落千丈\n媽媽覺得有問題帶去找醫生\n這一看才發現兒子染上了毒癮
```
的部分，附上對中毒敘述的質疑（ 如 https://www.facebook.com/groups/1847232902175197/permalink/1926790640886089/?comment_id=1926800267551793&comment_tracking=%7B%22tn%22%3A%22R0%22%7D ）
最後，在 LINE bot 裡面會兩者都呈現（ `有 1 人認為含有真實資訊，也有 1 人認為含有不實資訊` ），不講這則是「已證為真」還是「已證為假」；畢竟他可能是 mixed。
可以發一篇「含有真實資訊」的 reply，針對
```
學時間就有人發送免費試吃的糖果還是零食\n但那不是真的行銷試吃活動\n而是毒品零食\n\n大家提醒提醒孩子\n別因無知走上不歸路
```
的部分，附上警局以及檢察署的發言人回應的新聞證實說現在政府確實有查獲到這樣的事情在做宣導，
然後發一篇「含有錯誤資訊」的 reply，針對
```
漸漸的\n這位乖兒子生活提不起勁、成績也一落千丈\n媽媽覺得有問題帶去找醫生\n這一看才發現兒子染上了毒癮
```
的部分，附上對中毒敘述的質疑（ 如 https://www.facebook.com/groups/1847232902175197/permalink/1926790640886089/?comment_id=1926800267551793&comment_tracking=%7B%22tn%22%3A%22R0%22%7D ）
最後，在 LINE bot 裡面會兩者都呈現（ `有 1 人認為含有真實資訊，也有 1 人認為含有不實資訊` ），不講這則是「已證為真」還是「已證為假」；畢竟他可能是 mixed。
我不認為這種同時被標成「含有真實資訊」又標成「含有錯誤資訊」訊息，跟沒人回過的都應該被標成「無法判別」；他是個揉合出來的故事，來傳達一個消息，而這個消息剛好是政府目前正想推廣著的。
不過我在想
如果之後實作 segment 的話（ 請見 https://hackmd.io/s/rJQaJ9wwl#future-work-segments ）
針對個別 segment 就不會用「含有⋯⋯」這樣的分類方式了
如果針對同一個 segment 也有正反兩個意見，那這個 segmetn 就真的「真假難辨」了
如果之後實作 segment 的話（ 請見 https://hackmd.io/s/rJQaJ9wwl#future-work-segments ）
針對個別 segment 就不會用「含有⋯⋯」這樣的分類方式了
如果針對同一個 segment 也有正反兩個意見，那這個 segmetn 就真的「真假難辨」了
【真的假的】2017/1/26 新年前 Meeting Note ==== Participants --- GGM, Lucien, Johnson, Billion 討論哪些是 MVP、哪些不
那我覺得以上面這則毒品來說，如果 1星 vs 5星 的話，可能算出來就可以寫是 4星了，比 3星好一點 😂 ，或著還是補充原始數據。
2017-03-23 02:17:35.100 300 <158>1 2017-03-23T02:17:34.892133+00:00 heroku router - - at=info method=HEAD path="/" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=dc9cb563-d876-4c0f-8e82-2638e414f32e fwd="54.247.188.179" dyno=web.1 connect=1ms service=2ms status=200 bytes=135 protocol=https 2017-03-23 02:18:06.853 426 <134>1 2017-03-23T02:17:15+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.085 sample#load-avg-5m=0.115 sample#load-avg-15m=0.095 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12575116.0kB sample#memory-cached=1054932.0kB sample#memory-redis=1583712bytes sample#hit-rate=0.86567 sample#evicted-keys=0 2017-03-23 02:18:49.060 298 <158>1 2017-03-23T02:18:48.792726+00:00 heroku router - - at=info method=HEAD path="/" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=ff6fd74f-e3a9-40c2-8ac0-b70fecad5d26 fwd="54.251.34.67" dyno=web.1 connect=1ms service=1ms status=200 bytes=135 protocol=https 2017-03-23 02:21:19.516 298 <158>1 2017-03-23T02:21:19.145546+00:00 heroku router - - at=info method=HEAD path="/" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=27ff330a-27f0-4693-8031-b930dbecd9c5 fwd="54.251.34.67" dyno=web.1 connect=0ms service=2ms status=200 bytes=135 protocol=https 2017-03-23 02:22:01.153 423 <134>1 2017-03-23T02:21:14+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.075 sample#load-avg-5m=0.1 sample#load-avg-15m=0.09 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12574776.0kB sample#memory-cached=1054940.0kB sample#memory-redis=1583712bytes sample#hit-rate=0.86567 sample#evicted-keys=0 2017-03-23 02:23:49.221 298 <158>1 2017-03-23T02:23:49.084225+00:00 heroku router - - at=info method=HEAD path="/" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=ff02723a-9eea-400a-85f3-3f421d024ae7 fwd="54.251.34.67" dyno=web.1 connect=5ms service=6ms status=200 bytes=135 protocol=https 2017-03-23 02:24:03.151 424 <134>1 2017-03-23T02:23:52+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.28 sample#load-avg-5m=0.155 sample#load-avg-15m=0.11 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12574780.0kB sample#memory-cached=1054940.0kB sample#memory-redis=1583712bytes sample#hit-rate=0.86567 sample#evicted-keys=0 2017-03-23 02:24:15.525 300 <158>1 2017-03-23T02:24:15.242330+00:00 heroku router - - at=info method=HEAD path="/" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=a4118542-6ada-4443-ba9c-9e4bf1f09d99 fwd="54.248.250.232" dyno=web.1 connect=0ms service=2ms status=200 bytes=135 protocol=https 2017-03-23 02:25:06.343 425 <134>1 2017-03-23T02:23:52+00:00 app heroku-redis - - source=REDIS sample#active-connections=2 sample#load-avg-1m=0.155 sample#load-avg-5m=0.14 sample#load-avg-15m=0.105 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12574668.0kB sample#memory-cached=1054944.0kB sample#memory-redis=1583712bytes sample#hit-rate=0.86567 sample#evicted-keys=0 2017-03-23 02:26:32.699 299 <158>1 2017-03-23T02:26:32.447398+00:00 heroku router - - at=info method=HEAD path="/" host=<http://rumor-line-bot.herokuapp.com|rumor-line-bot.herokuapp.com> request_id=9e65a200-b4d4-48b2-b3ed-f6aeb378bb00 fwd="184.73.237.85" dyno=web.1 connect=1ms service=2ms status=200 bytes=135 protocol=https
oh no
Free app running time quota exhausted
該搬出 heroku 了⋯⋯
@ronnywang 請問 middle2 可以用嗎 QQ
他是 12factor app
https://github.com/MrOrz/rumors-line-bot/
只要能 push 與能設定 env vars，而且要有 https public link 這樣應該就能用
https://github.com/MrOrz/rumors-line-bot/
只要能 push 與能設定 env vars，而且要有 https public link 這樣應該就能用
rumors-line-bot - Line bot that checks if a message contains internet rumor.
https://middle2.com/register.php File not found QAQ
還是我先通通丟我的 linode 上 ._.
只是只要任何一個服務爆流量就整個爆炸 XD
我先刷個卡讓他可以跑好了 www
好了 沒事兒沒事兒
XD 太晚回來，可以搬來 middle2 啊
給我你的 email ，我幫你開帳號
想確認一下目前的給編輯的態度，是鼓勵重複回應還是有人回覆就好，預期每個訊息的回覆量大概有多少啊(?)，我覺得這可能會是一個呈現方式的討論基礎～
我覺得呈現原始評價數據是有價值，但是如果是鼓勵重複回應，那當回應數量大到一個程度後 ，就可能會變成 一面倒，或是 讓使用者困惑，最後可能還會面臨到需要另外給評論做價值評價的問題（哪一則評論值得作為來源）。
例如呈現 「 *有 `1 人` 認為含有真實資訊，也有 `1 人` 認為含有不實資訊* 」這可能沒有問題，使用者的判斷負擔不大，但如果是「 *有 `20 人` 認為含有真實資訊，也有 `1 人` 認為含有不實資訊* 」，如果我是想查證的使用者，那該選擇相信還是不相信呢？有可能 這篇文章只是 正確的部分 比較容易證實，也有可能 那 1則 不實的證明才是最重要的。
如果回應量大的話，採用星等 level 可以解決的是透過運算去平衡可信度的評價（也可以加進其他參數），也讓結果簡易呈現。
（不知道有沒有討論過）
我覺得呈現原始評價數據是有價值，但是如果是鼓勵重複回應，那當回應數量大到一個程度後 ，就可能會變成 一面倒，或是 讓使用者困惑，最後可能還會面臨到需要另外給評論做價值評價的問題（哪一則評論值得作為來源）。
例如呈現 「 *有 `1 人` 認為含有真實資訊，也有 `1 人` 認為含有不實資訊* 」這可能沒有問題，使用者的判斷負擔不大，但如果是「 *有 `20 人` 認為含有真實資訊，也有 `1 人` 認為含有不實資訊* 」，如果我是想查證的使用者，那該選擇相信還是不相信呢？有可能 這篇文章只是 正確的部分 比較容易證實，也有可能 那 1則 不實的證明才是最重要的。
如果回應量大的話，採用星等 level 可以解決的是透過運算去平衡可信度的評價（也可以加進其他參數），也讓結果簡易呈現。
（不知道有沒有討論過）
預期的回覆量應該是 1~2 篇唷，除非是特別有爭議的 article、導致編輯戰出現
如果 20人認為含有真實資訊、20 人認為含有不實資訊，而且有 40 篇佐證資料，那我覺得也是挺酷的 XD
但確實還沒討論到說如果真的有編輯戰出現的時候要怎麼辦
或許要看看編輯戰在這個平台上其實會長得什麼樣子，再來決定下一步呢
- 1
覺得是要考慮編輯戰的狀況，還有其衍生的回覆數量，才會知道下一步。因為以上討論的癥結點例子，好像都是在關於 爭議 article 的應對上。 🐼
而如果正反 1:1 的 mixed 沒有一個可定案的終結機制（如判定為 mixed ），那應該有機會持續轉變成編輯戰吧。星等的好處是可以直接算成 隱含 mixed 的 3 star ，在回覆量不論多寡上都能呈現客觀比對的結果。但如果預期的常態回覆量是 1-2 篇且無爭議的話，覺得採用星等的意義就不大了～
而如果正反 1:1 的 mixed 沒有一個可定案的終結機制（如判定為 mixed ），那應該有機會持續轉變成編輯戰吧。星等的好處是可以直接算成 隱含 mixed 的 3 star ，在回覆量不論多寡上都能呈現客觀比對的結果。但如果預期的常態回覆量是 1-2 篇且無爭議的話，覺得採用星等的意義就不大了～
https://www.facebook.com/groups/chatbot.tw/permalink/760432260801818/
```收到Line的通知，四月開始，除非你的Bot只是Trial帳號，好友人數在50以下，否則若你的bot需要主動發訊息(用到PushAPI)，那記得要去變更方案。Linebot好友人數在50000人以內時，只需要每月付款3888(進階版API方案)，如果你的bot好友人數在80000人以內時，需要每月付款8888(專業版API方案)```
```收到Line的通知，四月開始，除非你的Bot只是Trial帳號，好友人數在50以下，否則若你的bot需要主動發訊息(用到PushAPI)，那記得要去變更方案。Linebot好友人數在50000人以內時，只需要每月付款3888(進階版API方案)，如果你的bot好友人數在80000人以內時，需要每月付款8888(專業版API方案)```
我們以前到現在都是用
`免費版 月費0元 僅可使用Reply API`
`免費版 月費0元 僅可使用Reply API`
這個變更老早就有說了
他 pricing table 有改的樣子
嗯嗯挖災
我其實眼殘 .. XDD 我一開始看成
`好友人數在50以下，則你的bot需要主動發訊息(用到PushAPI)`
`好友人數在50以下，則你的bot需要主動發訊息(用到PushAPI)`
XD
2017-03-24
mrorz: 搬到 middle2 或用 gcp free 方案
yhsiang: 有申請 middle2 囉，等 ronny 升級 NodeJS 還有處理 build script~
yhsiang: 有申請 middle2 囉，等 ronny 升級 NodeJS 還有處理 build script~
說到這個 我們預算有一部分的錢是 aws 耶 如果沒花到錢的話 全部拿去贊助 middle2 嗎 XD
不然也可以一半一半 aws 應該有些服務還是用得到
Hmm
現在的費用是
每個月 $7 (Heroku) + $10 (Linode)
每個月 $7 (Heroku) + $10 (Linode)
看要不要把這個算進去
如果爆量的話我們可以買豪華的 Heroku lol
也可以贊助 middle2 呀 XDD
如果要長期 host 在 middle2 當然要贊助一筆～
2017-03-25
@dk00 has joined the channel
http://rumors.hacktabl.org/?orderBy=createdAt&before=WzE0OTA0MjAwODk2MjgsImJhc2ljI0FWc0Q5Y01kdEtwOTZzNjU5Qzk2Il0%3D&after=
資料庫發現大量重複舉報的 article。
但如果是透過 LINE bot，他在搜尋的時候應該不會重複舉報才對。
@ggm @darkbtf 請問你們有沒有空處理這個呢 QQ
由於 elasticsearch 放在 production 機器上沒有 expose 出來（本來就不該 expose @@）所以要連到 production 機器上面操作資料庫來查 article 送出的 user。
資料庫發現大量重複舉報的 article。
但如果是透過 LINE bot，他在搜尋的時候應該不會重複舉報才對。
@ggm @darkbtf 請問你們有沒有空處理這個呢 QQ
由於 elasticsearch 放在 production 機器上沒有 expose 出來（本來就不該 expose @@）所以要連到 production 機器上面操作資料庫來查 article 送出的 user。
我忙著做 rumors-site 的界面把 JSON 弄掉，一時半刻無法處理 orz
@mmm90415 has joined the channel
有 ssh key 嗎?
我可以上去看看
軍官那個是兩個 userId 舉報的
等等我 aggregate 一下 XD 確定一下
```
curl -XGET http://localhost:9200/articles/_search?pretty -d '{
> "query": {
> "match": { "text": "軍官翹班" }
> },
> "size": 0,
> "aggs": {
> "user": {
> "terms": { "field": "userId" }
> }
> }
> }'
{
"took" : 18,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"hits" : {
"total" : 403,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"user" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "U9019d71099419ef66cd46a3c1e7c0949",
"doc_count" : 393
},
{
"key" : "U02aea8403671f6d2a4a2d857524bc69d",
"doc_count" : 6
},
{
"key" : "",
"doc_count" : 3
},
{
"key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
"doc_count" : 1
}
]
}
}
}
```
curl -XGET http://localhost:9200/articles/_search?pretty -d '{
> "query": {
> "match": { "text": "軍官翹班" }
> },
> "size": 0,
> "aggs": {
> "user": {
> "terms": { "field": "userId" }
> }
> }
> }'
{
"took" : 18,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"hits" : {
"total" : 403,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"user" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "U9019d71099419ef66cd46a3c1e7c0949",
"doc_count" : 393
},
{
"key" : "U02aea8403671f6d2a4a2d857524bc69d",
"doc_count" : 6
},
{
"key" : "",
"doc_count" : 3
},
{
"key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
"doc_count" : 1
}
]
}
}
}
```
```
{”_index":"users","_type":"basic","_id":"U9019d71099419ef66cd46a3c1e7c0949","found":false}
```
{”_index":"users","_type":"basic","_id":"U9019d71099419ef66cd46a3c1e7c0949","found":false}
```
這個 userid 傳了 393 個，不過不知道這是誰
ohoh 好像不是 users index 唷
users index 是小編的帳號
咦 那為什麼每個 article 都會帶一個 userId
article 看起來是回報的?
喔喔，article 的 userId 跟 User index 不一定對得起來唷
這裡是個沒有弄好的設計：
https://github.com/MrOrz/rumors-db/blob/master/schema/articles.js
每個有 author 的東西（article, reply, replyconnection）都有 “userId" 與 “from” 這兩個 field
https://github.com/MrOrz/rumors-db/blob/master/schema/articles.js
每個有 author 的東西（article, reply, replyconnection）都有 “userId" 與 “from” 這兩個 field
以後打算開放 API key 來讓第三方寫 client
這個時候 from 就是某個 app id
userId 就是那個第三方 app 自己管理的 userId
userId 就是那個第三方 app 自己管理的 userId
這個設計確實沒有很好 Orz
如果我們能設計 OpenID connect / jwt 來做 authentication，把所有 user 都收入我們管理，系統上就可以更簡潔一點 |||
如果我們能設計 OpenID connect / jwt 來做 authentication，把所有 user 都收入我們管理，系統上就可以更簡潔一點 |||
原來如此，所以重覆的可能來自不同地方，但這樣是否沒有資訊可以往下追了 |||
所以可能要查的是這樣的：
這些新蓋出來的 article 的 `(userId, from)` 組合到底是什麼
這些新蓋出來的 article 的 `(userId, from)` 組合到底是什麼
稍微列一下 `(userId, from)`
OK 我再多 agg 一層
好唷麻煩你了 QQ
```
curl -XGET http://localhost:9200/articles/_search?pretty -d '{
> "query": {
> "match": { "text": "軍官翹班" }
> },
> "size": 0,
> "aggs": {
> "user": {
> "terms": { "field": "userId" },
> "aggs": {
> "from": {
> "terms": { "field": "from" }
> }
> }
> }
> }
> }'
{
"took" : 24,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"hits" : {
"total" : 497,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"user" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "U9019d71099419ef66cd46a3c1e7c0949",
"doc_count" : 487,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 487
}
]
}
},
{
"key" : "U02aea8403671f6d2a4a2d857524bc69d",
"doc_count" : 6,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 6
}
]
}
},
{
"key" : "",
"doc_count" : 3,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "BOT_LEGACY",
"doc_count" : 3
}
]
}
},
{
"key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
"doc_count" : 1,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 1
}
]
}
}
]
}
}
}
```
好像都是 linebot 來的 而且越來越多
curl -XGET http://localhost:9200/articles/_search?pretty -d '{
> "query": {
> "match": { "text": "軍官翹班" }
> },
> "size": 0,
> "aggs": {
> "user": {
> "terms": { "field": "userId" },
> "aggs": {
> "from": {
> "terms": { "field": "from" }
> }
> }
> }
> }
> }'
{
"took" : 24,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"hits" : {
"total" : 497,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"user" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "U9019d71099419ef66cd46a3c1e7c0949",
"doc_count" : 487,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 487
}
]
}
},
{
"key" : "U02aea8403671f6d2a4a2d857524bc69d",
"doc_count" : 6,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 6
}
]
}
},
{
"key" : "",
"doc_count" : 3,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "BOT_LEGACY",
"doc_count" : 3
}
]
}
},
{
"key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
"doc_count" : 1,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 1
}
]
}
}
]
}
}
}
```
好像都是 linebot 來的 而且越來越多
理論上要有 secret 才能把 from 設成「 `RUMORS_LINE_BOT` 」 https://github.com/MrOrz/rumors-line-bot/blob/master/src/gql.js#L32
所以可以確定是用了 linebot 的 client 做的吧
嗯，總之真的是 line bot server 送的
https://github.com/MrOrz/rumors-api/blob/60984d43fb29f63977d1221ccebe8c8d3693fdf7/src/checkHeaders.js#L6
https://github.com/MrOrz/rumors-api/blob/60984d43fb29f63977d1221ccebe8c8d3693fdf7/src/checkHeaders.js#L6
然後 line bot server 本身又有去驗證來自 LINE server 的 signature https://github.com/MrOrz/rumors-line-bot/blob/master/src/checkSignature.js
有辦法 log 送的人實際講了什麼嗎
他在 heroku logs
我開給你
也可能是 adb monkey runner 之類的
由於 LINE 有電腦版，這樣的操作用按鍵精靈就可以了呢
用 LINE 是要怎麼傳這麼多 |||
@vup72 has joined the channel
ohoh 好像不是 users index 唷
users index 是小編的帳號
咦 那為什麼每個 article 都會帶一個 userId
article 看起來是回報的?
喔喔，article 的 userId 跟 User index 不一定對得起來唷
這裡是個沒有弄好的設計：
https://github.com/MrOrz/rumors-db/blob/master/schema/articles.js
每個有 author 的東西（article, reply, replyconnection）都有 “userId" 與 “from” 這兩個 field
https://github.com/MrOrz/rumors-db/blob/master/schema/articles.js
每個有 author 的東西（article, reply, replyconnection）都有 “userId" 與 “from” 這兩個 field
以後打算開放 API key 來讓第三方寫 client
這個時候 from 就是某個 app id
userId 就是那個第三方 app 自己管理的 userId
userId 就是那個第三方 app 自己管理的 userId
這個設計確實沒有很好 Orz
如果我們能設計 OpenID connect / jwt 來做 authentication，把所有 user 都收入我們管理，系統上就可以更簡潔一點 |||
如果我們能設計 OpenID connect / jwt 來做 authentication，把所有 user 都收入我們管理，系統上就可以更簡潔一點 |||
原來如此，所以重覆的可能來自不同地方，但這樣是否沒有資訊可以往下追了 |||
所以可能要查的是這樣的：
這些新蓋出來的 article 的 `(userId, from)` 組合到底是什麼
這些新蓋出來的 article 的 `(userId, from)` 組合到底是什麼
稍微列一下 `(userId, from)`
OK 我再多 agg 一層
好唷麻煩你了 QQ
```
curl -XGET http://localhost:9200/articles/_search?pretty -d '{
> "query": {
> "match": { "text": "軍官翹班" }
> },
> "size": 0,
> "aggs": {
> "user": {
> "terms": { "field": "userId" },
> "aggs": {
> "from": {
> "terms": { "field": "from" }
> }
> }
> }
> }
> }'
{
"took" : 24,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"hits" : {
"total" : 497,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"user" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "U9019d71099419ef66cd46a3c1e7c0949",
"doc_count" : 487,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 487
}
]
}
},
{
"key" : "U02aea8403671f6d2a4a2d857524bc69d",
"doc_count" : 6,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 6
}
]
}
},
{
"key" : "",
"doc_count" : 3,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "BOT_LEGACY",
"doc_count" : 3
}
]
}
},
{
"key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
"doc_count" : 1,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 1
}
]
}
}
]
}
}
}
```
好像都是 linebot 來的 而且越來越多
curl -XGET http://localhost:9200/articles/_search?pretty -d '{
> "query": {
> "match": { "text": "軍官翹班" }
> },
> "size": 0,
> "aggs": {
> "user": {
> "terms": { "field": "userId" },
> "aggs": {
> "from": {
> "terms": { "field": "from" }
> }
> }
> }
> }
> }'
{
"took" : 24,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"hits" : {
"total" : 497,
"max_score" : 0.0,
"hits" : [ ]
},
"aggregations" : {
"user" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "U9019d71099419ef66cd46a3c1e7c0949",
"doc_count" : 487,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 487
}
]
}
},
{
"key" : "U02aea8403671f6d2a4a2d857524bc69d",
"doc_count" : 6,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 6
}
]
}
},
{
"key" : "",
"doc_count" : 3,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "BOT_LEGACY",
"doc_count" : 3
}
]
}
},
{
"key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
"doc_count" : 1,
"from" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "RUMORS_LINE_BOT",
"doc_count" : 1
}
]
}
}
]
}
}
}
```
好像都是 linebot 來的 而且越來越多
理論上要有 secret 才能把 from 設成「 `RUMORS_LINE_BOT` 」 https://github.com/MrOrz/rumors-line-bot/blob/master/src/gql.js#L32
rumors-line-bot - Line bot that checks if a message contains internet rumor.
所以可以確定是用了 linebot 的 client 做的吧
嗯，總之真的是 line bot server 送的
https://github.com/MrOrz/rumors-api/blob/60984d43fb29f63977d1221ccebe8c8d3693fdf7/src/checkHeaders.js#L6
https://github.com/MrOrz/rumors-api/blob/60984d43fb29f63977d1221ccebe8c8d3693fdf7/src/checkHeaders.js#L6
rumors-api - GraphQL API server for clients like rumors-site and rumors-line-bot
然後 line bot server 本身又有去驗證來自 LINE server 的 signature https://github.com/MrOrz/rumors-line-bot/blob/master/src/checkSignature.js
rumors-line-bot - Line bot that checks if a message contains internet rumor.
有辦法 log 送的人實際講了什麼嗎
他在 heroku logs
我開給你
rumors-line-bot - Line bot that checks if a message contains internet rumor.
@mrorz commented on @mrorz’s file 20170325-1752.bot.log: We've been spammed...
出現惡意攻擊了
LINE 好像有黑名單功能
我看看
LINE bot 無法
我寫個 blacklist 好了
然後資料庫備份可能要先處理了呢
如果要對資料庫做清理，要先有備份機制
如果要對資料庫做清理，要先有備份機制
好 我儘快弄個
看起來是有人弄了 sikuli script 一直洗唷
怎麼確定是 sikuli 呀
這人也太無聊
或許需要一個 abnormal 示警機制
但我要先更新網站外觀 orz
最好要有後台就是
啊是呢
kibana 嗎 orz
我 google 過 elasticsearch backend
除了 kibana 好像沒啥能用的 Orz
對呀
然後 kibana 要配 searchguard
不然會是裸露的
官方的 auth 機制要付費
QQ
現在有人改試「飯後喝涼水」了⋯⋯
然後我剛剛 deploy 好像有設定跑掉了，現在網頁會一直 cannot fetch
我先 revert 回去 囧
我先 revert 回去 囧
2017-03-26
我回高雄去大港了沒辦法及時處理 QQ 感謝蝴蝶
也可能是 adb monkey runner 之類的
果不其然換了個 userId ( U13ee837855712f64503bc9676ff9c25c )
@ggm commented on @mrorz’s file 20170326-0106.log: 所以他是一直傳同一份文章？看 log 是有不同內容的，LINE 應該是很容易換 id
不同內容，但都是傳入 gibberish
仔細看會發現他傳的都像是假文產生器產生的東西
是產生器出來的 還是是那種真的很多人在散播的呀？
往好處想是不是有人有一堆內容 想要建檔？
不是
「員年：達沃8動·蘇6克運，\n前克球9羅埃西1足亞」
這種是內容嗎
只是今天才仔細去看
由於 LINE 有電腦版，這樣的操作用按鍵精靈就可以了呢
So here comes the question: do we need captchas on users sending duplicated articles or sending articles too often?
Hmm...captcha in line bot
當然針對後期演化的假文產生攻擊，near-duplicate detection 不會 work
應該用頻率偵測吧
這個頻率高到不太合理
翻了之前的記錄，整理了編輯和社群小聚的進行方式，大家有想法請一起補充~~~~
https://hackmd.io/s/H1yCTyS2e
https://hackmd.io/s/H1yCTyS2e
編輯與社群小聚 進行規劃 === ## 編輯 ### 1. 編輯招募 * 哪一群人比較有可能加入編輯？（個人） * 可否調查一下社團內現在的組成，這樣要廣發招募訊息也會比較有方向（或是之前已經
其實我想像中的編輯社群或許應該是這樣建立的：
1. FB group 頒布規則（https://g0v-tw.slack.com/archives/C2PPMRQGP/p1489597696918885）轉為協作討論空間
2. 小編們闢謠，然後在 FB group 求救
3. 大家看到 group 裡的文章，tag 可能知道的朋友進來協助撰寫回應。
4. 更多小編看到自己真的不確定答案的時候能有個靠山，就更願意投入；隨著加入 group 的小編越多，能觸及到的專業問題也越多，參與者朋友圈內具備相關知識的人的機會也變多。
以上完成一個正向循環，社群就起來了。
1. FB group 頒布規則（https://g0v-tw.slack.com/archives/C2PPMRQGP/p1489597696918885）轉為協作討論空間
2. 小編們闢謠，然後在 FB group 求救
3. 大家看到 group 裡的文章，tag 可能知道的朋友進來協助撰寫回應。
4. 更多小編看到自己真的不確定答案的時候能有個靠山，就更願意投入；隨著加入 group 的小編越多，能觸及到的專業問題也越多，參與者朋友圈內具備相關知識的人的機會也變多。
以上完成一個正向循環，社群就起來了。
最近終於把網站整理到一個可以用的階段了，我明後天晚上就會頒布那個規則～
兩者應該不全然衝突，同意 @mrorz 說的，先在FB group 建立規則，利用這個空間作為闢謠疑問討論區。
但我還是覺得定期的見面交流有必要，可以讓編輯的執行經驗有系統的交流，可以增加內容的精緻度和使用者對話的有效性。
前期在擴展加入的編輯人數，增加現有編輯轉邀身邊朋友的方式很可行，所以一開始講的調查可以忽略。而裡面提到找特定專業的組織，其實並不排擠Johnson希望的做法，只是多了一個approach 外部資源的方式。
但我還是覺得定期的見面交流有必要，可以讓編輯的執行經驗有系統的交流，可以增加內容的精緻度和使用者對話的有效性。
前期在擴展加入的編輯人數，增加現有編輯轉邀身邊朋友的方式很可行，所以一開始講的調查可以忽略。而裡面提到找特定專業的組織，其實並不排擠Johnson希望的做法，只是多了一個approach 外部資源的方式。
他滿間歇性的耶，一段一段的
今日的攻擊，大概是一頁 25 篇產生器假文
我在想要不要
1. 網站介面在文章列表提供多選 + 通通標成Not article 的功能 (類似email app)
1. 網站介面在文章列表提供多選 + 通通標成Not article 的功能 (類似email app)
2. 統計文章作者 User ID 被標成 not-article 的次數，高的封鎖
3. 需 Review non-rumor 避免有人在多選的時候誤把有意義的回報標成 non-article ( 只要加上rumor 與 non-rumor 的回應，line bot 也能正常回覆這些曾經被標成 not article 的文章)
大家覺得呢
至於 near-duplicate detection 可能還是要做，因為今天有一個回報長這樣
http://rumors.hacktabl.org/article/AVsIpOUYtKp96s659DLY
http://rumors.hacktabl.org/article/AVsIpOUYtKp96s659DLY
往下卷可以看到「相關文章」那裡有一個一模一樣的文章
我覺得 line bot 裡面如果找到的字跟query text 相差真的超小
那就不讓使用者選擇「這裡沒有要找的文章」這個選項，直接給使用者看結果好了。
那就不讓使用者選擇「這裡沒有要找的文章」這個選項，直接給使用者看結果好了。
2017-03-27
其實我想像中的編輯社群或許應該是這樣建立的：
1. FB group 頒布規則（https://g0v-tw.slack.com/archives/C2PPMRQGP/p1489597696918885）轉為協作討論空間
2. 小編們闢謠，然後在 FB group 求救
3. 大家看到 group 裡的文章，tag 可能知道的朋友進來協助撰寫回應。
4. 更多小編看到自己真的不確定答案的時候能有個靠山，就更願意投入；隨著加入 group 的小編越多，能觸及到的專業問題也越多，參與者朋友圈內具備相關知識的人的機會也變多。
以上完成一個正向循環，社群就起來了。
1. FB group 頒布規則（https://g0v-tw.slack.com/archives/C2PPMRQGP/p1489597696918885）轉為協作討論空間
2. 小編們闢謠，然後在 FB group 求救
3. 大家看到 group 裡的文章，tag 可能知道的朋友進來協助撰寫回應。
4. 更多小編看到自己真的不確定答案的時候能有個靠山，就更願意投入；隨著加入 group 的小編越多，能觸及到的專業問題也越多，參與者朋友圈內具備相關知識的人的機會也變多。
以上完成一個正向循環，社群就起來了。
但我週六以前晚上都沒有空 orz
或許可以線上討論的事情就先討論一下？
關於 FB group 的討論規範
https://www.facebook.com/groups/1847232902175197/
最近有越來越多來問真的假的的 orz
我覺得可能要更新一下規範與置頂文。
想要新增這樣的規則：
```
版面以這些貼文為主：
1. 使用問題回報：請附上操作的步驟，還有遇到什麼樣的問題。
2. 不知道如何回應文章，尋求討論：必須附上 (a) 已經投稿至 rumors 網站的連結、(b) 自己找了哪些來源。另外，如果能附上自己對答案的草擬或想法，就更好了
3. 討論版規：反應關閉留言機制等等。
4. 討論現有功能或建議新功能。
5. 公告更新消息。
程式實作方面的討論，還有新知分享與閒話家常，請移駕 g0v slack 的 #rumors channel。
其餘將會視情況關閉留言，將版片留給協作相關的討論。
```
最近終於把網站整理到一個可以用的階段了，我明後天晚上就會頒布那個規則～
兩者應該不全然衝突，同意 @mrorz 說的，先在FB group 建立規則，利用這個空間作為闢謠疑問討論區。
但我還是覺得定期的見面交流有必要，可以讓編輯的執行經驗有系統的交流，可以增加內容的精緻度和使用者對話的有效性。
前期在擴展加入的編輯人數，增加現有編輯轉邀身邊朋友的方式很可行，所以一開始講的調查可以忽略。而裡面提到找特定專業的組織，其實並不排擠Johnson希望的做法，只是多了一個approach 外部資源的方式。
但我還是覺得定期的見面交流有必要，可以讓編輯的執行經驗有系統的交流，可以增加內容的精緻度和使用者對話的有效性。
前期在擴展加入的編輯人數，增加現有編輯轉邀身邊朋友的方式很可行，所以一開始講的調查可以忽略。而裡面提到找特定專業的組織，其實並不排擠Johnson希望的做法，只是多了一個approach 外部資源的方式。
- 1
禮拜四的 NCC 論壇，他說要請我們準備發言稿，我稍後把兩個子題貼上來（其實我不知道可不可以公開耶，他是寄信給我說開會內容的）
`1. 網站介面在文章列表提供多選 + 通通標成Not article 的功能 (類似email app)`
這個是不是也可以做在我們之前的分類裡面有一個是其他（or 閒聊）
這個是不是也可以做在我們之前的分類裡面有一個是其他（or 閒聊）
not article 就是「其他 or 閒聊」唷
`2. 統計文章作者 User ID 被標成 not-article 的次數，高的封鎖`
這個應該沒什麼問題，不過正確來說是指高頻率對吧？
這個應該沒什麼問題，不過正確來說是指高頻率對吧？
`3. 需 Review non-rumor`
這個說 Review 的意思是？他被標記後可以被復原？我覺得是需要的，我想到說如果有人會一直傳假內容上來，那麼他會不會也惡意地想要把全部文章標成 non-article 之類的
這個說 Review 的意思是？他被標記後可以被復原？我覺得是需要的，我想到說如果有人會一直傳假內容上來，那麼他會不會也惡意地想要把全部文章標成 non-article 之類的
其實這個「review」具體來說只是提供一個「只被標成『non-article』的文章」列表。這個列表大家都可以看，所以可以與首頁目前的 All / Not replied yet / Replied filter 並列。
嗯嗯那跟我下面講個應該類似，他就是一個標籤
不過我覺得可以把這個標籤的行為做的跟其他標籤無異，就是變成有 k 個人 認為他是 non-article，不見得 non-article 是個 on/off
然後 es 在搜尋的時候在設一個 non-article 的門檻，超過 3 個的不要吐出來
not article 就是「其他 or 閒聊」唷
不過搜尋的結果有兩塊，一個是回傳給小編的，一個是回傳給使用者的，給小編的可能門檻高一點？給使用者的門檻低一點？但是這樣也會發生一種情形就是當某篇文章被湊過高的 non-article 標籤之後，就再也看不到他了，那這時候就是使用 revert 機制的時候
其實這個「review」具體來說只是提供一個「只被標成『non-article』的文章」列表。這個列表大家都可以看，所以可以與首頁目前的 All / Not replied yet / Replied filter 並列。
嗯嗯那跟我下面講個應該類似，他就是一個標籤
我是覺得實務上，一則測試用簡訊要 3 個人標成 non-article 才會永遠看不到他，好像有點不實用 @@
我原本的想法是這樣的
1. 因為小編通常都會使用「Not replied yet」這個 filter 來過濾出沒人回過的 article，所以被回過 non-article 的文章，自然就不會列出
2. 但如果開放在 list 勾選數則一起標成「non-article」，那有可能會有人誤把有意義的 article 標成 non-article（或惡意地將大片 article 標成 non-article——但是小編是記名的，這個情形應該還好吧）。所以會需要一個 non-article 列表 filter 讓小編偶爾看看 non-article，找出事實上有意義的 non-article 送出新的 rumor / non-rumor reply。
3. 對 LINE bot 使用者來說，只要有 rumor / non-rumor reply，bot 就會顯示有回答，一則 article 有多少 non-article reply 並不會有任何影響。
我原本的想法是這樣的
1. 因為小編通常都會使用「Not replied yet」這個 filter 來過濾出沒人回過的 article，所以被回過 non-article 的文章，自然就不會列出
2. 但如果開放在 list 勾選數則一起標成「non-article」，那有可能會有人誤把有意義的 article 標成 non-article（或惡意地將大片 article 標成 non-article——但是小編是記名的，這個情形應該還好吧）。所以會需要一個 non-article 列表 filter 讓小編偶爾看看 non-article，找出事實上有意義的 non-article 送出新的 rumor / non-rumor reply。
3. 對 LINE bot 使用者來說，只要有 rumor / non-rumor reply，bot 就會顯示有回答，一則 article 有多少 non-article reply 並不會有任何影響。
針對「3」具體來說請見程式碼 XDD
https://github.com/MrOrz/rumors-line-bot/blob/master/src/processMessages.js#L159
我只計算 `rumorReplies`、 `notRumorReplies` 。「 `有人認為您傳送的這則訊息並不是完整的文章內容，或認為「真的假的」不應該處理這則訊息。` 」這句話在 if 的很後面，只要有一個 `rumorReply` 或 `notRumorReply`，那段話就不會出現。
https://github.com/MrOrz/rumors-line-bot/blob/master/src/processMessages.js#L159
我只計算 `rumorReplies`、 `notRumorReplies` 。「 `有人認為您傳送的這則訊息並不是完整的文章內容，或認為「真的假的」不應該處理這則訊息。` 」這句話在 if 的很後面，只要有一個 `rumorReply` 或 `notRumorReply`，那段話就不會出現。
哈哈清楚清楚
我覺得你這樣做也行，但是要從「non-article」救回來這件事情，因為「non-article」會越來越大，所以可能要輔助靠時間排序，這樣才會比較好救回來，然後時間久的應該就很難再救回來了。
不過呢，救不會來也沒差吧？就少一篇文章而已（也不會很不方便），如果這類的假文章真的很多，應該又會被回報
不過呢，救不會來也沒差吧？就少一篇文章而已（也不會很不方便），如果這類的假文章真的很多，應該又會被回報
那按照「最後有人回報」的間來排序「non-article」列表好了，這樣如果真的有 popular message 被誤標，也比較容易能救回來
我會找時間整理一下現在 DB mappings 之間的 relation。
之前為了要讓使用者可以比較好 filter 一些東西，所以 foreign key 擺放得有點奇怪（非傳統 RDBMS 的結構），但當初設計的 foreign key 擺放方式，對『按照「最後有人回報」的間來排序』沒有助益 orz
整理完 mapping 之後，一併整理 query 的需求（例如說要按照啥排序、要做出一個列表來列出「有 non-article」的文章等等），希望能與 @darkbtf 或 @sayuan 一起討論一下要怎麼調整 mapping 比較好 @@
之前為了要讓使用者可以比較好 filter 一些東西，所以 foreign key 擺放得有點奇怪（非傳統 RDBMS 的結構），但當初設計的 foreign key 擺放方式，對『按照「最後有人回報」的間來排序』沒有助益 orz
整理完 mapping 之後，一併整理 query 的需求（例如說要按照啥排序、要做出一個列表來列出「有 non-article」的文章等等），希望能與 @darkbtf 或 @sayuan 一起討論一下要怎麼調整 mapping 比較好 @@
一起討論++
針對「3」具體來說請見程式碼 XDD
https://github.com/MrOrz/rumors-line-bot/blob/master/src/processMessages.js#L159
我只計算 `rumorReplies`、 `notRumorReplies` 。「 `有人認為您傳送的這則訊息並不是完整的文章內容，或認為「真的假的」不應該處理這則訊息。` 」這句話在 if 的很後面，只要有一個 `rumorReply` 或 `notRumorReply`，那段話就不會出現。
https://github.com/MrOrz/rumors-line-bot/blob/master/src/processMessages.js#L159
我只計算 `rumorReplies`、 `notRumorReplies` 。「 `有人認為您傳送的這則訊息並不是完整的文章內容，或認為「真的假的」不應該處理這則訊息。` 」這句話在 if 的很後面，只要有一個 `rumorReply` 或 `notRumorReply`，那段話就不會出現。
rumors-line-bot - Line bot that checks if a message contains internet rumor.
哈哈清楚清楚
我覺得你這樣做也行，但是要從「non-article」救回來這件事情，因為「non-article」會越來越大，所以可能要輔助靠時間排序，這樣才會比較好救回來，然後時間久的應該就很難再救回來了。
不過呢，救不會來也沒差吧？就少一篇文章而已（也不會很不方便），如果這類的假文章真的很多，應該又會被回報
不過呢，救不會來也沒差吧？就少一篇文章而已（也不會很不方便），如果這類的假文章真的很多，應該又會被回報
2017-03-28
那按照「最後有人回報」的間來排序「non-article」列表好了，這樣如果真的有 popular message 被誤標，也比較容易能救回來
我會找時間整理一下現在 DB mappings 之間的 relation。
之前為了要讓使用者可以比較好 filter 一些東西，所以 foreign key 擺放得有點奇怪（非傳統 RDBMS 的結構），但當初設計的 foreign key 擺放方式，對『按照「最後有人回報」的間來排序』沒有助益 orz
整理完 mapping 之後，一併整理 query 的需求（例如說要按照啥排序、要做出一個列表來列出「有 non-article」的文章等等），希望能與 @darkbtf 或 @sayuan 一起討論一下要怎麼調整 mapping 比較好 @@
之前為了要讓使用者可以比較好 filter 一些東西，所以 foreign key 擺放得有點奇怪（非傳統 RDBMS 的結構），但當初設計的 foreign key 擺放方式，對『按照「最後有人回報」的間來排序』沒有助益 orz
整理完 mapping 之後，一併整理 query 的需求（例如說要按照啥排序、要做出一個列表來列出「有 non-article」的文章等等），希望能與 @darkbtf 或 @sayuan 一起討論一下要怎麼調整 mapping 比較好 @@
- 👌2
一起討論++
@ggm 要稿子的不是星期四 ncc 的會，是下個月世新大學的會議吧?
兩個好像是不一樣的?
原來是不同的會議呀
咦！我確認一下 對不起搞混QQ
噢對我搞混了那是 5/19 的
「假新聞的危機與回應」論壇 是 5/16 世新大學的 《傳播研究與實踐》期刊辦的論壇，這個才有要求要 1500 - 3000 字的稿子
不過小班也有敲我們問 NCC 要講哪些東西
這個我沒有要參加，那天有事
噢噢
那 @mrorz 也有收到世新大學那封信嗎
nope
我們只有你收到
「推動網路新聞真實查核機制之諮詢會議議程」
壹、會議時間：106年3月30日(星期四)14時整
貳、會議地點：交通通訊傳播大樓第2003室
叁、會議主持人：本會陳委員憶寧
肆、出席單位：
(一)大型網路平臺/通訊軟體/社群媒體：Facebook、Google、LINE、Yahoo!奇摩
(二)公民團體：g0v零時政府、財團法人台灣媒體觀察教育基金會、財團法人卓越新聞獎基金會、財團法人吳舜文新聞獎助基金會、財團法人新聞公害防治基金會、台灣新聞記者協會、PeoPo公民新聞平台
(三)政府部門：行政院政委吳政忠辦公室、國發會
伍、討論議題：
(一)如何查核網路上的不實新聞
1.大型網路平臺/通訊軟體/社群媒體如何判斷及查核網路上的不實新聞？
2.大型網路平臺/通訊軟體/社群媒體現階段針對新聞真實查核所提出的運作機制為何？
3.可作為我國推動之借鏡、作法及推動時程？
(二)如何推動第三方團體協助健全查核機制
1.第三方團體在健全查核機制可扮演之角色？
2.現有可提供協作之團體、資源或平臺?
3.建置新聞真實查核平臺之可行性及困難之處？
4.新聞真實查核機制建立後如何宣導推動？
(三)政府部門如何協助推動
1.何種網站問答集資料格式，有助第三方團體快速自動接取？
2.政府部門可提供之協力事項？`
壹、會議時間：106年3月30日(星期四)14時整
貳、會議地點：交通通訊傳播大樓第2003室
叁、會議主持人：本會陳委員憶寧
肆、出席單位：
(一)大型網路平臺/通訊軟體/社群媒體：Facebook、Google、LINE、Yahoo!奇摩
(二)公民團體：g0v零時政府、財團法人台灣媒體觀察教育基金會、財團法人卓越新聞獎基金會、財團法人吳舜文新聞獎助基金會、財團法人新聞公害防治基金會、台灣新聞記者協會、PeoPo公民新聞平台
(三)政府部門：行政院政委吳政忠辦公室、國發會
伍、討論議題：
(一)如何查核網路上的不實新聞
1.大型網路平臺/通訊軟體/社群媒體如何判斷及查核網路上的不實新聞？
2.大型網路平臺/通訊軟體/社群媒體現階段針對新聞真實查核所提出的運作機制為何？
3.可作為我國推動之借鏡、作法及推動時程？
(二)如何推動第三方團體協助健全查核機制
1.第三方團體在健全查核機制可扮演之角色？
2.現有可提供協作之團體、資源或平臺?
3.建置新聞真實查核平臺之可行性及困難之處？
4.新聞真實查核機制建立後如何宣導推動？
(三)政府部門如何協助推動
1.何種網站問答集資料格式，有助第三方團體快速自動接取？
2.政府部門可提供之協力事項？`
議程應該可以公開吧 XD
議程可啊
那個 hackmd 可以貼給其他人補充嗎？弄個分隔線之類的
你說哪個呀？我上面貼的那個 不是給 NCC 的 我搞混了 給 NCC 要另外開個
好，給NCC 另外開
嗯嗯 我現在就來開好了
4/21 NCC 會再辦一場
想先問大家的時間
星期五下午
@ronnywang
4/21 我可以參與
2017-03-29
奇妙的加開場呀 ._.
跟五月天一樣
NCC 還想要問4/28行不行
我想要直接說可以，然後推社群的人入坑
每週一次嗎 @@
每次的差別在哪裡呀
政府會回去想一想然後在下次跟大家討論這樣嗎
不是，怕一次講不完
還有各大公司還要回去請示長官
NCC 目前傾向不作為，只負責找大家開會。
（ au 很努力讓政府不要直接管
- 2
@ggm 要不要把給 NCC 發言的 hackmd 貼到 general，問大家有什麼意見要補充？
突然想起來><
好
已貼
2017-03-30
快速記一下，剛剛討論到可以做一些 data mining 知道哪些人文章是適合哪個人回應，然後推給他（不過這個比較遠，先記一下）
實作上應該是用 mining 做 auto tag，當初討論讓編輯者找自己偏好處理的文章，最先做的會是 `搜尋` -> `手動tag` -> `自動 tag`
還有提到，如果有人冒名政府來回應文章的話，要怎麼處理
這邊我有兩個想法：
1. 提示使用者，如果是宣稱 OOO 的話，要看他有沒有附註連結
2. 讓政府先公告後轉連結過來，就可以認證他是政府的不然就加個注意框
1. 提示使用者，如果是宣稱 OOO 的話，要看他有沒有附註連結
2. 讓政府先公告後轉連結過來，就可以認證他是政府的不然就加個注意框
基本上我們是有帳號機制的，如果他是在回應中，自稱自己是政府單位，看我們能不能用提醒，或是訓練大眾去 downvote 回應。
另外，如果要讓政府能積極參與的話，我們能設計認證帳號，給政府專門使用，被在介面上標示為認證帳號，但需要考慮如何不會讓使用者覺得這是言論管制。
實作上應該是用 mining 做 auto tag，當初討論讓編輯者找自己偏好處理的文章，最先做的會是 `搜尋` -> `手動tag` -> `自動 tag`
基本上我們是有帳號機制的，如果他是在回應中，自稱自己是政府單位，看我們能不能用提醒，或是訓練大眾去 downvote 回應。
另外，如果要讓政府能積極參與的話，我們能設計認證帳號，給政府專門使用，被在介面上標示為認證帳號，但需要考慮如何不會讓使用者覺得這是言論管制。
@mrorz 我覺得可以跟政府提，目前的闢搖專區很不適合爬資料，希望能有所改進。
有 RSS 就好
問題是資料結構的問題喔
除了165有整理比較好，但其他都還需要改進
其他連 rss 都沒有
是說 NCC 也沒有 open data
還有闢謠沒有附原文的問題
像是這則是把謠言跟答案混在一起
嗯對 衛福部的也是
我在 hackfoldr 加開了設計專區，我會慢慢整理一些設計上的問題與決策，另外也開了一個 md 來整理相關案例，希望大家能幫忙協助整理
- 👍4
案例專區 https://hackmd.io/s/HJZ_BN53x @mrorz @ggm @bil @hazelwei @ooookai
# 【真的假的】事實查核相關案例 ## Whatsapp Detector 這是一家哥倫比亞的新聞網站的專案，他們原先就有一個營運多年的lie detector 的查實網站，查實方式是有只要範圍符
Glossary https://hackmd.io/s/HyVGVEchg
# 【真的假的】開發・設計・使用 Glossary 術語對照 * Dev: used in the codebase * Design: used in the design process * I
@isabelhou has joined the channel
- 👍2
2017-03-31
Facebook's 'Town Hall' is probably the best thing the social network has ever done
http://mashable.com/2017/03/27/facebook-town-hall-launch/#TIfk5X5a4iqn
http://mashable.com/2017/03/27/facebook-town-hall-launch/#TIfk5X5a4iqn
