- Click here for Code Standards
- Click here for Sys-Admin and Configuration Management
- Click here for Technology Standards
- Click here for UI Standards
We want to continually improve the quality and reliability of our software.
We love coding… and want to have fun!
If you have any thoughts or ideas for improvement, then please create a pull request here: https://gitlab.com/kb/docs
Our current method of working is as follows:
Before starting work each day, please send a Daily Meeting email. The email should have three headings:
- Yesterday. What did you do yesterday (or what was the last piece of work you did for us)?
- Today. What do you expect to do today?
- Concerns. Are there any impediments in your way? We will review your email and see if we can do anything to help.
Create a ticket¶
Create a ticket for every support issue and every development task.
- Tickets for development tasks should be created for each piece of work which is estimated to take between 4 and 7 hours (maximum 2 days).
- Add tickets to the backlog or development (or support) board as required.
- Update tickets on the board so they reflect their current state.
Add the ticket number to the subject line of any email e.g.
Re: Fix invoice description #1234
For internal emails, include a link to the ticket in the body of
the email e.g.
Time record everything against a ticket (fixed price, hourly rate or free of charge).
We will pay your agreed hourly rate based on the time-sheet.
Time records should be created on the day the work is done.
Please make changes to the code by creating a branch and then a merge request.
Create a branch as follows:
git checkout -b 488-time-management
In this example, 488 is the ticket number and
a short description of the feature.
Add the URL of the merge request to the description of the ticket.
Ask another member of the team to review the work before merging the code back
master branch. Check the following:
- Merge request
- Unit testing
- Avoid new requirements (if possible).
- Time recorded
We aim to create short-lived branches and merge them quickly back into
Commit early, commit often¶
Please code in small units of work and commit after each change. For more information, see Workflow.
After each section of work is complete, it should be committed to the code repository.
At a minimum, the code will be committed at the end of each morning, afternoon or evening irrespective of whether it is complete or not.
We practice test-driven development using http://pytest.org/. We aim for a minimum level of coverage.
See Code Standards for the percentage.
Tests must be written when a bug is found and used to prove it has been fixed.
Code snippets for a fix or update to be installed in the
Private folder for
the client in a folder or
rst file e.g. for ticket 706, Shop, make a file
As of 20/10/2016, we don’t have a simple way to sync changes to our