@ibacher and I would like to propose we change the TAC name from:
“Technical Action Committee”
to
“Technical Architecture Committee”.
We think this is a better description both of what the TAC currently does, as well as how we want folks to be inspired to use that time/people/advice. Especially since the “action” part is predominantly handled by the Squad model.
This is not expected to change anything operationally about the TAC itself but hopefully will make it’s purpose and value more clear in the months ahead. E.g. we want folks considering major changes to the OMRS Core Domain / Data Model or a core module to see the TAC as a natural place where extra review can happen.
Thanks @grace for raising this! I just wanted to add some notes on the proposal from my perspective.
When we started the TAC, we chose “Action” (over “Advisory”) to emphasize that we want the committee to be responsible for real work, i.e., we do not want the TAC to become simply a “talking shop”. That very much remains a goal; the TAC should have real work and real responsibilities to the community.
Unfortunately, the role of the TAC seems to have remained unclear to many community members, including those of us who regularly attend the calls. I hope that switching from “Action” to “Architecture” to clarify this role. As @grace mentioned, the best pieces of work coming out of the TAC, including things like the design for queues, referral orders, the perennial discussions around date handling, etc., are precisely “architectural” concerns.
The idea of the committee remain the same: to provide technical advice to squads and community teams; to help us work from “We need feature X” into a clear notion of how we implement “feature X”, at least for those cases where the way forward isn’t clear; to help figure out how we coordinate complex technical work that we may want to undertake (can OpenMRS become a Spring Boot application?), and as a launching pad for new squads.
Hopefully, the proposed name change helps make the scope of the committee’s work more transparent to community members, so that the right people feel that it’s worthwhile to show-up. Of course, in keeping with the OpenMRS ethos, the “right people” are exactly those who want to participate or just listen in on those discussions.
The original intent was to have a “product committee” comprised of implementation and organizational leads (organizational leads, BAs, and not-necessarily technical people) reaching consensus on the path forward for OpenMRS and this “technical committee” comprised of technical leaders & decision makers across organizations coming to consensus on the technical approach to realize that vision.
