Policies & Procedures

From Sit
Jump to: navigation, search
Broom icon32.png This is a draft article (or section) and is a work-in-progress.
Please help us and our readers by clicking the edit link above and expanding/improving this text.

This page aims to document all of our informal conventions and policies that have turned into regular practice for members of the SiT! project team. Just because something is listed here it doesn't mean you must do it, but all the same if something isn't listed here maybe you should do it.

At the end of the day, common sense rules, but if all else fails lets have this page as some documentation on how to proceed.

Contents

Writing code

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
– Brian W. Kernighan

Your code should be neat and tidy and must make sense to humans as well as to computers. Read our coding guidelines to learn how we prefer to lay out our code and try and stick to that were you can.

  • Write code that other developers will find easy to read

Code that doesn't meet our coding guidelines may be rejected.

Commits

A commit should be one (and only one) logical unit, commit often so that your changes are useful applied as a patch or reverted if not required.

  • Make "atomic" commits

Committing individual changes also makes it easier to write commit messages. Whether contributing via svn, or via git or even by email it is very useful to have a bit of text that explains what your patch (changeset) actually does.

  • Write a comment when committing something to the repository.

A good commit message is brief and to the point while describing what has changed and if relevant why it has changed. If you fixed a reported bug you should mention the reference number in your comment but don't let that stop you writing a useful description of your changes.

Bug reports

  • Check to see if a bug report already exists before adding a new one.

Yeah it's obvious, but it's an easy one to skip when you're in a hurry and duplicate bug reports are a pain for everyone.

  • Set the release target at the appropriate time

Don't set a target on new bug reports but do set a target when confirming or fixing bugs.

  • When fixing a bug mark it 'Fixed in Git' or 'Fixed in SVN' and set the target version number

The 'Fixed in' and 'Target' version number fields of Mantis are useful and when filled properly make it easier when it comes to releasing. The 'Fixed in' field tells us where to find the code changes and the 'Target' field tells us when the change should be released.

If a bug has resolved itself, as some bugs do (nowhere near enough of them though unfortunately), set the resolution to 'No change required'

  • When a bug has fixed itself set the resolution to 'No change required'.

This helps us have a changelog that is correct, when no change has been made we don't want to list something on the changelog.

Publishing your plugin

Broom icon32.png This is a draft article (or section) and is a work-in-progress.
Please help us and our readers by clicking the edit link above and expanding/improving this text.
Personal tools
project