|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. |
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