How to Join

Click here to expand...

Agenda

Attendees:

OMRS Developer Forum 20141023

Lead presenter : Agustine Miencha

Time: 5:00pm - 6:00pm EAT

Topic : How to improve developer documentation so that it's easily understood by implementers

Participants: AMPATH Informatics Team

Gathered contributions :

Help better the documentation on system and module changes.This will help users to quickly familiarize at a glance with: changes and configuration related issues.

Help to create documentation that sensitize implementers on benefits of upgrading so they can make informed decisions before moving to newer versions of the system. This will be helpful to inform the needs of upgrading rather than just upgrade because support for lower versions will degrade or will be minimal overtime.

Having detailed documentation about new features and capabilities for implementing certain version of OMRS with pros and cons clearly outlined, will help guide upgrade decision making.

Create a page to document user experience using certain versions of OMRS and Modules. If possible start a wiki page with generic versions of OMRS/Modules (1.6, 1.7.1.8,1.9,1.10, 2.0..../OMOD 0.01….) to help document user experience. A template to guide on what should be shared within this page will be helpful so that implementers can help share experience. It should not matter how large or small your database one is using , sharing the experience will help others who would like to upgrade to review and plan better and also add details of their experience. We think this will benefit everyone in the community.

Improve or include the documentation for customized modules used within OMRS i.e. HTML extension

Update the documentation on modules per improved version of OMRS. Example for HTML form entry, it will be helpful to have information on which version is compatible with what version of OMRS. This stopped at some point.

Include documentation on basic infrastructure requirements to implement versions of OMRS and Modules.

TODOs:

Identify which module(s) are demonstrating best practice
Wyclif Luyima – Make an easy-to-read (1-page) description of best practices for module authors to follow – e.g., for each release, list (1) new features, (2) major bug fixes, (3) data model changes, (4) any other things an implementer might need to know if upgrading to that version, and (5) list of tickets included in the new version. Link to core release notes & a module or two that are examples of best practices.
After making the page, email a link to the implementers list and ask for feedback/edits
Sara Armson – Make it clear to implementers (on intro wiki pages for implementers) where to go when they do not find release note information – e.g., comment on release notes page, start a topic in OpenMRS Talk, or email implementers list.
Burke Mamlin – Get updates to Modulus on OpenMRS Technical Road Map – specifically, ability for implementer to enter comment on module and ability to rate module.
Sara Armson – Email implementers list to let them know that we have weekly space for classroom time called "OpenMRS University" on Wednesdays at 9am US/Eastern, but we have fallen into a use-as-needed for it because of lack of interest/attendance. If implementers ask for specific training (e.g., "How to deploy OpenMRS x.x" and "How to deploy version X of module Y"). These would be good topics for OpenMRS University (our "classroom") http://om.rs/u

Audio recording of the call: Listen online or download (available after the meeting)