don,
it's probably too hard to get everyone to agree on a single iron-handed rule deciding the way things should be. everyone has their particular best way of doing things. get the community to at least agree on what is best, but always allow for and accept reasonable variations.
the problem is actually motivating people to want to follow the agreed standard and not stray. i made the following suggestion in the top ten oacs priorities thread:
"require packages maintainers to document the scope, requirements, and status of their packages. the community should "certify" packages (ie. a community-recommended package) by reviewing quality, completeness, qa-testing and value. require package maintainers to document and communicate the status of their packages to the community or risk losing certification. clearly document packages that are not certified, and what the ramifications are for using them. encourage users to get their packages certified."
with a system somewhere along these lines (maybe applied more generally), you can pretty much tell everyone that if they want to receive the community stamp of approval and a gif of a big gold star next to links to their code, then follow the guidelines. if they don't get the stamp, they risk their packages and code not being used or supported. keeping a stamp of approval will also motivate people to keep up with their code and make sure it meets evolving standards.
