All OpenMRS ID accounts have been reset.

Read more and change your password before signing in.
Icon

EXTENDED: OMRS14 Proposals due 30 April! Read more and submit a proposal at OpenMRS Talk.

Skip to end of metadata
Go to start of metadata

Is it really a bug?

We appreciate your efforts to report a potential bug with OpenMRS. Before you do, please ask yourself the following:

  • Am I running the latest version of OpenMRS?
    • If I'm using an older version of OpenMRS, is my version still supported?
    • Check the Unsupported Releases (EOL) page to find out.
    • It's OK to report a bug in an older unsupported version, but it will not be fixed in that version. You'll need to upgrade.
  • Has the bug been reported already?
    • Search the various OpenMRS sites to see if anything similar has been reported or discussed in the past. You should also search for any specific error messages you are seeing, if applicable.

File a bug report

If you know the problem is related to the function or performance of a specific add-on module you're running, please consult the Module Repository and that module's documentation about how to get support. If you believe the problem is with OpenMRS itself, or if you're honestly not sure, you can file the bug report in the OpenMRS Trunk project in JIRA. You'll need to have an OpenMRS ID to do so.

Regardless of whether you're reporting the bug to the OpenMRS core team or to a module developer, to help those developers understand the problem, please include as much information as possible:

  1. A clear description of how to recreate the error, including any error messages shown.
  2. The version of OpenMRS you are using.
  3. The type and version of the database you are using, if known.
  4. If you are using any additional modules, custom templates, stylesheets, or messages, please list them.
  5. If applicable, please copy and paste the full Java stack trace.
  6. If you have already communicated with a developer about this issue, please provide their name.
Icon

We encourage you to use the method above to report bugs. However, if you are not comfortable creating a traditional bug report or are otherwise unable to do so, you may use our simple bug report form.

What happens next?

For OpenMRS bugs, our core development team will review your new bug report, attempt to verify it, and prioritize it. Once verified, they will be classified as "ready for work" at which point a developer can start working to resolve the issue. As the bug reporter, you will receive e-mail notifications from JIRA (unless you opt-out) with updates.

Once a developer has fixed the bug, it will be reviewed and tested, and included in an upcoming release of OpenMRS. You can follow the progress of the issue in the tracking system to determine what release fixes the bug.

How is priority determined?

We use the following definitions when prioritizing tickets:

  1. Blocker
    Blockers are issues that must be addressed before the milestone (or possibly development) can proceed. Blockers may delay all other issues, and it is worth assigning multiple developers to a blocker issue to get it resolved as quickly as possible.
  2. Must
    Critical issues must be addressed for their assigned milestone. Critical issues are those that have been attached to (and possibly help define) a particular milestone and the milestone should not proceed until they are addressed. If critical issues are falling behind, then we will direct resources to them as needed. Unresolved critical issues may delay a milestone.
  3. Should
    Major issues should be addressed for their assigned milestone; however, if resources are not available, then the issue may get moved to another milestone instead of delaying the assigned milestone. Unresolved major issues typically will not delay a milestone.
  4. Could
    Minor issues could be addressed for their assigned milestone, but only if resources permit. For major and minor releases of OpenMRS, we try to ensure that at least ten minor issues are being addressed if not many more. Unresolved minor issues will not delay a milestone.
  5. Non-essential
    Trivial issues are generally only assigned to a milestone if someone has volunteered the resources to move them along. Unresolved trivial issues will not delay a milestone.
  6. TBD
    To Be Determined issues have not yet been prioritized. This is the default prioritization for new issues until/unless the issue has been prioritized.
  • No labels