Command line client for Write.as https://write.as/apps/cli
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

CONTRIBUTING.md 2.0 KiB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546
  1. # How to contribute
  2. We're happy you're considering contributing to the Write.as command-line client!
  3. It won't take long to get up to speed on this. Here are our development resources:
  4. * We do our project management in [Phabricator](https://phabricator.write.as/tag/write.as_cli/).
  5. * We accept and respond to bugs here on [GitHub](https://github.com/writeas/writeas-cli/issues).
  6. * We're usually in #writeas on freenode, but if not, find us on our [Slack channel](http://slack.write.as).
  7. ## Testing
  8. We try to write tests for all parts of the CLI, but aren't there yet. While not required, including tests with your new code will bring us closer to where we want to be and speed up our review.
  9. ## Submitting changes
  10. Please send a [pull request](https://github.com/writeas/writeas-cli/compare) with a clear list of what you've done.
  11. Please follow our coding conventions below and make sure all of your commits are atomic. Larger changes should have commits with more detailed information on what changed, any impact on existing code, rationales, etc.
  12. ## Coding conventions
  13. We strive for consistency above all. Reading the small codebase should give you a good idea of the conventions we follow.
  14. * We use `goimports` before committing anything
  15. * We aim to document all exported entities
  16. * Go files are broken up into logical functional components
  17. * General functions are extracted into modules when possible
  18. ### Import Groups
  19. We aim for two import groups:
  20. * Standard library imports
  21. * Everything else
  22. `goimports` already does this for you along with running `go fmt`.
  23. ## Design conventions
  24. We maintain a few high-level design principles in all decisions we make. Keep these in mind while devising new functionality:
  25. * Updates should be backwards compatible or provide a seamless migration path from *any* previous version
  26. * Each subcommand should perform one action and do it well
  27. * Each subcommand will ideally work well in a script
  28. * Avoid clever functionality and assume each function will be used in ways we didn't imagine