In the same way as quoted in David's
mail, I'm skeptical about the results that will come out from this
ide-dev and all the IDE related discussions.
On 08/21/2013 10:17 AM, Gunnar Wagenknecht wrote:
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.
I also think that most of the things to improve in Eclipse projects
are already somewhere in the bug tracker as feature requests, but
simply did not get interest from contributors, because contributors
don't know/care about the value it brings to other use-cases than
the one they usually deal with. An authority evaluating the
criticity of a bug/feature request for general usage and helping to
prioritize bugs can definitely help for most projects.
This mailing-list could be an authority which gather feedback and
maintain a list of most recurring critics about Eclipse and
associate them to existing or new feature requests. It seems to me
that it is actually part of the duty of the Architecture Council
http://wiki.eclipse.org/Architecture_Council .
However, I don't think saying what's the most important is enough to
make everything better. In an OSS community such as Eclipse, no one
can drive a roadmap except the people who actually contribute code
to the project. Asking for something to be done is not enough to
make contributors implement it. Contributors already have their
priorities set up according to their own constraints, and no one can
change that. The power belongs to the ones who write the code, not
to the ones that request features.
So overall, the best way to get things improved is not to set
priorities on issues, but it is to write code and get it integrated
into projects. The bottleneck is not the amount of ideas to improve
Eclipse, but rather the amount of code written to implement these
ideas. So let's just write code and submit patches...
Personally, I'd also like to see a second goal of the
workgroup being the creation for patches for other projects to
accept.
I don't see what is currently preventing this to happen. Anyone can
create and submit patches for any project, and project are generally
responsive to contributions. I'm not sure Eclipse needs help on that
side.
|