cofacts

Month: 2017-03

2017-03-01

mrorz 10:38:25
更新一下現況
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 晚上:寫投影片。

所以我想要把現在 articles 裡面儲存 `replyIds[]` 的做法 (has-and-belong-to-many) 更新成 articles 裡面儲存 `replyConnections[]` (一樣是 has-and-belong-to-many) 每個 connection 會是個 object `{replyId: "要連結的 reply ID”, userId: “哪個小編建立的連結", feedbacks: [{評價 good / bad, 使用者 ID}]}`

mrorz 10:40:53
舊版本有,但新版本還沒放進去所以會暫時失效的東西包含

1. 新聞小幫手 integration:原本 line bot 會去問新聞小幫手,但新版的還沒實作這個部分。
2. 查詢爬蟲結果:⋯⋯就還沒寫。
ggm 15:48:16
投影片是不是要分工一下
ggm 15:48:28
你是做招募小編嗎?然後我來做招募爬蟲手?
mrorz 21:29:23
3分鐘報告捏
mrorz 21:29:31
超趕
mrorz 21:29:42
你有想講的東西嗎
mrorz 21:29:53
我本來打算把專案現況講一講就好
mrorz 21:30:04
然後徵求的人會包含前端工程師
mrorz 21:30:36
我明天晚上應該沒辦法把 rumors-site 寫完
只能讓他會動
但小編們必須要具備閱讀 JSON 的能力才能進行協作之類的⋯⋯
mrorz 21:40:47
本來是想禮拜五才寫 slide 的說 ._.
mrorz 21:40:52
我先寫 code
yhsiang 21:45:06
從早寫到晚的 mrorz

2017-03-02

ggm 01:31:03
ggm 01:31:09
好啊
@null 01:48:48

Log event

2017-03-01 17:37:11.769 173 &lt;190&gt;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 &lt;158&gt;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 &lt;190&gt;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 &lt;134&gt;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 &lt;158&gt;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 &lt;134&gt;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 &lt;134&gt;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 &lt;190&gt;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 &lt;158&gt;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 &lt;158&gt;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

mrorz 02:19:40
現在 API、LINE bot 與 database 都是最新的資料了,可以在 http://rumors.hacktabl.org/ 看到最新的 rumor 資料~~


Airtable 的編輯權限已經全數收回,明天晚上來實做編輯界面。

known issue of new LINE bot:
mrorz 02:20:56
1. 訊息裡面如果有 emoji 的話好像會過不了 LINE signature check。我是看網路範例的,但大概網路範例沒有處理 emoji 吧⋯⋯ @@
mrorz 02:21:45
2. 對同一篇文章送兩次 reply request 好像會讓 bot 回「糟糕,bot 故障了。可以再傳一次嗎? QQ」。
上面 1, 2 修掉惹
mrorz 02:22:12
TODO:
a. LINE bot 的 message drain (把使用者 log 塞進 s3)
b. elasticsearch 的 backup
c. 確認透過 LINE bot 蓋出來的 article, reply request 的 `from` property 是 `RUMORS_LINE_BOT`
lucien 19:22:01
投影片需要幫忙嗎
mrorz 20:13:23
我應該明天晚上才會做 slide 唷
會從過去的 Slide 來改
mrorz 20:21:02
基本上介紹現在 line bot 的操作流程 ( 有很多步 ) 就會花到一半的時間
剩下來要講超快
mrorz 20:21:31
一張 slide 15 秒的話只能講 4~6 張
mrorz 20:22:02
所以不用為大松準備太多 slide
反正我也講不完,所以我 prefer 自己處理,講得比較順
mrorz 20:22:50
倒是 3/6 的 slide 你們可以想想要如何處理
你們應該會需要數字
要由我這裡開權限,例如說 line official account 的使用數字等等
lucien 20:25:22
好喔

2017-03-03

ggm 18:57:18
沒問題 我是還沒有想 grant 要報什麼 不過應該是還好 XD
ggm 19:22:38
所以 mrorz 你明天會去大松麻
mrorz 19:22:47
yep
mrorz 19:22:52
早上會上台
ggm 19:23:01
yep
ggm 19:23:37
晚點才會來弄 crawler 的東西
ggm 19:23:51
然後其實 grant
ggm 19:23:54
```每組將有 3 分鐘介紹自己的提案, 15 分鐘的 Q&A 時間,不需要做影片。
期待您的提案!```
ggm 19:23:58
也是要講超快 哈哈
ggm 19:24:48
不過應該是還好 XDD 我覺得要準備一些東西等著 Q&A
ggm 19:46:51
啊靠杯 我發現
ggm 19:47:07
這篇的權限是錯的 XDDD
ggm 19:47:12
大家都看不到
ggm 19:47:13
算了 哈哈
mrorz 21:10:15
3 分鐘根本就是
介紹現況
given $$,未來會怎樣
end

這樣 XDD
mrorz 21:42:43
晚一點再修
mrorz 21:42:47
現在先弄個大綱
mrorz 21:43:09
一張只能講 13 秒
mrorz 21:47:16
我在想需不需要法律諮詢
主要有下面這些問題:

1. 如果 article 來源是網路文章(輸入到系統,未來才能做「回應 segment」),那附網址全文轉貼是 ok 的嗎?可以主張合理使用嗎?
2. 承上,如果有文章被標記「禁止轉載」呢?
3. 如果有人轉傳了私密訊息到資料庫裡面,受害者要求刪除,我們的步驟是什麼呢?
4. 如果有利害關係人因為假訊息被踢爆而名譽受損,利害關係人要求刪除平台上闢謠文章,那我們要如何處理呢?(亦即求職天眼通日前的狀況的加強版)
ggm 22:04:50
好像需要耶 … 我可以幫問
ggm 22:49:50
```UberEATS 3月6日南港正式開動!
誰說南港是美食沙漠!?

您的美食外送首選 - UberEATS ,進駐南港!
南港的朋友有福啦!3/6-3/10 整週免服務費!
多間精選餐廳,豐富美食任君挑選!

UberEATS 將於 ( 3月6日 ) 在南港正式開動!
37分鐘內,美食火速送達!```
ggm 22:49:58
所以明天可以叫了 XD?

2017-03-04

mrorz 04:43:25
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
mrorz 09:01:29
https://g0v-tw.slack.com/archives/general/p1488589212003782

Hello 我是第一個報告者 抱歉今天早上會遲到好一陣子 (現在才在頂溪捷運站 orz) 請先到的坑主先報告 QAQ

😉 1
mrorz 09:02:24
@ggm crawler 想要徵什麼樣的人呢?
@lucien 我們有需要其他 UX designer 嗎
lucien 09:04:45
應該不用吧,如果我有正常生產力的話,FE人力應該也不會差太多
lucien 10:56:17
你們在哪邊啊
ifengc 11:32:03
@ifengc has joined the channel
quad 12:38:59
@quad has joined the channel
quad 13:10:11
@lucien 這邊
quad 13:10:14
😄
ggm 13:22:54
呃啊抱歉我今天不會過去 … 我現在在上吐下瀉中 orz
😱 3
lucien 13:25:33
保重啊
ggm 13:25:33
我晚上或明天跟大家 sync 一下狀況 我先來去看醫生 orz
💊 4
lucien 14:58:17
Where is the credential of rumor-api @mrorz ?
linekin 15:02:21
我發了 2 個 pull request, 再麻煩有空時 reivew 看看
quad 15:50:39
我也發了兩個PR:
mrorz 16:52:04
感謝 linekin 與 quad :D
剛才回覆囉
quad 21:26:10
@mrorz 剛才回覆你回答
mrorz 21:29:43
Merged! Thank you
mrorz 21:42:22
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!
👍 1
foucault 23:34:31
@foucault has joined the channel

2017-03-05

bil 11:56:47
ggm身體有好點嗎@@
ggm 15:05:49
有歐謝謝QQ
mrorz 20:16:47
Take care QQ
mrorz 20:18:19
今天行程比較少,如果回飯店後有網路的話我應該會做 rumors-site 的外觀
把 JSON 弄掉這樣
mrorz 20:21:15
@quad 請問 rumors-site 還有沒有 ummerged changes 呢?

2017-03-06

ggm 21:12:18
@ggm uploaded a file: Slack for Android Upload
ggm 21:12:39
嗨各位我們有糧草囉!
lucien 22:17:50
@lucien uploaded a file: Image uploaded from iOS
lucien 22:42:49
@lucien uploaded a file: 有點亂的 after grant 討論
@null 22:58:51
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 比鄰的那個分類方式我從來沒有想過,是個新的靈感

我原本的分法確實是「如果未經證實,就不能說他是假的」
比鄰的分法有不同預設,是「如果未經證實,就不該說是真的」

如果我們的目標是要讓使用者不要輕易地相信東西,那後者預設為假會是一種更富科學精神的做法
@null 23:01:14
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 如果我們的系統是想要讓不同立場的人能標記錯誤之處然後狠狠打臉,那我的分法可以確保他打臉可以打得又狠又腫

但當然,要能狠狠打臉並不容易,所以就變成會有很多 non-rumor。
@null 23:03:20
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 然後我在想,這兩者混合的話會有什麼副作用嗎?

像是有三種分類

1. 已被證實
2. 未經證實
3. 已被證實不是真的
@null 23:04:58
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 對小編來說這樣分會不會有很大負擔?
「未經證實」跟「小編看過了但找不到」跟「還沒有小編看過」的差別又在哪?
@null 23:11:29
@ooookai commented on @lucien’s file 有點亂的 after grant 討論: 也許 *已被證實* 下可分成 真的 or 假的 ?
@null 23:13:50
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: Hmm我想我知道分成三種會有什麼問題了
@null 23:15:31
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 原本比鄰的分法 (真的 vs 沒人說他是真的)
還有我的分法 (假的 vs 沒人說是假的)
的預設值(沒人說是 xxx) 其實有著強烈的預設立場
@null 23:15:53
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 比鄰的分法告訴使用者不要隨便相信網路文章
@null 23:16:22
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 我的分法鼓勵精確打臉,不亂燒稻草人
@null 23:17:08
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 但兩個方法混在一起
那就什麼效果都達不到
@null 23:17:36
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 大家只會看那些被標記為真或假的消息
@null 23:19:28
@mrorz commented on @lucien’s file 有點亂的 after grant 討論: 那些沒被標記的,大家既不會預設他錯而進行批判性思考,也不會覺得我要努力證明他是錯的(不然別人會信以為真),就是個無感
@null 23:48:40
@ooookai commented on @lucien’s file 有點亂的 after grant 討論: 意思是這樣分嗎?🤔
1. 已證實已標記 (真or假)
2. 未被證實 或 不明確(含半真半假)

2017-03-07

lucien 00:53:21
我記得之前有針對 Reply 的 taxonomy 有做過討論,我覺得這邊要把分類名訂得清楚並文件化起來
lucien 00:53:45
像是還有 not used 其實意思是根本不是來問謠言的
lucien 00:55:31
看起來總共有四種:
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假
lucien 00:56:08
現在討論的是需要把 `未辯真假` 跟其他人 merge 嗎?
lucien 00:58:12
Ex. `已証為假` + `未辯真假` = `沒人說是真的`
lucien 00:58:39
我直覺的想法是乾脆就讓 `未辯真假` 的東西不要有回應
lucien 00:59:02
反正沒人有答案,編輯的回答幫助很有限
bil 01:29:23
如果
使用者看到的回應是
1.有不實資訊
2.找不到不實資訊(會有隱含訊息可信的暗示嗎?像是在幫訊息背書一樣@@")
3.資訊正確
4.資料庫找不到任何相關訊息/未辨真偽
5.有相關的文章,提供參考(搜尋引擎模式?)

哪一種是你們想看到的@@
lucien 01:38:54
2 跟4哪裡不一樣?
bil 01:39:02
我的想法是,會使用這個功能是因為我覺得我得到的資訊未辨真假,所以才要問問機器人。
如果他也告訴我資訊未辨真假他不知道,我會有點無助QQ
lucien 01:39:25
應該說沒有資訊可證真假時
lucien 01:40:19
那資料庫有沒有相關資料給使用者的價值是什麼呢?
lucien 01:40:42
1. 有資料但說我不知道真假
lucien 01:40:48
2. 沒資料
bil 01:40:48
當我說:A的話不是錯的
通常代表A說的是對的

當我說:我沒聽過/我不知道B的話對不對
我真的不知道,有問題你去問B
lucien 01:41:27
喔喔 不是三分法而是預設二分法
lucien 01:42:53
我覺得可以描述清楚一點就可以規避 不是錯的 = 可能對 加 不知道真假
bil 01:44:02
我的想像是資訊會隨著時間累積,所以偏好1
會提供資訊連結,但表示說
「有人有不同的看法」「訊息尚未獲得足夠的資料或支持」
lucien 01:45:11
也就是鼓勵大家多回應,即使還沒有完整資訊的情況下,但希望可以透過資訊慢慢更新來得到答案
bil 01:45:28
是的
bil 01:46:07
我的概念是,既然是謠言就表示有人覺得「可能對」
lucien 01:46:26
所以你期待的分類是什麼呢?
bil 01:50:15
就是4種嗎?
lucien 01:51:03
不一定
lucien 01:51:31
只要你的分類可以涵蓋所有情況就好,可以 merge
bil 01:52:58
1.聊天測試
2.已證為真
3.不足採信
lucien 01:54:04
也就是 merge `已証為假` 跟 `未辯真假`
bil 01:54:21
是的,當然這只是我的偏好
bil 01:54:58
原因是我覺得我在這個過程是需要選擇其中一個價值的@@
lucien 01:55:06
嗯嗯那我們現在有三種,可以再討論三種的好壞以及預設立場,看看怎麼樣比較適合
bil 01:56:46
謝謝lucien~
bil 01:57:04
今天辛苦了
lucien 01:58:12
`不足採信` 這類有涵蓋 `未辯真假` 有個問題是會找不到參考資料
lucien 01:59:48
因為 `未辯真假` 這類狀況,也就代表沒有文章有答案。
lucien 02:00:51
沒有一個明確立場的文章,通常就不會寫出來,因為目前網路文化偏好有強硬立場,給人簡單好懂的答案,而不是還沒有答案的保守立場。
lucien 02:01:19
不知道小編們實際經驗如何呢?
bil 02:03:48
是的,所以我才會認為
a.訊息可靠,不是謠言
b.不足採信(請當成網路謠傳)


A.是謠言
B.找不到不實資訊(請當成真有其事)

兩個價值要選一個來當作編輯的原則
lucien 02:09:23
hmm… 我的問題是小編選了 b ,但是最後沒有 reference ,也沒有辦法解釋說是因為你沒查證完還是你真的找不到資料,這樣會讓 `不足採信` 給人感覺的效力變低
lucien 02:10:17
當選了 b 之後,那理由跟引用要寫成什麼樣子呢?
bil 02:10:30
也就是說,可信的效力很低呀@@
lucien 02:11:11
那你跟使用者說不足採信的理由跟引用會是什麼呢?
lucien 02:11:46
會不會變成都會是 「找不到相關資料」 、「引用為空」?
lucien 02:12:31
這裡應該是讓我最擔心的地方
kooioao 02:15:37
如果無法被證實是真的,是不是也代表很難找到引用資料去證實是假的?
bil 02:16:41
回應:沒有足以證實這則消息可靠的文章資訊,請謹慎看待網路謠言,不要輕信。
理由:找不到/找了提供關鍵字有的文章
引用:空的/
lucien 02:17:31
是的,所以我的提案是 `未辯真假` 直接移除,當做還沒有答案,但代價是會有很多謠言沒有答案,把回應門檻拉高了。
lucien: 移除 `未辨真假` 後,代替它的會是?
沒有
就是還沒有答案就不應該回應
bot 感覺ㄧ定要給使用者一些回應吧?
Bot的回應是還沒有人回應或是有答案
沒有人回應 = `未被證實` = `不足採信` ?
我的版本不是
就是未辨真假
未被證實 = 已證為假 + 未辨真假
這樣分同樣會有 `沒有內容的回應` 的結果不是嗎?
(未辯真假的部分)
我覺得你誤會了什麼
我的分類為:
- 只是閒聊
- 已証為真
- 已証為假
- 未辯真假(沒有資料能證明謠言為真或為假)

我的提案為:
只使用以下三個分類
- 只是閒聊
- 已証為真
- 已証為假

當有未辯真假的情況,編輯不應該回應,所以最終在 bot 會因為沒有資料變為 `此謠言還沒有人回答`
所有 `未辯真假` 的情況代表編輯沒有能力找到答案,編輯能給的答案效力很低,那不如不回答。
瞭解~
我應該是誤會了 `回應` 是在討論 編輯給的回應,而不是 bot 給 user 的回應。
bil 02:18:51
是呢@@
lucien 02:19:17
我覺得 @bil 的方案可以讓討論變得比較容易,但會很容易產生大量一樣的 `不足採信` 回應,一直看到一樣沒有內容的回應,我覺得會下降大家對 bot 的信用
lucien 02:20:27
其中也有一種可能是編輯者還沒有認真查證,就選了 `不足採信` ,結果讓後續編輯,就認為他已經被回答,就沒有更深入查證了。但其實說不定有答案。
bil 02:22:17
咦,可是我以為目前的做法是有反駁的文章比較多@@所以不足採信比較好用,提供了不實的部分與連結
lucien 02:22:37
喔喔
lucien 02:23:13
如果能證實,多數不足採信的文章其實都是 `已証為假` 那我覺得可以阿
mrorz 12:08:50
我在想,如果除了 `已證為真` 以及 `已證為假` 之外的那些還沒有處理的、或是沒人找得到的文章,在給使用者的敘述上採取懷疑的角度,是否就能達到比鄰版 `不足採信` 「預設為假」的效果呢?

給使用者的回應例子:

```
目前沒有人證實此訊息的真實性,請保持懷疑態度對待其內容。
```
bil 14:45:52
是的

以及,進來的文章其實沒有分過
fact & opinion
比如像是心情小語人生建議或是相信神等等,比起謠言或是事實真假,更像是作家個人意見抒發或是信仰之類的。我覺得有需要做一個區別,這些事情跟non rumor可能還是有點不一樣@@

2017-03-08

Daniel 09:03:44
@danielhsu has joined the channel
mrorz 15:27:39
心情小語、早安問好(今天有好多婦女節訊息)、反諷
都是不處理的東西呢
如果有人對他下這樣的標記,其他小編進可以考慮跳過他們
這類能跟聊天測試合併成新的一類嗎?
我覺得可以,就是類似 don't care 這種種類
可是我覺得don't care 名字不好,但還想不到好名字
gossip ? 😂
我覺得好像也不錯
kooioao 18:35:43
發現有一些進來的訊息有時間性敘述
例如:「十年來最強烈冷氣團第二波報到,週五以後特別寒冷」「今年.....」
這種訊息在特定時間過了之後,它的真實性就失效了,或是之後其實在不同的時間,卻都被判斷相似的文章,感覺好像會有一些問題 (?
lucien 19:01:43
True
mrorz 19:18:41
@mrorz uploaded a file: 有人在試 production server 嗎 @@

2017-03-09

wjwang 01:18:21
@wjwang has joined the channel

2017-03-10

ggm 21:10:50
嗨 3/18 有個 g0v grant kick-off 的活動 有誰要一起的嗎?必帶: ggm, @mrorz @lucien
ggm 21:11:39
還有他有問我們有沒有希望邀請的人(或組織)他們可以幫忙橋