Using the Bug tracker and the bug tracking process

The following diagram depicts the Sahana bug resolution process

Bug trackers

The Sahana bug trackers uses Trac system to enter and manage the workflow for bug and enhancements resolution. The two trackers can be found at the following URLs

Bug Attributes

  • Reporter - The author of the ticket.
  • Type - The nature of the ticket (for example, defect or enhancement request)
  • Component - The project module or subsystem this ticket concerns.
  • Version - Version of the project that this ticket pertains to.
  • Keywords - Keywords that a ticket is marked with. Useful for searching and report generation.
  • Priority - The importance of this issue, ranging from trivial to blocker.
  • Milestone - When this issue should be resolved at the latest.
  • Assigned to/Owner - Principal person responsible for handling the issue.
  • Cc - A comma-separated list of other users or E-Mail addresses to notify. Note that this does not imply responsiblity or any other policy.
  • Resolution - Reason for why a ticket was closed. One of fixed, invalid, wontfix, duplicate, worksforme.
  • Status - What is the current status? One of new, assigned, closed, reopened.
  • Summary - A brief description summarizing the problem or issue.
  • Description - The body of the ticket. A good description should be specific, descriptive and to the point.

Bug Entry Template and Example

To better ensure that your bug report is not rejected (marked incomplete or invalid), please provide as much information for a developer to be able to reproduce the bug. The bug report should have:

  • Environment: Your system and browser version details and configuration
  • Steps: Exact steps required to reproduce bug
  • Expected result: What you expected to happen
  • actual result: What actually happened
  • Screenshot: A picture is worth a thousand words and serves also as confirmation of the validity of the bug

An example is given below:

IE browser-Version7.0.5730.13
Mozilla Firefox browser-Version2.0.0.1
Windows XP Professional version-2002 SP3

Steps to reproduce:
1) Go to following link & log into the system as admin user.
2) Click on ‘Volunteer Management’ module.
3) Click on ‘Management’.
4) Click on ‘Modify Abilities/Limitations’.
5) Select a skill from ‘Remove skills’.
6) Click on ‘Remove’ button.

Expected Result:
Message should be displayed indicating that the skill removed successful.

Actual Result:
User does not get an appropriate response and it is little bit messy to find
out whether the skill is removed properly when you have an enormous
number of skills.

We would like to suggest following as enhancement as well.

•‘Remove’ button should be disabled while a skill is not selected
from the ‘Remove skills’ and it should be enabled only when skill is selected.
•Message should be prompted similar to ‘Please select a skill to
remove’ when ‘Remove’ button is clicked without selecting a skill.


  • Anybody can access the bug tracker and submit bugs. When submitting bugs, the following properties are expected to be set by the submitter
   Status   --- Open
   Category --- Select the module which this bug belongs
   Group    --- Select the branch
   Comments --- Explain clearly how to recreate the bug
  • Bugs should ideally be tested as being 'current'. One easy way to do this is to use the online CVS demo. This is updated from the main CVS repository hourly.
  • Once the bug has been submitted the “bug marshals” (Isuru, Mahesh & Fran for this month) will check if they are valid bugs (e.g. feature requests get moved to that tracker) and if they are, will clarify them, prioritize them & assign them to the respective developer (see below). Bug marshals can also test user-submitted patches. Bug marshals can also assign to the current release's Bug Blockers list
  • Bugs' changes are notified automatically the Developer mailing list.
  • Developers are expected to access the tracker regularly. Bugs should be sorted by Priority to see which ones should be tackled 1st.
  • Once the bug is fixed the developer should change the status to 'Pending' and communicate the fix to the bug marshals.
  • Once the bug marshals has validated the fix (or else a reasonable amount of time has passed, e.g. 1 week) then they should close the bug.
  • If the bug marshals finds that a closed bug has been closed prematurely then the bug should be re-opened.

List of which modules are owned by which developers

  • Installer - Pradeeper
  • Framework - Chamindra (with Ravindra)
  • Security - Ravindra (with Chamindra)
  • ACL (Access Control, Security) - Ravindra
  • Catalog/Reporting - Sanjeewa
  • Disaster Victim registry - Isuru
  • HTML/CSS - Priyanga
  • Inventory Management system - Mahesh_kks
  • Localization - Prabath
  • Locations - Ravindra
  • Organisation registry - Ravindra
  • Messaging module - Sri Ganeshan
  • Missing Persons registry - Isuru
  • Reporting - Sanjeewa
  • Request Management system - Mahesh_kks
  • Shelter Registry - Mifan
  • Situation Mapping (GIS) - Mifan
  • Sync - Priyanga
  • Volunteer Co-ordination (old 'vol') - Ravindra
  • Volunteer Management (new 'vm') - Trishan
  • Portable App version - Chamindra
  • WAMP version - Chamindra
  • Debian package - Pradeeper
  • Redhat package - Pradeeper
  • Infrastructure - Pradeeper (with Chamindra)

QR Code
QR Code dev:bug_tracking_process (generated for current page)