Just few months after the last GSOC has ended ,
Once again, Google Summer of Code 2021 has been just announced officially by Google . Please refer to Google’s OpenSource Blog page and GSOC official site .
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
However , there are Some exciting changes that are coming to the 2021 GSoC to add more flexibility into the program for students and mentors alike.
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 .
Students eligibility has also changed . In 2021 ,students need to be 18 years or older and either 1) enrolled in (or accepted into) a post-secondary academic program (including university, community college, PhD program, licensed coding camp, etc.) as of May 17, 2021 or 2) if they graduated from a post-secondary academic program between December 1, 2020 and May 17, 2021 .
As usual, OpenMRS also will start preparing the application to get accepted with Google Summer of Code 2021.
Those changes are really interesting. Essentially, it sounds like we’ll need to either find/define smaller projects for students or have a couple of students work on the same project.
Seems very interesting changes with Google Summer of Code 2021!!, these are few more changes
Shortened coding period - The coding period is reduced to 10 weeks from 12 weeks.
Evaluations - Next year onwards, there will be only two evaluations (First evaluations - 5 weeks, and final evaluations - 10 weeks). For more interesting, the first evaluations is kind of optional (but encouraged to be completed) - so if a student doesn’t complete the first evaluation they will not automatically be removed from the program. They are still required to complete the final evaluation.
Eligibility requirements - It’s accepting from a larger community not just accredited university programs. This includes licensed coding camps, community colleges, and many other programs that may not be accredited yet but are post-secondary academic programs.
What’s next…!
We have to start preparing the projects as we have to reduce the project requirements for GSoC 2021. It’s not actually diving the project into two parts but it depends on the overall project completion goals. (~175 hr projects - 10 weeks)
We should have a larger number of projects + mentors compared to the previous years, as this year we can get more students on board.
Even the project time or coding period shortened, effort from mentors will not be half as much even though the project size is cut in half. We can’t expect two or more projects from a mentor, So it’s better to have different projects from more community members.
Another cool idea that seemed more important about the coming GSOC 2021 is to make students get more involved in the organisation work and remain participating in an organisation(openmrs) even after the program gets finished not only GSOC as a program since some students get lost after the program which is i think a very interesting goal.
It’s too easy to set our sites high and end up with projects just finishing or 95% complete by the end of the summer, which greatly diminishes their chances of getting deployed and used by implementers. I’ve been suggesting that we aim for 10 week-long projects, expecting that there will be time allowed for unexpected delays along with time for testing, release, and documentation. Now we will need to consider what could be reasonably accomplished in 2 months if we are going to ensure that 90% or more of our projects are not just complete code-wise, but released & used by the end of GSoC.
This makes sense. A mid-term evaluation primarily serves as a mechanism to provide feedback and, if necessary, fail early for projects that are struggling. I mid-term evaluation is less helpful for projects that are ahead of schedule (just a reminder to heap praise on the student).
This is excellent and should be used as an opportunity to raise the bar & expectations of students, not to lower them.
I’d suggest we aim for ~140 hours - 8 weeks of coding and at least 2 weeks for releasing, deploying, testing, documentation. Let’s try to make sure every OpeMRS GSoC project is set up for success: (1) students learning how fun it can be to write code & save lives and (2) leveraging our unique position to make direct connections for aspiring open source developers with implementers on the front lines of critical health care in developing countries.
More is better, but I would advise quality over quantity – e.g., I’d gladly give up a year of 20 GSoC projects (with some projects not completing, some students less engaged, and many cases where the work of the developers is not directly appreciated by implementers) in exchange for 8 projects with stellar students starting a lifelong journey of enjoying open source coding and celebrating how each project is saving lives. While we can strive for 20 stellar students saving the world, I’d gladly give up on quantity if it helps us maximize quality for the students.
Totally agree. We’ve always tried to have a primary & backup mentor for each project and to limit mentors to a single project. That has worked well.
We have some really fun & cool opportunities in 2021.
Frontend Development. The micro frontend squad has been hard at work building a frontend framework for OpenMRS that embraces a best practice approach to modern frontend development (e.g., leveraging ECMAScript’s standard for asynchronous modules, TypeScript, Carbon’s Design System, etc.) all in an approach that prioritizes FHIR and allows disparate frontend technologies (e.g., React, Angular, Vue, etc.) to play nicely together. There will be a growing number of opportunities to build out frontend features in this framework in 2021. This is the direction we’d like all OpenMRS frontend development to converge toward.
Building an Analytics Engine. The Analytics Engine Squad is working to develop the foundation for a common approach to getting data out of our relational model into a format that can be a sliced & diced for analytics & reporting using contemporary tooling like Apache Spark, Debezium, etc. Our hope is this solution can be our initial foray into a microservice approach for the backend, providing some basic functionality out of the box with OpenMRS, yet able to scale into the cloud.
Light GSoC on FHIR! The world is adopting FHIR as the standard for clinical information and OpenMRS is helping lead the way. The fhir2 module is here and an important strategy for OpenMRS moving forward to help us migrate to FHIR becoming the primary model for OpenMRS inside & out. There’s plenty of opportunity in expanding the fhir2 module to support more aspects of the FHIR API, especially those resources & features needed to support growing frontend efforts.
Oh CIEL! The CIEL dictionary is the de facto standard for concepts in the OpenMRS Community. We’d like all implementations to start with CIEL and those needing to add concepts would first look to CIEL for their concept. But using all or part of the CIEL dictionary often involves manual effort & too much SQL. Fortunately, the Open Concept Lab (OCL) offers a platform to make dictionary management, including access to CIEL concepts, much easier. The OCL for OpenMRS squad is working hard on a client to leverage the capabilities of OCL for the OpenMRS community. There are opportunities in expanding the OCL client to support dictionary maintenance within OCL and to help Andy move his CIEL management & delivery into OCL.
The last mile. Any implementer can attest to the sweat & tears involved in deploying and upgrading OpenMRS servers, especially at scale. The OpenMRS community is working on standardizing our deployment process, leveraging container technology like Docker. There will undoubtedly be opportunities to build and enhance deployment tooling in 2021. If it hasn’t already been addressed by GSoC 2021, our standalone could use some love.
Having been around the community and seen the great works done by @suthagar23 and @mozzy for gsoc ,i humbly write in to express my interest of being a gsoc administrator for the year 2021. cc @jennifer@grace@suthagar23@mozz
Thanks for the clear outline of the GSoC 2121 program.
I would like to inquire if there could be any open internship opportunities as of now given that it`s until March 2021 when GSoC intern applications will be open.
,
