User:Diadara536/gsoc-2013-application

The sooner we know about your project proposal the better. We can save you a lot of time by bringing more eyes to your draft and pointing you to the right direction. You are encouraged to start drafting your application as a subpage of your mediawiki.org userpage as soon as possible. Once you feel the basic idea is framed, the next steps will be to find or file an enhancement request at Bugzilla and send an email to the wikitech-l mailing list including the links to your wiki page and your bug report.

If you have any question the best place to ask is the Discussion page related to the program you are applying to.

Identity

Name:Nithin P Saji
Email:nithin111@gmail.com
Project title:On screen keyboard for Jquery.ime and other addition of other features

Contact/working info

Timezone:IST
Typical working hours:10 am to 2 pm flexible
IRC or IM networks/handle(s):diadara

Project summary

Two or three paragraphs describing your project -- what it means to accomplish, and how it will benefit MediaWiki or Wikimedia projects such as Wikipedia.

Start your paragraph with {{tracked|nnnnn}}, where nnnnn is the number of the report linked to your proposal in Bugzilla. If you project has been discussed at the wikitech-l mailing list then include the URL to the thread as well.

Deliverables

It should be possible to break down your project into some bullet points describing particular features or milestones which can be reached individually. Consider that we may wish to roll out the system for testing while at an intermediate stage of completion, and that time estimates might vary, leaving you with more time than you expected or (more likely) a lot less -- some features can be pushed back if you end up short.

Required deliverables

• ...
• ...

If time permits

• ...

Project schedule

Try to break your deliverables into "milestones" which can be reached in sequence. Show us your estimated schedule of when you'll reach each functional milestone. Don't forget that real time may change -- leave enough buffer for your required features to be completed!

We suggest that you budget one-half to one-third of your time for merging with trunk, pre-deploy review, testing, bugfixing, documentation of course, and other integration work.

About you

We don't just care about your project -- you are a person, and that matters to us! What drives you? What makes you want to make this the most awesomest wiki enhancement ever?

You don't need to write out your life story (we can read your blog if we want that), but we want to know a little about what makes you tick. Are you a Wikipedia addict wanting to make your own experience better? Did a wiki with usability problems run over your dog, and you're seeking revenge? :-) What does making this project happen mean to you?

Participation

We don't just want to know what you plan to accomplish; we want to know how. Briefly describe your work style: how you plan to communicate progress, where you plan to publish your source code while you're working, how and where you plan to ask for help. (We will tend to favor applicants that demonstrate a clear vision for what it means to be an active participant in our development community.)

Past open source experience

Do you have any past experience working in open source projects (MediaWiki or otherwise)? If so, tell us about it! If you have already written a feature or bugfix in a Wikimedia technology such as MediaWiki, link to it here; we will give strong preference to candidates who have done so.

Any other info

Please add any other relevant information -- UI mockups, references to related projects, a link to your proof of concept code, whatever. There are no specific requirements, but we love to see people who love what they're doing. Show us you're excited about this project and have an interest in the background and are considering how best to make your idea work.