Monday, December 2, 2013

GSoC Lessons: Part 1: Application Period

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:
  • A patch / pull request
  • IRC / email involvement / idling
  • File a bug (I mean this in the "Mozilla" sense: an actual bug, a feature request, etc.)
  • Fix a bug / make a commit
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.


  1. I'm not dismissing the flip-side consideration, but I think it would be important to consider how many past successful SoC projects might have not happened given the requirements we consider.
    I have no idea, but I know that students are often younger and the nature of that is less experience and doing new things for the first time.

    1. Thanks for your feedback! I'm not sure if it's just early in the morning here, but I'm having trouble understanding your sentence. I think you're saying: "Given more stringent requirements, how many successful GSoC projects would not have happened?"

      I agree that this would be an interesting number to look at. I'd also be curious about the other: "Given more stringent requirements, how many failed GSoC projects would not have happened?" Maybe it's worth cutting out a little bit of the good if you can get almost all of the bad! I don't know!

      I agree with your point about less experienced students and I think this fits into what I'm getting at the "patch / pull request" section above: it's not always feasible for a student to figure out the community, find a bug, submit a patch, etc. This might point to a larger issue that it's too hard for new contributors to get involved. I'm not sure making this a hard requirement is a good idea, but I think requiring a "patch / pull request" is a way to fulfill my three personal requirements above: "use, passion, and skill". This is certainly not the only way, however! (Nor is it a guarantee of any sort.)

  2. I think having the student fix a non trivial bug is interesting because it shows how the student will handle the review process: will he be happy to be mentored to improve the quality of his submission? Will he be annoyed that his patch isn't perfect the first time? Having these interactions tells a lot about how it will feel like to mentor the student during the summer.

    I don't think it should be required; but students should know it will be taken into account by possible mentors while evaluation their applications.

    1. I agree it's interesting to see how they handle feedback from a community and you can learn a lot from it! I don't know how I feel about "requiring" it (What about for someone applying for a project that is from scratch?) But I think it should be strongly encouraged!