Developer Guidelines

Features, bugs and tasks

  • Everyone is invited add feature requests/ideas, bugs and tasks.
    • New features are added with proposed state. The features will be evaluated and, if found suitable, included in planning.
    • Bugs will be delegated, (hopefully) reproduced and fixed, according to severity.

Working with the issues (features/bugs/tasks)

As we sit separately and work with the issues, there are some basic rules we need to adhere to, to not end up in a spaghetti a process.
  • When adding issue, make sure add task type and component. Now that we're working on Android and iPhone, and maybe WP7, we use the component information to sort between the different feature sets in the
  • If you ready to take on a new issue, let the rest of us know what issue you'd like to work on in discussions. If you have no preference, we'll find something for you to do. Not all issues might be ready to work on directly, so by getting this notice we get a chance to design and agree on the solution, before you start (make mock-ups or whatever). There are examples of such threads already in discussions. Furthermore, depending on the size and the complexity of the issue, we have to decide in which branch, you'll make your work.
  • When we have agreed upon the overall solution design and goal, you'll get explicit "go ahead". You'll assign the issue to yourself and move the issue from Proposed to Active. If we agree upon a feature branch, you can create one as well (see more below). Badabing, you're ready to go! :)
  • We plan our work in iterations, as described in Some sort of time plan. We work only with items in the "current" iteration. If we need more to do, we can move later planned work into to "current". (This is how we have overview on what has been made during a given period of time and what then can be tested).
  • Please be extra communicative - we work virtually with each other, and the only way to keep everyone up to date is to use Discussions and to have updated issues.

Working with the code

  • As we don't have to support many different versions of the app, the idea is to work with the code in the trunk.
  • We should be able to work side by side in the trunk, if we "slice" our issues well (no or little overlapping work).
  • If an issue is particularly large or complex, we might decide to spawn a feature branch for the work.
  • Before you start, please familiarize yourself with the code. If you have any questions, we're ready to answer them.
  • As of this time there are no explicit code guidelines. Please keep your code readable, simple and stable, and we go from there :)
  • All work need to have an issue associated to it. Write issue number in commit message when checking in.
  • Don't start working on an issue, and, even more important, check-in code to the trunk, that you haven't gotten explicit go ahead for.
  • We work after the basic "scout" principle of leaving a site in a better state than when we arrived. If you, while working on a feature, find some code that could need a bit of cleaning up, please feel free to do so. That way we'll keep our code from getting too smelly. You can do this as part of your feature development, and do not need to create a separate issue for this.
  • Major refactorings need, however, to be created as issues and managed as such.

Committing code

  • We work after the Copy-Modify-Merge model.
  • Before committing, please ensure that:
    • You have updated your local copy of the code with the latest version of the code in the trunk (handle any merge conflicts locally)
    • As we have no unit tests to help us keep the code stable (yet), you need to test the merged code with extra care.
    • When you have asserted that the code runs and is stable, you can commit the code to the repository.
  • Remember, do not commit code to the repository, without explicit go ahead (see the section above).
  • Remember to add the Issue Id to the commit message.
  • When the code has been committed
    • Add "How to test" information to the issue (makes the life of a tester much easier ;o)
    • Move the issue to Fixed state.

Last edited May 20, 2011 at 6:34 PM by christerdk, version 9

Comments

No comments yet.