20170318 g0v grant kick-off
===

## 會前討論

### 1. 看看 318 有哪些專家會被請到場進行交流，要問他們什麼問題
* Wikipedia，怎麼處理編輯權限的問題，維基小聚怎辦
### 2. 看看當初提案報告裡列出的 KPI，列出 TODO，拉時程
* 使用者達 10000 人
* 現在 LINE bot 有效好友數是 16098，可以把「使用者」定義為有真的使用過的，有詢問過文章。
* 資料庫裡的有效謠言文本達 5000 筆
* 現在文章數有 4160，回應數是 214，可以把有效謠言文本定義為，具回應，且有辦法查證真偽。
* 真的假的社團人數達 2000 人
* 現在有人數為 1576
* 參與協作人數達 100 人
* \> 27 人
* 日活躍使用者達 100 人
* \> 20 人（從回應數計算）
### 3. 專案管理（不只是程式協作，還有現下小聚等等其他東西籌備的專案管理）方式
Trello？現在的 github issue + github project？要開放還是僅限工作人員使用？後者的話會不會很難跟工作人員之外的人 sync？
* 工程技術相關的專案
* github -> org -> project : milestone, issue
* 小編 + 小聚相關
* 如何管理未回答文章？
* 用什麼工具：增加系統功能
* 讓小編自己選文章，回答購物車，標記為：我想回答
* （登入後）多加兩個 filter 「我想回答」、「我回答過」
* 已開 [issue](https://github.com/MrOrz/rumors-api/issues/34)。
* 需要 SOP （認領文章機制，對外求救機制）
* 本月懸案（可納入使用者提報數量，並據此排名）
### 4. 討論區定位（FB group, github issue, slack )
* FB group：

版面以這些貼文為主：

1. 使用問題回報：請附上操作的步驟，還有遇到什麼樣的問題。
2. 不知道如何回應文章，尋求討論：必須附上 (a) 已經投稿至 rumors 網站的連結、(b) 自己找了哪些來源。另外，如果能附上自己對答案的草擬或想法，就更好了
3. 討論版規：反應關閉留言機制等等。
4. 討論現有功能或建議新功能。
5. 公告更新消息。

程式實作方面的討論，還有新知分享與閒話家常，請移駕 g0v slack 的 #rumors channel。

其餘將會視情況關閉留言，將版片留給協作相關的討論。

* Slack：想說什麼就說什麼
* Github issue：討論過比較明確要做的事情，或是問題

### X. 其他聊到的東西

#### 使 LINE bot 能被加入群組

Lucien 提到有人說可以將 LINE bot 放進群組，並且指出某 LINE bot 作為例子。之前 [FB 討論串](https://www.facebook.com/groups/1847232902175197/permalink/1894846064080547/)也有人提出一樣的建議。

##### 放進群組的挑戰

a. 群組的發文比接收轉傳訊息頻繁非常多，[先前](https://www.facebook.com/groups/1847232902175197/permalink/1895101707388316/)就有人把 LINE bot 加入群組結果癱瘓 LINE bot、LINE bot 的回應又洗版了的例子。

b. LINE bot 可以接收群組內所有訊息，有隱私疑慮。若有人針對此點大做文章（例如「請大家注意，真的假的 LINE bot 其實可以看到所有人的訊息，是唐鳳大數據監控的陰謀！」），會使人失去使用此服務的信心。LINE 之前就大肆流傳過[針對內建功能的謠言](https://briian.com/28478/)，LINE 的使用者是會相信這種謠言的。

##### 針對上述挑戰的解方

當 LINE bot 偵測到來自群組的訊息時，行為與收到轉傳訊息要不一樣。（Line bot server 可以判斷得出來）

a. 針對系統的 bottleneck 做 cache。如果瓶頸在 API server，那 LINE bot 就預先載入 1000 則熱門流言，在加入群組時只會針對這類流言做回應，完全不做 query。

b. 針對隱私，可以在 LINE bot 進入群組時先揭露自己會看到所有訊息這件事情，並且提供群組內所有成員讓 LINE bot 離開的方式（例如說「若您想要『真的假的』離開群組，請輸入『滾開』」之類的）。

## 和與會者討論的筆記

### 維基
* 細部分工：知識領域、語氣、語順
* 每週的聚會，爐主，offline
* 維基：勳章、感謝
* 結案機制（wiki 特色條目）
* 維基的編輯會看其他編輯之前編了什麼

### 新聞所阿孝老師

#### 老師分享的「真的」「假的」二分法無法處理的流言範例

* 游錫堃曾在某場選舉被對手說，如果游錫堃拿得出國中畢業證書與聯考成績單，自己就退選。對手沒有說任何不實的話，但其 intent 為質疑游錫堃的大學學歷。
* 珍妮特·庫克融合數個受訪者的故事，寫成《Jimmy's World》報導，獲得普立茲獎，後來被踢爆 Jimmy 並不存在。Jimmy 雖然是假的，但報導的故事確實發生過，只是不是發生在「一個Jimmy」身上。意味著這樣的社會問題確實發生，可是多人故事融合後，整個文本也並非為真。

#### 問題癥結

* 有時候文章要標成「真」與「假」其實很掙扎。
* 有時候文章一部分是真的，一部分又是假的。

當時與老師談話時，MrOrz 給的回應是，由於我們允許複數個回應，又會將認為是真的的流言，還有認為是假的的流言分別顯示，鼓勵不同的答案，希望可以用允許 diversity 來解決真假 ambiguity。

不過，比鄰指出，如果使用者仰賴 LINE bot 來判斷一個文章是真是假，同時給他們「真的」以及「假的」的答案以及理由，或許不是使用者想要的。（這也是一般使用者的習慣，他們傾向獲得直接的解答，而非『需要再次查證』服務，這樣的使用心理也是要考慮的部分）

談到國外 facebook / google沒有 collaborative fact checking 而是偏好第三方機構來替結果認證背書時，妤庭也認為說不定國外也有想過這種允許多個答案並陳的 collaborative fact checking，但後來選擇不這麼做，原因是因為當碰上兩造意見不相上下時，就會需要另外一個專業、客觀的第三方來做事實上的認定。

維基社群的上官有說，他們之前碰到維基條目跟其他文本有出入的爭議時，會採用專業者盲閱的方式做檢驗。舉例來說，維基百科與牛津詞典中的解釋有出入，他們會把來源拿掉，只給文字，送給多位學者、研究者審視，由他們來指出錯誤或要修正之處。
（上官:抱歉看這邊的討論紀錄，我才發覺我當時誤解Hazel的問題，當時我以為他在問維基百科上的內容可不可靠，我以為他在講是否有學術研究在討論維基百科內容值得信賴的程度，所以跟Hazel講了2005年在Nature上登出的一篇[維基百科可信度的學術研究](https://zh.wikipedia.org/wiki/Wikipedia:%E7%B6%AD%E5%9F%BA%E7%B0%A1%E8%A8%8A/2014/2%E6%9C%88/%E5%96%AE%E9%A0%81%E7%89%88%E6%9C%AC#.E9.97.9C.E6.96.BC.E7.B6.AD.E5.9F.BA.E7.99.BE.E7.A7.91.E5.8F.AF.E4.BF.A1.E5.BA.A6.E7.9A.84.E5.AD.B8.E8.A1.93.E6.80.A7.E7.A0.94.E7.A9.B6)，但平常維基百科並不會用這麼高成本的方式來面對所有的內容建置。平常的話就是盡量找到夠大量的志工，並且針對不同領域的志工提出適合他們參與貢獻的方式辦活動。台灣的維基分會這幾年舉辦活動的資料可以參考我們網站中的[台灣知識種子計劃](https://meta.wikimedia.org/wiki/Wikimedia_Taiwan/Projects)裏頭的介紹。）

或許我們先保持現在這樣的呈現方式，之後再來問問使用者這是不是他們所要的。

#### 文章分工、小編分類

老師舉之前莫拉克風災時，救災平台從各自為政導致物資重複收取的狀態，變成由胖卡計畫製作的災情中心網站整合。

由於要整理不同來源的資訊，因此他們有針對編輯進行一套包括資訊挑選、文字撰寫重點的講習訓練，提供獨立作業的SOP和格式。而這群編輯往後就都在台南、高雄、屏東等地方獨立作業。

編輯手冊是必要的，而有訓練的編輯講習也是維持訊息一定水平的溝通管道。

Hazel: 編輯也會需要專業分工，真的假的作為平台，需要跟不同領域的編輯建立關係，協助他們建立回覆的守備範圍，並熟悉各自的查證通路。

#### 「真的／假的」的三種分類方式（Reply type）

之前[請小編對 reply 分類的討論](https://hackmd.io/s/rk1KHEgsg)有這三種分法：

* 不預設立場 by Lucien
* 已證為真
* 已證為假
* 未辯真假（不回應）
* 個人意見（閒聊、來亂、觀點不同）
* 預設正面立場（要打臉請拿事實）by MrOrz，目前系統實作
* 含有不實
* 查無不實
* 個人意見（閒聊、來亂、觀點不同）
* 預設負面立場（別輕易相信謠言）by 比鄰
* 已證為真
* 不足採信
* 個人意見（閒聊、來亂、觀點不同）

就這三種分法，請教老師何種比較合適。

阿孝老師針對「不預設立場」分類中的「已證為真」、「已證為假」提出那種部分真、部分假的訊息在這樣的分類下難以分類，且證實為真為假，其實需要嚴謹的討論過程，如果是單一回答中就提出真假問題，這樣的資訊可能會造成另外一種誤解。

他認為以我們目前的查證流程，「查無不實」和「含有不實」或許是比較貼近Line的生態和整個產品的服務初衷。

## 會後討論

### Reply type 定案

針對[前述二分法的癥結](https://hackmd.io/BwNgpgjAxgRgTFAtFEBWCiAsBDADGRbKATgzAHYwBmYgE3Igt0yA?view#問題癥結)，晚餐時提出的分類方式如下，改編自「不預設立場」的分法：

* 採用「含有不實資訊」「含有真實資訊」「個人意見」3 種，如果沒填寫就是未辨真假
* 如果一則訊息有部分「不實資訊」又有部分「真實資訊」，那小編就要一個人 reply 兩次，一次填真實的是哪些部分、列出 reference，另一次填不實的是哪一些部分、也列出 refernce。
* 對於尚未有人回應的文章，系統回覆之訊息可以傳達我們希望大家如何看待這些文章，例如「目前沒有人證實此訊息的真實性，請保持懷疑態度對待其內容。」這樣就有「預設文章為假」、「希望大家不要輕信訊息」的精神在。

Pros:
1. 之後如果決定了這個平台要預設「請懷疑真實性」與「在沒人拿證據打臉錢請當成真的」的話，這種分法比較好把「未辨真假」合併到其他選項。
2. 將部分真實、部分不實分開，之後要切換到 [segment](http://beta.hackfoldr.org/rumors/https%253A%252F%252Fhackmd.io%252Fs%252FrJQaJ9wwl) 或許也比較容易。
3. 只要有回應，就一定是有查到資料的部分，也一定有資料來源。
4. 用「含有⋯⋯」以及分次回應來解決「部分真、部分假」的文章，不用硬在「整篇都已證為真」、「整篇都已證為假」之中掙扎。

Cons:

一則 article 可能會有很多回應，眼花撩亂。
如果使用者新聞都只看標題、LINE 訊息也不點連結，那這對使用者是否有幫助，仍然需要評估。（雖然會來跟 LINE bot 做好朋友的 TA 應該不太介意啦）

### 小聚形式

線下小聚形式 by 比鄰：不要超過 2.5 小時，固定一或兩周一次，開在週間晚上、不佔用週末大家寶貴的時間。

GGM: 編輯者的小聚可以每週 1 小時線上

Hazel: 建議可以去4/20維基社群的[新手編輯訓練](http://wikiwomen.kktix.cc) 看看他們的訓練重點。目前已經聯繫上舉辦維基小聚的朋友，有任何編輯上的問題，都可以先跟他們討論。（上官：上面給Hazel的編輯聚會主要是針對女性參與者，如果是非女性的話建議參加每月第二個週六下午13:30-16:00在西門卡市達舉辦的[新手寫作聚](https://zh.wikipedia.org/wiki/Wikipedia:%E8%81%9A%E4%BC%9A/%E5%8F%B0%E7%81%A3%E7%B6%AD%E5%9F%BA%E4%BA%BA%E8%87%BA%E5%8C%97%E5%AE%9A%E6%9C%9F%E8%81%9A%E6%9C%83/%E5%81%87%E6%97%A5%E5%AF%AB%E4%BD%9C%E6%9C%88%E8%81%9A)。）

### Label 功能

https://github.com/MrOrz/rumors-api/issues/32