Technical Action Committee Updates and Discussion

Last week, the Technical Action Committee had a kickoff meeting. Most of the discussion focused on reviewing roles and responsibilities, discussing the differences between the Product Change Committee and the Technical Action Committee, and sharing initial ideas around what the TAC should focus on for the next couple of months.

Here are some of the points that came up during the meeting, some of which are similar to recent discussions that the PCC have had:

  • Important to have countries and implementations represented on the PCC so that the product responds to on the ground needs
  • Interested in having a roadmap that is grounded in what is feasible, what we know we can do now (i.e: in the next 3-6 months)
  • TAC can help identify what modules are used in the ecosystem that can be leveraged by others
  • TAC can determine the technical direction/approaches to invest in and what will help us get there (Microfrontends, being RESTful, moving away from server side, how OpenMRS can work at scale and how we get there, etc)
  • TAC could come up with its own set of priorities for the next few months that can be shared with the PCC to inform a roadmap.

You can find the notes and a link to the recording here.

During last week’s PCC meeting, questions came up about Sync 2.0, FHIR, and OCL for OpenMRS: where do these currently stand? What is next? These seemed to the PCC like questions that fall under the TAC’s purview.

The TAC did not set a weekly time to meet and instead decided to circulate a Doodle poll to help arrive at a time. I encourage everyone who is interested in participating in these discussions to take a Doodle poll. Special note: the time options displayed on the Doodle poll should be: 4pm EAT | 1pm UTC | 9am EDT | 6am PDT or 5pm EAT | 1pm UTC | 10am EDT | 7am PDT.

With Daylight Savings Time starting again in a couple of weeks, I’ll set one time for the coming two weeks and we can confirm how to handle the DST change at the next meeting.

@burke @ningosi @ssmusoke @mksd @jdick @mseaton @mogoodrich @dkayiwa @isears @angshuonline

1 Like

Thanks @jennifer! Sorry I missed this the first time.

I replied to the poll and will get this on my calendar. My schedule is pretty crazy these days, so I’m not sure how many standing meetings I can fit in my calendar, but it sounds like I may way to prioritize this one over the FHIR squad.

Take care, Mark

1 Like

Sorry @jennifer - caught this late. I can only make it next week. I replied to the poll, although the times are 30 mins off for me.

1 Like

Thanks @mogoodrich and @angshuonline! This is why we have dates further out. :slight_smile:

Right now, it looks like Wednesday, October 30 at 6:30pm IST | 4pm EAT | 1pm UTC | 9am EDT | 6am PDT works for those who responded.

Thanks, works for me!

Bringing in updates from other threads so they are all in one place…

2019-10-30 Key Points and Decisions

  • The TAC provides our technical direction and strategy. We want make our technical vision explicit and get alignment on our technical challenges and priorities.
  • It’s important for the TAC and the PCC to have intentional opportunities to work together. We need to figure out when and where to make this happen.
  • The TAC should also make sure that the platform is maintained and up to date. We acknowledged that we face a chicken/egg dilemma: we want and need resources to get work done - and we need to know what work needs to be done in order to allocate resources to work that is actually needed by implementations.
  • Listing out what needs to be done is not going to help with alignment unless we know what our objectives are, what our technical direction and strategy is. Otherwise, we’re simply creating a list and people end up working on tickets or modules that are outdated while current work that would benefit many in the community languishes.
  • As a result, we spent 20 minutes brainstorming potential objectives. These need to be fleshed out.

Action Items

  • Put the rough objectives into a Google document
  • Turn the list of ideas into real objectives (@mogoodrich offered to help me with this, others are welcome to pitch in)

We also:

  • Confirmed our weekly meeting time since Daylight Saving Time starts this weekend. This is what the new times would look like: 7:30pm IST | 5pm Nairobi | 4pm Cape Town | 2pm UTC | 9am Boston | 6am Seattle
  • Figured out where and how we want to communicate on a daily/weekly basis: Dedicated Talk thread for now.

Notes: https://notes.openmrs.org/2019-10-30-Technical-Action-Committee

Click here for the recording.

2019-11-06 Key discussion/decisions

  • Recruiting technical leadership is more of a means to an end. Our objective is to make sure we actively build technical leadership to advance the platform and ecosystem
  • Recruitment is really an Operations thing - this committee (and the PCC) should inform Operations of their needs related to technical leadership to Operations
  • Another important objective focuses on recommended/endorsed technologies for the community
  • Added another objective that focuses on making OpenMRS implementation easier in different contexts - and the six different focus areas fall under this:
    • Improving configurability by end users
    • Easing deployment and upgrade paths
    • Increasing modularity and Improving development experience
    • Integration, interoperability and data sharing
    • Improve metadata management
    • Making sure the platform is stable (and stays stable)
  • Ideas for OMRS19
    • Hackathon focused on microfrontends + FHIR
    • Propose objectives/focus areas as unconference session
    • Friday session summarizes input
    • Use this as a leading session and then regroup

Action Items:

  • Add more feedback on the document
  • Take this and see if we can map this with the PCC needs - Mark has some thoughts about this
  • What objective/technical focus area will have the most impact/value for the community
  • Questions from the community and PCC about Sync 2.0, FHIR, and OCL for OpenMRS

Notes: https://notes.openmrs.org/2019-11-06-Technical-Action-Committee

Click here for the recording.

Happy New Year, everyone!

Based on discussions in Maputo, we’re changing the TAC’s meeting time as we’ll be spending this month fleshing out the technical vision @burke talked about in Maputo.

According to December’s Doodle poll, Wednesdays are out and Fridays might be in - at 7:30pm IST | 5pm Nairobi | 4pm Cape Town | 2pm UTC | 9am Boston | 6am Seattle. That said, Doodle’s time zones have had a mind of their own recently, so please confirm your availability or take the poll if you haven’t already. @burke @mseaton @mksd @dkayiwa

Hi @jennifer, happy new year!

This Doodle is for Monday only, I can only do Fridays with certainty.

Fridays are typically a good day for me to meet. I think we will need to update that Doodle Poll you linked to with some additional options if it is to be useful (at least it doesn’t show very many options to me any more).

Friday’s also work for me, but Monday’s I have too many standing meetings to attend another one.

Yes, the doodle pool is currently only showing me two time slots (both on Monday) as options…

Oh Doodle! I re-set the poll with times on Monday, Wednesday, Thursday, and Friday, so please use the link below and not the previous ones. I didn’t change the dates since we’re trying to find a recurring day + time.

Thanks for all of the feedback, everyone! The earlier time on Friday won’t work for @burke and also conflicts with monthly Bahmni Governing Committee meetings. :slight_smile:

Can we try Fridays at 8:30pm IST | 6pm Nairobi | 5pm Cape Town | 3pm UTC | 10am EST | 7am PST?

Is this UTC-based – i.e., during daylight savings time from March to November it would be Fridays at 8:30pm IST | 6pm Nairobi | 5pm Cape Town | 3pm UTC | 11am EDT | 8am PDT?

That could work for me, except that it’s not what the Doodle shows.

This works for me

Here are some of the key points and decisions from last week’s TAC/PCC call:

  • This meeting is now a joint meeting of the TAC and the PCC, so we should expect there to be some tension between product and technical - this is good!

  • Being on the same page about where we’re headed and what near term wins are is as important as having a core group of developers

  • We expect this group to:

    • Have a shared vision for community development
    • Connect directly with implementations and understand why certain work is being prioritized
    • Track, understand, and respond to what is “hot” in the community
    • Ensure decisions get made when a specific decision is a blocker for the community
  • Known needs may not be at the forefront of developers/implementer’s minds (maintenance, performance, reliability, etc)

  • We are custodians of the shared community artifacts, which comprises the Platform, the Ref App, Microfrontends, and integrated components (like ETL)

We’re still committed to make sure that each meeting moves towards action and that work to be done in between meetings is specific and clear.

For more details, read the notes or listen to the recording.

During our Technical Action Committee (TAC) kickoff meetings, @mseaton asked the perfect question:

What are we doing?

This wasn’t just a the right question for the TAC group; it’s a great question for OpenMRS. With a growing community, expanding opportunities, constrained resources, an aging codebase, and a variety of incompatible frontends, it’s more important than ever for us to have a shared vision of what we are doing.

We started out by enumerating potential areas of focus for TAC:

  • Platform maintenance (Library updates, Performance issues, Memory leaks, Security)
  • API curation (REST documentation, FHIR API, Road Map for API)
  • Architecture (Microservices, Cloud support, CDS, Switching to PostgreSQL, Forms support)
  • Vertical solutions (HIV, TB, NCD, Maternal Child Health, Retrospective data entry, …)
  • Mobile OpenMRS (Android & iOS clients, progressive web applications)
  • Integration (OCL, SMS, Lab, Pharmacy, Inventory, HR, DHIS2, smart devices, …)
  • UI Strategy (Web Framework 3.0 road map, migrating from OWAs, UX design framework, patient-facing UIs)
  • Reporting (ETL)
  • Community tooling (SDK, migration to OpenMRS, or between OpenMRS versions, packaging artifacts, Docker images)
  • Strategic Decisions (EMR platform/middleware vs “full” EMR, harvesting from existing efforts)

Early goals for TAC will be to refine this list and prioritize some areas for which we can produce artifacts (Talk posts, blog posts, white papers, or project plans) that the community can use to align our efforts.


For more details, read the notes or listen to the recording.

1 Like

We came out of Friday’s discussion with some action items to help decide what we should focus on:

  • @mksd created a survey for ranking the items that were identified at last week’s meeting (see @burke’s post above). Already done!
  • @ibacher @mseaton @dkayiwa committed to filling this out by next Friday, February 7.
  • I agreed to send out this out to a few people who couldn’t make it, like @burke, @mogoodrich, and @jdick. I’ll also aim to send reminders every other day.

@mogoodrich raised some questions about oversight of what goes into the Ref App + Platform and how we maintain our technical products. The good news is that we’re in the process of filling the TPM position - and we recognize that there are still some resource gaps that we need to figure out how to address. We decided to tackle some of these questions on a future call.

Here’s a link to the notes and the recording.