這裏是Eclispe方式(Eclipse Way)的第二部分。
計劃(Planning)
爲下一次的發佈設計一個藍圖。組件團隊定義所要開發的組件的計劃，然後管理委員會（PMC）制定出最初的項目計劃。在計劃中，總有一些我們可以做什麼和我們想做什麼的折中。計劃每個季度都會更新，以此來反映項目的進度，新的條目等。在正式發佈前，這個計劃才最終定稿。
風險評估(Risk assessment)
儘可能早的指出高風險的項目和有許多依賴關係的項目。如果需要，制定一個將這種項目去掉的時間表。這種做法降低了其他項目的風險。
Collective ownership
每週，管理委員會(PMC)會聚一次。所有組件小組的領導人和PMC的成員每週會有一個電話會議。會議紀要會在開發者的郵件列表中發佈。建立動態的團隊來解決組件交叉中的問題。如果可能，讓小組成員面對面的討論。
APIs
每一都準時發佈，但是必須保證系統架構的完整性。持續的發佈高質量的API。
APIs優先 (APIs first)
儘早的反饋API中出現的違反標準的地方。原因很簡單，工作的東西不一定意味着它的API是被允許的。當定義一個新的API的時候，這裏至少必須有一個使用者(client)參與其中，越多越好。
我還是建議看eclipsepowered.org上的原文。總覺得翻譯的不是非常貼切。
