Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Are feature requests contributions?

The comment that I reposted to my blog opened my eyes a bit more to what I think is needed. In case you missed it, it's here:


And I think Gunnar is highlighting this a bit too. What we're really missing is co-ordination between the various IDE projects. A lot of us have similar functionality and there is a lot of duplication of effort. And we really haven't made it any easier to add new languages. Xtext helps with a lot of it now, as long as it's parser generator can handle your language. Without having this forum in the past, we've all gone in slightly different directions and there are a lot of inconsistencies in the UI when you combine multiple languages. And of course the SCM and ALM projects fit into that as well. That co-ordination is part of what I hope we can address.

And frankly, yes, this probably should be in the domain of the Architecture Council. However, it has decided not to actually do any architecture and is focusing on process instead (which frustrates me and a few others to no end).

But as you point out Mickael, nothing happens unless people contribute. I'm just hoping building a community around the Eclipse IDE and making it a thing will help bring it that much needed attention.

Doug.

From: Mickael Istria <mistria@xxxxxxxxxx>
Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: Wednesday, 21 August, 2013 5:09 AM
To: "ide-dev@xxxxxxxxxxx" <ide-dev@xxxxxxxxxxx>
Subject: Re: [ide-dev] Are feature requests contributions?

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

Back to the top