I briefly talked about my experiences at the Google Summer of Code 2013 Mentor Summit. I’ve been pretty remiss in sharing what was actually discussed there and for that I must apologize! This will hopefully be one of a few posts about what I learned and discussed at the Summit.
The first part I’d like to talk about is the application period: welcoming students, requirements for student applications, etc. Much of what I say on here is just ideas I’ve heard other organizations implement (with my personal opinion on them, please don’t think this represents what Mozilla is suggesting students do, or even what I’m suggesting Mozilla should ask students to do!)
I had many separate conversations about what is required for an application to be accepted. It seems that Mozilla is actually on the side of one of the easier organizations to apply to. We don’t (to my knowledge) require that students have contributed at all to the community beforehand. It is possible that some smaller communities inside of Mozilla require more than just an application, but there does not seem to be any rule across Mozilla. I said I wouldn’t offer my opinion above…but I lied: I think Mozilla should make it clearer to applicants what is expected of them before the application.
There seem to be a variety of things different organizations “require” before accepting a student application, for example:
I think all of these have pros and cons and making any a hard and fast rule would probably be a bad idea. Personally for Instantbird, we greatly encourage students to idle on IRC and get to know us; and to fix a minor bug or two or three. What I’m always looking for is: use, passion, and skill.
Asking for a patch / pull request (I include these together since they really just depend on how an organization accepts changes) can be a bit intimidating for a new user. I think this can be a pretty rough thing to ask for new contributors that might not want to share their work publicly with a large group of people (on a mailing list, public bug tracker, etc.) where they might be wrong. Even after being part of the community, I find that GSoC students are often very unwilling to publicly share code unless it’s “perfect”, but I digress. Anyway, if you’re considering “requiring” this, I think it should be pretty clear that this changeset doesn’t need to be perfect, it just needs to show that the student is able to read code, understand a bug report, provide a fix and test it.
I think it’s perfect reasonable to ask students to idle on IRC and join mailing lists. They should definitely be trying to understand the community before attempting to join it. It isn’t just a matter of if the community thinks the student would be a good fit, but also the student must ensure they can fit into the community.
Filing a bug is a great way for a student to show a few different things: they’ve used your software; they’ve used your software enough to find a bug in it (and there most likely is one!); they’re able to express themselves in a clear and concise matter. If you’re lucky they’ll find something that actually annoys them and fix it themselves!
I have fix a bug listed last. You might ask how this differs from submitting a patch…and it does! Fixing a bug requires a patch to go through whatever review process your project uses, but builds upon just submitting a patch. My thoughts on this are pretty similar to just submitting a patch, but it depends on how large the bug is.
Something I found interesting is that almost everyone I talked to didn’t treat their GSoC students any differently than they would treat a new contributor to their project. They still had to prove they were worthy of commit access, etc. Is there anything else you ask of your students before they apply to GSoC? I’d love to hear it!
Some other topics I’ll hopefully find some time to write about include: community lessons, and handling a failing student. The community one will be very not-GSoC focused and could apply to just trying to incorporate new contributors…but I’ll include it in this series.