Re: [ide-dev] Are feature requests contributions?

[Mickael Istria <mistria@xxxxxxxxxx>]

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.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets