Bug organization

From TAPASWiki

We are using Sourceforge's bug tracker for bugs on TAPAS. It was felt to be the reasonable, lightweight solution that fit our needs for this phase of the project.

We will use the bug tracking system in the following way (this is organized by the way Source Forge organizes its bug tracking solution). As always, we are taking a lightweight and flexible approach and will change things as needed.

Contents 1 Categories: 2 Assigned To: 3 Status: 4 Group: 5 Resolution:

Categories:

• These have been set up based on components of our system (PDA, server, conduit). We’ve broken down the development team essentially along the lines of the components. This seems easiest for our skills, resources, team organization etc.

Assigned To:

• The person that the bug has been tasked to. This should be the person perceived as being most effective in fixing the defect. Often, this person may have authored the corresponding code, but in other cases, this person may just have more time available. Therefore, please note Bug assignment is not equal to blame assignment.

If a user reports a bug and is not sure

• Assignment should not change unless necessary.
• Necessary changes to assignment include:
  • The person to whome this bug was assigned to has to time available to fix the bug.
  • The assignment was in error (eg a server bug was assigned a conduit bug)
  • The bug is found in another developer's code "domain" (i.e. changing the assignment based on a pending document / data should be avoided). Here are some situations with suggested resolutions:
  • If a bug is found in more than one person's domain, then a discussion should be had with that person and a second bug reported in that code.
  • If a bug is a mismatch between two approaches, then a solution should be decided on by the team and the bug assigned to the person responsible for fixing that bug.

Status:

• Developers are encourage to work with submitters to ensure bugs are worked out. Ideally submitters would close a bug once they have done the proper testing.
• However, developers CAN close the bugs once resolved. This is decided for a number of reasons:
  • There is QA time at the end of each cycle in the next year and bugs will be reviewed as part of that.
  • It may be unreasonable for a user (eg Physician) who might submit a bug to track it back and resolve it.
• It is expected that within our core development team, we'll be subscribed to the list and review any self submitted bugs as part of shared development culture on the project

Group:

• Groups will be used for the versions of the components.
  • v0.4.x describes bugs in the test code prior to release of version 0.5. Any bugs listed in 0.4.x need to be resolved for the 0.5 release.
  • v0.5 describes bugs found in the code of the first version that is used for NSMobile and includes Calendar, Messaging and the conduits. For version 0.5 the server is based on Plone.
  • 1.0 Describes the second version of the code based that includes the patient summary. It also migrates our server platform to JAVA 1.5.
• We’ll be targeting a different number for the next release and we’ll specify this shortly (and likely we’ll target a 1.0 release for March 31, 2006 - with a few steps in between).

Resolution:

• These can be used by the person assigned the bug and by the submitter.
• The bug list admin will not be checking on the bugs themselves, but will simply be OKing the posts, making sure they are not spam.