Task Volunteering

Advocacy is volunteering. If you are making an impassioned plea for a feature, a fix, or your latest idea you'll probably convince everyone on the mailing list. Well reasoned, passionate arguments tend to win. But wait! Who is going to implement your change? Surely you don't think that anyone else cares enough about it. That leaves only you. So next time you get to dancing and singing on a mailing list be aware that you are volunteering to do your task.

You don't program therefore you can't contribute? Surely you jest. In any effort of any size there are dozens of tasks that do not involve programming. A couple instances suffice to make the point:

documentation. There isn't a project on the planet that is fully and carefully documented. If you can write you can document. Even if you write badly at least there will be a starting point for documentation.

• translating. You speak two languages or maybe you can read english but are a native speaker of another language. Pick any project. They need you to work on ``internationalization'', that is, translating all of the menus, messages, and documents to your native language.
• porting. Many porting tasks simply require access to a machine. For instance, you just bought a new 64-bit computer. Pick a bunch of projects, compile them, and try to run them. File bug reports with detailed console logs.
• packaging. Linux distributions like RPMs, Windows like InstallShield. If you have access to InstallShield and there are projects that can run on Windows you can build installation packages for them.

Projects everywhere need quality assurance testing. All you have to do is download the project, build it, play with it, and file bug reports. Speaking of bug reports, many projects needs a ``bug administrator''. They need someone to nudge people about the high priority bugs. They need someone to listen to the mailing list and file bugs that users complain about but fail to insert into the bug database.

Projects need to be pried out of the developer's hands. A programmer never believes his project is ready and certainly it is never finished. But it pays, especially with a new project, to follow the motto: ``Release early, release often''. That way you get feedback about what is right and wrong about the project. You can lead the way by setting up an early release plan and focusing the efforts to get a working

(comcast story)