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 65 Next »




Write Code. Save Lives.

OpenMRS has has been selected as a mentoring organization for Google Summer of Code™ 2018! 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 2018:
GSoC 2018 Flyer

Latest Status

Congratulations to the 12 students selected by OpenMRS to participate in GSoC 2018! The community bonding period has begun, and students will start work on their projects on May 14th, 2018.

Program Timeline

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

  • 4 Jan: Organization applications open
  • 23 Jan: Organization Application Deadline
  • 12 Feb: Organizations Announced
  • 12-27 March: Student Application Period
  • 23 April: Accepted students announced
  • 23 April to 14 May: Students get to know mentors, read documentation, prepare for work on their projects
  • 14 May: Students begin coding for their Google Summer of Code projects
  • 11-15 June: Mentors and students submit Phase I evaluations
  • 9-13 July: Mentors and students submit Phase II evaluations
  • 6 August: "Pencils down" date
  • 6-14 August: Students submit code, project summaries and mentor evaluations
  • 14-21 August: Mentors final evaluations
  • 22 August: Final results of Google Summer of Code announced

Accepted Projects


Expectations for Students

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. Do some code reviews. Reviewing code from others is one of the great ways to learn the OpenMRS code base.
  8. 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).

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 2018, 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
  • JQuery
  • Node.js
  • 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 task?
  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 websites or applications 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 one 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. 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.
  8. 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.
  9. What is your preferred method of contact and how should we reach you with it? (phone, email, IRC, IM, etc.)
  10. 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.)

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