We have been doing this work for clinical screens over the past few months, and it takes a bunch of experts + the participation of real-world sites for UX testing sessions.
On the cheap side one would maybe argue that we could lower the bar for non-clinical screens… but to the point of having it done by GSoC students? I wonder what others think.
I actually kind of forgot that they had to draft a proposal. My view was rather to shape the work to a point where they are being asked to execute on the specifications that have been laid out for them, with a scope of work that is reasonable for a team made of a handful of them.
Porting administration functions into micro frontend modules will not be a small task, but it does lend itself to a “map reduce” (i.e., parallelized) solution. It would break down into at least 12-15 or more individual projects of varying size. Can we define them in a month? It depends was bar we set (more on this below).
Agreed. These could lower the priority of porting certain functions (e.g., concept management, location management, etc.).
I wouldn’t let perfect be the enemy of the good. If we can create an admin home page that organizes administration functions to our liking and provides a convention for how new admin functions are added to it, the individual administration functions can be iterated or replaced as needed. Even if several admin functions leave room for improvement, the work of getting necessary REST API endpoints built out and having any alternative to the 15 year-old JSP pages would be a big win for the community and for accelerated adoption of micro frontends.
Much of this has been worked out by the MF Squad through work on the clinical dashboard features and more fundamental pieces like Domain Decompisition.
I agree with @mksd. We would define the projects (e.g., create scheduling management for Admin 3.0, implement global property management for Admin 3.0, etc.) with clear specifications. The draw for students would be exposure to React/TypeScript + the ECMAScript Module specification + FHIR, Java work for gaps in the REST API, the opportunity to work in close collaboration with fellow students ("it doesn’t matter which piece you’re working on, because we each succeed by all of us succeeding), and – of course – writing code & saving lives.
Students proposals, like all prior GSoC years, would give them an opportunity to outline how they will approach the task, demonstrate why they’re the right person for the job, and layout their proposed timeline/work plan.
The Address Hierarchy, Metadata Sharing, OpenMRS Atlas, several reporting enhancements, patient merging, Bootstrap of OpenMRS 2.x, and the Legacy UI module itself, so I wouldn’t underestimate their potential. The benefits from GSoC are directly related to the effort we put into it. If we do a poor job of describing the projects, don’t make them exciting, and don’t interact much with students as they’re applying, we get weaker students and less return; however, if we do a good job of describing the problem, getting students excited about it, and interacting with them during the front-end of GSoC (February & March), we can get excellent students. In fact, some of our best and most productive OpenMRS developers in the community over the years have come to use through GSoC.
That said, I would definitely make a low bar. The starting point of acceptability would be parity with what we’ve got working in micro frontends. Once there, we’ll have a set of modular functions we can improve over time and the hard work of getting everything able to work in micro frontends will have been done.
