2014-10-02 Developers Forum
Owned by Jamie Thomas
How to Join
Click here to expand...
Agenda
- Quickly review previous meeting minutes (5 min)
- WIP from Bahmni update on work their doing on top of the new order entry API in 1.10, WIP from Sara and ThoughtWorks on Concept Management Module
- QA (how can we get better, next steps for testing releases)
- Suggestions for modules that need development attention based on their usage (Suranga)
- Review next meeting agenda
Minutes
Developers Forum 2014-10-02
Attendees
- Michael Downey
- Suranga-ack
- Darius Jazayeri
- Sara Armson
- Willa
- Ryan Yates
- Wyclif Luyima
- Sri Maurya Kummamuru
- Quiet, mumbling people (Who is this? :-))
- Mike Seaton
- Daniel Kayiwa
- Nyoman Ribeka
- Jan Flowers
Agenda & Notes
- Review last week's outstanding TODO's (Content modules)
- TODO: Burke to schedule a dev forum to revisit future release process/scheduling/strategy
- (deferred)
TODO:Someoneto schedule next round of Allergies tasks (don't drop the ball -Darius)
- Scheduling less important than not forgetting that this comes next
TODO: Sarawill email TW & Bhamni team to ask for which week later in October works and we'll swap topics
- November 13th, 2014-- confirmed
- TODO: Someone to get KenyaEMR team to describe how bundles are delivered
- Suranga will e-mail dev@ list calling attention to Steven Wanyee et al.
- How are they packaged (do they have to be baked into core applicationContext? Delivered via module?)
- What infrastructure changes exist to incorporate the bundle
- TODO: Someone to schedule design call(s) on how 2.x UI should handle the bundled content and including programs
- QA (how can we get better, next steps for testing releases)
- Pending: Jan will arrive sometime after :30 after the hour - arrived, but topic not able to be discussed today, will follow up via email to start discussion and schedule for a dev call
- Suggestions for modules that need development attention based on their usage AKA "How not to ignore (good / any) work when / where it happens
- 1) Conventions
- Whats our existing approach to figuring out which modules will be supported by the core team ?
- Downey: Suggestion of different terms compared to above link. "OpenMRS-maintained" vs "3rd-party".
- New Modules directory terminology: "Owner" is the lead dev or org that "owns" the copyright and is responsible for the module. "Maintainer(s)" are individuals who have access to release/update the module and people who are generally working on it.
- Example: Dispensing module that PIH owns, and is using specifically for its Mirebalais site. PIH might be willing for "someone" to fork it and make it more generalizable.
- How do we manage upgrading them (do they all get some love whenever a new release of OMRS is made ?
- How often do we revise our list of core supported modules ? do we even have one ?
- How do we manage module ownership ? especially in the case of it being maintained by implementers, who may be too busy to figure things out ?
- Some modules have an active maintainer(s) who cares for keeping the module up-to-date, organizing bug reports, issues, new features, etc.
- Examples of above: XForms module (Daniel Kayiwa), Reporting module (Mike Seaton), others.
- Some modules HAD an active maintainer but that person may either be (a) no longer actively maintaining it, and/or (b) is no longer really around the project. Example: Metadata Sharing module (Rafal)?
- IDgen module: Mike Seaton originally wrote it, is probably usually listed as the maintainer, but others (Mark, Darius, etc.) are actually doing maintenance on it. Mike "may or may not" (but really, he does!) really want to maintain the module.
- 2) How do users find out about modules developed by other implementing orgs, and manintained elsewhere ?
- Do they just browse github, or ?
- Word of mouth ?
- Is there a centralized list of informaton ?
- We do have wiki pages for some modules on wiki.openmrs.org, but not all of them.
- We do have issue trackers for some modules on issues.openmrs.org, but not all of them, either.
- modules.openmrs.org is the most "official" directory of module "advertising". We can't really enforce people to use our issue trackers, our wiki, etc. But at least we *can* enforce them to provide some metadata like support links, etc.
- What happens when we want to develop an idea, and need to figue out what work has been done in the past ?
- What happens when the original owners are missing but the community wants to move it forward?
- Two scenarios usually happen in other FOSS projects: (a) the owner transfers ownership to someone (or some org) else, or (b) the "thing" is forked and a new version carried forward and advertised as the improved version.
- FYI: GNOME often has this same problem with lack of active ownership and maintainers, and often has higher user/customer demand for improvements than people to work on the app. https://wiki.gnome.org/Apps
- Do we need a gardening team ?
- Somewhere between *product* managers & project managers (closer to product managers)
- These people would need to understand high-value & high-demand needs (modules) and "fairly" balance the various interests throughout the community
- They'd need to do some curation and identification (through communication) across projects/modules, and then roll that up into one master list
- This is probably going to be rather subjective:
- All OpenMRS installations are not created equal (in terms of impact, size, scope, etc.)
- Some modules have more strategic importance in the products we ship (bundled)
- Need to be close to the Guides team to identify newcomer contributors able & willing to work on module projects
- TODO: Suranga to start an OpenMRS Talk/dev@ list notification to further develop the roles of the "gardening" team.
- TODO: Jan to update the dev@ list thread about re-scheduling the QA topic and starting
After action review
Cancelled due to lack of interest in reviewing ourselves
What did you expect to happen?
What actually happened?
What can we do better?
- Preview next week
- Burke will be back & things will be "normal". (??)
- Order Entry, round 2: Order Sets, Templates, and Order Groups (to kick off a series of design calls on this topic)
TODOs
Transcripts
- Audio recording of the call: Listen online or download (available after the meeting)