Contributing
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
Your first step should be getting a build running on your machine. See the Building wiki page for more information. Once you have a build running, check out Forking page to learn managing your fork within a Go project.
See the Architectural Overview wiki page to get a better understanding of how the code base is organized.
Please follow the coding standards as mentioned in Go Coding standards. This will help us to standardize our codebase with the Go community.
If you find any inconsistencies of the codebase with the coding standards, please send a PR.
When you start working on some code change, please create a new branch from the latest master.
git fetch origin
git branch fix-of-this-issue Creates a local branch with the same code as master.
git checkout fix-of-this-issue Switches to the fix-of-this-issue branch.
Add files, do commits.
git push remote fix-of-this-issue:fix-of-this-issue Pushes the commits of fix-of-this-issue branch to the remote master.
Send a PR of the fix-of-this-issue branch with the master.
By doing this, you won't be changing the master of your fork. It also adds to the readability of the PR.
If you are better at putting others to work and have ideas on how others can use their skills, jump into issue #250 and suggest them, or look for inspiration for something you can take on yourself!
We have created an easy fix label so you can find easy issues to start with. These issues should be easy enough for you to get your feet wet with the code base. We have a Gitter chat where you can ask questions about implementation details or get more information about a task. Our community is friendly and welcoming so please don't hesitate to ask questions.
If you've got some QT/QML experience or even some JS chops, you can help out with the QML frontend. Checkout the QML Architecture and Development guide for more info.
Please see the Implementing commands page.
Both the lime repo and the gopy repo now display a test suite code coverage badge. If you want to get into writing Go code, looking into writing tests for the non-covered code would be an excellent starting point.
For example clicking on the badge 
So the task at hand is to make all those red bits green by creating new tests or adding to the existing ones. Your effort in doing so will be immediately shown at the repositories main pages via the code coverage badges and the code required for a test is typically not that many lines of code, making it an ideal task to get started with.