We rank the proposals that target Kiwix and request a number of slots based on those.

We’re more likely to accept ideas which are realistic than ones which are “way out there”. But should you actually 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.

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.

Important reading:

https://dontasktoask.com/

http://www.catb.org/~esr/faqs/smart-questions.html

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.

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.

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 and core tools from our repo.

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: There are no questions. We have all once been new to Kiwix, we have all needed to ask questions. Asking them is proving to us that you are serious. Even better: explain why you are asking your 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 a certain way, and not.