Skip to end of metadata
Go to start of metadata

Roles 0.01 Draft

 

  • No labels

10 Comments

  1. If I am responsible for engineering quality assurance, I can't assure very much quality. (wink) 

  2. I think most documentation would fall under Software Engineering. As for reporting, I think this falls under both Research and Content (since the report definitions themselves might be considered content but the purpose of the report is more related to use-case/outward facing relationship)

  3. As discussed on the call, I think it is important to have the office of the executive director represented as a box so that we can include the various functions that fall under that role and complete the picture in terms of a functioning organization. The typical role boxes could include resource mobilisation, strategy and operations, stakeholder relations and outreach, finance, admin, legal, public relations, ex officio on Board etc. (all the tasks Paul is mostly doing, already!)

    Under software engineering, it may be an idea to have additional roles for linking to other software (not sure this is the correct name) e.g. DHIS, Mobile apps etc). This would entail working with other open source software organisations who want to link directly to OpenMRS to spec this out and move it through he development process. Perhaps having this role would have meant having the DHIS2 link sooner? 

    I am not sure documentation fits with the other two roles under content development, but also not sure where else to put it, unless a box of its own. It could be a big piece if done properly? 

  4. At OpenMRS Camp14 we talked about the creation of a Software Testing Lea. Where will that role go?

     

    1. Hi Jamie Thomas ...  That's probably the yellow box under engineering assigned to "Joseph Schnogenlocker". 

  5. I see my name in a "Peer FOSS" section, under OpenELIS. I'd like to encourage some "growing together" of O/S in the lab space, and having OpenMRS reach out to the lab community, rather than to just one project, might be a nudge in that direction. 3 systems I can think of are: OpenELIS, BLIS, and Bika, and there may be others still on the "active list". Second thought, maybe Jan would be a better LIS representative than I would. Good thing to discuss next week?


    Also, I might be a good liaison to either academia (though of course a number of us are academics), and/or to CDC/DGHA - I'm certainly not unique in having colleagues on the federal side, but I could ask Xen if he'd like me to make that role more explicitly part of my work with their group.

    my other thought, Paul, interesting that (as is often the case) the technical roles are best defined, best filled out, best specified. I wonder if instead of the FOSS Peer liaisons, we should consider liaisons to groups working in strategically important areas with which OpenMRS data, OpenMRS software, and OpenMRS organization should interact. Instead of "DHIS/HISP", it would be "DHIS/HISP plus other M&E, Population Health interfaces". Instead of "OpenELIS" it would be "LIS: OpenELIS, BLIS, Bika, ..." Etc. Ditto Pharm. Ditto Logistics. My thought is that the mission would be a little more like keeping up with what's going on in an area and thinking about strategies and partners, rather than focusing only on one relationship. In some areas, DHIS, there probably is only one relationship, but there might be value in how it's labelled.

  6. Within Software Engineering, I could imagine things like:

    • Technical Architecture and Strategy (technical "big picture")
    • Platform (API, web services)
    • Application (OpenMRS, Reference Application)
    • Quality Assurance (making other dev teams better at testing/quality)
    • Infrastructure Development (modulus, atlas website, SDK, ...)
    • Community Developer Swim Lane (developers growing their numbers)

    Some of these could cut across other groups, but these groupings are meant to focus on the technical, developer-focused roles.

  7. To summarize my comments on the call - within partnerships, could think of relationships to Projects, Development Groups, or Sectors (eg., M&E/Population Health, Lab Info Systems, Pharm, Logistics).  

    While I don't like the term "Sectors", I do like that concept better than the other two, though Development Groups might need to be an exception in some cases - where a group works across several sectors/domains, for instance.

    The partnership people would be the point of contact for those from different areas, if they had no place else to start with the community, but they would also have some responsibility for knowing who the participants were in a domain, and perhaps for reaching out to them periodically.

      1. I like "domains"

        the software expression is "systems".  The interoperability expression is "interfaces". The data expressions might be "domains".  The organizational expression is "projects".  I think domains is loose enough to account for all of them.

        the liaison to the lab domain would be a point of contact for LIS developers, would know a little bit about the FOSS (and perhaps other) systems in use, would perhaps loosely track LIS projects and implementations and perhaps reach out to those projects when when appropriate, and would understand (and perhaps drive) OpenMRS' interface strategy to data in those domains.

        Again, I see some domains of interest as

        1. M&E/Pop Health/Aggregate Data Reporting (knowing there is some overlap w/ OpenMRS capabilities, but also knowing that there are systems out there which address this domain)
        2. LIS
        3. Pharm
        4. Logistics (not completely indepenent of Pharm, once we scratch beneath the surface, but not exactly the same thing.  Maybe one person for both until we better understand the issue)
        5. ...

        And, domain partnerships are not the only important partnerships.