Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Resources

Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 62 Next »

Write Code. Save Lives.

OpenMRS is excited to be a mentoring organization for Google Summer of Code™ 2019! Since 2007, we've enjoyed participating in this great program and we're extremely excited about the projects and mentorship opportunities available this year. Coding for OpenMRS is a great way to practice your coding skills and, at the same time, help benefit people in developing countries who are on the front lines of the battle against HIV/AIDS, TB, Malaria, and other public health challenges. For a more detailed history of who were are and what we do, please see here.


On this page ....


Google Summer of Code at OpenMRS 
om.rs/gsoc

Learn more about Google Summer of Code 2019:
GSoC 2019 Flyer

Program Timeline

See here for more info on the full GSoC 2019 program timeline.

  • PASSED 15 Jan : Organization applications open
  • PASSED 06 Feb: Organization Application Deadline
  • PASSED 26 Feb: Organizations Announced
  • PASSED 25 Mar -09 Apr : Student Application Period
  • PASSED 06 May : Accepted students announced
  • NOW 07 May - 26 May 18:00 UTC Students get to know mentors, read documentation, prepare for work on their projects
  • AWAITING 27 May: Students begin coding for their Google Summer of Code projects
  • AWAITING 24 - 28 June: Mentors and students submit Phase I evaluations
  • AWAITING 22 - 26 July: Mentors and students submit Phase II evaluations
  • AWAITING 19 - 26 August: Students wrap up their projects and submit final evaluation of their mentor
  • AWAITING 26 Aug - 02 Sep : Mentors submit final evaluations of students
  • AWAITING 03 Sep : Final results of Google Summer of Code announced

Selected Project Ideas for GSoC 2019

Project NameSelected StudentPrimary MentorBackup MentorWiki Page
  1. Build new UI for Attachments Module as an OWAMODULE
[Click here]

2. Location Based Access Control Phase 2 MODULE

Tawrun Vankineeni[Click here]

3. UI For Reset Password via Email Project OWA

Tendonge Awo-Nasako Ryan[Click here]

4. Further Improvements to AddOns WEBAPP   

Unknown User (reubenv)[Click here]

5. Patient Search Criteria Module MODULE

Rushikesh Chaudhari [Click here]

6. OpenMRS Atlas 3.1 WEBAPP 

Sai Sandeep Mutyala[Click here]

7. Condition List (MVP) MODULE

Haripriya Reddy[Click here]

8. UI For Patient Flag Module OWA

Rishav Rakshit[Click here]

9. UI for Common Lab Module OWA

Wandji Collins [Click here]

10. OpenMRS Android Client 2.8+ANDROID

@Deepak Prasad

[Click here]

11. Automation of create-openmrs-owa with React Components OWA

Mithilesh Kohale[Click here]

12. Nigeria Telemedicine App ANDROID

Unknown User (levine)[Click here]

13. Implement Boostrap as a foundation for Reference Application UI WEBAPP

[Click here]


Required Skills (Just an abstract idea, it may differ based on the project scope)

  • MODULE -  Java, Spring, MySQL
  • WEBAPP - JSP, HTML, CSS
  • OWA - JavaScript, React, HTML, CSS
  • ANDROID - Java

We are still working on some project analysis, and plan to add here soon. Please keep watching this page for project updates.

Expectations for Students

Warm up practices for GSoC 2019 :https://talk.openmrs.org/t/gsoc-2019-warm-up-practices-for-students/21009

Before being accepted

  1. Become familiar with OpenMRS and the project(s) for which you're applying. If relevant, make sure you have OpenMRS installed and running. Read the Developer GuideGetting Started as a Developer, and ask others in the community if you have questions. If you ask questions the smart way, you'll get better responses.
  2. Make sure your development environment is installed and running, and optimized for maximum efficiency. Review our Conventions page.
  3. Review project ideas listed here & ask questions about those or other projects in the GSoC category on OpenMRS Talk.
  4. Spend as much time as possible in our IRC channel or Telegram chat, as well as on OpenMRS Talk with other community members. Remember, GSoC-specific questions should be asked on Talk.
  5. Introduce yourself on the community introduction page on OpenMRS Talk.
  6. Achieve /dev/1 status. (earn the /dev/null badge and then earn the Smart Developer badge by passing the quiz).
  7. Work on JIRA tickets. Pick some tickets from JIRA (under your targeting project or any where) and work on those tickets. Send the pull request with your changes to respective repository 
  8. Run, Test and identity some potential issues in OpenMRS Core or modules. Create new tickets in JIRA if those are not reported yet.
  9. Increase your visibility on OpenMRS Talk and IRC. Help others in the talk and participate in to other's discussions as much as possible.
  10. Do some code reviews. Reviewing code from others is one of the great ways to learn the OpenMRS code base. This is a must. No student will be selected who has not done code reviews.
  11. If you're returning to do GSoC with OpenMRS for a repeat term, be just as thorough (or more so!) than first-time students. Don't skip steps and work extra hard to impress your mentor(s).
  12. Additional expectations : 
    1. Write some blogs about OpenMRS or any related matters on OpenMRS which can help to others.
    2. Properly document your work in JIRA and help others to continue from it.
    3. Work on some #community-priority tickets.

After being accepted

  1. Set up a blog for your work on open source projects, including GSoC. Post the URL on OpenMRS Talk. If you don't have a blog yet, you should create one. You will be required to write a blog post every week about your planning work and project progress during GSoC.
  2. Contact your mentor immediately. Make a plan to communicate with them regularly. You should plan to use some combination of IRC or Telegram chat, or discussions on OpenMRS Talk (in a specific category or with a unique tag). Open source projects communicate in the open, so plan to keep any direct/private communication to an absolute minimum.
  3. Be sure to CC your backup mentor in communications. When you email or post on Talk, be sure to CC your backup mentor so they are kept abreast of progress on your project.
  4. Review any JIRA issues related to your project and work on some initial bugs or feature development, or work on some general OpenMRS bugs. Ask your mentor for guidance. (This doesn't mean begin your project!)
  5. Prepare a detailed project plan together with your mentor. Browse the current OpenMRS code specific to your project and review the requirements for your project together with your mentor. Include SMART goals and schedule milestones for each week. Publish the project plan on OpenMRS Talk in the appropriate category. (Request a new subcategory if needed.)

During the program

  1. Complete a short required "progress report" each week so we can make sure things are on track and there are no problems with your project. Contact organization admins any time if you have concerns about working with your mentor(s).
  2. Write at least one blog post every week to help stay on schedule and to share your work publicly.
  3. Commit early. Commit often. This is an important value in our open source community - read why.
  4. Prepare mid-term & final project presentation videos about your project's status, progress, and any questions you have for the community.
  5. You are now part of our developer community. We want you to feel like part of the team, so we expect you to:
    1. Conduct ALL project-related discussions on IRCTelegram, or OpenMRS Talk. (No direct emails!)
    2. Ask questions (the smart way) if you get stuck.
    3. Participate in our weekly Developers Forum when your schedule allows.

After completing GSoC

  1. Write a final blog post summarizing your overall experience! If you like, talk to the org admins for consideration to cross-post this article to the Google Open Source Blog.
  2. Stay involved with your project or other projects as your schedule permits! There is always plenty of development work needed for OpenMRS volunteers like you.
  3. Continue to watch OpenMRS Talk for additional questions or feedback about your GSoC project, and for other topics that interest you.
  4. Participate as a mentor for Google Code-in, in late 2019, should OpenMRS be accepted to participate. Your involvement will show secondary school students how they can use their skills in programming and open source projects.

Expectations for Mentors

In general, Mentors are community volunteers who are willing to give a student a great experience in open source development. Mentors should be knowledgeable enough in open source development and their project to provide quality mentorship during Summer of Code. Note that mentors cannot also participate as a student (i.e., someone applying as a student to GSoC should not also volunteer to be a mentor in the same year).

Before student selection

  1. Commit to spending a minimum of 4 hours each week to be available to guide and mentor students (not just your assigned student).
  2. Commit to being present in IRC and/or Telegram to help answer questions as much as your schedule allows, at a minimum of 4 hours each week.
  3. Prepare a good overview of your project idea(s) and have them linked to this wiki page.
  4. Watch OpenMRS Talk for questions about your project idea(s).
  5. Review student proposals and work with other mentors and organization admins to select the best candidates for OpenMRS.
  6. Treat returning students who have applied with as much (or more!) scrutiny than first-time students.

After student selection

  1. Ensure your student is ready & active. They should have a dev environment, be regularly communicating in the community, and have prepared a project plan together with you. (See above for student expectations.)
  2. Read the GSoC Mentor Guide and ask questions if you have them.
  3. Be sure to CC your backup mentor on communications with the student so your backup mentor can keep abreast of the project's progress in case she needs to step in for you if you have an emergency that will take you away from GSoC for more than a week during the program.
  4. Reach out to the Summer of Code organization administrators if you have questions or concerns.
  5. If the student is not active during the community bonding period, please contact the organization administrators.

During the program

  1. Help your student be successful. Commit to spending a minimum of 4 hours each week answering questions, giving advice, working with your student on blockers, and evaluating your student's progress.
  2. Complete a short "progress report" each week to help stay on schedule and catch potential problems early.
  3. Have fun and work hard! The highest-performing mentors will get an expenses-paid trip to Google's headquarters in October to geek out with fellow mentors from other open source projects.
  4. Schedule some time to chat 1-on-1 with your student to talk about their post-GSoC plans. Will they continue in their university program? Are they looking for a job? Help them understand the world beyond GSoC, and how they can continue contributing to OpenMRS.

After completing GSoC

  1. Stay in touch with your student and help them find interesting ways to stay involved with OpenMRS.
  2. Apply to attend the GSoC mentor summit in October! It's an awesome way to connect with other people in the open source world and have fun!

Expectations of Backup Mentors

Backup mentors have no explicit expectations beyond staying abreast of a project in case they need to fill in or take over for the primary mentor in case of an unforeseen circumstance. While we generally avoid anyone being a primary mentor for more than one project, we do allow primary mentors to serve as a backup mentor for one other project, since the need for backup mentors to take over the role of primary mentor for a project is very rare.

Before student selection

  1. None

After student selection

  1. Ensure the student and primary mentor are copying you on communications. This is most important during the program, but it is important you be aware of the project goals and this is a good time for student and primary mentor to build a habit of CC'ing you on communications.
  2. Read the GSoC Mentor Guide and ask questions if you have them.
  3. Reach out to the Summer of Code organization administrators if you have questions or concerns.
  4. If you are not hearing anything about the project during the community bonding period, please remind the primary mentor and student to CC you on communications.

During the program

  1. Briefly review communications when CC'd and watch the project page and blog entries of the student. Your job is to be aware of progress on the project and be ready to step in and assist if the primary mentor must step away from mentoring for some unforeseen reason.
  2. If you are not seeing regular communications about the project touch base with the primary mentor and student to remind them to CC you in communications.

After completing GSoC

  1. Make sure to congratulate a successful student!
  2. If you aren't already, consider becoming a Primary Mentor.

Have Additional Questions?


Our Technology At-A-Glance

The OpenMRS project's architecture is quite extensive, and incorporates a number of different components, programming languages and frameworks. As an GSoC student, you may be required to work on one or many of these components. Each project is different – consult the mentor and project documentation for details. The OpenMRS Developers Guide covers some of our software's technical architecture in more detail.

Some of the core skills you might be able to use in our projects this year include:

  • Java
  • The Spring Framework
  • The Hibernate Framework
  • JavaScript, Query, Node.js, React, Angular
  • Android, iOS Development
  • More to come ....

Application Requirements & Questions

You should have communicated in advance with the potential mentors listed above to prepare one or more project proposals. This proposal must describe in detail how you would plan to approach the project, and must include goals and a draft timeline. In addition to the project proposal, you need to respond to the following questions:

  1. Who are you? What are you studying?
  2. Why are you the right person for this project?
  3. Describe in detail your software development experience by various technologies. Include all technologies you have used for development projects.
  4. List any previous experience working with open source projects other than OpenMRS. (This experience is not a requirement.)
  5. Provide links to any projects created by you, or other source code examples.
  6. Please provide the URL to your OpenMRS Talk profile page.
  7. You must have made at least two coding contribution to OpenMRS BEFORE submitting your proposal. We recommend achieving the /dev/1 stage as you become familiar with OpenMRS. Please include in your proposal all relevant issue numbers, pull requests, commit links, etc as a table. for these contributions. If you don't include this information, your proposal will not be reviewed. It's not necessary for your pull requests to be merged; we just want to see that you've made some effort to learn the basics about OpenMRS development.
    1.  Sample Table

      Issue NumberProjectPull Request LinkStatus
      TRUNK-XXOpenMRS Corehttps://<link>In Progress
      TOTAL  XX
  8. You must have made at least three pull request reviews BEFORE submitting your proposal. If you don't include this information, your proposal will not be reviewed.
    1.  Reviewed Pull Request Details

      ProjectPull Request LinkWhat are the issues/suggestions/improvements which you mentioned in the review?
      OpenMRS Corehttps://<link>Just 1 - 2 line summary or 2 bullet points are enough. Don't write paragraphs here 
      TOTAL : XX
  9. Describe your interactions with our community so far. Include dates of developer forums you have attended, and include any IRC nicknames used when visiting our channel previously.
  10. What is your preferred method of contact and how should we reach you with it? (phone, email, IRC, IM, etc.)
  11. Do you have any other commitments during the program? (Include any and all holidays, vacations, travel, exams, classes, research projects, other work, job offers, etc.)
  12. Have you participated in the Google Summer of Code before? If yes, please mention the year, respected Organization, and your final result(Pass/Fail). - It will not affect your current application, we just wanted to make sure your attempts.

  13. Are you planning to mentor for a Google Summer of Code Project this year(2019) in any other organizations? If yes, please mention the respected organization name. You can’t be a student and mentor for same year.

  14. Are you planning to apply multiple organization this year? If yes, then which organization is your first preference if you get selected for both organizations(No need to be OpenMRS-Just mention your better selection)?

P.S : All personal information which is required in the above questions will be kept inside the OpenMRS and only used for the relevant matters. So you should be aware that you are providing some personal information to reach or represent you while applying here.

When preparing your application, also remember to:

  1. Use the title of the project for which you are applying as the title of your application. If you are submitting an application to work on the "Add whirlygigs to OpenMRS" project, then make the title of your application "Add whirlygigs to OpenMRS".
  2. Submit a thoughtful application. Simply regurgitating documentation from the wiki will not impress us. Rather, show that you've thought about the project and provide some ideas on how you would approach the solution. You can ask other people in the community for ideas in advance. The best applications not only refer to one of the GSoC projects, but also demonstrate you have thought about the project by providing a description of how you think you might approach the project, including a rough timeline of the steps involved.





  • No labels