[How to] Contribute Code

SickGear Wiki: Home | Reporting Issues | Frequently Answered Questions | Install Guides

Document Dated: 19 Dec 2014

We follow [git flow] (http://nvie.com/posts/a-successful-git-branching-model/) methods for pushing code to SickGear

SickGear is not a space to learn how to write nor is it a playground for coders egos. For example, making code "nicer" is opinion and does not give users anything of value, the time to make code "nice" is during the crafting of a feature, and before the final complete testing. Code changes should have good rationale, performance gains should be provable by unit tests, adding dependancies should have a really good reason. This philosophy reduces errors and maintains stability via considered incremental change.

1. For branch names, use CamelCased "feature/AddNewFeature" (e.g. feature/AddThemePicker, feature/ChangeThemePicker)

2. Use present tense for commit texts and changes.md

Use	Instead of	Usage
Add	Added	Add a new feature, behaviour
Change	Changed	A change to general behaviour or appearance
Fix	Fixed	Fix a bug
Update	Updated	Only for a library update
Remove	Removed
Reason: a commit has an action when applied... e.g. commit 123 will change, not commit 123 will changed

3. Be clear and thorough with commit messages (commit "amend" until satisfied)...
   Use line one as a summary¹ (copy text from changes.md). If you need more, add a blank line, then detail each item in paragraphs. This way, when you create the PR, Github will use line one¹ as the PR title, and the paragraphs as the description field

   • where appropriate, state affected page(s) and/or tab(s)

   • too vague... "Add feature abc."
     better... "Add feature abc to page blah. <blank line> Use abc to do actions a, b and c."

   • too vague... "Fix searchtvdb api command"
     better... "Fix invalid responses when using searchtvdb api command."
     because it explains the actual issue addressed and how to test/view results.

   • too vague... "Fixed error ..."
     better... "Fix widget from breaking display on page blah."
     because anything and everything can be "Fixed error".

4. Code conventions...

   • use tabs for indents on any line that is html, css, or javascript output (i.e. 1 tab character per indent)
   • use spaces for indents on any python line (i.e. 4 space per indent)
   • cheetah lines should be pulled to the left, then use regular python indents
   • blank lines inbetween cheetah lines should be commented with a #
   • only use double quotes within html output
   • use single quotes for all language code. For the explit use of "\n", separate like so... var = 'text' + "\n". Basically, to avoid "\"test\""

5. Always submit PRs (a) squashed and (b) rebased against the latest develop. The exception is to PR bug fixes against a release/x.x.x branch when one exists, and update it's CHANGES.md instead of that on develop.

6. Clearly explain in the PR what it changes (we cannot read your beautiful mind)

7. Clearly explain in the PR how to test for your change (not all testers understand code)

8. Update file CHANGES.md to describe what your PR achieves that is different from current main branch release, please add text at the end of the top section

Please understand that your PR may be rejected if we feel it isn't mature enough or doesn't fit our ideology to be included into SickGear. If you are unsure about if your changes would be accepted to SickGear, do feel free to ask one of the devs before you start coding.

Happy coding and thanks for reading :)