# 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](https://g0v.github.io/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 頁面][YA0H]
* 從資料處理的角度看， 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` ][metadata]中

### 其他可以呈現在 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 。

[YA0H]: http://kinmen-tao-884344.middle2.me/repos/moedict-webkit
[metadata]: https://github.com/g0v/ambassador/blob/master/src/types/metadata.js