【真的假的】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.