Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

This page describes the proposed process for tracking openIMIS issues. This process is divided into two parts:

  • Capture issues and requests from users and the wider community through a dedicated portal (service desk)
  • Log and track software development issues

The openIMIS Service Desk Report provides realtime insights on the current issues. 

The following diagram present our issue tracking process. Please scroll down for explanations. 

Service desk

The service desk is the entry point for general questions and requests on openIMIS. 

1. Making a request

Any "customer" can access the openIMIS portal in order to submit a request. One can also register (by providing an email and password) to this service desk, in order to follow his/her request in a more personalised manner.
The customer is prompted with matching requests found the openIMIS knowledge base. If there isn't any satisfying match, the customer should raise one of the following request:

  • Question about openIMIS
  • Report a bug
  • Request a new feature

2. Handling the request

The dedicated Service Desk Team receives all requests sent by customers via an admin portal (not visible publicly). The role of this team is to sort, assign, categorise, and act on the request in order to provide support to the customer. The team is composed of agents.
The process is as follows:

  • Any new request comes in with the status "Waiting for support".
  • An agent for the service desk picks up the new request and assigns it to a member of the team. 
  • The assignee can then act on the request in different ways:
    • if more clarification is needed about the request -> send a response to the customer -> set request status to "Waiting for customer".
    • if it can be fulfilled by the agent -> send a response to the customer -> set request status to "Resolved".
    • if it is a request for a new feature -> send a response to the customer -> set request status to "Pending" until it is assessed by openIMIS Implementer Committee, Developer Committee and Coordination Desk (Steering Group and TAG might also be implicated).
    • if it is a bug (or an approved request for a new feature) -> send a response to the customer -> set request status to "In progress" -> create a linked issue in the Software development issues tracking project.

Software development issues tracking

1. Raising an issue

Issues that require software development can be raised in different ways:

  • For the general public, all issues must come through the openIMIS service desk (as described in the above section).
    • If a bug was raised, the service desk agent create one (or more) linked issues in the software development issue queue to define technical work to be done (The linked issue(s) are visible in the original request, for the customer to follow up). This issue will remain in the backlog until it is prioritised by the Developers Committee.
    • If a request for change was made and approved in the service desk, the service desk agent then links it to the the software development issue queue (as defined above for the case of a bug).
  • For developers in the community, anyone can create an issue in the queue. This issue will remain in the backlog until it is prioritised by the Developers Committee.

2. Acting on the issue

To begin with, all created issues are staged in a backlog. The Developers Committee then decides to allocate issues in "Sprints". Currently, the development methodology is not agile-based, so sprints are not used in an agile way. Instead, sprints will be used to define a time window to accomplish the work needed for a given release.
Developers and other technical users can then move issues to different status as work progresses via a board:

  • To do: a developer needs to be assigned or take up this issue
  • In development: the developer is currently working on this issue
  • In testing: the work related to this issue is completed, and testing can start
  • Done: once testing is signed off, this work is considered as done and will be reflected in the next code release (and the original requestor will be notified automatically).


References:




  • No labels