So, I think the question for this list, is how do we avoid having an "IDE workgroup" become a big "feature-request-wish-list workgroup" that merely causes more work for existing committers ... more work just to read and triage and justify ... rather than encourage community participation in providing bug fixes and providing implementations of new features?
Hmm … I thought the meaning of a "workgroup" is to produce stuff vs. discuss stuff. ;-P
Jokes aside, there are hundreds (if not thousands) of feature requests in the Eclipse bug tracker already. I think an important goal of this workgroup should be to help committers identify those with a high relevance to the community. Thus, one goal of the workgroup should be (IMHO) focusing on producing input consumable by existing projects as guidance for the roadmap planning. This could be an analysis of the current Bugzilla queue, results of user surveys, requirements/design descriptions for specific features, etc.
Personally, I'd also like to see a second goal of the workgroup being the creation for patches for other projects to accept. For example, if there is an interesting feature that requires coordinated efforts in more than one project, someone from this workgroup could be the one pulling things together. This assumes that some amount of workgroup members have already Eclipse development experience. From the past discussions that lead to the creation of this list I think that a lot people that care about the IDE and might participate in such a workgroup are experienced committers. :)
-Gunnar
|