Writing your Google Summer of Code application - Kiwix
1 2 3

  • The basics

    Here are the main tips to help you in writing your GSoC application (thanks to the folks at Apertium!)

    1. Be realistic

    We’re more likely to accept ideas which are realistic than ones which are «way out there». But if you have a «way out there» idea, don’t panic! We’re still interested, but we’ll try to find a subset of it which is achievable in the time scale available. Time flies, project tend to overshoot or end up being more complicated that thought, so try to err on the safe side: this is a sign of maturity.

    2. Have a plan

    Three months may seem like a long time, but it isn’t. Show you have a definite plan with dates and deliverables, split into weeks is probably best. Don’t forget to leave time for getting familiar with the platform (this should be ideally before, or during the community bonding period), and for documentation. If you know of any breaks or absences beforehand, be upfront about them and plan around them.

    3. Dont ask to ask, just ask

    Important reading: https://dontasktoask.com/ and http://www.catb.org/~esr/faqs/smart-questions.html

    4. Read the ideas page. Please do.

    If you find yourself asking do you have any XYZ projects… – you didn’t read the ideas page and that will make us sad. So read it before asking questions!

    But if you have another idea, that’s great and we want to hear all about it. Simply show that you’re proactive and you will be in the top 10% already.

    More tips

    We’re not saying that following the advice below will automatically get you a mentor, but going through it will give you a pretty good chance!

    Join our Slack channel

    There’s a link to get an invite in the repositories. We don’t post it here so you are forced to read the contributing.md file. Once you are in the #GSoC channel, even if you’re idling or don’t say anything, you’ll discover more about how Kiwix works.

    Create a GitHub account

    But – you should already have one (or Gtilab, SourceForge, etc.). We want to look into previous work you’ve done, even if it’s a little game for your sister: it will tell us how you think and interact with other developers.

    Become familiar with Kiwix

    First, install Kiwix. Download a ZIM file or two. Play with it, and see what you could improve. You typically want language data from GitHub, core tools from our repo.

    The Kiwix culture

    When you think of Kiwix, think Wikipedia (Be bold!) or think Nike (Just Do It!). Preferably, both.

    Rule 1: Ask questions! Not generic ones, but specific ones, on the repo (so we know what they pertain to).

    Rule 2: No questions are stupid. We have all been new to Kiwix once, we have all needed to ask questions. Asking them is proof to us that you are serious. Even better: explain why you ask this question. A good summary shows us that you have done some thinking and want to confront an actual problem.

    Rule 3: When you suggest a fix, be ready to explain your reasoning behind it (i.e., why this particular approach is the best).

    If you think you know the problem better than the mentor does, it could be that you have misunderstood it. But then again you could be smarter: please ask why things are this way and not <insert smarter idea you had>.

    One more thing

    While your code is compiling, look through the GsoC student guide from FLOSS manuals.

  • Application template

    Your application should contain the following information:

    • Your name, country of residence and current (or last) school attended
    • Your e-mail address (and other information that may be useful to contact you)
    • Some information about yourself like:
      • Do you have any prior open source experience?
      • Link to your Github/Gitlab/etc. account
      • List of PR/issues from the Kiwix codebase that you have worked on

    Then write a proposal, including

    • A title
    • A summary of how you intend to complete this project and why you made these specific choices
    • A list of any potential challenges you can see at this point

    Finally, add a detailed work plan (including, if possible, a schedule with milestones and deliverables):

    • Week 1: milestone 1
    • Week 2: milestone 2 and 3
    • Week 3: milestone 4
    • Week 4: milestone 4 1/2 (it’s okay to be approximate as long as you show understanding of your challenges)
    • …
    • …
    • Project completed!

    Include time needed to think, to program, to document and to disseminate. Make sure to factor in time taken to run any experiments/debugging and write them up in your work plan.

    Do not send us your CV, and do not waste time writing a cover letter explaining why you’re the best. Simply show us your code and your ideas, they’ll speak better than you ever will!