Difference between revisions of "Top tips for GSOC applications"

From Apertium
Jump to navigation Jump to search
m (→‎Other tips: sourceforge account)
Line 9: Line 9:
* '''Be planned'''
* '''Be planned'''
** 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.
** 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.


== Advice for GSoC candidates ==

generally, you should :
* 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 [Apertium-viewer].
* browse the wiki, especially [[Apertium New Language Pair HOWTO]]
* in a language pair try to edit the files, break stuff, and then make it work again


==Other tips==
==Other tips==

Revision as of 16:23, 24 March 2010

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.
  • Be planned
    • 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.


Advice for GSoC candidates

generally, you should :

  • 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 [Apertium-viewer].
  • browse the wiki, especially Apertium New Language Pair HOWTO
  • in a language pair try to edit the files, break stuff, and then make it work again

Other tips

  • 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!)

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