【真的假的】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. 改 API 與 DB 增加欄位（type）
  2. 實做 mutation API
  3. 在 Article type 新增 relatedArticle field（用來在 detail page 列出 related article）
  4. 將使用者回報的 false positive 寫成自動化 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”.
  7. List articles API
  8. Redux archetecture & data fetching mechanism in rumors-site. Shows JSON in page.