Better contributing guide

[nic-hartley]

Goal

Our contributing guide (CONTRIBUTING.md) should include all forms of contribution (bug reports, feature requests, and pull requests) not just PRs, and be more specific.

Description

The current CONTRIBUTING.md was written by me over the course of about 10 minutes, as a placeholder for when we had something better. I think it's workable, but it's certainly not ideal, and we should at least change some parts of it to better fit how we want people to contribute. Specifically, the new one should:

• Include all forms of contribution, not just code (we want it all in once place, not split up between the README and CONTRIBUTING)
• Provide links to pre-templated, pre-tagged issues to insert information into (this can be done pretty easily)
• Make sure to capture the core "event loop" of contributions:
  • Issue is submitted
  • Issue is triaged by contributors
  • Issue is claimed for contribution
  • PR with code is made
  • PR is reviewed
  • PR is accepted and code is now in master
• Preferably be clear and easy to read, with a minimal amount of pre-existing knowledge. We're not a Git, Java, or GitHub tutorial, though, so we can probably assume people can figure out stuff like "add the label foo to the issue" and "fork the repo" on their own.

Additional notes

A couple of things about how I've been using issue labels so far:

• Issues go from discussion wanted when they're first posted to up for grabs once the discussion is done to neither when they're being worked on
  • I've been skipping discussion wanted for a few, but that's because I know they're necessary and no one else is here anyway :(
• They can be both enhancement and bug, but that should be rare (and it's only if the proposed feature's implementation would have to work around or fix a bug to continue)
• good first issue is necessarily subjective, but we should try to keep at least a small backlog of them -- things like minor bugs or new features are a great way to get people involved in a codebase without drowning them under details.
  • good first issue can also be used for things which are low-priority and somewhat tedious, so we encourage other people to do them for us!

None of that is set in stone, but if we change it, we should make sure to update the existing issues to follow the new guidelines.