I’m creating this topic to help new GSoC mentors like me, and consult with experienced mentors on how to’s, potential challenges, etc.
It would be great if some senior contributors could shed some light on topics like day-to-day communication with internee for remote assistance. For example, how different time zones affect the progress, or training of prerequisites, like version control using GitHub; Agile development using Trello; building with Maven; Documentation on Wiki; Eclipse/IntelliJ plug-ins, etc.
Thanks for raising that @owais.hussain, the mentor manual and Expectations for Mentors provide some broad guidelines, but don’t really cover those concerns based on others’ experiences. The Expectations for Students may also help a bit more to get an idea of what’s expected of students, and the potential issues that may arise.
Student GSoC blogs can also be good reading to gain further insight. Otherwise, if there are common issues (or advice) that mentors have, we can try put those together in a Mentor FAQ through the course of the program this year, for future mentors to refer to.
This is a likely scenario. Students can submit up to three proposals for different projects across organizations, and similarly, we should expect to have several applications from multiple students for the same project. Once the student application process opens and applications start to be submitted, project mentors will be asked to review these applications. Mentors are encouraged to review applications for the projects they are personally involved in, as well as those for other OpenMRS projects. We will set up a meeting for project mentors during this time to discuss application evaluation criteria and review student proposals as a group. I’d encourage mentors to read through the chapter on Selecting a Student from the GSoC Mentor Guide. This is a great resource exploring student motivations and general student selection criteria.
In most cases, your potential mentor(s) will have lots of ideas and preconceptions about each project that were not included in its original description on the Project Ideas page. Discuss and research the project idea in as much detail as possible. You may even consider preparing mock-ups (illustrations, powerpoint, or websites) to help clarify your understanding and vision of the project. You will want to discuss the scope of the project idea, including which parts are critical versus optional for the summer timeline. This process will directly feed into your application and ideally distinguish it from all the others. Just think about it: if you’ve helped clarify the project idea and contributed to an actual plan of action, it makes it an easy process for mentors to evaluate your proposal and give it a high ranking!
In other words, students are encouraged to begin discussing projects, contributing code to OpenMRS, achieving /dev/1 status, and working on introductory tasks related to the projects they’re interested in. As they begin to develop their project applications, they may want to start spec’ing out the actual project tasks, mocking up ideas and the high-level architecture. However, they cannot officially start working on the project before the start date, since applications have not been submitted yet, and students have not been selected yet. Students should be aware of these expectations if they have familiarised themselves with the guidelines for interested students and GSoC Student Guide.
Sidenote: If you’re looking for ideas for relevant introductory tasks for students to work on, please raise this on Talk to discuss further.
in the event multiple students are applying for the same project – you will evaluate the completeness of their proposals as well as the quality. I’ve seen really good ones and I’ve also seen proposals that were laughably bad. I started collecting those.
Students should at a bare minimum:
Have a DETAILED but not too detailed timeline of how they will spend their summer – this is a REALLY tight timeline – and leaves little room for getting stuck on little things.
they should have UI mockups
Not working on any issues prior to applying is an instant rejection in my eyes.
I have a weird question. If I see two students, one with enough potential to complete the project on her own without any real need for mentoring, and another who may or may not complete the project, has weak SE background, and will require some mentoring effort.
The first candidate is an opportunity to solve a community problem.
The other candidate is an opportunity to create a problem solver.
Which one to accept?
@owais.hussain There are some basic qualifications that are important (students should be technically skilled, have good communication skills, and be self-disciplined with sufficient availability to complete a project), but there’s also more to it than simply finding the student with the highest level of expertise. Other factors should be considered, such as the quality of their proposals, how motivated they are to work on a project, their fit within the community etc.
If a student doesn’t meet the basic criteria, this is likely to show in their proposal(s). Having said that, if you find that an interested student is lacking sufficient technical skills as you engage with them on a project, it’s fine to communicate these things with the student in a constructive manner, possibly as points to address/consider when writing up their proposals.
Hope that helps, I’m sure others have opinions and insight into this too.
One more point to mention - you do not need to make these decisions alone. Mentors will have an opportunity to review and discuss feedback on proposals as a group. And remember that students can submit applications for more than one project, so it’s also about finding the best fit of students across all the projects.
Definitely keep me in the loop @owais.hussain regarding the proposals… have there been any submitted yet? I probably wasn’t as engaged as I should have been during the initial stages but would definitely like to weigh in!
The primary goal for GSoC is to give students an awesome experience in open source coding so they become lifelong productive contributors to open source… and, hopefully, some of them will stick with OpenMRS. Coding skills are certainly an important factor, but not the only one. For example, a more junior programmer with a passion for the domain, a great personality, and the intellectual curiosity to push themselves to learn & grow might be a better investment than a very skilled programmer with the personality of an ice cube who is just doing GSoC for the money.
We have several examples of GSoC students who have spent years contributing to OpenMRS and/or going on to successful careers because of their time with us.
I’m reviewing the proposals submitted to me. I’m confused about a few things:
Currently, the proposals are in Draft format. When will they be finalized. Is the 27th March deadline for final proposal submission or we have to make decision on our selection by this date?
If I Press the “Want to mentor” button on GSoC site, does it mean I have made final decision about mentoring the student? Or is it only an indication of interest, which can be for multiple students?
How will the student be selected? Is it primary mentor’s call, or a joint agreement between mentors and GSoC admin?
The draft proposals will become ‘final’ after the deadline day provided the student has given a proof of enrollment. As far as our decision on project and proposal selection is concerned, we can make it after the deadline.
This is just an indication for other community mentors that you are interested in mentoring that particular student.
It’s a joint agreement. All mentors along with the org admins will work together in deciding what projects and what students they want to finalize.
