Hi Community
, As we are approaching mid January , its a good time for the community to start brainstorming ideas/potential projects for Google Summer of Code 2022.
Following on the success of more than a decade of involvement in Google’s Summer of Code initiative, OpenMRS once again plans to apply as a mentoring organization for Google Summer of Code™ 2022 , and we are looking forward to identifying potential project ideas and mentors for GSoC 2022 as part of the organization application process.
The organization application starts on February 7, 2022 , so we would like to get as many projects fleshed out by then. If you have any ideas for projects , and/or would like to volunteer as a mentor , this is the time and place to get those discussions going.
We should have a larger number of projects + mentors compared to the previous years, as this year we are likely to have many applicatants since GSOC is no longer limited to students and its now open to newcomers 18 years and older .
see our GSoC Project Creation Guidelines.
GSoC projects can be new modules/OpenWeb Apps/projects, involve enhancements/new features for an existing module/OpenWeb App/project, or PoC work for an idea, but should have the following attributes:
Must involve coding(Major part) and be OpenMRS-related ideas
Clear objectives and requirements
A minimal viable product can be completed in 6-8 weeks (allowing time for bug fixing, documentation, and getting to production).
Meaningful contributions to the community
Involvement of at least one motivated product owner (e.g., implementation) eager to use the project’s output
Should have some features which may give a chance for design, coding, testing, and documentation as well as analytical thinking and creativity for students.
Available mentors (If don’t have, we can get it later)
New Project Ideas
If you have any new ideas which are supposed to be initiated through GSoC 2022, please go ahead and arrange a Design forum for it or post it in the Talk and get the community opinion on that ideas. (You can contact any of us, and invite our community also).
If there is already a wiki page for your project or very similar project, update that page instead of creating a duplicate. If you need to create a new project page, please choose the “Project Page” template.
Project name *: Foo Bar Project← by convention, end your page title with " Project"
Primary mentor *: Your OpenMRS ID / TBD
Backup mentor *: TBD
Assigned to *: TBD
Abstract *: 4-5 paragraph(s) describing the background, purpose, motivation of the project. Make it exciting! The more interesting your project sounds, the better the applicants you will get.
Sample use cases *: Provide 2 - 5 sample use cases which need to be developed. It should be simple which could able to understand by a person who doesn’t have any experience with OpenMRS.
First Task : If you have any simple task(which can be completed with in 3 - 5 days) related to your project, mentioned that in here. It can be a JIRA issue or any PoC. You can use to evaluate the capability of the student for that project ( Optional - But good to have)
Project champions : name one or more product owners (who will use the output?)
Required Skills *: list the skills required to apply (e.g., Java, React, Angular, REST, HTML/CSS, basic SQL, etc.)
Objectives *: A short list of what should be accomplished during the summer
Extra credit : list any nice-to-have features or approaches
Dev Tracks * : Include GitHub URL and JIRA URL of the project
Resources *: include links to any wiki pages, Talk discussions, websites with related/helpful info
Add page label: gsoc2022
Add a link to your project page and proposed mentor below.
Here is the GSOC 2022 timeline :
February 7, 2022 - Organization Applications Open
February 21, 2022 -Application Deadline
March 7, 2022 - Organizations Announced
April 4, 2022 - April 19, 2021 - GSoC contributors Application Period
May 20, 2022 - GSoC contributors Projects Announced
May 20 - June 12, 2022 - Community Bonding
June 13 , 2022 - Coding Period Starts
November 28 ,2021 - Mentors submit final evaluations
Starting a list of ideas below; I’ll put up a specific message for each one so folks can “” the ones they like. But here’s the summarized list, with est. difficulty in (brackets):
Category: Frontend / OpenMRS 3
Enable HTML Form Entry forms in OpenMRS 3 (Medium)
Next Generation Implementer Tools for OpenMRS 3 (Advanced)
Responsiveness & Tablet-based Needs for OpenMRS 3 (Medium?)
Next Generation Form Builder UI for the OpenMRS Community (Medium-High?)
Category: OCL/Concept Management
Microfrontend the OCL Module and reduce backend dependencies (Medium)
Category: DevX
SDK Support for Building the 3.x RefApp Distro (@burke can you add a post here describing your idea?)
Category: Infrastructure
Migrating from OpenMRS ID to KeyCloak (@burke can you add a post here describing your idea?)
Note: While we want to switch gradually away from HFE in favor of an easier to use next generation form tool, HFE is still the major tool used by existing implementers, so 3.x not supporting HFE is a major adoption blocker. Basic support for HFE forms in 3.x would be a phenomenal value-add to all implementers using HFE and wanting to try out 3.x.
The main need/user story is: “As an implementation who has many, many forms created with HTML Form Entry, we want to use 3.x while still being able to use our old HFE forms, so that we don’t have to go through a very expensive and painful process of changing all our HFE forms over to match the new 3.x form schema.”
There are two low-hanging-fruit ways this might be implemented:
The HFE form could open in a separate tab
iframe to show HFE forms - so the user would be in the UI here, but the form showed here would be an HFE form instead of a Carbonized 3.x form (see image below) - I think this is my preferred hack, since it keeps the user within the one EMR experience:
O3: Next Generation Implementer Tools for OpenMRS 3 (Advanced)
350hr project. Designs already completed.
User Story: Non-tech users can set up a 3.x EMR in a friendly, no-code UI, similar to designing a website. Empowers local team members to set up and config their EMR themselves. (More detailed user stories and requirements documented here.)
Scope: technical work on the redesigned config tools for O3. *Design is done because Ampath/@jdick graciously already paid for designs and user testing, sample designs below, and @bistenes gave a lot of architectural and technical input but then had to set the project aside.)
O3: Responsiveness & Tablet-based Needs for OpenMRS 3 (Medium?)
We have a ton of designs for 3.x that show how the frontend UX should change based on screen size or device (e.g. large desktop, small laptop, or tablet). Much of this responsiveness still needs to be implemented consistently throughout the application.
Example of the difference between large desktop, vs small laptop, vs tablet:
OCL: Turn the Open Concept Lab Module into a 3.x App
The OCL Module is the last remaining OMOD that depends on the (effectively deprecated) OWA Module. We want to be able to remove the OWA Module from our 3.x RefApp distro, and currently it’s just the OCL Module preventing this.
@ibacher has already set the groundwork by setting up an ESM monorepo and skeleton of the work on GitHub.
This is a smaller project; 175hrs. Fine for a newer dev but needs some past React experience.
O3: Redo Legacy UI Cohort Builder. In addition to supporting all current functionality, would also like to be able to save a search history (UI there in legacy but never implemented afaik). Add ablity to update an existing cohort based on a scheduled run of a search history.
@anshul We’re still in the project ideation/development phase and those ideas really come from those in the community who have a good project idea and are interested in working with a GSoC contributor. Our full list of GSoC projects will be published on our Wiki by February 21, 2022.
Until then, @anshul, if you know of community members with clear ideas for moving the Android Client project ahead in a way that has high value for our community & OpenMRS implementations, then the next three weeks is the time to start bring up the project’s objectives, identify mentors, etc. A potential next step will be to post the idea here, start a Talk thread, and/or hold a Design Forum to flesh out the project.
Thanks for the suggestion @kdaud, I made a small draft with a set of requirements; Feel free to update this Google Doc.
Extending tests
The student should collaborate closely with the o3 team to identify new workflows and design tests.
Making tests more reliable
Current tests are less reliable because they are not very stable. Sometimes they pass, but there is still a chance that they will fail. Also, tests suddenly start to fail when there are new changes in the implementation. We need to look into ways to improve the reliability of tests.
Run tests against Pull requests
Currently, we don’t have a mechanism for running tests against Pull requests. As a result, no failures can be detected until the changes are merged and someone run the tests manually. It makes it difficult to detect root courses as well as to engage developers. We need a proper way to run these tests against the changes in pull requests.
Improve developer engagement
We do see a lack of engagement of O3 developers with E2E tests.
The possible reasons might be:
The E2E tests are not yet a part of the current development cycle.
It isn’t that easy for an O3 developer to easily get started with E2E tests due to lack of documentation.
It is a bit hard to work with the local environment.
We need to find solutions to the above while identifying other ways to make things easier for developers.
Apart from that, we do have some set of challenges as well:
Making local test runs repeatable despite data mutations
Handling metadata of the dockerized DB
Syncing local setup with the latest development version of O3
Running tests against an unmerged version
Fixing the screen recording feature. It’s not recording properly for a few weeks.
Accessibility Testing is defined as a type of Software Testing performed to ensure that the application being tested is usable by people with disabilities like hearing, colour blindness, old age and other disadvantaged groups. It is a subset of Usability Testing.
The end goal, in both usability and accessibility, is to discover how easily people can use a website and feed that information back into improving future designs and implementations.
The importance of Accessibility Testing
Cater to market for Disabled People.
About 20% of the population has disability issues.
1 in 10 people have a severe disability
1 in 2 people over 65 have reduced capabilities
Disabilities include blindness, deaf, handicapped, or any disorders in the body.
A software product can cater to this big market if it’s made disabled-friendly. Accessibility issues in software can be resolved if Accessibility Testing is made part of the normal software testing life cycle.
Abide by Accessibility Legislations
Government agencies all over the world have come out with legalizations, which requires that IT products be accessible to disabled people.
Following are the legal acts by various governments –
United States: Americans with Disabilities Act – 1990
United Kingdom: Disability Discrimination Act – 1995
Australia: Disability Discrimination Act – 1992
Ireland: Disability Act of 2005
Accessibility Testing is important to ensure legal compliance.
Avoid Potential Law Suits
In the past, Fortune 500 companies have been sued because their products were not disabled-friendly. Here are a few prominent cases
National Federation for the Blind (NFB) vs Amazon (2007)
Sexton and NFB vs Target (2007)
NFB Vs AOL settlement (1999)
It’s best to create products that support the disabled and avoid potential lawsuits.
Accessibility Testing with jest-axe
OpenMRS 3.0 uses Jest to run the unit tests. Because of that, we can use Jest aXe to test our React components’ accessibility tests.
Jest aXe
Custom Jest matcher for aXe for testing accessibility
Accessibility (a11y) of applications is much easier to get right if worked in from the start, rather than retroactively going back to try and fix. While the GDS Accessibility team found that only ~30% of issues are found by automated testing it can help to establish a baseline with virtually no effort to include and run.
It cannot and does not guarantee what we build is accessible, as it can only statically analyse code, but it provides a great start.
Demo
Adding Accessibility Testing OMRS 3.0 will increase usability and accessibility.
As you can see it’s straightforward to add jest-axe to integrate aXe automated accessibility testing.
jest, jest-dom, and jest-axe work smoothly together to form a versatile testing toolkit for testing React components from a functional user perspective.
I will keep adding my findings to this. Feel free to update this google doc
” the ones they like. But here’s the summarized list, with est. difficulty in (brackets):
