owned this note   changed a year ago  
Linked with GitHub

【真的假的】設計決策

基本原則

從設計過程中摸索出來的 CoFacts 產品設計方向原則，確定我們產品發展的方向，沒有違背當初專案發起的核心精神，並同時幫助團隊在無法決定產品方案，幫助團隊選擇優先嘗試的方案。
例如，在沒有用戶資料背書、沒有類似產品參考、團隊討論有分歧時……，能作為一個剃刀幫助消除選項。

而又由於我們的產品有以下特性－－

  • 開放性：所有產品的開發設計過程公開，讓社群能檢視與參與討論。
  • 社群性：事實查證的過程中，有不同類型的用戶參與其中，不僅是單單的詢問者及解惑者，會有維護自己領域的專家、宣傳主觀意見……等等，不同目的性的用戶參與其中。
  • 有機性：用戶不會完全按照產品當初的設計來使用產品，而是會隨著使用，發展出新的使用方式。
  • 非營利性：產品設計不需要為了追求營利、追求流量為主要目標，而是用戶互動能從中達成公民價值。

因此，我們能透過核心原則的擴展方式，來漸進發展調整方向。

傳達媒體識讀的精神，讓大眾意識到對消息的懷疑與查證精神

根本解決謠言散播傳遞，必須從閱聽人的媒體識讀教育著手，提醒用戶時時保持對單向來源訊息真實性的懷疑，降低未經查證的謠言繼續被散布。

由於謠言很難從發送源頭禁止，而直接透過網路或是平台服務禁止，又有著限制言論自由的潛在風險。

所以我們蒐集整理發送進來的所有文字，並且邀請每個人一起協作驗證，去檢查每則資訊背後的可靠性。藉由對謠言的反駁與明示，提醒用戶永遠在輕信錯誤資訊前必須保持懷疑的態度，學習了解單一結論背後更多的可能，重視凡事查證的必要性。除了簡短文字的摘要，也附上能相佐證的新聞與資訊，培養一般大眾更廣泛的閱讀習慣，而非只能從親友間片面段落的訊息文字看世界。

又比如歷史事實與歷史解釋，同一件史實的發生，可能會因為解釋的方法不同而產出不同的文字段落。

我們希望能讓習慣接受親友訊息的朋友們慢慢了解到，轉傳訊息的這些內容當中，有許多部分其實並非真實的資訊，而是未經科學驗證的斷章取義，甚至可能只是撰文者自己的主觀想法或者解釋推論而已。

促進社群對於不同意見的對話，尤其是主觀意見沒有絕對答案的討論

社群上傳播的不僅是謠言，同時還有沒有客觀評斷標準的主觀意見，當社會有重大分歧（如：服貿、同婚、夏林清事件等等）時，大多數的言論都會出現在撰文者所舒適的平台（如自己的 FB、blog 等等），隨著討論熱度上升，連結「原文」與「回應」的需求也水漲船高。一個能在此時即時連結「原文」與「回應」的服務，可以降低參與門檻、促進公眾討論，應該有相當的價值。

另一方面，這類訊息之所以會引起廣泛討論，也是因為他沒有標準答案、任一方都不是已知的「事實」，而是持有相反立場的「主觀意見」。這是傳統 fact checking 系統所不會碰觸的領域，但作為「連結文章與回應」的服務，毋需刻意迴避碰觸主觀意見。

最大保留自由度（Be able to fallback）

設計過程中，如果不確定發展方向時，選擇保有設計未來可能性最大的方案，也就是選擇了這個方案，未來較容易還原方案或是轉換到其他方案。

社群實驗精神

我們相信透過大量群眾的討論、查證過程中，事實能漸漸被逼近，即便有部分的查核過程有問題、查核結果有誤，但終能用量平均誤差，讓最後結果能被接受，因此我們不設計一步封喉的查核步驟、而是透過大眾資料不斷累積的過程中，達到事實查核的過程。

文章回應的分類

使用者能用什麼標記來回應一篇文章。

使用最大保留自由度

  • 含有真實訊息
  • 含有虛假訊息
  • 非完整文章或訊息
    • 開發測試用無意義訊息
    • 詢問句
    • 片段節錄訊息
    • 文章長度過短

20170506 新增分類討論

由於在查證過程中，發現目前分類不敷使用，因此我們想要跟大家討論一下決定新增的分類內容：[Outdated, Unproven, Opinionated]

Outdated 過期文章

“Outdated” 為有時間區間的活動或是消息，在以往的分類體系（含真、含假）需要兩篇回應來個別描述內容真實 、時效錯誤。
範例：
物資捐贈、臉書投票活動、etc

Outdated 設計方案

Outdated

  1. 直接新增一個 Outdated 標籤
    文章過期狀況如上圖所示，有兩種狀況：回報時已經過期、預期未來會過期。而對於_未來會過期的文章_，Outdated 標籤無法有效地處理，試想一篇文章在有效期間會被大眾標記為正確文章，而等到過期時，文章已有許多「正確」標記，讓小編不會注意到這是一篇需要被更新登記為「過期」的文章，同時已經累積的「正確」標記數量，反而會成為更新成「過期」的壁壘。

  2. True But… 使用條件句下真實的標記
    為了避免上述問題，提出如果滿足條件就是真實的標籤，讓使用者看到條件，自己判斷現在狀況是否滿足條件。例如：在 2017/06/30 以前 、 募資金額未達 $100,000 等等。
    但問題在於條件句會十分多元複雜，難以正規化讓程式自動判斷是否有沒有滿足條件；而讓使用者判斷的問題是，考量到我們的 Linebot 用戶群體是有較為年長的對象，太過複雜的敘述會容易產生誤會或是忽略條件句只看到標記為真實的狀況。

  3. 讓 reply 本身會過期失效
    送出 reply 時讓小編選擇「回應有效期限」，在過期之後 reply 被視為沒回過。但 reply 會留在回應串中，等待新答案。因此過期的回應可以重新進入未回應列表，讓小編重新回應更新答案。

考量到讓

  • Linebot 用戶能輕易讀懂標記
  • 教育用戶哪一類文章會有過期的情況，讓用戶以後能小心面對有過期風險的文章

我認為 Outdated 的標籤類型有從 Has Rumor 獨立的需求，同時為了處理時效問題，引進 reply 過期功能。

Unproven 未證實文章

“Unproven” 為假說或是未成為共識的資訊，但無法說他是虛假訊息，因為他有部分案例已證為真，整體還在實驗驗證或是討論中。
範例：
尚未有嚴謹醫學證實的 CPR 方式
https://cofacts.g0v.tw/article/AVrGYUx3yrDaTqlmmqTr

Unproven 設計方案

由於案例過少，同時 Unproven 其實可以歸類為成「有部分證據但未取得共識的主觀意見」，所以併同 Opinionated 一起處理。

Opinionated 個人意見

“Opinionated” 是個人主觀意見，其實作為 factchecking 服務應該是直接略過，或是最多做意見中的引用查證。但是 Mrorz 的公民核心理想是意見交換討論，考慮能不能在查證的過程中促進意見不同的人群交流。

範例：

Opinionated 設計方案

  1. 淡化「opinionated」：可以放在「不處理」裡頭，但必須要改變「非完整文章或訊息」的 wording。
    但是現有「不處理」主要是內容形式上錯誤的問題，而不是內容本身的問題，合併在一起不太合適。

  2. 是用 opinionated 當做討論主觀意見的用途，增加「有人反駁的主觀訊息」，然後必須要把反對意見貼到出處。出處裡面是另一個主觀訊息也沒關係。
    既然已經是主觀意見，沒有辦法中立查證，與其放置不處理，不如增加一個對話的可能性，讓不同主觀意見在同一個地方產生對話。
    問題可能在於主觀意見很難找到第三方的反對意見，讓主觀回應都被留在沒有人回應的狀態。

考量到保留最大自由度 （若之後需要移除，還有機會直接用程式 mapping 處理，或是把 reference 移除）以及 促進社群對於不同意見的對話 兩點，使用第二點設計方案。

Reference

國內外平台分類範例彙整
20170306 團隊對於分類的討論
20170510/0517 新增分類的討論
2017/8/16 「個人意見」Medium 公告，含有此功能之用意的說帖

標準化查證時的「參考來源」格式

傳統上，文章與書籍的參考來源會統一為一致性的格式
標準化「參考來源」的格式

https://cofacts.g0v.tw/article/5691343520184-rumor

回應一次多答的設計

事實查核 VS 消息脈絡

許多消息是有變化的過程與脈絡的，比起直接呈現事實與否，讓群眾討論理解消息的脈絡與全貌比較合適
// rementioned by Whiski @2017/3/30 NCC 網路事實查核機制會議

防止惡意人士傳入亂碼文章（謠言）

展開回應選項

https://www.facebook.com/groups/cofacts/permalink/2055948657970286/

Cofacts Editor Organization 機制

Cofacts organization 類似 github organization 或 Facebook fan page，可以讓複數個 Cofacts 帳號用同一個「組織」名義回應。

目標是希望透過 attribution 與實際給編輯者 credit，讓事實查核組織更熱衷於在第一時間主動回應。

需求

Must-have

  • 組織頁面：List of (linked) replies under an organization
  • 顯名原則：網站與 chatbot 回應列表中直接顯名此回應由 XXXXX 提供；回應過後提供組織介紹與連結；覺得回應有用時的分享連結，也會顯名「誰誰誰標記為不實訊息」。
    • 與一般查核協作者有區隔，避免任意使用者自行冠名

Nice-to-have

  • self-served 申請建立組織：驗證網域 (google site verification API) 或驗證 Facebook fan page
  • 組織頁面設定：顯示名稱、顯示頭像、Description、組織裡有哪些人
  • 組織貢獻度：一樣也顯示「等級」
  • Cofacts 網頁與 LINE bot rich menu 上會有所有組織列表
  • 個人/組織身份切換：發文時，讓使用者自己選擇要用個人身份還是組織身份發文
  • 個人貢獻轉移至組織：在回應列表，讓使用者勾選把自己過去的 link 轉移到組織之下
  • URL preview 上特別標注：Cofacts 網站上驗證網域的超連結，都提供 popup 或小 badge3 連結到組織頁面
  • 送出文章時也送出到組織設定的 LINE@ (提供列表)
  • 流量追蹤：公開相關流量數據（google analytics 接 google data studio）
  • 偵測是否為 IFCN 一員 (or 提交 assessment 結果)，顯示 code of principles 以及提供 complaints form: https://ifcncodeofprinciples.poynter.org/complaints-policy
Select a repo