The Contributor's Code: What Should be Expected of FLOSS Contributors?
Free and open source projects provide an amazing example of what volunteer contributors can do. While many folks are paid to work on open source, there's still an enormous amount of work done by volunteers. Like any volunteer work, though, contributions can be disrupted by more pressing work and personal issues. What do, or should, contributors commit to when volunteering with a project?
There's an interesting post on the topic from a Perl contributor, with a rough guidelines of the responsiveness he strives for with his CPAN modules. Basically, it boils down to responding to questions about code within a week or so, looking at good patches (with tests) quickly, and handing over co-maintainership if he loses interest in a module.
In general, all good guidelines, but mostly centered around personal projects that may or may not be widely used. What about participation in projects where volunteers need to coordinate with other folks?
Bearing in mind that "real life" always takes priority, contributors should commit to timely response, following through on things they agree to take on, and having an exit strategy when in an important role. For instance, contributors who serve as release managers for a project should be training someone else to take the job when they need to move on. Respond to emails in a timely fashion, even if it's "I got this, but I'm too busy to give a meaningful response right now."
Saying "no" when appropriate is a good thing too, to avoid getting burnt out. This can be the hardest of all, because it's easy to overestimate the amount of time available to work on outside projects. I've seen way too many good contributors leave projects altogether because they were doing too much and felt burned out.
Wrangling a commitment out of volunteers is tricky, but it might be a good idea for projects to not only explain how to contribute, but what the expectations are.