The technical committee's purpose is to "build the product the right way". This group meets regularly to address issues of:
Overall system architecture
Setting clear standards for code quality, contributions and feature performance
Encouraging contributions and evaluating contribution maturity
Technical review of proposed features
Determines which features and code are allowed into the global product
Providing infrastructure (forums, CI, CD, etc) to enable community discussions and contribution review
Owns the OpenLMIS GitHub repository, common branch management and release cycle
Responsive to community input; collaborates with other OpenLMIS committees
This group will regularly review its membership criteria:
Senior level developer/architect
Experience with OpenLMIS (1+ year)
Active/ongoing engagement in OpenLMIS
Technical Committee Open Questions List:
Open Question
Answer
Those Present
Decision Date
How we tag stable releases. What is the period? Time based or feature based?
When is a module “mature” enough to be included in a release.
What is the SDLC for OpenLMIS?
What is the contribution methodology?
What documentation does the technical community want (about the code, architecture, etc.)?
What documentation should come out of an implementation?
Do we call (not which is it) OpenLMIS a product or a platform or something else?
What are the 5 things that make you glow about this product? Everyone should make this list and then we consolidate for the community. Different use cases, value proposition. Can be leveraged for messaging
Technical re-arch follow-ups • Need "contribute back" process (coming in further sessions) • Need DB update strategy • Reporting is a perennial need and request from ministries. Need a solid reporting solution • Need to define extension points for processes like R&R
What is a preferred/good way to implement SSO? Does HIE recommend anything?
What are migration/upgrade paths, even if we completely rewrote the application?
Discussion, what module or feature can we rearchitect as a vertical slice? • Notifications (existing email and SMS) is a candidate, may be lacking in "domain". • Reporting module: a rewrite could be advantageous (but does that hit problems like defining a domain model?)
What about Jasper made it insufficient as a reporting engine?
Once the branch is ready for a 2.0 tag, how do we continue with work? We tentatively agreed to a basic structure: we have a master branch with a corresponding develop branch. New projects can start from any point on master, but it is recommended they start from a release tag. New projects are in their own branches. Code targeted for global first flows into ‘develop’. At periodic intervals or at user request, code is merged into master. A pull request is required for a merge into master – the reviewer (typically a Tech WG member) checks it and accepts or denies the merge. Overall release management, e.g. when we can set the next release tag, is something we’ll have to work out with the overall community Does this need more fleshing out?
What are the implications for countries between now and 2.0 master? What do we tell them during the transition?
How is a feature, ready to be merged, defined as Done? Any requirements around documentation, testing, etc.
Question arising from doc concern: If code is merged into dev/master, what is the Done criteria? If feature is gradually built and constantly merged in, when is that feature "done"? Needs to at least be Done by the next release tag.
Beyond the buckets of “in core” and “not supported”, is there a “supported but not core” bucket?
How long will the re-architecture would take and how much will it cost? Depends on scope identified by prod / tech committee
Is it possible to set-up linked issues between different Jira's? How can we compare the backlog of OpenLMIS against those of various on-going implementations?
Tech committee may use GitHub for product issue tracking. Do you see any problems with this?
Other questions, some of which Josh already has on the agenda: - Collaboration tools (DL, IRC, etc.) - When can we get to work on the 2.0 release tag work? Will TZ or MOZ ever make a release branch and stop merging into each other? - How do we document OpenLMIS? We will likely need updates to the original configuration Guide, as well as a tech guide and others. By “How do we document”, I mean how do we author and publish? Options include purely wiki-based, source-controlled text (likely processed by some text engine), etc. Wiki may be easiest, especially if we can release tag it as Atlassian doc somehow accomplishes