Top tips for GSOC applications

From Apertium
Revision as of 18:01, 20 March 2011 by Jimregan (talk | contribs) (→‎Other tips: * If you think you know the problem better than the mentor does, chances are you have nowhere near the amount of experience necessary to work on the project.)
Jump to navigation Jump to search

Writing your GSOC application

Here are the main three tips to help you in writing your GSOC application with Apertium.

  • 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.
  • Be appropriate
    • Demonstrate you have a knowledge of Apertium, how it works and the problem it has that you'd like to solve.
  • 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 and for documentation. Anyone thinking of working on a language pair should make sure that they read about testvoc and other quality controls, and factor those in.
  • Get in contact ASAP!
    • We get a lot of proposals: some good, most bad. Get in contact with your potential mentor as soon as possible by sending your proposal to the mailing list, and asking for feedback. Be responsive to feedback. Refine your application based on feedback. If the mentors remember you, your chances of being picked are higher. If you push a proposal through the Melange site without prior discussion, there's a good chance it won't even be read.

Other 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!

  • A good idea for newbies would be to install Apertium and read through the new language pair HOWTO. This might even give you some more ideas!
  • Create a username on this Wiki, this way we can work collaboratively on applications.
  • Have your sourceforge username at hand... if you don't have one, create one. (Run, don't walk!)
  • Join IRC, even if you're idling or don't say anything, you'll discover more about how Apertium works.
  • When you think of Apertium, think Wikipedia (Be bold!) or think Nike (Just Do It!). Preferably, both.
  • Rule 1 here: Ask questions! Keep asking. The more you ask, the better.
  • Rule 2: No questions are stupid. We have all been new to Apertium once, we have all needed to ask questions. Asking them is proof to us that you are serious.
  • First install Apertium and a language pair (look in the wiki)
  • Update the wiki so the next reader wont encounter the same problems as you did
  • Play with some language pairs, perhaps using Apertium-viewer.
  • Browse the wiki, especially Apertium New Language Pair HOWTO
  • In a language pair of your own choice, try to edit the files, break stuff, and then make it work again — and then tell us about it
  • If you think you know the problem better than the mentor does, chances are you have nowhere near the amount of experience necessary to work on the project.

Template

Name:
E-mail address:
Other information that may be useful to contact you:
Why is it you are interested in machine translation? 
Why is it that they are interested in the Apertium project? 
Which of the published tasks are you interested in? What do you plan to do? 
Include a proposal, including 
    * a title,
    * reasons why Google and Apertium should sponsor it,
    * a description of how and who it will benefit in society,
    * and a detailed work plan (including, if possible, a brief schedule with milestones and deliverables).
Include time needed to think, to program, to document and to disseminate.
List your skills and give evidence of your qualifications. Tell us what is your current field of study, 
major, etc. Convince us that you can do the work. In particular we would like to know whether you 
have programmed before in open-source projects. 
List any non-Summer-of-Code plans you have for the Summer, especially employment, if you are applying for 
internships, and class-taking. Be specific about schedules and time commitments. we would like to be sure you have 
at least 30 free hours a week to develop for our project. 

Work plan

  • Week 1:
  • Week 2:
  • Week 3:
  • Week 4:
  • Deliverable #1
  • Week 5:
  • Week 6:
  • Week 7:
  • Week 8:
  • Deliverable #2
  • Week 9:
  • Week 10:
  • Week 11:
  • Week 12:
  • Project completed