| Table of Contents |
|---|
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 projects to provide quality mentorship during Summer of Code. Note that 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
Commit to spending a minimum of 4 hours each week to be available to guide and mentor students (not just your assigned student).
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.
Prepare a good overview of your project idea(s) and have them linked to this wiki page.
Watch OpenMRS Talk for questions about your project idea(s).
Review student proposals and work with other mentors and organization admins to select the best candidates for OpenMRS.
Treat returning students who have applied with as much (or more!) scrutiny than first-time students.
Selecting Students
Selecting the most suitable student for the project you mentor is a crucial part of GSoC as it directly affects the outcome of the program. When evaluating candidates, you can consider the following things:
Understanding of the Project: Check if the student clearly understands the project idea, how they plan to approach it, and what outcomes they expect. Look for well-explained proposals that show the student has done research on the project, including its background, goals, and why it matters to OpenMRS.
Technical Proficiency: Evaluate the student's technical ability to execute the project successfully. This can be done by reviewing their prior work, such as code contributions, projects, GitHub activities,
etc.
Alignment with Project Goals: Determine how well the student's proposal aligns with the goals and requirements of the project. Look for creativity, innovation, and feasibility in their proposed solutions.
Community Engagement: Consider the student's involvement and engagement with the OpenMRS community. This includes participation in discussions, contributions to documentation, and responsiveness to feedback.
Be Mindful of AI-Generated Proposals: With advancements in technology, there might be instances of AI-generated project proposals. While these proposals may appear polished, look for genuine understanding, personalization, and originality in the student's ideas.
Should you require additional information from students, feel empowered to reach out to them directly and request the necessary details. You are also encouraged to assign additional tasks to them if you need further assessment of their abilities. We welcome your proactive engagement in ensuring thorough evaluation and selection processes.
Refer to the GSoC Guide on selecting a student for additional insights and best practices.
You can also use our marking rubric as a guide when assessing student proposals
. You can find it here. While it's not mandatory to strictly adhere to this rubric, consider its guidance for pivotal decision-making moments.
In the event that you encounter multiple qualified students for a project, please reach out to the Org Admins for assistance. They can facilitate recommendations of these students to other project mentors. Should another project mentor express interest in selecting them for their projects, the admins will coordinate with the students and Google to make the necessary arrangements.
Once you have completed the evaluation process, please send your outcomes to the Org Admins. They will review your decisions and compile the selected student list to be sent to Google. Ensure that you provide reasoning behind your selections or rejections to the Org Admins, enabling them to address any fairness concerns effectively. Your transparent and well-founded justifications will contribute to maintaining integrity throughout the selection process.
Feel free to reach out to the Org Admins if you require assistance or have any questions during the selection process. Their support can be valuable in making informed decisions and ensuring a successful GSoC experience for both mentors and students.
After student selection
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.)
Read the GSoC Mentor Guide and ask questions if you have them.
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.
Reach out to the Summer of Code organization administrators if you have questions or concerns.
If the student is not active during the community bonding period, please contact the organization administrators.
During the program
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.
Complete a short "progress report" each week to help stay on schedule and catch potential problems early.
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.
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
Stay in touch with your student and help them find interesting ways to stay involved with OpenMRS.
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!
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 mentors for one other project, since the need for backup mentors to take over the role of primary mentor for a project is very rare.
After student selection
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 the student and primary mentor to build a habit of CC'ing you on communications.
Read the GSoC Mentor Guide and ask questions if you have them.
Reach out to the Summer of Code organization administrators if you have questions or concerns.
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
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.
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
Make sure to congratulate a successful student!
If you aren't already, consider becoming a Primary Mentor.