Please excuse the garbled proverb, I don’t mean to say that people in Rome shouldn’t use GitHub. Instead, I’m talking about using the right tool for the job and the community. Sometimes the “right” tool is completely wrong, because the audience is wrong for the tool.
Collaboration works well when you use the right tools. For developers, that’s often git and GitHub. Wanna work on some code? Throw it up on GitHub. Check out the code, make your changes, and commit. Most developers working in open source today are likely to know git well enough to work with you. (Note that I’m using “GitHub” as shorthand for any git repository/service, really.)
At the edges of developer communities, though, there’s a temptation to use developer tools for non-development work. For example, creating marketing materials and documentation.
For some documentation projects, git is probably the right tool. Especially if you’re doing books and trying to document along with a release cycle. But for creating marketing materials or “living” documents that change a lot? Probably not such a great idea.
Use the tools that are lightweight and easy for anyone to work with, preferably something browser-based and that allows revision control. (e.g., a wiki.) While there are flaws with those tools, they’re “good enough” and – most importantly – they pass the “native” test for people who are contributing to non-code projects. Do they have a browser? Check. Can they figure out how to use the wiki in 5 minutes? Check. Do they need to create an account with a third party service or download a tool they wouldn’t otherwise need? Nope. All good.
Resist the urge to impose your favorite tools on an unsuitable audience. It’s always tempting to go with what you know best or optimize for your own use case, but resist the urge when it’s going to be detrimental to getting maximum participation and building community.