Browse files

Commit the initial documentation.

  • Loading branch information...
Lee Hambley
Lee Hambley committed Jun 19, 2017
0 parents commit 2787adb7d083cdd044e333e31118234a4699d8b1
Showing with 817 additions and 0 deletions.
  1. +61 −0
  2. +662 −0 LICENSE.txt
  3. +93 −0
  4. +1 −0 VERSION.txt
@@ -0,0 +1,61 @@
# Contributing to Harrow
* Use [Stack Overflow][so] for Capistrano-related how-to questions and support
* [**Don't** push your pull request](
* [**Do** write a good commit message](
## Getting help
Most people will prefer to use the coud-hosted version of Harrow at
Paid plans include support which extends to debugging your environment and
If you're a paid user of and you want to report an issue or send us a
patch please let us know when talking to us, it will help us prioritise the
issues we're dealing with.
If you're a paid user of please talk to us directly using the support
channels embedded within the web application.
## Tests
Most of Harrow is fairly well tested. Use of type-safe languages on the backend
(Go) eliminate the need for a whole class of unit tests, but we're unlikey to
be able to take a patch without corresponding tests.
Details of how to run tests are included in the README documents of the
respective component sub-directories.
## Coding guidelines
The backend is written in Go which includes a canonical formatter. Please make
sure to run the formatter and check for redundant imports before preparing your
PR. If you've changed the dependencies please be mindful to include the
relevant lockfile changes for the package manager.
The front-end, style-guide, configuration management etc don't have fixed
coding guidelines. Patches to introduce canonicalizing linters for these
sub-projects would be gladly accepted. In lieu of that, "whatever vim does" is
the expected format of files.
## Changelog
The changelog is maintained in Git notes (
Please refer to the post at
for more information.
GitHub doesn't support PRs for tags/notes and non-tree refs, so unfortunately
we can't make this part of the PR process, one of the core maintainers will
write the changelog entry if one is required.
## Breaking changes
We adhere to [semver]( so breaking changes will require a
major release. For breaking changes, it would normally be helpful to discuss
them by raising a 'Proposal' issue or PR with examples of the new API you're
proposing [before doing a lot of
work]( Bear
in mind that breaking changes may require many hundreds / thousands of users to
update their code.
Oops, something went wrong.

0 comments on commit 2787adb

Please sign in to comment.