第三次除黴會議(已結束)
編輯歷史
| 時間 | 作者 | 版本 |
|---|---|---|
| 2017-07-07 17:45 – 17:45 | r0 – r1 | |
顯示 diff+ 第三次除黴會議(已結束)
+ 此文件路徑：全民除黴計畫hackfoldr / 會議紀錄 / 這裡
+
+ *會議資訊
+ 會議名稱：第三次除黴會議
+ 在「第零次新聞松」 http://hackfoldr.org/NEWShackathon/
+ 時間：2014-08-02（六）10:00AM~18:00PM
+ 地點：摩茲工寮（MozTW社群）
+ （地址）台北市德惠街23號B1（捷運中山國小站）
+ （地圖）http://goo.gl/maps/IDMws
+ （MozTW工寮網站）http://moztw.org/space/
+ （MozTW工寮ＦＢ）https://www.facebook.com/MozSpaceTPE
+
+ /* 不用填了，集中到別處
+ 報名參加：Rhozan、MRBIGMOUTH,Wilber
+ 無法參加：皮皮(萌典松)、
+ */
+
+ 與會者：
+
+
+ *＜一＞議程 (各組有需要請自填)
+ *1.1 .常用工具及協作平台
+
+ *1.2. 新舊成員介紹
+ YiChi、詹詹?、
+
+
+ *1.3. 舊進度追蹤&檢討 參照：第二次除黴會議紀錄、2014.07月進度報告
+ *app命名與團隊未來發展、域名問題確認 (參考附件)
+ *
+
+ *承上、並連同1.3.1問卷初步結果一起，討論核心策略
+ *網域方面，建議是一個作品一個子網域domain，不要用request uri去分
+ *Example：appname.app4am.org
+
+ 1.4.APP命名提議
+ 1.4.1.第一輪表決（一人三票）：
+ *01--除媒APP（新聞欸批批）
+ 投票：wei yu chen、Wilber、Summit、YiChi、zanzan、Michael ＝ 六票＊
+ *02--新聞評分誌
+ 投票：Michael ＝ 一票
+ *03--新聞看守所
+ 投票：
+ *04--新聞急診室
+ * 投票：mrbigmouth、MG、Wilber、Carol、zanzan ＝ 五票＊
+ *05--貂民新聞/日報 - 媒體亂報，貂民回報 (參考)
+ 投票：Rhozan ＝一票
+ *06--硬新聞 in news
+ 投票：mrbigmouth、MG、s5y、Summit、Rhozan ＝五票＊
+ *07--救新聞 old news all news
+ * 投票：Joy、YiChi ＝二票
+ *08--就是新聞 Just News
+ * 投票：wei yu chen ＝一票
+ *09--新聞肝指數
+ * 投票：Jennifer、Carol ＝二票
+ *10--新聞啄木鳥
+ * 投票：wei yu chen、MG、Joy、Jennifer、Summit ＝五票＊
+ *11--新聞戰(讚)
+ * 投票：s5y、mrbigmouth、Joy ＝三票
+ *12--新聞大作戰
+ * 投票：
+ *13--新聞東西軍
+ * 投票：s5y、Carol、Rhozan ＝三票
+ *14--黑新聞
+ 投票：
+ *15--新聞眾點
+ 投票：Michael ＝一票
+ *16--新聞觀察站
+ 投票：
+ *17--新聞誌異
+ 投票：
+ *18--新聞解毒
+ 投票：YiChi ＝一票
+
+
+ 1.4.2.第二輪投票（一人一票）
+ *01--除媒APP（新聞欸批批）
+ *投票：Wilber、Michael、Zanzan、YiChi
+ *02--新聞急診室
+ *投票：Carol、MG
+ *03--硬新聞 in news
+ *投票：s5y、Rhozan
+ *04--新聞啄木鳥
+ *投票：wei yu chen、Joy、Jennifer、mrbigmouth、Summit
+ *也許可以把啄木鳥當成文案(的意象)??
+
+
+ 1.4.3.第三輪投票（一人一票）
+ *01--除媒APP（新聞欸批批）
+ 投票：Michael、s5y、Summit、Wilber、YiChi、zanzan
+
+ *02--新聞啄木鳥＊
+ 投票：mrbigmouth、wei yu chen、Joy、MG、Jennifer、YUTIN、Carol
+ *請考慮到一般使用者一看到這個名字就可以引發興趣、並初步瞭解作用的感覺
+
+
+ 1.4.4.＜附錄＞投票發問區
+
+
+
+ 1.5. 新進度規劃討論
+ 1.民眾對於新聞好壞認知的市場調查結果與分析(若還沒有發布出去,則先針對問卷內容討論說明)
+ 2.除媒的新聞好壞分數評比機制規劃
+ 3.APP使用情境流程探討 / UI 圖檔放在這裡 -- 未完成, 各組分工先進行
+ 4.募資事項 -- 未完成, 各組分工先進行
+
+
+
+ *＜二＞會議紀錄摘要
+ 大家互相幫忙整理
+
+ 2.1.核心策略訂定
+ *這個項目關係到整個app的運作模式，會連同問卷初步結果、使用者習慣、推廣模式等等一併作歸納性討論。需要盡量用旁觀者、使用者角度思考。
+ *
+
+ *
+
+ *未來需考慮媒體修改新聞後，影響評價的狀況?
+
+ *1. APP的主要定位：
+ *客群定位：大眾，初期主要為網路使用者/行動裝置使用者，如果能吸引到不太主動看新聞的人最好，因為靠別人得知消息的人更容易被錯誤資訊誤導。
+ *功能定位：對使用者來說，這個東西是「新聞」、「交流評論」定位？如果是前者，目前已經不少新聞app，似乎無法吸引原本就不看新聞的人；個人偏向是後者，但在命名上也得有新聞的涵意，實際上這是一個新型態的媒體平台。
+ *2. 定位確定後，對外形象：
+ *嚴肅？有趣？還是別的？；參考問卷統計結果。
+ *3. 形象確認後，命名 (again orz)
+ *4. 續功能定位的細節，併同1.3.3APP使用情境流程探討一起討論：
+ *需要給使用者什麼樣的資訊，可以的話，依重要性排序
+ *好/壞評比 (新聞可信任的程度)
+ *熱門議題、新聞
+ *好新聞
+ *違規事項
+ *使用者能主動參與什麼互動
+ *初期：目前設計：留言*、評價、打臉實名、長文分析實名+認證
+ *中期、後期：(自填)
+ *時間夠或是途中有點˙子請自行加入，只是調性要盡量和初期相同，差異過大可能就要用別款產品來做了。
+
+
+ 2.2.評價機制
+ 已決議好的架構
+ *使用者分等機制（四級）
+ *訪客：下載APP後無登入的使用者，只可瀏覽新聞與評價。-權重 0
+ *註冊會員：使用FB、Gmail等第三方帳戶註冊的使用者，可使用新聞細項缺點評價。-權重 1
+ *認證會員：使用手機門號或其他方式進階認證後的使用者，可進行新聞細項缺點評價、發表簡短評論在一百五十字左右說明為何會如此評論。-權重 2
+ *專家評論員：一開始由我們邀請新聞媒體工作者加入，之後由認證會員作出貢獻或發表優良評論到一定數量後升級而成。可進行新聞細項缺點評價、發表簡短評論在一百五十字左右說明為何會如此評論。權重比例更高- 權重3
+ *新聞評價分類與模式
+ *議題類- 系統會針對各媒體新聞去分類議題,是為了讓重要性議題可即時追蹤,不被臨時的花邊等新聞洗版
+ *不做總評價- 議題類不會放各家媒體在該議題的所有新聞評價總分, 避免使用者因為該議題總評價過低就放棄閱讀
+ *APP議題列表顯示排序以熱門程度為主
+ *該議題3天內有新聞(確保議題還有新鮮度)
+ *該議題的新聞總則數(議題重大所以媒體一直追)
+ *該議題的總評論數(使用者參與熱烈度)
+ *先不要有圖片 - 這部分待議, 重大議題人工增加圖是可行的
+ *低價值新聞情況- 低價值新聞代表不重要, 獨自成一議題, 也是會出現在議題列表, 只是會在很後面(在沒更新就會不見-自動過濾), 如果後續媒體對該低價值新聞議題新聞則數上升, 且評論者變多, 代表重要自然也會上升到熱門議題
+ *議題下新聞列表
+ *各家媒體評價比較-自由, 中時, 蘋果, 聯合
+ *評價方式
+ *該媒體在該議題下所有新聞的總評價
+ *該媒體個別新聞個別評價
+ *不用分數代表發霉程度, 用明確性質的燈號結果- 紅燈, 黃燈, 綠燈(暫定三色燈)
+ 尚未決議的架構
+ *個等級使用者的權重大小
+ *燈號代表發霉結果的計算方式
+ *比例式? ex 幾篇新聞有幾篇被評論, 過60%就紅燈or評論數比例
+ *個人是希望用這種方式，一來是容易計算二來使用者易理解，計算方式：只計算評價成立的新聞 (滿足達到可信度的最低評論數量)，未達評論數量或完全沒評論的新聞都不計入，這樣會比較準確，也避免分母過大的問題。
+ *絕對值門檻式?
+ 以上尚未決議, 需要再個別開會決議, 再者有請新聞組請教新聞老師有關於評論細項的權重分類( 分三類: 最嚴重,次嚴重,最不嚴重), 可做為權重分類依據
+
+ 2.3.其他待辦工作：
+ 2.3.1.寫個文案，促進問卷填寫的人數。
+ 2.\\3.2.確認新聞轉載的著作權問題。
+ 2.3.3.請教新聞學老師
+ *擔任專業評論員
+ *評論細項的完整度
+ *評論細項的權重分類( 分三類: 最嚴重,次嚴重,最不嚴重)
+ *2.3.4 APP使用情境流程探討 / UI 圖檔放在這裡 -- 未完成, 各組分工先進行
+ *2.3.5 募款計畫方式
+
+
+ *＜三＞結論重點&進度時程訂定
+ 3.1.結論重點：
+ 3.1.1.
+ 本次開會未決事項很多，時間多用於人員相互解釋與溝通觀念，發現到很多需要釐清的細節，因此依照人員專長特性，拆解兩個工作小組，容易聚焦執行細節，以利生產進度。
+ （主要就是要把事情拆解成小塊，容易消化與處裡之）
+
+ 3.1.2.續上、Ａ組是處裡程式設計，視覺介面，使用者投票流程機制
+ Ｂ組是處理制度設計（文案），對外界（人）的溝通，以及行政或文書工作
+ （以上兩點 Michael 這次會寫個針對會議過程的觀察報告，一兩天後給大家看）
+
+ 3.2會議檢討
+ 在除黴目標和該討論事項之外, 我們內部的會議也該要有檢討讓往後的會議更加順利進行, 促進效率
+ *by Wilber 會議心得
+ *這次會議原本列好4大項目要進行討論, 但最後只決定APP名稱與部分新聞評價機制, 未達目標是因為有幾個部分可以再改進
+ *遲到－每次會議都有新人加入, 遲到導致重複新舊成員介紹, 和解釋會議事項, 儘管可以按時進行, 晚到的人就先聽, 有問題私下問, 可是實際遲到情況是會議開始的30分鐘內陸陸續續到達, 這期間是會議開場的新舊人員介紹, 無法跳過後到的人, 因為會把新舊人員介紹擺在會議之頭, 是因為這個計畫是由各領域的人合作而成, 需要大家彼此了解背景or認識才能有深入討論, 而且還需要跟新成員說明過去一些已決議事情, 簡介今天目標, 所以遲到的行為 會導致後面的會議很不順暢, 不斷有相似問題產生, 簡而言之不要遲到!!
+ *會議的討論事項只有列大架構, 沒有事先定義好邏輯的先後順序, 導致討論發散, 這次的新聞評斷機制就是這樣, 比如還沒有統整大家對於會員的權重分配認知, 有人認為有3種會員有人認為是4種會員, 所以在會議中我不斷把大家拉回來要求大家先決議好最基事項, 大家有共識, 才能繼續地走下一步, 越是複雜的架構, 更需要一步一腳印走好, ex 評斷用結果顯示而非分數, 議題架構不評斷媒體好壞等等...簡而言之會議事前要定義好決議順序, 會議前充分預習好, 才可以有效預防討論發散
+ *新聞評論機制該追求的是原則, 不是完美, 這次因為納入新聞松, 參與人員非常多!! 人多總好的, 但各有意見的討論落入了完美陷阱, 世上沒有完美的架構, 但我們能做到的是精神原則, 原則走好, 不怕人家非議, 如果遇到惡漏洞or惡意攻擊 ,就是再調整應對, 關於新聞評斷機制的原則我個人認為有
+ *公正公平 -> 所以要專家+大眾參與, 權重比例要合理
+ *評價結果能正確反應新聞問題 -> 閱聽人能確實掌握新聞錯誤
+ *新聞評價機制的比較能夠影響閱聽市場 -> 結果論我們成功達到改善媒體端
+ *幫助閱聽人建立獨立思考能力 -> 最終目標
+
+
+ *＜四＞進度時程訂定 (包含規畫、技術、推廣、活動等行程，沒寫到就自填)
+ 4.1.（重要）下次開會時間
+ *暫定9月6日，待聯絡再次確認。
+
+
+ 4.2.（重要）
+
+
+
+
+
+
+
+
+ ＝＝留話區＝＝
+ 2014-08-02
+ 沛宸：大家今天辛苦了，會議紀錄有缺或疑問的再幫忙補一下喔。
+ －－－－
+ 第三次除黴會議 20140802（hackpad的）
+ 20140802
+ －－－－
+ 2014-08-03
+ Michael：
+ １）我這次會寫個針對會議過程的觀察報告，一兩天後給大家看。
+ ２）所有人請把肚裡裏頭疑問趕緊寫上去，我來幫大家排列整理，沒寫出來的會被直接忽略，以利生產進度繼續前進。
+ ３）這段具體化文字，本人介入主導的方向是幫助沛宸「協調生產線」，用工廠的工作經驗。
|
||