YAOH x jothon co-work

caasi 11/3

• 聊天功能
  1. 搜尋 log ，顯示結果包含前後三條句子，好快速查找是否該加上標籤的功能
  2. 從 log 跟 nickname 建議三個標籤的功能
  3. 二到三個視覺化圖表（貢獻者、討論者、時間軸）
  4. 結合線上訪問結果的入坑頁

ttcat+caasi 11/13

• 媒合功能
  1. 期中報告以兩個 user cases 出發：新手要找坑、坑主要人更好瞭解他的專案
  2. 視覺化圖表
  3. 訪綱 - 入坑頁（來得及的話再做）
• 聊天功能
  4. Research 未來同時接 Slack archive 去蒐集其他頻道 log 的可能性
  5. CHAT BOT 相關功能約 yutin 大松時討論

Team review：在黑客松的期中報告不明確，要再補充是否完成以上項目。希望大眾（或者至少曾參與過專案的參與者）看了期末報告之後可以很清楚 g0v 的專案。

ronny+ipa+caasi 12/1

• 提案關鍵
  「整理這些專案，為他們多添加一些脈絡，也許會有更多人願意填坑」。「很多專案的脈絡留在 fb 、 irc 、 Slack 的對話記錄，或是小松的過程中，沒有被關聯在一起，這計畫也希望可以把專案 repo 與這些資訊關聯在一起。」

• 整理資料

  • fb po文
  • 聊天（irc, slack)
  • github repo
  • hackmd, hackpad
  • hackfoldr

• 原始呈現

  • 時間軸
  • 聊天討論
  • 相關的 tag
  

• 一週進度

  • dashboard 建立
    • 自動產生每專案的 dashboard
      • 整理 g0v repo 下的專案
        • 多個 repo 問題(待解)
        • 運用主 repo 的 g0v.json：描繪專案介紹、哪些 repo 是同案(待解)
          • g0v org 下的案子卡西應該可以主動增改 g0v.json
      • 整理非 g0v repo 下專案
        • 放在個人 repo 如何匯入
  • 訪談訪綱整理成文件（QQ大集）

ronny+ipa+caasi 12/8

本週進度與討論

• dashboard
  • mockup: 尚未
  • 專案簡介、repo、人：
    • 抓 g0v.json: description, contributer, tag（先抓）
    • 問題：有些專案有很多 g0v.json –> 先確定主要的 repo（先抓再調整主從）
  • 共筆資料：
    • hackmd, hackpad 加 tag –> 運用 g0v search: ronny 嘗試增加 hashtag
• url 加 tag（社群動態）:
  • twitter, fb, hackmad, hackpad 等
  • 問題：開放自己寫 hashtag 混亂，不開放不精準 –> 先暫緩開發
  • g0v editor 可補強、替代、連結（editor 去抓加 「網址加hashtag」的資料庫，送PR）
• 訪談 QQ 大集： https://g0v.hackpad.tw/QQ–LTnlkP6GBOV

下週進度

• dashboard:
  • 前端框架先出
  • 吃 g0v.json: description, contributor, tags
  • g0v search 增加 #hashtag 功能
  • 社群動態（網址加 hashtag、irc、fb 動態暫緩）
• QQ 結構大集

caasi 12/14

• repo page
  
  
• 網址加 hashtag （功能，非資料）
  
  

ronnywang, ipa, caasi 12/15

• 未來 awesome g0v 用產生的？
• issue 加 tag ？或是按 tag 過濾？
• QQ 題庫可以被選到 g0v.json 或其他的結構化資料中，坑主可以選題產生 hackpad/hackmd ？
• 針對 issue 需要什麼人力的 tag ？例如設計師、程式員、 UI/UX
• 整理提案資訊？
  • ipa 問 ronny g0v search 能否整合 YouTube 影片？
• fork project 會包含原本 contributors

下週進度

• dashboard:
  • 升級 g0v.json ，好呈現專案成果與相關 repos ，
    • 並整合主從 repo 的 contributors
    • 還有整合主從 repo 的 contributors
  • 將 search 換成 g0v search

ronnywang, caasi 12/22

• LIVE 頁面
• 從資料處理的角度看， ronny 還是覺得先把 g0v.json 爬下來處理比較好
  • 好處：
    • 不會撞到 GitHub API 上線
    • 只需要留 parent 欄位，不用列 projects
    • 不用列出 project 的 name
  • 缺點：
    • 不即時
• 但是 products 的欄位（type, subtype, name, url） 要留著，畢竟成果不見得會有 repo
• 要瞭解誰是上游（資料來源，處理資料的 repo ）？誰是下游（成果，用到這個專案的資料的專案）？哪些是同類的？怎麼整理在一起？
  • 最初的想法是 ronny 建議的，只填 parent 就好
  • 但這樣不好處理一個資料集供給很多專案這種結構
    • 可能可以把它獨立出來成一個專案
• 後來採用 group, dependencies, products 方案，此方案靠 group 來組織同類專案；靠 dependencies 來描述專案上下游； products 則如以往，描述成果：
  • group 是 repo 完整的 URL ，如果填自己的話，表示他是主專案， project hub 列專案時應該列出 groups ，而不是所有 repo
  • dependencies 有很多個，包含 repo 完整 URL
  • products 仍是產出
  • 目前的規劃在放在 YA0H 的 metadata.js 中

其他可以呈現在 repo 頁面上的資訊

• 如何呈現專案活躍度：
  • 從參與者最近的活動下手
  • 從 issue 下手
  • 從 commit 下手
• 決定新的參與者結構
  • g0v.json 一樣只列名字，但是可以從 g0ver 那邊拉到詳細資訊？
• 決定一套基礎的 issue labels ，並用在 g0v.json 的 needs 欄位
• 莫忘 QQ 結構大集

接下來要做

• 要個 domain 吧～
• 和專案主討論新的 g0v.json 架構是否合適？

一月方向

• 幫其他專案準備 patch.json ，最少要加上 group 欄位
• 掃過所有的 patched g0v.json ，把結果存到 /data/groups/${url}.json 中，作為「相關專案」的資料來源
• 挑出三組 group

目的是讓大家看到按這個結構寫完的 g0v.json ，會有怎樣的呈現成果。

二月方向

• 改完
• 讓 g0v editor 產生新的 g0v.json
  • 將 g0v editor 嵌入 YA0H 中？

目的是讓 TxT 組開始幫忙完善其他 g0v.json 。