Updated: 現在這頁已經爆炸了，有各種討論與實作 XD 我們慢慢把它整理出來到不同頁面吧:
拋磚人: kcwu
狀態：已經運作專案 (邊討論邊實作中)
專案簡介: 許多人想幫忙但不知如何下手, 需要簡單的 task. 本專案希望讓各 project 的 easy task 更容易被找到
工作目標:
關於 Label 定義的內容，已切到新頁面 g0v issue label
使用資料: github issue api
記錄一下以免忘掉，同時也需要有人整理一下，log 好多。XD
August 15, 2013
14:07 < billy3321> clkao: g0v的404不適合放這個
14:07 < billy3321> 應該要放issue list
14:07 < billy3321> "您要找的網頁看起來不存在，不過您要找的工作應該在這裡。"
August 12, 2013
18:00 < kcwu> isacl: 我原本想的是新做出來的只是 search/filter 系統(read only). 操作還是讓大家自己回 github. 自己作 issue tracking 太 累了
18:31 < isacl> kcwu: yeah 大致上是 readonly 沒錯。但是沒 github 帳號���人，如果想開始處理這個 issue. 我們要想辦法標示。
18:31 < isacl> kcwu: source of truth 必須是 github
18:32 < isacl> kcwu: g0v 自己的 db 可能會有些額外的 flag.
18:33 < isacl> kcwu: 目前主要是 jeffhung 在處理實作，可以彼此 sync 一下想法。
21:42 < ETBlue> isacl_: 請問 g0v tasks queue 整合跟 http://miau715.github.io/eo4/related_job.html 需要串起來嗎？
21:42 < kcwu> ETBlue’s url: [eo4 人力銀行]
21:43 < isacl> ETBlue: 我覺得要
21:43 < ETBlue> isacl: 不曉得要怎麼弄，沒概念中...
21:44 < isacl> ETBlue: 請問目前 eo4 開寫寫後端抓 github issue 的 code 了嗎？
21:44 < isacl> s/開寫/開始/
21:44 * ETBlue 受 eo4 人力銀行作者黃米奧指示幫忙橋事
21:44 < clkao> 應該還沒，不過 jeffhung 的 widget 好像弄的差不多了
21:45 < hcchien> 喬事!!
21:45 < isacl> 不確定 jeff 有沒有做獨立頁面。 如果要做，可能也是後端用同一份，頂多前端 CSS 不同，分別是 eo4 跟 widget.
21:46 < clkao> right
21:46 < clkao> 目前應該沒做 但是 controller 重用應該相當容易
21:46 < isacl> http://utcr.org/g0v-issue-tracker/ 至於這醜東西，我最近會把它下掉 XD
21:46 < kcwu> isacl’s url: [g0v Tasks Queue Viewer for Github]
21:47 < ETBlue> 好一頁坑坑洞洞的網頁... 每行都是坑
21:48 < isacl> ETBlue: 嗯，那後端應該就實作一份 storage 跟 github issue client. 看要不要一起到某一頁 hackpad 橋一下
21:48 < isacl> ETBlue: eo4 有 hackpad 討論頁嗎
21:49 < ETBlue> isacl: 目前只有在這串討論... XD https://groups.google.com/forum/?hl=zh-TW%E3%80%82#!topic/g0v-moc/6uG5L6jY9fQ
21:49 < kcwu> ETBlue’s url: [Google 網上論壇]
21:50 < isacl> ETBlue: jeff 的現在都在這邊 http://hack.g0v.tw/g0v-issue-tracking/1ngNLPX3mLr
21:52 < ETBlue> miau715: hooray! isacl: 就是這位
21:52 < superbil> miau715: 請直接發問即可
21:52 < isacl> jeffhung: ping
21:53 < ETBlue> miau715: 剛才對話 isacl> ETBlue: 嗯，那後端應該就實作一份 storage 跟 github issue client. 看要不要一起到某一頁
hackpad 橋一下
21:54 < isacl> miau715: Hi, 我目前也只是起頭實驗一下 github API 的使用，沒有另外做什麼了。而 jeffhung 那邊做了一個 widget, 我們的討
論都在: http://hack.g0v.tw/g0v-issue-tracking/1ngNLPX3mLr (有點凌亂)
21:54 < miau715> 我現在做的 eo4 因為主要是想讓自閉人比較容易參加，所以專案的主要成員可能會需要多費點心..
21:55 < miau715> 主要問題是預期每個專案會有負責人或管理人
21:55 < miau715> 也有每個專案的參與者
21:55 < miau715> 不知道目前有沒有哪裡已經整合了這種資料，沒有的話要怎麼生出來我也沒概念...
21:58 < isacl> miau715: 我們之後會訂一個資料存取 API 給你抓。並且可以用 label 名稱作 filter. 可以抓出需要特定專長的 task, 或是適合新 手的 task 等等。
21:58 < jeffhung> kcwu, isacl: 我這兩天人在醫院剛好可以開工，明天開始上班就沒那麼多時間了，所以我選擇了直接就先開幹，想說有東西可以
動之後，大家應該就會有更清晰的想法。建議大家先把想法 dump 到 http://hack.g0v.tw/g0v-issue-tracking/1ngNLPX3mLr ，
irc 東西太多追不完。XDD # 18:33 < isacl> kcwu: 目前主要是 jeffhung 在處理實作，可以彼此 sync 一下想法。
21:58 < isacl> miau715: 可能會在這幾天吧，還不需要實作，但 web API 先訂出來，較容易接軌
21:59 < lanfon72> miau715:暫時...沒有
21:59 < isacl> jeffhung: 嗯我也是平日在上班，不過我可以先訂個 restful API, 然後 document 起來 ok 嗎？
22:00 < miau715> 我也想過要不要做媒合配對或是新手專用一類的，但後來想一想覺得...太複雜了 XD 還是大家上去看看有沒有可以撿的工作就好
22:00 < miau715> 況且哪些工作適合「新手」實在是每個領域都不一樣阿 Orz
22:01 < isacl> miau715: 嗯沒錯，可能領域的 label 先訂出來吧。 hackpad 上有個 label 表格看似是之前 clkao 整理的。
22:03 < isacl> miau715: http://miau715.github.io/eo4/related_job.html 這頁裡面的東西, API 都會提供資料。
22:03 < kcwu> isacl’s url: [eo4 人力銀行]
22:03 < jeffhung> isacl: 我比較傾向不要訂 restful api，再怎樣訂大概都跟 github 的差不多。
22:03 < isacl> miau715: 王小明是 github user 還是？
22:04 < isacl> jeffhung: 嗯是會差不多。那你本來預計用什麼方式存取我們的 issue cache?
22:04 < jeffhung> miau715: 我目前的想法是，每個 issue 可以標 easy/medium/hard 或 programmer/designer/writer 之類的 labels
22:05 < miau715> @isacl 我沒有預設用什麼方式登入耶，只是總要有個方式判定使用者的身分這樣＠＠
22:05 < isacl> miau715: hmm. facebook XD?
22:05 < jeffhung> 請大家分頭進 github 為每個 issue 標 label，這樣前端 filter 完之後，就可以依據瀏覽者的屬性，顯示適合跳的坑。
22:06 < miau715> @jeffhung 我沒有期望要標困難度，因為大部分人應該都遇過別人說「這很簡單阿你怎麼做那麼慢..」之類的不爽事情XD
22:07 < miau715> 總之我覺得難度應該是接工作的人自己感覺的而不是發工作的人說的...
22:07 < jeffhung> miau715: 這樣講好像也對。
22:08 < miau715> 所以我理想中的發工作方式是大工作也許比較活躍的人接下來，然後他可以再開單下包
22:08 < jeffhung> 總之，我想像中的 filtering 大概可以就分幾個維度。可以是能力特性、難易度、專案類型... 等等，whatever。
22:08 < isacl> jeffhung: 嗯那 cache 想存在哪邊嗎？
22:08 < miau715> 或直接發「需要分配工作」的工作讓擅長溝通的人來接
22:08 < jeffhung> isacl: 我還在想。多一層 cache 要處理 consistency 也挺麻煩的。
22:09 < miau715> 工作可以是任何形式，只是目標要清楚，不需要猜測要幹嘛的時候比較容易參與
22:09 < miau715> （理想狀況 = =;;;）
22:09 < jeffhung> isacl: 有點想偷懶先完全沒有 cache，完全沒有 cache，完全沒有 cache，等有人抱怨太慢再來看哪邊慢。
22:10 < jeffhung> isacl: 另外剛剛想到的一個噁濫招數，現在會慢是因為每個 repo 都要個別呼叫拿資料。乾脆我們拿 github 當 cache。
22:10 < isacl> jeffhung: yes, 但如果你指得是用前端撈 issue. 沒 github 帳號的人，沒辦法過 OAuth 抓 github 的 issue.
22:10 < jeffhung> isacl: 開一個 repo 專門 aggregate issues，這樣前端只要撈這個 repo 就好，一個 api call 搞定。
22:11 < jeffhung> isacl: 我直接用 curl 不加帳號也可以撈資料啊。應該是不需要 login 也能抓的。
22:11 < scourgen> 可以架一个proxy，没有账号的请求走proxy，proxy再用某个内置账号去捞数据？
22:11 < isacl> jeffhung: 沒過 OAuth, 一小時撈超過 60 次會被擋住。 :P
22:12 < scourgen> 带了token就可以很多了
22:12 < isacl> scourgen: 沒錯.
22:12 < scourgen> 没有token很多api都限制一小时60次
22:13 < jeffhung> isacl: 咦？是 per hour 不是 per minute 喔？這樣就搞笑了。XDD 那走 OAuth 有其他 rate limit 嗎？
22:13 < scourgen> For requests using Basic Authentication or OAuth, you can make up to 5,000 requests per hour. For unauthenticated
requests, the rate limit allows you to make up to 60 requests per hour. (The Search API has custom rate limit
rules.)
22:13 < jeffhung> 可見我寫程式不夠快，測試時撞不到 60 req/hr 的限制。XDD
22:13 < isacl> 因此中間可能需要加一層。另外，沒有 github 帳號的人，想要關注或是標明說「我要參與某 task」這資料有可能也必須另外存
22:14 < jeffhung> isacl: 那我現在傾向於這個 cache 基本上用起來跟
22:14 < jeffhung> isacl: 原來的 github api 很像，只是多了我們想要外加的 annotation 欄位。
22:15 < scourgen> jeffhung,说明你不是 reflush driven development
22:15 < isacl> 另外，若又需要自己做出 issue 跨 repo 的關聯，也可能需要另外存資料。（當然也有可能在 github issue 的 description 偷加
自己的 tag）
22:15 < scourgen> 这是好事
22:15 < isacl> jeffhung: 嗯同意
22:16 < isacl> jeffhung: http://developer.github.com/v3/#rate-limiting 就是 60 跟 5000 request per hour 的差別
22:16 < kcwu> isacl’s url: [GitHub API v3]
22:17 < jeffhung> isacl: 原始 github 上的 issue 怎樣跟存在 external storage/cache 的連動，還需要再多想想。
22:17 < isacl> 因此我才有提出說，如果有想換 issue tracking 平台，要趁早說 :P 不然我們要被埋進坑裡面了
22:18 < isacl> jeffhung: yeah. 但如果想提前串前端，API 可以先開出來。不見得 web/restful, 但先開一下可能會比較容易接下來進行
22:19 < scourgen> jura 如果是 for open source project的话是free的
22:19 < scourgen> 强烈推荐一下
22:19 < scourgen> jira
22:19 < tuiry> pofeng 可以麻煩你，在圖片/文案沒有成熟前，不要發布在公開宣傳頁面嗎?
22:20 < isacl> scourgen: 嗯 jira 真的很強大。不過後來大家昨天覺得還是用 github, 單純好用，而且 source 也都在 github, 整合方便。
22:20 < jeffhung> isacl: 我的想法比較 decentralized，強迫大家統一到某平台使用 issue tracking，這樣會不 work。我們該做的是，大家喜歡
用什麼平台，我們就盡量去支援。
22:20 < isacl> jeffhung: hmm. cache 我也還沒有特別的想法
22:21 < scourgen> source到不是什么问题，现在各个project manage系统都支持的很好
22:22 < isacl> jeffhung: 若 decentralized ，未來 task 可能會分散在不同的平台，那我們就更需要自己 own 一份了。
22:23 < jeffhung> isacl: 我們可不可以這麼說，我們缺的是 OpenID for Github，如果大家不管用哪邊的帳號，都可以參與 issues 的討論，這樣
cache 的問題就可以解決了？！
22:23 < isacl> jeffhung, miau715: 抱歉得先暫離一下，晚點回來追討論 :)
22:24 < jeffhung> isacl: 或是 mash up 就好，cache 就只是單純的 cache，不牽涉 logic。
22:24 < isacl> jeffhung: 嗯不要做 logic
22:26 < jeffhung> isacl: cache 不做 logic 的話，那選擇就多了，切來切去也可以。(就算有過 OAuth 還是有 rate limit，所以可以大家一起來
貢獻 cache/fetcher [誤])
22:26 < isacl> jeffhung: 大致應該是兩個目標: 1. 沒 github 帳號的人要能參與。2. 要能跨 repo 的集中管理 task.
22:27 * isacl &
22:27 < jeffhung> 2. 集中「管理」 task 還是
22:27 < jeffhung> isacl: 2. 「集中{管理」 task 還是
22:28 < jeffhung> isacl: 2. 「集中『管理』 task 」還是「集中『呈現』task」就好？
22:28 < isacl> jeffhung: 對本來有想讓每個人看網頁時，ajax 去 update cache XD 但這樣有點危險
22:28 < superbil> 感覺呈現就夠了
22:29 < superbil> 管理的話權限又會集中(?)，然後會要處理，純粹讓人快速找到再回到該專案就很夠
22:29 < isacl> 嗯 sorry, 管理改成呈現，之後再看怎麼加上簡單的「關注」之類的功能吧
22:30 < jeffhung> 2. 集中「呈現」的話，那我現在弄得大概就是這樣做 (除了 rate limit 問題)
22:31 < jeffhung> 基本想法就是 filter 有若干 dimension，歡迎大家幫忙發想，但基本上都是用 label 來過濾。
22:32 < jeffhung> 另外排序若 issue 很多時就會有幫助，可以用哪些屬性來排序，也歡迎大家幫忙發想。
22:33 < jeffhung> 排序的話就不限於 label，但必須是 github api 裡面有的欄位 (或未來外加的 annotations)
22:33 < isacl> jeffhung++
22:33 < jeffhung> filter 可以有 pseudo label，如 repo name as label 就是一例。這個要特殊處理，也歡迎大家一起發想。
22:34 < isacl> 前端 widget 跟 eo4 要怎���不重複工，也可以討論一下
22:34 < jeffhung> 基本上「呈現」的問題，假設 scope 設定成以上，程式方面就可以快速進行，大家的發想結果，以後再改進去很快。
22:35 < jeffhung> 1. 沒 github 的人怎麼參與暨迴避 rate limit 問題
22:35 < jeffhung> 假設我們目標只設定在「呈現」，那就可以是只靠 cache 解決。
22:36 < jeffhung> cache 可以有兩種做法：1) 被動 cache: 當有人瀏覽時，自動 cache 住 2) 主動 cache: 用 crontab 主動「爬」github api 放 進 cache 裡。
22:37 < jeffhung> 2) 比較簡單，request rate 也好控制。但是情況 cache 是舊得機率還算大。
22:38 < superbil> jeffhung: github 有提供 server hook ，這個是否可以提供為「主動」的更新來源?
22:39 < jeffhung> superbil: 這也是個好辦法。
22:40 < jeffhung> 總之，我建議 cache 的 spec 跟 github api 要 compatible，未來切過去就很快，現在也可以先假裝沒 cache 這回事。
22:41 < jeffhung> 而 cache 要 behave like a proxy 用 1) 的做法，還是 behave like a simple storage 用 2) 的做法來更新，都可以。
22:52 < isacl_> jeffhung: 對耶 rate limit 只要架個 proxy 就解決了，而且又簡單。API 就完全跟 github 一樣。很棒的想法。
22:52 < isacl_> 我明天應該可以用
22:53 < superbil> isacl_ jeffhung ++
22:59 < jeffhung> 我現在的做法是，用 jquery plug-in 寫 dao 存取 github api or cache，然後寫 angularjs controller 把 presentation 跟
dao 接起來。
23:00 < jeffhung> 首先，jquery plug-in 那部分還不怎麼 jquery，我準備等 interface 比較確定要長怎樣時再來弄。但基本上都會是靠
callback 把內容送出去。
23:01 < jeffhung> 這樣的做法，以後 jquery plugin as the dao 與 angularjs controller 的部分，理論上可以 reuse。
23:02 < jeffhung> 若 reuse 時是 angular，那就跟 controller 接，若 reuse 是其他東西，那就跟 jquery plug-in 接。
23:02 < jeffhung> hmm.. jquery plug-in 這邊可能根本不需要是個 jquery plugin。Anyway 再說。
Chia-liang Kao 提到 https://github.com/miau715/eo4 有個 full site 的 mock up。
miau715 放到 github pages 上了： http://miau715.github.io/eo4/
後端 API 架構：
proxy settings
ATS (Apache Traffic Server) 的設定初步搞定，關於上面討論的 hostname 與路徑，都是小改，隨時可以調整。現在這台可以暫時先給大家開發實驗用。
現在 ATS 的設定如下：
註：尚未設定 cache, (目前 browser 看到的 302 Not Modified 是來自 github ) 但利用 proxy 去 append query string, 帶上 client_id 與 client_secret, 因此可以達到 5000 request per hour 了。（如果還是不夠用，再來設 cache）
Demo server: http://utcr.org:8080/