This project should have a contributing guide (named CONTRIBUTING.adoc). It should explain how to get setup for development (pulling in content from the README), how to run tests, preferred coding style and goals for the project.

We can draw generic content and messaging from other contributing guides in the ecosystem (See https://github.com/asciidoctor/atom-language-asciidoc/blob/master/CONTRIBUTING.adoc and https://github.com/asciidoctor/asciidoctor.js/blob/master/CONTRIBUTING.adoc). What should be unique about this contributing guide is a clear list of goals for the project. Here's a draft of those goals:

• Avoid unnecessary whitespace in the generated AsciiDoc
  • Unnecessary whitespace can be a real nuisance for users.
  • If we handle whitespace well, it's a chance to stand out against pandoc.
  • Tests should verify whitespace accuracy).
• The code should not generate any Ruby warnings
• Follow contribution workflow
  • Every change should be submitted as a pull request (and ideally associated with an issue)
  • Unless it's a very trivial change, pull requests should remain open for ~24 hours to provide a chance for comment and review
  • Pull requests should get a thumbs up from at least one other person in the project. Don't hesitate to mention other members in a comment to prod them.
  • If you want to avoid a merge commit, you can use the "squash and merge" feature 0of the merge button
  • Each change should have one or more tests that can verify it.
• We should generate clean, consistent AsciiDoc, following the recommendations in the Asciidoctor User Manual. (see http://discuss.asciidoctor.org/Joining-the-Docbookrx-project-tp4695p4709.html)

The document doesn't have to be perfect to start. What's most important is that we get it started.