GSoC 2021 : Project/Mentor Brainstorming

Community GSoC
1

Hi all , As we are approaching the end of November , its a good time for the community to start brainstorming ideas/potential projects for Google Summer of Code 2021.

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™ 2021 , and we are looking forward to identifying potential project ideas and mentors for GSoC 2021 as part of the organization application process. The organization application is due **on January 29, 2021 ** , 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.

Note the key changes in GSOC 2021

  1. Shortened coding period - The coding period is reduced to 10 weeks from 12 weeks.

  2. Raduced Project Size/time .Starting in 2021 , students will be focused on a 175-hour project over a 10-week coding period instead of the previous 350-hour projects

We should have a larger number of projects + mentors compared to the previous years, as this year we can get more students on board.

Note @burke suggests we aim for ~140 hours - 8 weeks of coding and at least 2 weeks for releasing, deploying, testing, documentation

GSoC 2021 timeline,

  • January 29, 2021 - Organization Applications Open
  • February 19, 2021 -Application Deadline
  • March 9, 2021 - Organizations Announced
  • March 29, 2021 - April 13, 2021 - Student Application Period
  • April 13, 2021 - May 17, 2021 - Application Review Period
  • May 17, 2021 - Student Projects Announced
  • May 17, 2021 - June 7, 2021 - Community Bonding
  • June 7, 2021 - August 16, 2021 Coding Period
  • August 31, 2021- Results Announced

please see the full Timeline here .

For more information on project timelines and expectations for primary and backup mentors , please refer to the OpenMRS GSoC 2021 wiki page . The wiki page will be updated with the list of projects and mentors as they are identified.

Previous GSoC Projects

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 2021, 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).

Creating a GSoC 2021 Project Page

  1. Browse to unassigned projects on the wiki or have your own idea
  2. 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
  1. Add page label: gsoc2021
  2. Add a link to your project page and proposed mentor below.

cc @grace @jennifer @dev2 @dev3 @dev4 @dev5

7 Likes
2

see Innitial ideas from @burke

1 Like
3

Thanks @mozzy for this first early bird catch upon GSOC project brainstorm 2021 :ok_hand:

4

Thanks @mozzy

5

great thanks @mozzy

6

Thanks @mozzy,

CC : @dbryzz @lobeserge @insookwa

1 Like
7

Hello everyone! Here’s a project idea (originally proposed by @ibacher) for GSoC’21. Please take a look!

7 Likes
8

Hello every one,

Re-sharing this topic to get your attention on this. Please let us know your projects and ideas for GSoC 21. We have to finalize the ideas before the end of this month.

Thanks.

3 Likes
9

For over a dozen years of participating in GSoC, we’ve reached out the community to drum up a collection of interesting projects. I’d like to propose a slightly different approach this year. What if, instead of taking whatever ideas come to mind, we created a coordinate set of projects that together could be a substantial gift to the OpenMRS Community?

I’ve been working on a draft for Modernizing Administration functions for OpenMRS. In short, this is building a new, modern version of our administration functions. It’s not a small undertaking and would likely require at least half a dozen or more GSoC projects. Here are some of my motivations:

  • We need pragmatic ways to begin migrating countries, organizations, implementations away from using server-side rendering (JSPs and GSPs) in new development and build capacity & excitement in the way web applications are built today (client-side applications against REST APIs – most often FHIR – in medical applications). It’s 2021.
  • Nearly every distribution and implementation of OpenMRS in the world today is still using the JSP-based administration functions that were introduced over 15 years ago (commonly via the Legacy UI module).
  • The work on a new frontend framework within the Micro Frontend squad is reaching critical mass where there’s enough framework & conventions in place against which new features can be built.
  • We could produce an “Admin 3.0” module to serve up these Micro Frontend-based administration functions that could effectively be a drop-in replacement for the Legacy UI module. If we pulled it off, many implementations would choose Admin 3.0 over Legacy UI because it looks & works better and be using Micro Frontends without even realizing it.
  • One of our first project proposal for GSoC 2021 is itself administration functions (FHIR metadata administration)
  • Several of our admin features do not (yet) expose a REST API, so there would, in many cases, need to be some Java-based work to add these features. We could divide projects up by functions and have students responsible for both backend & frontend development OR we could have some projects responsible for filling in gaps in the backend (mostly Java work) and other projects focused on frontend (mostly React & TypeScript work) OR we could mix & match based on student’s interests & skills.
  • We would need to develop an extensible admin screen as the parent for administration functions with the extension point(s) and conventions necessary to make it easy for projects to add new administration features (precedent for this already exists in the existing Micro Frontends work). Ideally, we’d have this in place before GSoC begins, so students would be plugging new admin functions into it.
  • While a 100% “complete” Admin 3.0 module (i.e., at least capable of replacing the Legacy UI module) would be dependent on the success of all projects, the modular approach of admin functions would allow us to deliver any percentage of the admin functions and be well on our way (even if we have to finish up some functions post-GSoC to get it completed).
  • One of my least favorite aspects of recent years of GSoC has been the relative lack of interaction between students and reduced exposure to the community. A coordinated project like this would promote lots of knowledge sharing & teaching amongst students and provide plenty (even weekly) opportunities for community showcases.

We’d need to get buy-in from the Micro Frontends Squad. This would certainly draw a lot of attention of incoming GSoC candidates to want to help out with Micro Frontend tickets (both a curse & a blessing… but likely more of the latter).

We’d also want to get input from implementations & organizations on the relative priority/value of the various administration functions. For example, how many people are using Forms Management or HL7 management? If they only routinely use 3-4 functions from the “Advanced Administration” screens, which are they?

Thoughts? Is this madness or a bad idea? Or do you think we could pull it off?

Cheers,

-Burke :burke:

11 Likes
10

@burke i find it a nice idea, since we have only a month to get our projects, could this time frame be enough for as to plan these projects, we might need a number of them?

1 Like
11

Looks powerful @burke

The idea looks great to me . we need to break it down into smaller tasks/projects that can be accomplished with in the GSOC period. And we will need heavy in put from the MF squad members cc @mksd @mksrom @samuel34 @ruhanga @florianrappl @ivange94

1 Like
12

i will also bring up this during our pm call today

13

This sounds great! Also, for the GSoC students, it would add to their experience of working in a collaborative project.

2 Likes
14

Great idea @burke - thanks for concretely expressing this idea around a single unifying GSoC project, which I’ve heard several people endorse in past conversations.

If we decide on this route, and we start to prioritize what types of existing admin functions we tackle, we should consider how our planned strategies and approaches around Initializer and OCL might influence this. Maybe these don’t change anything (eg. we still want to allow all metadata to be created and edited via an admin UI that directly modifies the DB in real-time), but it might also be worth considering an alternative approach centered around visualizing and editing Initializer configuration files, as well as being able to do things like view whether an OpenMRS server is up-to-date with a set of Iniz configurations or not, what the differences are, and functions to apply specific or a set of those changes on demand.

Just a thought - interested in others perspectives, particularly @mksd and @mksrom.

Mike

4 Likes
15

Thanks so much @burke for outlining this in so much detail, and I still ought to go through your draft document. A couple of thoughts below.

  • Redoing the legacy admin screens? Yes.
  • As a new Admin 3.0 MF, plug and play? Yes.
  • Having GSoC teams work on well defined deliveries? Yes… but here there are caveats.

Ideally some good old functional analysis should be made to know where we are heading. As in:

  • As a data manager at Acme, I need to merge duplicate patients and correct erroneous encounters.
  • As a business analyst at Acme, I need to have a flexible tool to manage concepts
    • This connects to @mseaton’s point, this flexible tool isn’t needed at all if Acme uses OCL anyway…
  • As a client admin at Amani Hospital, I need to manage users and assign their roles, give them access to locations… etc.
  • …

When this functional analysis is done, then it’ll be time for some UX design.
And only then the GSoC students can start bringing those screens to life by joining the MF Squad for the time of a summer… assuming the overhead can be taken on by existing members (that’s a biggish if.)

If the above proper approach is not possible then the minimal delivery should be to take an existing admin screen and “make it better” in React and bundle it in this upcoming Admin 3.0 MF. But again, what does “make better” mean, we cannot leave this up to the students to figure out.

To be discussed further obviously. I would be curious to hear from @grace, @jdick and all the usual suspects.

2 Likes
16

I went through the documentation shared by @burke and seems very interesting!

@mksd You input on this time frame also makes sense, and we don’t have that much of time left to plan and design the screens before the project inauguration (We might have one or two), and in other hands, it’s not useful if we follow a random design or existing design which is going to be deprecated soon with any kind of new designs for the UI (or Admin 3.0 MF)

In my head, I hope there is a requirement for a kind of service layer in the MF projects which are responsible for the minor business-level decisions of the screen. Some of the examples are,

  1. REST API Requests or FHIR requests
  2. Model validation and creation/alteration (Patient, Role, Person…)
  3. Common error handling

So why don’t we have a JavaScript(ES6) NPM module which holds these service layer methods, which are exposed to be used by the MF modules? So it would be a common module and attached as a dependency for the MF modules. So once we finalize the plan and designs for the screens, we just have to develop the MF modules with the help of this common NPM module to handle the screen inputs with the server.

Untitled Diagram
Untitled Diagram721×431 14.2 KB

17

I’m not the best person to answer this, but in my understanding those ESMs that you suggest already exist. Or at least most of it already exists.

18

@mksd @suthagar23 are you referring to these modules

19

Indeed, and more specifically openmrs-esm-api.

2 Likes
20

@burke, great timing! This is exactly where I’d like to see us going with our GSoC projects - and I’d encourage other squads to think about how they can leverage GSoC 2021 as well. @ibacher mig

It might be worth taking a look at the timeline for GSoC: and thinking about how we can leverage the different stages (project idea => project proposal => bonding => coding) to prepare a coordinated suite of GSoC projects like this to be successful. If memory serves correctly, GSoC students really tend to get involved as early as March, when they begin exploring projects and preparing their proposals. So what would successful proposals look like? Could we guide interested students in such a way that the proposals include any of the functional analysis or UX design @mksd mentioned? Would that be too much to ask?