User Stories & Functionality

Owned by Elliott Williams
Last updated: Jan 22, 2014
2 min read

The module repository should adapt to the needs of different users interacting with it. This page attempts to define those types of users, write a basic user story for each, and design functions of the module repository to address their needs. This page should help write a more-complete spec of the modrepo in the future.

Feel free to add / comment / iterate on this list.

Module Developer

"As a module developer, I want the repository to require little extra work from me to publish my module, so that I can focus on developing my module, not publishing it. I want the repository to provide resources for feedback, support, and compatibility, so that I can better serve users of my module and can reduce direct support inquiries."

  • Maven script to publish module: mvn publish or similar.

  • All modrepo metadata found in an omod.json file...only one additional file has to be written to support publishing.

  • Module repository site facilitates feedback through stars, comments, relevant wiki pages, and support inquiry contacts.

  • Continuous Integration testing will help verify compatibility with other modules and will form a version compatibility matrix.

Implementer

"As an implementer, I want to easily discover modules so that I know what functionality is available for my implementation---this includes detailed information on what the module actually does. Since I'm not experienced with Java or Maven, I don't want to have to worry about dependencies or conflicts between modules. I only want to see modules that will work on my current version of OpenMRS, and I want those modules to be verified to work."

  • Module Repository can be browsed from within the OpenMRS admin interface, only allowing installation of compatible modules.

  • One-click install from the admin panel or the website simplifies the installation procedure.

  • The modrepo provides screenshots and plenty of space for an extended description or Readme file.

  • Modules pass their tests before being published. If a module introduces instabilities, it's flagged as unstable in the repo.

System Administrator

"As a system administrator, I want module management and structure to remain that same, so that I don't have to re-learn how to manage my implementation's module. I need to manage custom modules with modules from the community repo, so that we can implement functionality supported by the OpenMRS community as well as our own in-house modules."

  • Despite changes to the module infrastructure, OMOD files can still be uploaded into the app path like they've always been.

  • Module package lists can be written, allowing the sysadmin to easily pull multiple modules from the repo to a new instance of OpenMRS.

  • Any organization can host their own (private) module repository that the OpenMRS can talk to. This allows them to take advantage of new functionalities, like auto-updating and dependency management, without having to release in-house modules to the global community.