User:Jesse Groppi/GSOC 2010

Identity
Name: Jesse Groppi

Email: [mailto:jagroppi@gmail.com email]

Project title: Edit Forms

Contact/working info
Timezone: CST (GMT/UTC -6) prior to project, during project I could be in GMT/UTC

Typical working hours: Any

IRC or IM networks/handle(s): IRC: DuTempete; Skype: jesse.groppi; Google Wave: jagroppi AT googlewave DOT com; MSN: jagroppi AT gmail DOT com

Abstract
Wikimedia projects have been around for nearly ten years, now. There are millions of pages on thousands of subjects written in thousands of differing styles. This is an intimidating concept for editors and readers alike.

Over the years, editors and administrators have agreed upon certain styles for similar types of content to be written in. The method, however, has been imperfect. It is absolutely normal to find pages that don't fit their designated style, and most new editors begin editing without knowing there are guidelines at all.

My project is designed to benefit the content needing to be created and edited in a similar format many times over. In the editor, templates will be used to produce sets of fields at the beginning, the end, or in lieu of the edit box entirely. Entire namespaces can be set to always display a certain template, and individual templates can be categorised in order to be made available via drop-down menus.

This extension (or core mod) would help ensure that format guidelines are followed by making it easier to do, as well as enabling new editors to be informed from the very beginning. Most importantly, this project would improve usability for both editors and readers.

Templates
First, I should state that I'm aware of some planned changes to templates within the usability initiative. Any changes I would like to make are either identical or in line with the initiative's plans. While I'm working on the template code, I'd like to maintain communications with the folks working on the initiative.

The changes I have in mind start with adding metadata. Templates will have types and parameters will have input types. Parameters will also be able to contain lists of possible values for use in drop down menus.

Error handling will include the ability to coincide with templates that have not been updated with the new syntax. The metadata will have default values such as inline template types, which aren't affected by the new code, and text field entry for parameter input types.

About you
Hello! My name is Jesse, and I'm an adult student from Chicago, Illinois, in the United States. Programming and web design have been hobbies of mine since I was, shall we say, much younger. I am mostly self taught, though I have taken a couple classes in order to meet the requirements of a teaching endorsement in computer education. I am, in fact, a student of education; my joint bachelor's degree in English and drama should be completed in 2012, but my ultimate goal is to receive my Post Graduate Certificate of Education, also from the University of the West of England, in 2013.

People often look at me incredulously when I say I'm a writer that is also interested in programming and mathematics. However, I find them to be rather similar to each other. All three require a strong grasp of logic, thinking creatively and outside the "box", and the ability to convey meaning to others. That said, I'll admit that programming scratches a mental itch that I can't satisfy elsewhere. I enjoy it immensely, and get much gratification from working with the open source and free knowledge communities.

Tasklist/Deliverables
This section outlines the step-by-step tasks involved in my project. Points in bold are deliverable products.

Absolute basics

 * 1) get familiar with the specific files, classes, and methods involved in the project
 * 2) * Draw up a flowchart of the template code
 * 3) * Draw up a flowchart of the editing code (will probably need to be super-simplified)
 * 4) flowcharts for expected changes/hacks to existing code
 * 5) * template code
 * 6) * editing code
 * 7) mock-up of interface layout
 * 8) plain language or "pseudo" code
 * 9) * template pseudo-code
 * 10) * editing pseudo-code
 * 11) * wiki syntax interface pseudo-code
 * 12) write template changes
 * 13) test template changes
 * 14) write interface changes
 * 15) test interface changes
 * 16) write editing changes
 * 17) test editing changes
 * 18) test overall mod/extension

Niceties in order of priority

 * 1) Skinning
 * 2) * Monobook
 * 3) * Vector
 * 4) Localisation
 * 5) * preparing elements for localisation
 * 6) * obtaining translations
 * 7) * implementing localisation
 * 8) Favourite templates
 * 9) * preferences that bring up commonly used templates to the top of the menus

Project schedule
I've made a Google Calendar that best explains how I would like the flow of work to go.

Participation
I tend to work best in a very structured environment. If you look at the Google calendar I linked above, you can see that is exactly what I've created for myself. I plan to start work and information gathering as soon as I receive my acceptance notice, and I've created a very probable work schedule that is, of course, not set in stone.

I am also a stickler for constant communication, both for accountability and teamwork purposes. I do consider my mentor, myself, and the MediaWiki community a team; if this project is not for them, it's hardly worth the effort I plan to put into it! On the calendar, you can see I intend to have a meeting with my mentor immediately, so that we can get to know each other and discuss anything that needs clarification before I begin work. Once that is concluded, I've allotted the next week for meetings with interested WMF projects and WikiEducator.org. I want them to be able to provide input at all stages of the project. I also intend to post daily updates on my progress. There are also mandatory weekly meetings with my mentor, with optional on-call meetings on a second day (The days and times I picked are only for example).

My goals for communication and participation are to make it easy for the community and mentor to follow along while also minimising their time commitment to the project.

Past open source experience
I have no direct experience contributing to open source software, however I have been working with the MediaWiki platform since 2007, when I began editing WoWWiki.com. I haven't made many contributions to WMF projects, but more recently I've become involved with WikiEducator.org, the founder of which is a member of the WMF Advisory Board, and I've contributed to several Wikia projects.

Better related, I've started my own MediaWiki site, from which I learned PHP and gained a familiarity with the internal code. I designed the skin, and hope to package it for use by other community members as soon as I iron out all the kinks.

Any other info

 * links to suggestions mentioning wiktionary
 * links to wikieducator OERNZ requirements and other discussions
 * basic mock-up of:
 * prepend wiki
 * prepend WYSIWYG
 * append wiki
 * append WYSIWYG
 * takeover wiki
 * takeover WYSIWYG
 * requesting suggestions for templating (infobox, navigation, category requirements)