Skip to content

Latest commit

 

History

History
107 lines (86 loc) · 5.36 KB

APPLICATION-GUIDE.md

File metadata and controls

107 lines (86 loc) · 5.36 KB
Raw

Applying to work with Mozilla in GSOC 2020

This document is a rough guide to what we are looking for in a GSOC application, and in the applicant. It should not be interpreted as a checklist, but it does list both what we would like to learn about an applicant and pitfalls to avoid in the application process.

Mozilla does not assign "pre-work" to prospective applicants; while it might be helpful for us in assessing applicants' abilities - and we always want to be open to new contributors - we also don't want to treat GSOC acceptance as a prize you might win if you volunteer hard enough. You are always welcome to download our code and learn about our teams, products and build processes but as a participant the best approach is to use what you learn to inform an excellent GSOC proposal, not to think that you need to rack up "points" in order to be considered.

What we would like to see

Perhaps obviously, we need a few specifics: Your name, email, telephone number or other contact method, your country of residence, timezone and primary language. We'd like to know about your programming experience, as well; this can be work or internship experience, other open source projects you've contributed to, and what you've worked on in school. What you have done and what you have learned are both valuable here.

Beyond that, the questions we would like to see answered in your application include:

  • What project are you applying for?
  • Do you understand the requirements for it, and -
  • Are your skills and experience a good fit for this project and it's goals? In short, why you, and why us?

The best applications we receive tend to answer these questions with project diagrams and work schedules, breaking down projects into their deliverable components and describing the timelines on which these components might be shipped.

This isn’t necessarily the schedule we’d hold a successful applicant to or even how the final project will end up looking; scope changes are normal and you will ultimately work with your team to determine the best path forward. What’s important here is that we see your ability to sketch out a realistic work plan. Writing software is hard and scheduling software is harder, and our priority in this is to set up these projects and the people participating in them for a successful summer. We consider this step to be an important leading indicator of that success.

Strong applications also note that you've made other choices outside GSoC that are roughly aligned, in some way, with the project itself. A hypothetical application to work on audio compression algorithms from somebody who has previously worked on music applications, for example, might be better-received than one from somebody whose primary career focus has been front-end web development or mobile applications.

Finally, do you have any other commitments during the GSoC period, and how will they affect your work? These aren't normally deal-breakers; in the past we've accomodated people who've needed to care for elderly relatives on a certain schedule, and in one case a student needed to be away from their work for a week in order to get married. We can be reasonably accomodating on this front, we simply prefer not to be surprised.

Errors to avoid

Every year we need to immediately discard an upsetting number of applications for avoidable reasons. Some of these may seem obvious, but they keep coming back, so you should be aware of them.

  • Failing to apply for a specific project. A surprising number of people apply for... nothing? I'm not sure how this happens, but I suppose in some sense those applications are all successful; in applying for nothing, they successfully receive nothing. If this is not your preferred outcome, please avoid this oversight.

  • Cut-and-paste errors, including irrelevant and superfluous information. If you've included the fact that you're licensed to operate a forklift in your application, we are likely to think that you haven't given this the thought it probably requires. If you've overlooked formatting errors or template residue in your application, what does that say about your code?

  • Suggest that hard work and enthusiasm can overcome a complete absence of demonstrated ability or relevant experience. While you may be willing to work hard, people with experience work hard too, so this argument does not hold a lot of water.

  • Bear in mind that project mentors at Mozilla are doing this work in addition to their usual full time jobs, and may not be able to respond to your inquiries immediately. At this time of year we get - to put it mildly - a lot of email, so the more clear and concise you can make your inquiries the easier they'll be to answer.

  • Finally, please double check that your application is actually finished. We've had a number of students with "FIXME" or "TODO" in their final applications, which we have to disqualify, however good the part that's already done looks.

Again, thank you for your interest in Mozilla and the Google Summer of Code. We look forward to seeing your applications, and hope that if you've got questions that you can find us on Matrix.

Please note