-
Notifications
You must be signed in to change notification settings - Fork 1
R GSOC FAQ
- Students are now called contributors.
- No proof of college enrollment required. https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation
- Two project sizes, 175 and 350 hours over 12 weeks. (previous year was 10 weeks, or about 350-400 hours total if student works 35-40 hours per week)
- Extended timeline coding period starts June 13 and ends Nov 21 rather than Sept 12.
Mentors should ideally provide an email and github ID so contributors can easily get in touch. Mentors may be provide other contact info (linkedin etc) but that is not a substitute for email/github which are the most important.
First of all, it is not OK to favor contributors from the same institution (all contributor applications for a project must be considered). The official GSOC rules state: “UNIVERSITIES: If you are a university, we expect you to select contributors outside of your program. Selecting contributors from your university is okay (1 contributor tops) but if you accept more than 1 contributor from your university you likely won’t be accepted into GSoC again. You should be bringing new contributors into your project.” Therefore, for R project to be accepted as an organization in future editions of GSOC, accepting contributors from the same institution as their mentor needs to be an exception (not the rule).
However in the past we have accepted contributors from the same institution as their mentor, as long as there is another co-mentor from another institution — the idea is to encourage contributors to join the wider R package development community, and to make sure the project is beneficial to the wider useR community. Please keep in mind that the point of GSOC is to bring new contributors into the free/open-source software development, and not to finance the summer research projects of university contributors.
Each GSOC mentor should be ready to spend some time advising their contributor on their R coding project. For a particular project, we normally require two mentors from different physical institutions (this helps to make sure that contributors still get mentorship, even if one of the two mentors drops out of GSOC). For each project there should be at least one mentor with:
- previous GSOC experience
- R package development experience
- domain expertise
(please list qualifications in the Mentors section of the project idea wiki page)
After the hard deadline for contributor applications to Google, mentors and org admins will rate all contributor applications. Google will assign us funding for a certain number of contributors, and only the top projects will be funded.
After a mentor has written a project idea, how much time should he/she expect to spend reviewing potential contributors?
If you write a good project test then you should be able to quickly figure out which contributor (if several apply for your project) is the best. Once you find the best contributor, you should probably spend a few hours reading and suggesting improvements to the application that he/she writes and will submit to Google.
What is the amount of time that mentors are expected to invest on contributors during the 3 months of coding?
You will need to allocate at least 1 hour a week for a skype call + the amount of time it takes to respond to contributors questions via email. For the contributor to be successful he/she will need you to be responsive to his/her questions. As a mentor it is your responsibility to only accept contributors that you will be able to adequately mentor. So a mentor who does not have much time must only accept a very autonomous contributors who does not need much more guidance than the weekly skype call, and a mentor with more time may be willing to accept a less autonomous contributor.
It depends on the project idea. For my Animint project I had an application from Carson Sievert, who was clearly an ideal contributor, so I had to turn down a couple of other applicants. However some other projects never got any contributors who applied.
You should clearly define what you expect from your contributors in the “test” part of your project idea. In my experience the best contributors will build on your project proposal and add their own ideas. For example Carson Sievert worked on my Animint package last summer, implementing facets and a bunch of other things that I suggested, and then he went on to implement shiny/Rmd integration which was not at all on my TODO list, and he did a great job pretty much without my guidance.
Yes if all the contributors that apply are clearly not good enough (or not autonomous enough), you should not accept them. However the R project regularly gets more slots than we can use from Google, so it may be worth it to take a chance on a contributor that you are unsure about.
Keep in mind that the main purpose of GSOC is to teach the contributors about open-source R package development, and that advancing your particular project is of secondary concern.
Also keep in mind that a contributor must establish contact with mentors (preferably by completing project tests to demonstrate that he/she is a good match for the project) and then do a formal application to Google with a specific project proposal.
No. Contributors should pick one project and spend time creating a really good application for that project.
There is no mentor-only forum but you can get in touch with other mentors (as well as contributors) via the gsoc-r google group.
There can certainly be more than one contributor per R package, as long as the contributors are working on different aspects of the package, and that this is clearly reflected in their project proposals. However, if there is a lack of slots available from Google, we will prefer to allocate them 1 for each R package. In that case, mentors may have to make a choice between two (or more) good contributors.