OpenLMIS Triaging

Owned by Mary Jo Kochendorfer (Deactivated)
Last updated: Nov 22, 2017
3 min read

The following proposal was drafted for the team's review. The final copy will be loaded to docs.openlmis.org.

Please leave comments if you have input/feedback.

Submitting an issue/bug related to an OpenLMIS Release Candidate

OpenLMIS release process is outlined http://docs.openlmis.org/en/latest/conventions/versioningReleasing.html#

Add information around notifying the community. Can point implementers to the manual test cases if they want to leverage. Assigning bugs to the appropriate epic.

Potential text:

  • OpenLMIS will alert the community via Slack and the listservs of an upcoming release and candidate. 
  • OpenLMIS will do a full regression on release candidates. The team will follow a detailed regression test plan for each release. An example test plan: 3.2.1 Regression Test Plan. Implementers are welcome to review and leverage OpenLMIS test cases.
  • Implementers are expected to follow the Implementation Release Process in testing the release candidate within the review period. If a bug is identified, implementers shall do a root cause analysis to ensure the bug is indeed a core bug versus any implementation specific components and code. If the bug is from the release candidate, implementers should submit a bug in the OpenLMIS Jira project and associate it to the Release Candidate Epic. For instance, the 3.2.1 Release Candidate is associated with this epic.

Updated the Review Period on ReadtheDocs on  .

Submitting an issue/bug to OpenLMIS

Current instructions are http://docs.openlmis.org/en/latest/contribute/contributionGuide.html?highlight=pull%20request#reporting-bugs

Potentially add information on how to watch/track issues. Make a diagram showing how a bug is first called 'roadmap' and is triaged within the sprint schedule (could be up to two weeks). Specifically state that implementers should view triage to make sure it is core bug. Do we need guidelines our gates for 'hot fix'? Add more on how to use labels (potential)

Potential text:

  • All bugs must be submitted to the OpenLMIS Jira project.
  • "Follow or watch the OLMIS ticket for updates on its status. Instructions on tracking issues: HERE."
  • Additional information: Implementer is responsible for informing implementation stakeholders team about the status of the bug.

Proposing or Implementing New Features in OpenLMIS

Update Coordinating with the Global Community to reference the new section on Proposing a new feature:  Updated  

http://docs.openlmis.org/en/latest/contribute/contributionGuide.html?highlight=pull%20request#contributing-code

  • Potentially add information on how to submit a 'new feature' ticket in JIRA. Be explicit about how to interact with Product Committee.
  • Potentially add more detail about the feature and technical proposal piece. Do we need to be explicit in how long it will take the community to respond or what the average length of time is?

Update the Coordinating with the Global Community Section with information on contributing features. https://github.com/OpenLMIS/openlmis-ref-distro/blob/master/docs/source/contribute/contributionGuide.md

Update Feature Roadmap, add the following text for SUGGESTING FEATURES:

Please follow these instruction if you want to suggest a new feature or if you'd like to develop a feature and contribute it back to OpenLMIS. The OpenLMIS Product community will review, provide feedback, and prioritize. If the work isn't funded, the Product Committee will attempt to identify resources to implement and bring to the attention of the Governance Committee. If this work is funded and done by external resources, the work can move forward with those resources.

  1. Create a "new feature" OpenLMIS Jira ticket. The default ticket status will be "Roadmap". Include the following information in the ticket:
    1. Summary: One line description of the feature
    2. Component/s: if you know which service is impacted by this feature, please include. If you do not know, leave it blank.
    3. Description: Include the user story and detailed description of the feature. Highlight the end user value. Include user steps and edge cases if applicable.
    4. Affects Version: leave blank
    5. Do we need to provide specific examples of how to create a Atlassian login, create a 'new feature' and example ticket/epic features??
  2. Send an email to the product committee listserv with the following information
    1. Jira ticket number (preferably linked)
    2. User story (using our personas)
    3. User impact (Does it improve usability? What currently is missing or not working?)
    4. Explain how the feature is global (and not project or implementation specific). Reference Global vs. Project-Specific Features for examples.
    5. Outline any time sensitivities so that the product committee can respond 
  3. Product committee will review the request in the upcoming meeting and provide feedback or request clarification. Once the feature request is understood, the Product Committee will evaluate the request and determine priority. If resourcing is available, the feature will be scheduled for work. The Product Committee will provide the following information back to the requestor:
    1. Update on review and evaluation
    2. Status of priority
    3. If scheduled, when it will be completed by
    4. Information on how to follow the progress
    5. Additional questions for clarity and understanding the feature

General Support

Are there specific pieces of information we want to make sure is available? 

Business development inquiries (more indepth and review of requirements)


OpenLMIS: the global initiative for powerful LMIS software