Eclispe方式(Eclipse Way) - Part II

这里是Eclispe方式(Eclipse Way)的第二部分。

计划(Planning)
为下一次的发布设计一个蓝图。组件团队定义所要开发的组件的计划，然后管理委员会（PMC）制定出最初的项目计划。在计划中，总有一些我们可以做什么和我们想做什么的折中。计划每个季度都会更新，以此来反映项目的进度，新的条目等。在正式发布前，这个计划才最终定稿。

风险评估(Risk assessment)
尽可能早的指出高风险的项目和有许多依赖关系的项目。如果需要，制定一个将这种项目去掉的时间表。这种做法降低了其他项目的风险。

Collective ownership
每周，管理委员会(PMC)会聚一次。所有组件小组的领导人和PMC的成员每周会有一个电话会议。会议纪要会在开发者的邮件列表中发布。建立动态的团队来解决组件交叉中的问题。如果可能，让小组成员面对面的讨论。

APIs
每一都准时发布，但是必须保证系统架构的完整性。持续的发布高质量的API。

APIs优先 (APIs first)
尽早的反馈API中出现的违反标准的地方。原因很简单，工作的东西不一定意味着它的API是被允许的。当定义一个新的API的时候，这里至少必须有一个使用者(client)参与其中，越多越好。

我还是建议看eclipsepowered.org上的原文。总觉得翻译的不是非常贴切。