It's only human to want more, and sometimes we want more for less.
As an occasional contributor, my impression is that there's just not enough people to review bugs and patches and keep ownership of the various components. In the projects I've contributed to, this has been a steady decline over the years. So, I agree with Doug, more cooks!
However: As a former (individual) committer who just wasn't active enough (life happens), I wish there was more time! I think there's an untapped potential in the project "hangarounds". People who have been following the project or component for a while, are power-users but also know the design codebase, but do not have the time to be a committer with all that entails. The hangaround.
By that, I mean a person who keeps up to date with the project or component, and is willing to assist the committers in a number of areas:
- Bug triage
- Spreading the good word about the project (superuser/ambassador)
- Fixing bugs
- Reviewing and testing patches, etc. from the contrbutors at large.
- Pushing initiatives like Bug Friday
- Extend test coverage
- Keeping [helpwanted] markers on bugs relevant and realistic
- Review and write documentation
- Participate on mailing list and/or newsgroup
Often full-time Eclipse member committers are indeed colleagues working together on significant areas of new functionality, and they often optimize their communication by keeping it to themselves. This is unavoidable and mostly OK. Hangarounds wouldn't be "in the loop" for that kind of development, but their knowledge of the project or component make them valuable reviewers -- keep in mind that a large share of the Eclipse user audience are software developers, and should be accustomed to such tasks and hopefully welcome them.
While I don't know every project in the Eclipse ecosystem, I'm sure project hangarounds already exist, in practise anyway, and that their contributions are valued. However, I think it should be encouraged lots more, also so that the committers had a better feeling of which contributors to turn to for help.
I know, I know, code is the true measure of most things Eclipse, but even if you can't code Eclipse all day, you can still contribute. Let's not forget that.
3 comments:
Very good point. Btw, the Eclipse Platform has a dedicated doc component... meaning that you can become a committer just for writing documentation!
I've been a hanger for quite a while (not the least impacted by my day job not being C, Java or Eclipse based - oh well, at least it's not Microsofty) and one of the big problems (for me) is the fact that bugs are owned by the project teams, not by the community.
There's plenty of cases where a bug has been reported (and is still valid) against a really, really old version of Eclipse but the version number has never been changed. Or bugs that are in the RESOLVED FIXED state but have never been punted from that to VERIFIED (or even VERIFIED to CLOSED). And adding items such as 'helpwanted' or even changes to the subject (or that it's a bug that's applicable more than just one OS) are only possible from people who are 'superusers', project owners, or the person who filed the bug in the first place (which after several years, can even be an invalid mail address).
Of course, bugzilla has its own share of problems - being too chatty by email, for example, and of course the famed RESOLVED NEVER which took a year or two to be deprecated. But 'we shouldn't change that bug because of email spam' is an example of the tail wagging the dog.
Wikipedia works because anyone can change anything. Yes, you get annoyances - but as this year's EclipseCon suggested, it's now faster to undo damage than to cause damage in the first place. The same should be true of Bugzilla. Only then are you going to get hangers doing anything useful to help work through the pile of bugs in a project, because otherwise you can only affect your own (and frankly, half the time it ends up with a 'resolved duplicate' onto a bug which you then have no control over).
Lastly, patches almost never get reviewed in a timely fashion. I know of several patches which were closed, not because it wasn't useful, but simply because the JDT team have dropped in numbers over the years and there wasn't enough time to review it - after which, of course, the patch becomes basically meaningless because it doesn't apply. The team project is another example of such inaction - I wrote a Kerberos CVS client that's still sitting around in an (open) bug that probably has no chance in heck of being committed because it probably doesn't apply even now.
It's much easier to change smaller projects (Mylyn, ECF etc.) probably because they have smaller teams and so are more dependent on contributors from working with them. Ones where there are a full-time project set owned by one company - you can pretty much give up on that. I filed a bug long, long ago where EFS systems couldn't provide a filename with ':' in the title, because that's not a valid char on Windows filing systems. Yeah, but it's valid on my EFS system, right? That never got actioned, despite removing the code in Path that did that validation.
And let's not forget my advice for raising bugs late in the cycle - if you ever want a feature to never be added, raise it after 3.xM7. Any enhancements automatically go into an effective RESOLVED NEVER state, and anyone who raises a duplicate against a newer version gets duplicated against the bug raised against Eclipse 2.0 which is never going to get looked at ever again.
It would also help to have a prescribed set of standards for operating bugs - for example, have bugs that have been VERIFIED for older than a couple of months automatically closed, and when/who should move a bug from RESOLVED FIXED to VERIFIED to CLOSED. It's all well and good letting each project choose its own rules, but the community at large isn't going to be party to those decisions, and if we can all agree on the same uses, we'll be able to let the community help out more.
Oh how I could use your help on XSL Tools. Any contributions you send to wst.xsl will be looked at in a timely manner. I guarantee it.
Post a Comment