I know this is an open source project, but I want to raise a critical issue in that the platform and modules are becoming more and more complex to work with and take too much time to get anything working
I want to suggest an investment to streamline the process, even drop some backwards compatibility to simplify the dev work needed.
I have spent over 40 hours trying to get a simple test case for the ProgramAttribute tag in HTML Form Entry that our implementation needs, and its frustrating due to cryptic errors and no resources to refer to
@jennifer this needs focus otherwise the few implementation technical resources available become strained due to the fact that everything is so much harder to do
@ssmusoke, we discussed this during today’s TAC meeting and @jennifer will be reaching out to you. There are likely a spectrum of things that could be done to improve the development process:
Update our default archetype to promote best practices
Dropping support for older versions where it can simplify things
Update(s) to the SDK
Improvement(s) to dependency management between modules
Improving the more common cryptic errors to no longer be cryptic
Hopefully, we can help you enumerate the key pain points and come up with some action items to improve things. Sometimes, simply defining the problem, agreeing on a solution, and getting it written down is what keeps it from getting fixed (especially when there are GSoC students or other community volunteer developers asking how they can help).
However I would also like to recommend that a consideration be made to divert some of the “resources” dedicated to QA to this effort.
Depending on community volunteers and GSOC to drive key needs of the community is not moving the needs forward as fast, as you may notice Ref App 2.10 took 1 year to get done.
As the core slows, so do the rest of us the implementors forcing us to take “bad” shortcuts to meet our short-term goals.
@mksd the application context, profile specific versions, exclusions etc. By the way despite all that time invested, I have not yet gotten the very basic test case for the problem I am solving to run (as I am resolving build failures) which should basically be a 16 to 20 hour task
Dropping backwards compatibility would definitely simplify things. But it is a challenge because most of the implementations out there are still using older versions of the OpenMRS platform.
As we collectively look for ways to reduce complexity, i would in the meantime advise that when you find yourself blocked for an hour, immediately ask for help. Unless you of course want to have some fun digging deep.
I personally find such challenges as interesting ways of breaking my routine of doing some boring tasks.
I am back still frustrated at how difficult it is to add a custom HTML Form Entry tag for a feature that was added into core, up to 80 hours wasted basically on this with no hope of an end in sight
@burke@paul as key leaders for this project is what is the plan to get core development resources to at least put the basics that the platform should provide out of the box, that is the core models and extensions, rather than leave implementors to waste cycles trying to get the basics up and running?
I do not think the model of leaving core development to community volunteers and implementors is viable in the long run
The custom tag is meant to be part of HFE UI as its part of a core object, Patient Program Attributes, after 3 months trying I have accepted and given up, closed my current PR and unassigned myself from the issue.
I am going to find a way to hack a workaround in the next couple of days
