Write Code. Save Lives.
OpenMRS is participating for its 7th year as a mentoring organization for Google Summer of Code™ in 2013. We've enjoyed participating in this great program in the last 6 years and are 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.
We will follow the official Google timeline for the program. In summary:
- April 8: Official announcement of Google Summer of Code participating organizations.
- April 8 - April 22: Interns communicate with potential mentors to define projects. Interns work on introductory tickets, submit patches, etc.
- April 22 - May 3: Intern application period.
May 3 - May 24: Mentors review, rate, and select interns. May 27: Accepted interns are announced.
- Through June 16: Community bonding period.
- Get to know your fellow interns and mentors.
- Do the things listed above in "Next Steps" below.
- June 17: Coding begins!
- You should have a project plan in place by this date.
- Important: Commit code early and often!
- July 29: Mentors send Google a mid-term evaluation of your work.
- September 16: Plan to finish coding by this date, then use the final week to scrub code, write tests, improve documentation, etc.
- September 23: "Pencils down." No more coding after this date. Mentors submit their final evaluations.
- October 1: Results of evaluations are announced.
Congratulations to our interns for Summer 2013! Both GSoC and OPW interns are listed below. Please contact your mentors as soon as possible to discuss next steps during the community bonding period.
Outreach Program for Women
If you're a woman interested in getting involved in OpenMRS, you should also check out for the Outreach Program for Women, which runs at the same time as Summer of Code but is also open to non-students and non-developers!
Interns, Mentors, and Projects
The following interns will be working on projects via Google Summer of code and the FOSS Outreach Program for Women in Summer 2013:
|Intern Name||Mentor Name||Project|
|OpenMRS SDK |
Backup mentor: Burke Mamlin
|Intuitive User Interfaces for Report Designer |
Backup mentor: Lluis Martinez
|Developer and Implementer Documentation Improvements|
Backup mentors: Ada Yeung, Michael Downey
|OSGi Support |
Backup mentor: Daniel Kayiwa
|Patient Matching Module Strategy Enhancements |
Backup mentor: Jeremy Keiper
|Data Integrity Workflow Module |
Backup mentor: Ada Yeung
|Validation Module Enhancements|
Backup mentor: Nyoman Ribeka
|Concept Management Tools App for Our New Reference Application |
Backup mentor: Wyclif Luyima
|Improving Mobile Development |
Backup mentor: Steven Githens
|Improvements to the HL7Query Module |
Backup mentor: Rafal Korytkowski
|De-Identified Patient Data Export |
Backup mentor: Ben Wolfe
|Reporting Web Services and Pentaho Integration Enhancements |
Backup mentor: Mike Seaton
|OpenMRS-DHIS2-SDMX-HD Integration |
Backup mentor: Saptarshi Purkayastha & Bob Jolliffe
Backup mentor: Burke Mamlin
Next Steps for Accepted Interns
After accepted interns are announced, here's what should happen:
- If you can, attend the next scheduled Developers Forum on 30 May to briefly introduce yourself and meet other interns. Attend as many Developers Forums as your schedule permits.
- Contact your mentor immediately. Make a plan to communicate with them regularly - at minimum, once each week. Determine the best way to communicate (e-mail, IRC, IM, VoIP, telephone, etc.).
- Double-check your subscription to our developers mailing list to keep track of what's going on in our development community and spend lots of time in our IRC channel with other community members & interns.
- Make sure you have OpenMRS installed and running. (You should have done this already since you were accepted.) Read Developer Guide, Getting 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.
- Make sure your development environment is installed and running, and optimized for maximum efficiency.
- Review our Conventions page.
- Set up a blog for your work on open source projects, including GSoC. Send the URL to Michael Downey. If you don't have a blog yet, you can create one for free at WordPress.com or Blogger.com. You will be required to write a blog post every week about your planning work and project progress during GSoC.
- Browse the current OpenMRS code specific to your project and review the requirements for your project together with your mentor.
- Agree on final requirements with your mentor, and post a formal written proposal including project schedule (timeline) on which you both agree.
- As your time permits, 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!)
What we expect of interns:
- Become familiar with OpenMRS and your project before the start date.
- Complete a short "progress report" and write a blog post every week to help stay on schedule and share your work publicly.
- Commit early. Commit often. This is an important value in our open source community - read why.
- Join the interns mailing list. (We'll invite accepted interns to this list after they are announced).
- You are now part of our developer community. We want you to feel like part of the team, so we hope you will:
What interns should expect of OpenMRS during the summer:
- You will have fun!
- You will learn how to work within an open source project – one that's helping people save lives around the world.
- You will have dedicated time (4-5 hours each week) with an experienced OpenMRS mentor, and will have a backup mentor for questions or problems.
- If you ask a question the smart way, our community will do its best to help you.
- The Summer of Code program leaders (both at OpenMRS and Google) will be available if any problems arise between interns and mentors.
What we expect of mentors:
- Help your intern be successful. Commit to spending a minimum of 4-5 hours each week with your intern answering questions, giving advice, working together, and evaluating his or her progress.
- Complete a short "progress report" each week to help stay on schedule and catch potential problems early.
- Read the GSoC Mentoring Manual and ask questions if you have them.
- Reach out to the Summer of Code project leaders if you have questions or concerns.
- 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.
Helpful Community Resources
- If possible, join the Developers Forum every Thursday. You can participate by telephone, Skype, or even just on IRC.
- We use JIRA as a tool for issue tracking and project management.
- Tips for using e-mail:
- If you have a highly specific question, contact your mentor.
- Technical discussions, ideas, and requests for feedback should be sent to the entire community on the developers mailing list.
- The Interns mailing list is for accepted interns to discuss program administrative issues. This list should not be used for technical discussions. Accepted interns will be automatically subscribed to this list.
- IRC discussions in the #OpenMRS channel of freenode are always fun! Useful for shorter discussions or for large group discussions
- Use the OpenMRS wiki often:
- Be sure to make a user profile page.
- Every project should have a OpenMRS wiki page where you document your project, progress, technical details, show mock ups, etc.
- Google Docs — an excellent tool for sharing and collaborating in real time on documents or spreadsheets, when the wiki is not appropriate.
- Scheduling tools:
- During the summer, each intern will be required to give short presentations during our weekly Developers Forum to explain and demonstrate their project during the program. You can use our screen sharing tools to demo your project.
- More information about the presentations will be posted here as the program start date approaches.
We're happy you were interested in working on OpenMRS during Summer of Code 2013. Here are some tips that we prepared to help your application process be easier and more successful. These are all things you should begin early to start getting involved.
TL;DR (http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn't_read): Become an active contributor in our community right away. The sooner you do this, the more familiar we'll be with your name and your work.
- First, read the GSoC Student Guide to get familiar with Google Summer of Code.
- Create an OpenMRS ID and a personal space on your wiki and tell us about yourself. Here's a great personal wiki page from a MediaWiki student you might want to use as a guide.
- Join our developers mailing list to keep track of what's going on in our development community.
- Join our IRC channel and introduce yourself – meet some other community members and tell us about yourself and why OpenMRS is interesting to you. Spend lots of time in IRC getting to know us.
- To start, install OpenMRS (just like a user would) and learn a bit about how it works. If you have problems, write the developers mailing list and we'll help you work through them.
- Set up your development environment and fix some simple bugs listed on our Introductory Tickets list. Read Getting Started as a Developer for details on how to do this. You will need to have committed OpenMRS code to submit a successful application.
- Join our Developers Forum every Thursday to learn about the latest activities & work happening in our community or join an OpenMRS University call every Wednesday. You can participate by telephone, Skype, and online via Adobe Connect.
- Interact with our community. Continue to ask smart questions (what?) on our mailing list or hang out on IRC to ask and answer questions.
You should have expected to see the following questions on student applications:
- Who are you? What are you studying?
- Please provide the URL to your wiki personal space. (If you don't have one yet, please create one.)
- Why are you the right person for this task?
- Do you have any other commitments we should know about?
- List your Java experience.
- List your web interface experience.
- List any previous experience working with open source projects. (This experience is not a requirement.)
- Please provide links to websites created by you and/or source code examples.
- Do you have experience with Spring/Hibernate/DWR/HL7/Tomcat/MySQL/AOP? (Experience with any/all is not a requirement.)
- What is your preferred method of contact and how should we reach you with it? (phone, email, Skype, IRC, IM, etc.)
- Please include your IRC nickname used when visiting our channel previously.
- Provide ticket numbers of any patches/code you have committed to the OpenMRS code base.
Checklist for a successful application
- Join us in IRC before you apply. We're looking for applicants who have interacted with the community, asked some insightful questions, and made even small contributions (completed some intro tickets). Don't be afraid to ask questions.
- Knock out one or two introductory tickets. This demonstrates that you are self-motivated, makes you familiar to the developer team, and gives you a taste of the development process. Keep track of the issue numbers that you work on. We'll ask you for them in your application.
- Use the title of the project idea 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".
- 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.