Francis,
There's the helpwanted keyword. The bugzilla in question is already so
marked...
I tried to help with https://bugs.eclipse.org/bugs/show_bug.cgi?id=191322
and while my patch was kind of not so great (it sucked), they helped
turn it into a proper fix. Now I can take better advantage of the
great ability to produce warnings about ill formed Javadoc
references. It pays off to make an effort to contribute.
My experience with the JDT team is that they are totally awesome. JDT
and PDE's support for external folders on the classpath was a lot of
work for them and it's made life so much easier for those of us who
need to bootstrap a runtime:
http://wiki.eclipse.org/EMF/Getting_Source#Developing_on_Eclipse_3.4
Francis Upton (News) wrote:
Speaking more generally, I partially agree
with Eric, in the sense that I also experienced some difficulty to
communicate with (in particular) JDT developers in the sense that some
request enhancements of mine were just closed because "not in scope"...
One day I also started to wonder what actually were in scope for e4,
but only recently I read something about this topic on InfoQ.
Maybe the most significant example is this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204231
In that request enhancement, I suggested the creation of a tool to edit
resource bundles, providing a hint of a third party existing tool (no
longer updated) that has all the features I would need from such a
tool. Well, the bug was initially closed after TEN minutes as WONTFIX
because there were no plan to add a new editor for properties (although
what I meant was totally different from the existing one).
After complaining, I got it to be reopened, but I was left with very
scarce hope...
I have had several interactions with the JDT team on various issues,
and while I have disagreed with them on some things, I have found them
to be very responsive and agreeable to contributions that they could
see make sense (I was able to contribute an extension to LTK undo with
their guidance that solved my problems). It's also apparent from their
attitude and interactions they are very good owners of their
components, as they work very well and want to make sure they continue
to work well for everyone in the long term. This attitude is exactly
what you want, as far as I am concerned and I look forward to
continuing to work with them.
Whenever I want something that's not there, I assume I will have to
provide it, if it's something relatively small, I generate submit a
patch with the bug report. If it's something larger, then I will ask
if the thing I want would be accepted as a contribution and outline
what a contribution might look like. Once I get agreement on these
points I make a contribution.
Open source works like that; we (as clients) have no right to demand
anything. We are not paying for anything, and we are lucky that we lot
more than we pay for. However, unlike commercial products, we are able
to contribute our own work.
One of the things we might be able to improve in our community
development is to provide an easy way to identify the projects that
want contributions, so if you can't make the contribution, perhaps
there is someone else who is interested in the same thing or something
similar that's able to. I realize that bugzilla is used to track all
of this stuff and we do have flags for things that we want
contributions for, but maybe all we need is a little more documentation
(perhaps just a wiki page) with some guidance about how to use these.
|