...
1.8 update:
Wyclif:
Set to have the beta 2 to release friday. Will not include the 'intitialization wizard database copier ticket'.
Darius: working on multi-column index ticket. Will not be in 1.8 but instead in a module that can be done at any point.
Roger: please explain the module decision
Darius: Having it in a module allows impl to run it at any time.
Roger: I proposed having it as a liquibase in main line with precondition that if they have less than X observations.
Roger and Darius will take discussion offline
Burke: Do we need an RC?
Ben: Yes, but only if there aren't any changes in the beta
1.9 planning:
Reviewing tickets on roadmap.openmrs.org:
Multiple tickets are partly done.
concept mapping will be finally discussed today
Burke dislikes the 'documentation of interaction points with ancillary systems' ticket.
Paul: This ticket is largely for documentation. Some code exists, some doesn't. This is mostly for things like 'I have a lab integration system, how would I integrate?'. Would be nice ot have a web page for that
Darius: this might involve some code being written.
Diptanu: I can help contribute to that document. We use openmrs and other systems
Burke: I want at least something on a wiki page instead of a bunch of points on a call that are lost.
Shaun: is this a list of 'you should do this this and this' or is it a best practices?
Burke: Its more of a pointer to people that have done things
Burke: there is not '1 hammer' to solve everyone's needs
Stanford Hack-a-thon
A handful of student hackers will be working on openmrs tickets for 24 hours straight this weekend.
We need people to help them on irc/forum, especially overnight on Saturday Feb 12th
Concept Mapping Updates
concept mapping improvements for 1.9
Andy: We also need a derived table for exploding children/grandchildren/etc for speed improvements
Burke: We can do that later potentially
Andy: But if it is not usable with the speed improvements, its useless
Roger: concept map type might not need to be a user defined table
Burke: openmrs does not want to be an ontology management system. modules can add their own types.
Darius: using a table adds a lot of complexity
Burke: fair enough, but we shouldn't assume that the values are in X enum and will never have more
Roger: what about the open archetypes standard
Carl: We're working on that and the occ integration to share concepts
Roger: Andy has mapped his concepts in a snomed way. Is this data strucutre sufficient to handle OSA model. If not, is it possible to make somethign to handle both
Burke: it'd be nice to let other systems do what they do best, openmrs can just provide the basics
Roger: can some of this be in core vs a module?
Andy: The relationship type of tables can probably be a module
Andy: There could be entries in the refernece_term table that are not mapped to a concept yet.
Roger: translations are not possible in the term table
Andy: we weren't looking to create a dynamic translator here
Andy: do we want a source column in the term_map table?
Glen: what if the terms in the term_map are for two different source?
Darius: just join to term to get the source
Andy: how to know which rows in termp_map to delete when doing an update?
Glen: do a pattern matching on ... ____
Darius: terms have a unique id. Do term_maps have a code?
Andy/Glen: Yes, they probably do
Andy: could add a 'external_code' column to term_map' (TODO)
Darius: How to work if we add locale to reference_term (TODO)
Darius: How does this work if term_map has a code? (TODO)
Ben: can we rename concept_map to something more in line with concept references
Burke: concept_map ⇒ concept_reference_map
Jer/Roger: need some documentation on how this works with concrete examples
Roger: Darius' weight example is a good one to use
The "patientmatching" module tickets
Shaun: James will not be able to do all of the tickets, especially UI.
Darius: send an email to dev list with the tickets and the potential work involved
Release Manager Responsibilities
Paul: Bump this to next week? Needs to be first on the list next week
Darius: 5 min overview:
1) RM is the one to push users to finish tickets
2) RM follows up on tickets telling Darius someone to work on them
3) Picking tickets that go in the release
4) Making wiki page for release
5) Doing the release (packaging, etc)
Burke: how much time is involved (full time, part time, no time)
Paul: wants more of a wording on the page like 'just do this, its not hard, we'll help you"
Diptanu: is information available online? or on the ticket?
Ben: The wiki only has minor documentation
Darius: can demo what's been added to the logic module
Outcomes
| Tasklist | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name|| |
...