There's been a fair amount of discussion about volunteers and community outreach of late, both on the Planet and in the newsgroups. The following is probably nothing new, but here's my take.
In eclipse.platform.swt, Ed said:
Human nature is such that if everything is working
smoothly, for example, if every desired SWT feature simply appears out
of thin air, then there is no compelling need to change behavior. Only
when things get painful or uncomfortable is action taken. If the belief
is that others are responsible for providing the level of comfort to
which we've grown accustomed, that action will typically take the form
of complaints rather than constructive steps to deal with the issue
directly.
I couldn't agree more. That's been my experience w/ PDT -- blog about successes/failures, open bugs, see minor improvement. This was Phase One: Complaining. Not very effective.
Then I started lurking in #eclipse and found that there were a lot of people eager to use PDT, but who were having issues getting it up and running, or migrating to it from another PHP editor. So, after finding myself answering the same questions over and over, I started contributing to the Eclipse wiki, writing docs on installation & migration. Phase Two: Support / Documentation.
Last week, I found myself volunteering for PDT's first Bug Day (which frankly didn't go as well as I'd have liked). To digress for a moment, here's why:
Of the bugs tagged for BugDay, Roy suggested I look at the ones about code formatting, as they were long-standing issues.
I know next to nothing about structured text editors and how the data model is used to properly indent code, so this was a bit of a struggle -- first to find where to insert breakpoints, then to really understand what was going on. Roy was very supportive and helpful, but ultimately I don't think I had enough experience to really be useful.
The other reason for my failure to launch was that much of BugDay got eaten up with my other commitments, and the time zone offset meant that by the time I was done with all my other stuff in Toronto, it was very, very late in Israel. Time zone offsets suck. Incidentally, if you're looking for a way to help PDT, here's their list of BugDay bugs, for which they're actively seeking patches.
Digression aside, I've also been actively contributing to the PDT newsgroup and mailing list, fielding more setup, migration, and install questions. Phase Three: Feeling the Pain / Getting Your Hands Dirty.
PDT has had some tough times in the past with Integration builds only being delivered once a month and update sites that only provide Release builds, or incorrectly displayed requirements & install instructions on build pages. So, as Ed said, there's a pain: a pain that I want to help fix. And because the pain is personal, I've offered to assist with their build infra so that they can more easily publish weekly builds and monthly milestones, which they seem thrilled about. Clearly this is a shared pain. Phase Four: Code Contribution.
So... what's the point of all this? Offer your help as best you can. Do what you can to be supportive out on the periphery. Get your name out there. Chat with the teams on IRC, in newsgroups, or on their dev list. Worm your way in. Contributing to Eclipse means giving your time, but it should also mean ownership of what you contribute, because others need to give their time to process your contributions. The more you show your commitment & involvement, the more effective you will be.
After all, Eclipse is a meritocracy -- you have to earn your seat. :)
