Requirements documentation rocks.
"Requires" someone on the team being trusted enough to have final say what goes in it after discussion.
If, after the requirements are locked down, and there are requirements no one on the team volunteers for, then it's a sign the requirement list is flawed or too long and there needs to be another brain drain meeting. Never be concerned a requirements list will be too short. I've never seen that happen.
It's never too late to draw up a requirement doc. Start with what's done, add what's not done (but being actively worked on by someone- regardless of working time frame) then add the dream stuff which have been discussed, then start pairing it down. Give someone final say even if it's only temporary (until release x) or a date. If this means the leadership changes hands once in a while, it's a good thing. Eventually, the person who most fulfills the role (no one is perfect) will stand out.
My experience is when you have a working product in distribution people are able to use, incremental releases with relatively few new stable features are well received by the community. Volunteers can only sprint for so long. Getting some features behind you lets the team release some brain cells to get the real life stuff done with less stress.
Big, comprehensive fat feature releases are also well received, but usually require more tech support and longer periods between satisfaction rewards for the team.
The community will (and has no choice) wait for anything. The sooner a stable feature release is possible, the sooner devoted and talented end users will step up in the forums and provide some of the tech support (how toos) to new users.
I see no reason a freeware dev team should provide 100% of the support for a product after a reasonable number of people are using it reasonably well (successfully.)
Instead, planning for directing new users to community forum resources for common new user problems can reduce dev time (contact us directly for missing files, textures, crashes, etc.) but let the community take on the howto stuff.)
Since passion can be a great motivator and obstacle, an objective requirements leader outside the dev team can come in handy to preserve the team passion, yet focus on reasonable objectives. It's never too late on a freeware, open-ended dev cycle to do these things.
-Pv-