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