從立文 / clsung 處輾轉知道 pugs 要離開 foundry 了.

嘆氣之後, 加油吧.

參考資料:
Comparing Web Frameworks
prototype
tacos
In tune with Tapestry, Part 1
In tune with Tapestry, Part 2

Tapestry Site:
Tapestry Wiki
Javaref
TeamWork

Tools:
aptana

source code search 找到某 api 的用法

rating / collaborative filtering

兩個人覺得, 要是東西都能被 comment / annotate / discuss 好像不錯.

Amazon 很大部分的價值就來自於使用者的 comment.

被 comment 的東西, 可能是 project / release / page / piece of code.

可以參考的一些作法: http://www.loosewireblog.com/2006/03/a_directory_of_.html

(怎麼找到這一頁? google: third voice gabbly)

And … LCamel
地理分佈: http://clustrmaps.com/counter/maps.php?url=http://clustrmaps.com

活躍度可以弄成雷達圖, 不只是一個數字.

造成 bug 會增加 karma, 多了下地獄.

比方說, "p2 is a sub-project of p1" , 我們是否要讓 p1 的管理者也自然是 p2 的管理者?

這兩個 project 的 subversion repository 是否可以合一?

又如 "p1 uses p2", 那其間的 ticket 是否可以互相 reference ?

或許對 launchpad.net 該多點瞭解..

http://rt.openfoundry.org/NoAuth/Severity2.html
這一個只有第一行會變色, 移到每某一行時, 那一行還會變色

http://rt.openfoundry.org/NoAuth/Severity3.html
這個是想用數字或圖案以及顏色來表達

請大家給點意見及想法, 包函顏色 表達方式 顏色提示的方式.
Aguo with LCamel

為了維護現有專案的 tickets, 新的 issue tracking system 系統會優先考慮使用 Best Practical 公司出的 RT.

舊的 ticket number 應保留. URL 選擇性的保留.

或許也可以提供一套以上的 issue tracking system 給使用者挑選.

功能:

要好搜尋, 不然很容易發重複的 ticket, 或者印象中有留 ticket 卻找不到.

能很方便的看到 recent changes, 從 人/時/處理狀態 等面向過濾. (如工作報告時, 可以完全從 issue tracking system 來看)

可以 tagging. (如: “subversion系統, 移機, 備份, 網路, 優先處理”)