【真的假的】2017/1/26 新年前 Meeting Note
====

Participants
---

GGM, Lucien, Johnson, Billion
討論哪些是 MVP、哪些不是，還有頁面怎麼設計。

---

Website MVP
---

目標：替代 airtable。Provides similar rumor / answer recommendation to make editors' life easier.

### Landing page = List page

希望可以幫助小編找到要闢謠的資料，也要有簡單的搜尋。

* 三個 tab 分別列出「尚未處理的訊息」、「標成『沒有不實資訊』的訊息」、「有不實資訊的訊息」。
* 點進不實訊息 detail page
* 懶得做專案介紹，先有功能再說

Optional: Search for rumor / answer / crawled doc （可以切換，讓小編們可以查詢）

### Rumor detail page = Answer listing + authoring page

顯示 rumor 與現有 answer，以及提供送出新的 answer。

#### 顯示

* Desktop first 兩欄式設計
* 左欄：上面放 rumor，中間放 answer input，下面列出 answers
> 排序方面，希望新的 answer 會排在舊的 answer 之上。因為使用者在寫新 answer 時，會看到舊有的 answer，一般來說新的 answer 應該會改進舊的。引入像知識加或 Stackoverflow 的 upvote / downvote 機制需要小心，需要一些規則或限制來避免平台使用者用 downvote 排擠少數使用者之狀況（想像成八卦版的推/噓）。另，如果真有編輯戰的行為，就等遇到之後再來處理（比照維基百科：先鎖定，然後管理者彙整）。
* 右欄：列出 related rumors 的 answers。

#### 編輯

* 無須登入
* 必填：有沒有不實消息（airtable 的 "type"）、查證內容、佐證資料。
* 用「比重新寫謠言還簡單」的操作，鼓勵小編直接從右邊側欄挑一個現有 answer 來與 rumor 來做連結。
* 在登入系統寫好前，送出 answer 後不能透過 UI 來修改。
* 希望「建立新資料」是免登入的，鼓勵大家產製內容；
* 但希望「編輯現有資料」要掛名登入，用以提升破壞的難度。

---

Future work: Segments
---

要解決的問題：

1. 有些流言是複合性的，揉合了現有的其他謠言而成。
> 例： http://rumors.hacktabl.org/article/5362270457238-rumor 前半講雞腳的問題，後半講雞蛋的問題，兩者可能要分開闢謠。

2. 有些流言大多部分與其他相同，但多出一兩句需要另外闢謠。
> 例：
> 第一篇： http://rumors.hacktabl.org/article/5514464734557-rumor
> 第二篇： http://rumors.hacktabl.org/article/5478127110102-rumor
> 兩篇有若干相同之處，但第一篇多提了一個不實消息『目前最有效的「雞尾酒療法」，只能延長發病死亡時間。』，需要比第二篇多一段。

因此，我們需要比 rumor 更細的 entity ——「segment」（文章段落）

Rumor ---[has & belongs to many]--- Segments ---[has & belongs to many]--- Answers

### Creating segments

* 對 answer 文字加入字數限制（比照 twitter）。
* 建立 Segment：小編框選段落，就能對這個部分寫 answer，字數限制另計。（鼓勵針對小區塊做回應）
* Reference 只能填一個連結。Optionally 讓使用者填一個 label，因為有些 reference 可能很長又沒有段落 permalink，要用文字描述相關段落在哪裡。

### How segments are shown

* 在 LINE bot 上，顯示「這則訊息有 3 個段落被標示有不實訊息，2 個段落被證實沒有不實訊息」，然後給使用者 rumor detail page 的連結。
* 在 Rumor detail page 顯示時，Rumor 處標出各個 segment，讀者點一下就會自動捲到下面相對應的 answer 處（像是讀 footnote 那樣）。此時 answer 依照文章位置或許較貼近 footnote 的閱讀體驗。
* 若一則 rumors 有很多 segment 而且彼此重疊，可能會造成閱讀上的困難。此時：
* 提供「自動選擇」與「全部」segment 的切換。
* 「自動選擇」會選擇一組 segments 使得彼此重複最少，而 segment 數量盡可能地多（鼓勵 segment 越細越好），並且只選擇這組 segments。
* 當使用者瀏覽沒人處理過的 rumor 時，若資料庫有長得完全一樣的 segment，那就應該要在 rumor 上面標示此 segment 以及與此 segment 連結的 answer，讓小編輕鬆地將 Rumor 與資料庫內現有 segment 做連結。
* 首先拿 rumor 全文搜尋 similar rumors，including their segments。
* 對於每個找到的 segment 都拿到 rumor 上比比看，如果有 match 就顯示。
* 使用 sliding window + 可以滾動計算的 hash，來判斷特定 segment `S = <S1 S2 S3 ... Sn>` 是否在 rumor `R = <R1 R2 R3 ... Rm>` 中存在：
1. 對 `S` 做 hash。hash 值計算為 `(S1*x^0 + S2*x^1 + ... + Sn*x^n) mod M`， `x` 與 `M` 為大質數。
2. `for all a from 1 to m-n`，計算 `hash(<Ra Ra+1 ... Ra+n-1>)`，如果與 S 的 hash 一樣的話，才做字串比對。不一樣的話，`hash(<Ra Ra+1 ... Ra+n-1>)/x + Ra+n * x^n` 就會得到 `hash(<Ra+1 Ra+2 ... Ra+n>)` 的 hash。以上比對 S 與 R 之複雜度為 `O(m-n)`。

### Migrating from current status to support segments

目前資料庫 entry 結構是

Rumor ---[has & belongs to many]--- Answers

加上 segment 就是對於每個 answer 與 rumor 的連線，都開一個 segment 來擺放，而 segment 內容等於整個 rumor。

若這些 rumor 有新的 segment，也會顯示這些新的 segment（因為重複較少）

---

Actionable Items
------

* Lucien: 產出wireframe
* GGM: 寫 grant proposal
* MrOrz:
1. [x] 改 API 與 DB 增加欄位（type）
2. [x] 實做 mutation API
3. [x] 在 Article type 新增 `relatedArticle` field（用來在 detail page 列出 related article）
4. [x] 將[使用者回報的 false positive](https://airtable.com/shr23o1yosGdfd3Xy) 寫成自動化 validation script 用來判斷 search 演算法的 false positive rate
5. [ ] DB migration from airtable to elastic search (w/ non-rumors!)
6. [ ] New LINE bot flow that allows users to choose from several possible rumor candidates. skip "best match".
6. [x] List articles API
7. [x] Redux archetecture & data fetching mechanism in rumors-site. Shows JSON in page.