|Re: [ide-dev] Are feature requests contributions?|
I would love to help support a hackathon. If someone volunteers to organize it, I can help provide prizes, funding and promotion.
One way might be to organize and run frequent hackathons. Eclipse does run a lot of DemoCamp's, but these look to be more like education sessions than actually working on code. A real code fest would be a good way to not only address some of the many long outstanding bugs, but also give people the opportunity to work on the design and implementation of new features. Even if the feature wasn't actually completed, it would go a long way to providing a more substantial requirement than just 'I would like feature x'. The PTP project is running such an event as part of our User/Developer Workshop in September, but I would like to see a regular IDE hackathon for the platform.
On Aug 21, 2013, at 1:03 AM, David M Williams <david_williams@xxxxxxxxxx> wrote:
This list hasn't seen much activity since it opened, so I'll add a deliberately provocative comment.
And, actually, it is not an original idea. I ran across the following statement in the "README" file when I went to recompile "liferea feed reader". I found it so interesting, I'll quote the whole section in full:
4.1. No Feature Requests!
First: *Feature requests are [not] contributions*. A lot of users think so and
don't see at all why this should not be the case. While there might be a
bit of interest on what new features the users would like to have, feature
requests tend to take up *a lot* of the time spent on support. Short of
ignoring feature requests the only polite way to answer them is an elaborate
explanation of the reason why the developers have decided not to implement
this feature requests and that they already have thought about it. So feature
requests are a constant justification exercise invented to punish developers.
Please be kind and do not participate in this.
Naturally, I don't share exactly the same view, but I can see their point, and think it's bold for them to state it so strongly. They went on, in the next section, to describe how to make contributions for bug fixes or new features.
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?
I have no answers, per se ... I just thought it an important question.
ide-dev mailing list