Engineering Lead

Owned by Paul Biondich
Last updated: Jan 17, 2014 by Burke MamlinVersion comment
3 min read

Contact Information


Burke Mamlin

Email:  burke@openmrs.org
Phone:  +1-317-274-9191
Twitter: @ekrub
IRC: burke
Blog: http://blog.burkeware.com/

Office Hours:  Mondays 10-11am US/Eastern

Description

The Engineering Lead is an individual who oversees and operationalizes the OpenMRS community software development process.  This person has the requisite leadership skills to turn community feature requests (represented in the software development roadmap)  into specific community design and development activities.  He or she does this in a way that is architecturally robust and reusable.

Responsibilities

  • Establishes community culture around software engineering process:  “each OpenMRS developer should feel like they are the center of the universe”.
  • Oversees process to convert developer volunteer interest into routinely active contribution
  • Arbitrates the OpenMRS open source development process
    • Ensures that the development roadmap is realized in a timely, responsive fashion in the form of new, implementable releases of the platform
    • Ensures that the OpenMRS platform is adapting to community needs over time in close collaboration with community leadership
    • Identifying key modules/features of OpenMRS requiring support/integration
    • Ensures a sustainable architecture for the OpenMRS platform and core applications
    • Participates in most development, design, and project management calls
  • Fulfilling the development road map laid out by the community.
  • Ensures that the developer community is participating in the road map planning process, representing developer needs & contributing technical expertise and scoping to road map planning decisions.
  • Ensuring appropriate management/oversight of full-time OpenMRS (e.g., seconded) developers

2014 Engineering Goals

Process & Roles

  • Engineering roles refined
    • Rotating manager in place
    • Make sure people are working within their roles
  • Process defined for prioritizing available community development
  • Process defined for queuing work for community development
  • Continuous deployment advances
    • Lights stay green – e.g., process for handling red lights defined & understood by community
    • At least two sizes of deployments in test harness (small & big)

Developer Experience

  • SDK used by most developers (new & experienced)
    • SDK working with OpenMRS 2.0
  • Attribution in nightly builds – i.e., automated attribution
  • Exploring metrics of developer experience (recognizing when someone is making significant contributions, devs are being lost, etc.)

Software Development

  • OpenMRS Platform 1.11 release (with all the changes that were previously done for 1.10)
  • OpenMRS 2.1 defined and released
  • Shift to MariaDB as default engine
  • We finally get a new module repository

2013 Engineering Goals

Process & Roles

  • Roles Defined (documentation of expectations, requirements, ...) 

    Target: roles documented by end of Q2 2013

  • Implementations noticeably more involved in development

    Targets:

    • At least 25% of scrums involve a product owner who is an implementer
    • Feedback from implementation scrums demonstrates that implementations are now seeing OpenMRS involvement as a good ROI

  • Tangible maturation of our continuous deployment practices.

    Targets:

    • TODO: summarize targets from CDI maturity model exercise

Developer Experience

  • The birth of a developer SDK by Q4 2013
  • Improved developer documentation by Q3 2013
    • A developer guide (soup-to-nuts technical introduction)
    • An API reference guide (e.g., singe-page HTML "OpenMRS Developer Reference Guide")

Software Development

  • Fulfill the 2013 technical road map. :-)
  • First release of the OpenMRS Reference Application – OpenMRS 2.0 – at Implementers Meeting 2013
  • At least one minor release

Requirements

  • Infrastructure support (wiki, ticket tracker, continuous integration, mailing lists, …)
  • At least 5 FTE of dedicated OpenMRS Developers that can be held accountable to oversee development (code review, provide development leadership for sprints, training activities, etc.)
  • At least 1 FTE of dedicated OpenMRS Documentation support that can be held accountable to ensure that technical documentation is progressing & sustained.
  • At least 30% protected time
  • Project management support (BAs coordinating/leading scrums, managing agenda, keeping minutes, ...)

Not Responsible for...

  • Maintaining roadmap and coordinating discussions with stakeholders around it (this should be in the purview of community leaders)