Things I learned from reviewing GSoC proposals
This past summer, I’ve had the honor to participate as a mentor for the Oppia Foundation in the Google Summer of Code program. With this opportunity came the responsibility to review student proposals. I’ve rarely been on the reviewer side of application processes (I’m usually the applicant!), and after reading a few online submissions, I noticed some trends among the remarkable proposals.
For some background information, GSoC is a coding-intensive program for students. Students apply through GSoC to work with an open source organization on a 3-month long programming project. Due to its project-oriented nature, students are to delineate what they want to work on (and how) in their proposals.
Back up your ideas with evidence.
I’m not sure how much this applied to other organizations, but for Oppia, our prompts were generally more open-ended. For example, one of the suggested project ideas was to design a learner dashboard, but we didn’t specify exactly how the dashboard would work. Open-ended prompts like this left space for freedom and creativity; in turn, it became the students’ responsibilities to sell their ideas.
Presenting results from usability studies is a great way to back up your design decisions. Some student applicants detailed the user feedback behind each UI element, and this really gave their proposals an edge. By convincing us that their designs were evidence-driven, they promised an end product that is usable and would address real user needs.
Comparing different algorithm performances is also an awesome way to demonstrate how and why you chose certain implementation strategies. Basically, whether it’s design or development, show your reviewers that you’ve thought about the issues thoroughly, and that your decisions are supported by facts or logic.
Show that you know what the project is really about.
As stated above, Oppia outlined a couple of design challenges for applicants to take on. Having a clear picture of what the challenge is about is vital to proposing a good solution. Among the proposals that were shortlisted, in addition to proposing good solutions, some eloquently argued for how their ideas can address the design challenge. This gave us confidence in considering their candidacy.
Show that your ideas can scale.
Many students included wireframes to illustrate their solutions. However, many of the solutions lacked the ability to scale. For example, some designs would look messy if there were 50, instead of 5, content cards. Some designs would quickly become unusable if the users were browsing the website on smaller devices. One tip is to consider the worst case scenario: what would the interface look like if the user were browsing the site on a tiny phone with 100 information items? Of course, it’s not always necessary to be this extreme, but if the design is usable at this scale, then the design will probably be more usable in general! This applies to the code base, too. Is everything going to be hard-coded? Can the system dynamically load the content without compromising the speed? Ideas that scale are ideas that sell!
Say what you mean, mean what you say.
Communication skills matter! It was much easier to read the submissions from students who were able to articulate their ideas well. From what I’ve seen, here are some elements that stood in the way of clear communication:
- Excessive and unclear use of pronouns.
- Intricate diagrams.
- Awkward sentence structures.
- Random jumps between ideas.
- Vague phrasing. This happened quite a lot with deliverables — be concrete and clearly state what you plan on delivering!
Organize your proposal.
Some participants organized their proposal neatly, and that effort definitely did not go unnoticed. An organized proposal (along with an easy-to-read layout) helps reviewers to follow the ideas better. Some ways to achieve this: logically structuring the proposal, separating paragraphs into sections, and clearly labeling each section.
Rejections aren’t personal… ask for feedback!
This seems obvious, but it’s something I think should be said. When I was job-hunting and getting rejected, there were countless instances when I wondered if I were un-hire-able.
Now that I was on the reviewer side, I realized how tricky it is to pick between applicants! We’ve had to reject good applicants in order to accept exceptional applicants. We’ve had to turn down interesting proposals simply because they weren’t quite the ideas we were looking for.
In any case, I think it’s great to ask for feedback, so that you know what you can improve on.
Open source, open opportunities!
For students who are interested in contributing to open source code, I highly recommend the program. It’s great to have something functional and deliverable within a 3-month period. Students applications will open for the 2018 program in March — while Google has yet to announce the participating organizations (in fact, organizations aren’t applying until January 4th), it’s never a bad idea to start early and get some experience with open source contributions before then!
