# Introduction

> _While Melange will apply as an organization, there is no guarantee that we will be accepted as an organization for GSoC 2010.  You're invited to drop by at #melange IRC to discuss.  Help us make it happen._


## [Possible Mentors](PossibleMentors.md)
These are, in order, the most likely or best mentors for this project idea.

## Skills

  * All developers will need to have experience in, or be willing to learn Python.
  * Prior experience with Django or an equivalent framework would be a distinct plus.
  * Knowledge of JavaScript (AJAX), and a feeling for web design is big plus as well.

## Difficulty
'Easy', 'Moderate' or 'Hard'.  Hard is not necessarily better!  We are risk averse!

## Early Spinoffs

We want code that we can actually use, not code that shows great promise.  At the half way stage, you MUST have something complete that we can actually use as a 'spin off' of the work.  In discussing projects we will try to help you find ways to have spinoffs along the way.


---


---

# Idea Details

---


# New Document Editor

### Description
We're looking for a better way to handle documents, document revisions and document editing in Melange. To do that we need to switch the text editor from TinyMCE to something better usable and safer when it comes to HTML. Documents are used throughout Melange to show and edit, for example, the very Home Page, organizations home pages and, most important, project proposals.

#### Characteristics we're looking for
  * Safe handling of HTML tags, or switch completely to Markdown syntax
  * Be able to add custom tags
  * Code highlighting (should be able to recognize automatically the language to highlight)
  * Support for anchors
  * Show images linked from the Net and/or uploaded to the system using BLOB API.
  * Be able to accept attachments (perhaps with checking over MIME part to accept only certain types of files)
  * Be able to add links
  * Control over appareance (left, right, center, bold, italic, color, etc)
  * Autosaving during editing
  * Be able to show diffs between editing (but it should be possible to turn it off for certain pages)
  * Document access control

We did an internal study about the switching and we're thinking the safer way to go is not to use HTML for editing at all (but we welcome new exciting proposals!), so probably a solution could be to use an already made Markdown editor. To do that we need a markdown parser and a markdown WYSIWYG (or at least a WYSIWYM) editor. On the backend side, we need to store different revisions of each document. The simplest way to do that is to store a new document each time it's edited and to show the differences on the frontend side using libraries like Google-Diff-Match-Patch. The hardest way is to have a proper revision control system completely written in Python. One challenge of this part of the project may be the showing of proper differences of the very Markdown tags.

#### Useful Links

  * [markItUp!](http://markitup.jaysalvat.com/home/)
  * [Showdown](http://attacklab.net/showdown/)
  * [Creole Parser](http://www.ivan.fomichev.name/2008/04/javascript-creole-10-wiki-markup-parser.html)
  * [Google-diff-match-patch](http://code.google.com/p/google-diff-match-patch/)
  * [SyntaxHighlighter](http://alexgorbatchev.com/wiki/SyntaxHighlighter)
  * [Highlight.js](http://softwaremaniacs.org/soft/highlight/en/)

### Skills
  * JavaScript (and jQuery)
  * HTML
  * DHTML
  * Ajax
  * CSS
  * Python

### Difficulty
Moderate

### Mentors
  * Mario Ferraro (Merio on #melange)


---

# Testing, Code Guru, Code Quality Assurance

### Description

Melange is sorely lacking tests, and it's hurting our development speed significantly. What we need is a extensive set of unit tests for our logic and views, as well as functional tests to make sure that all views work as expected. This will require learning the codebase first, so as to know what something should do. Test-based exploring would be most suitable (learning how the codebase by writing tests that confirm that things work a certain way). We want test coverage such that it is possible to refactor a core function without doing any manual testing, and still be fairly certain that everything works as expected. On top of that, we want to be able to start doing TDD, which is a lot easier if there are a lot of tests already. All developers will be asked to include tests with their changes as soon as we start doing TDD, so once the momentum picks up things should get easier.

A lower priority, that can be pursued once we have decent test coverage, is to make sure that all pylint errors are fixed, and that all warnings are fixed or suppressed as appropriate. This way we can require that each commit introduces no new pylint errors, which will ensure some level of code quality.

### Skills

  * Python
  * Django
  * Testing

### Difficulty

Moderate, but requires a lot of effort

### Mentors

**Sverre Rabbelier (SRabbelier on #Melange)**


---


# Social Features

### Description

Google Summer of Code is not only about coding, but it is also an annual event which gathers together thousands of people who belong to hundreds of communities or just start their adventure with open source.

We have received a number of requests for adding social features to Melange. Some users would like to update their work progress for public view, while others want to share their interests and activities. Maybe someone is giving a speech at a conference nearby and you are invited to drop in. There is also a large number of more or less official meetings which are often organized on students own initiative.

Currently we use our dedicated mailing lists for these purposes, but we definitely want something better.

The project ideas consist of a few parts which are rather independent, but in some parts they may interfere with each other.

#### Google Calendar API integration

As mentioned above, there is a lot of events and important dates. This part is mostly about integrating Google Calendar API into Melange, so that we are able to manage them.

I recon there should be a few different calendars:

  * one global calendar to emphasize program official dates and events (i.e. current timeline entries)
    * editable by: program host
    * visible to: everyone

  * one global calendar to show social events like unofficial student meetings, interesting open source conferences, etc.
    * editable by: program host, but all users may request putting a new event there
    * visible to: everyone

  * one private calendar for each accepted organization
    * editable by: organization admin
    * visible to: mentors and students who work for the organization

#### User personal page

Each user should be able to create her own personal page and customize its content within given permissions. The main requirements are that users can:
  * edit description using also HTML tags
  * add a personal photo (it should be quite easy to store it now thanks to the new Blobstore API)
  * maybe embed some custom gadgets; anyway we need to ensure that any code that is pasted by users is safe to prevent for example XSS vulnerabilities.
  * display all roles for all previous programs; the user should be able to either show or hide this information; this way it is more official so that users cannot take pride in fictional achievements
Besides the fact that the user has influence on how the page looks like, its general layout should be pleasing to the eye and readable.

#### Finding nearby students by geomodel

Is not it frustrating when you live in Europe and receive invitation to a conference which takes place in Australia? There is no doubt it is a marvelous country, but the chances that you will go are slim, aren't they? Thanks to geomodel project it is possible to filter the results the based on a given location. The project itself is still in its infancy, so working with it may require adding some changes. There may be not enough time to implement all interesting queries during the Google Summer of Code coding period, but adopting the source code to be useable for Melange would be a nice feature.

Of course this is only an initial draft. Other ideas on adding different social features are appreciated, thus the final range of the project may vary.

#### Friends list (LinkedIn, Facebook)
TBD

#### Useful Links

  * [Google Calendar](http://www.google.com/calendar/)
  * [Google Calendar API](http://code.google.com/apis/calendar/)
  * [Blobstore API](http://code.google.com/appengine/docs/python/blobstore/)
  * [Geomodel](http://code.google.com/p/geomodel/)

### Skills
  * Python
  * JavaScript
  * HTML
  * CSS

### Difficulty

Moderate/Hard (depending on the final goals)

### Mentors
  * Daniel Hans (dhans on #melange)


---

# Usability improvements

### Description
Melange has done its good work for Summer of Code 2009, but we're looking for usability enhancements to improve user experience throughout the workflow. It's no secret that the current architecture and, consequently, the current user interface has its rough edges. We've made some steps to improve user experience, for example, shrinking the sidebar (which, for developers and administrators, is very long) and, recently, beginning to integrate [jQGrid](http://www.trirand.com/blog/) to address [Issue 201](http://code.google.com/p/soc/issues/detail?id=201). But much work still has to be done.
In an ideal world we should be able, for example, to use Ajax and DHTML more extensively for many tasks: to do this, however, something in the Python/Django architecture has to be changed.
Here some ideas to improve the user experience, but they're not "what we want", but "what we think we want": we very welcome fresh ideas from wannabe students. The most important thing to have in mind is that every improvement should follow the current minimalistic (Googley) style.
Prototypes and/or mockups are most welcome in proposals about this project.

  * **Sidebar**: The current sidebar shows, for example, the same links for each Organization in the system, which is unnecessary. To improve this, for example, we should either have a single page with the list of all organizations and the links that lead to the proper pages to deal with them or a superduper DHTML/Ajaxy sidebar that appear from a side of the page with a control panel (for example with a tab "Organizations", an autocomplete combobox to select an organization and the tasks that can be done over that organization). Another option is a sliding sidebar (iPod style), something that, clicking on a higher level link, slides to show only the second level and so on.

  * **Developer/owner control panel**: The control panel mentioned in the sidebar topic could be also a totally different page, which should address specific needs of each role. An iGoogle style control panel could be very welcome. Much code for iGoogle style interfaces has already been written during last year SoC project (from Mario Ferraro and Daniel Hans), [Statistics Module for Melange](http://bitbucket.org/dhans/statistic-module-for-melange/), which is not yet integrated in the main branch.

  * **Workflow/notifications**: in this moment the workflow is not very clear, for example, for a student. We would want to show current/next steps in the user's homepage and a more beautiful way to show notifications (e.g. when a mentor publish a new comment on project proposals), maybe integrated with the control panel mentioned before. Think about yourself: what you would like to know during the lifecycle of your project proposal? What has not been immediately clear when you first dealt with Melange?

  * **Client side/ajaxy form validation**: Even with tooltips shown for every field in Melange (they also need some refinement though), sometimes users put wrong stuff in form fields, and is common habit to alert the user in a friendly way without any page reloading (which takes time). So we would like to integrate some client side validation (e.g. over regular expressions), but there could be also the need to have some ajaxy roundtrip for particular checkings (e.g. link\_id already existent). Some clever way to avoid most of the duplication that will come between JavaScript and Python cleaners/checkers is a plus.

  * **Autosaving of forms/documents**: This is something that could be catched by another project (see "New Document Editor"), but if no proposal is accepted we still would like to have it for better user experience. Sometimes it happened that users take much time to fill in forms and/or documents (either because they were thinking or left the computer because of any reason): obviously sessions have their timeouts, so when they were going to save their editings... a message complaining about not having logged in appeared to the user and an issue complaining about lost modifications appeared in our bug tracker :). So we need a way to autosave temporary informations in our models to avoid this kind of problem.

  * **Form design**: if you try to use Melange's survey module, you will find it working and functional but still with some rough edges on usability. We would like to find (and code!) a way to improve owner's user experience when it comes to create survey forms.

#### Useful Links

  * Sidebar
    * [BDC Drilldown Menu](http://www.barandis.com/dev/jquery/ddmenu/index.html)
    * [iPod Drilldown](http://www.filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/)
    * [jGlide Menu](http://www.lanrentuku.com/down/js/daohang-541/)
    * [TabMenu](http://www.flash-free.org/wp-content/files/e24tabmenu/index2.html)

  * Validation
    * [jQuery Validation Plugin](http://docs.jquery.com/Plugins/Validation)
    * [jQuery Validate Plugin](http://plugins.jquery.com/project/validate)

  * User interface
    * [GMail](http://www.gmail.com)

### Skills
  * JavaScript (and jQuery)
  * HTML
  * DHTML
  * Ajax
  * CSS
  * Python

### Difficulty

Moderate/Hard

### Mentors
  * Mario Ferraro (Merio on #melange)


---


# New Data Seeder

### Description
Everytime it comes to developer tools, most of developers are lazy or just overwhelemed by bug fixing and/or new exciting improvements that those tools are postponed forever. We make no exception! :) Although these tasks are normally not so exciting like bringing new end-user features, they are necessary for the whole application ecosystem, and to help developing ... new end-user features! Melange has two little cool modules (seed\_db and seed\_many) to seed the datastore, but they're quite outdated and doesn't respond to all our needs. Developing a fresh new and flexible module to seed the datastore to easen our work is going to be exciting as developing new end-user features. We would like an Ajaxy frontend and a strong bulletproof backend which communicates asynchronously with the frontend to make test cases easier to setup, which is easy to extend and mantain.


&lt;DanielPleaseConfirmYourAvailability&gt;


Be aware that some code about a new data seeder has already been written by the awesome Daniel Hans, so you might want to talk also with him to have some hints on writing your application.


&lt;/DanielPleaseConfirmYourAvailability&gt;


#### Characteristics of the module

  * **Data seeder**: The data seeder should be a Python module which takes input from the frontend, does its duties and respond back to the frontend asynchronously (just to confirm that the Task has been activated). All seeded data should be distinguishable from user entered data. It should use Task Queue API for data seeding. Because it will be necessary to test and setup test cases also for statistics module, it could be quite complicated:

  * **Statistical distributions of data**: Having all students coming from USA and 1 year old is not the best thing when it comes to testing. Then we should need, for any model, a way to define a statistical distribution that the seeded data has to follow. Students ages, e.g., need to probably follow a normal distribution, not to forget that that distribution should be parametric: Summer of Code has no students under 18, but other events might accept different students age ranges. An exciting feature (although not required) would be to analyze past data of the same event in the datastore to gather probability densities. Same thing for students degree, country, other models details, etc.

  * **Easy to mantain**: Although standard melange models are not likely to change heavily in the future, no one knows... so we need to have a way to make the data seeder easy to mantain and extend. Maybe a clever use of Python reflection/introspection and (maybe?) some use of GAE metadata would make the module highly flexible.

  * **Dependency**: There's no way to create mentors if there are no organization seeded before. So, the seeder should be smart enough to tell the user that it should seed organizations first, or should give an option to automatically seed those organizations before seeding mentors. Also for this task, clever use of Python reflection and GAE metadata could give enough flexibility.

  * **Easy setup for test cases**: So, we would like to test the organization home page. But then a document for this organization must be created and associated with the organization home page. This is some kind of dependency, but it's not closely related to datastore, but to an abstract concept. Here it comes the flexibility for the seeder to accept some kind of configuration (probably guided by a JSON object that comes from the frontend) associated to test cases.

  * **Timeline**: Same thing for the timeline. If we want to test midterm surveys, we need to have the datastore seeded with everything that is necessary to go back and forth in the timeline.

  * **Options**: It should be possible to define some options for the seeder (e.g. number of entities to seed, number of org admins who are also mentors (fixed number or random)).

  * **GHOP/GSOC**: data should be seeded for multiple GSoC style programs instances, and also for GHOP style program instances (which are not seeded at all currently).

  * **Ajaxy frontend**: Because of Task Queue API lack of a "reverse" communication, there is no possibility to respond back to the client when a task has finished: standard GET and POST requests are to be done. Still, there is no need to have a page reloading when doing this, as also standard GET and POST requests can be sent asynchronously. About the frontend we would like some ideas from students, depending on the backend architecture they propose. Furthermore, the Ajaxy frontend can be very simple: Ajaxy in this project doesn't mean extreme DOM manipulation, just asynchronous communication. We strongly prefer an awesome data seeder than a fancy frontend, as the frontend can be improved lately if the backend is well developed.

### Skills

  * Python
  * Some Django, Javascript, Ajax, HTML/CSS skills, although not strictly required, are a plus
  * Strong background in Statistic is a plus too

### Useful Links

  * [Task Queue API](http://code.google.com/appengine/docs/python/taskqueue/overview.html)

### Difficulty

Moderate/Hard

### Mentors

  * Mario Ferraro (Merio on #melange)


---


# Extending GHOP

### Description

**Notification system for GHOP: (This may make use of feeds module)**
  1. At the moment GHOP Tasks have a single subscribe button, subscribing to it sends the notifications as mails. Every change to the task will trigger a notification. However user must be able to customize through some kind of dashboard or something, what kind of updates he wants.
  1. Also he must be able to configure it as Feeds(RSS, Atom or whatever) or mails or on-site(socghop.appspot.com) notifications
  1. Also the notification system now works only when some event is triggered, like the state of task is changed. But we need a notification system in place for reminders too. For example if a task is claimed by a student, it should reminders to both mentors and students about the remaining time so that they spring into action.

**Statistics and visualization for GHOP: (May make use of the work Merio and Daniel have done during last GSoC)**
  1. Each student should have access to data of his own work:
    1. Number of tasks requested
    1. Number of tasks claimed
    1. Number of tasks that I did not complete and subsequently reopened
    1. Number of tasks that I completed
    1. (Many more)
  1. Similarly stats can be prepared per organization
  1. And for the entire programme
  1. Also per task
    1. For instance, number of times a task was reopened

Visualizations like Pie chart etc can be plugged with these stats

There are many other possibilities. We will update them as and when we can think of them. Also if the potential student can do the work of going through our app and come up with ideas of what else can be extended, he will have an upper hand on others ;-)

**Submitting/Uploading the work**
  * At the moment one can say on a GHOP Task that he has completed the task and put a link to it in the URL to your work field and give more info about the work as a text in the info field. But it is required for students to be able to submit their work which may contain diffs of the code, translations, wikis among other things or the full files of the work they have done. Few tasks may also require audio/video files, like the tasks which require making spoken tutorials, for instance. The way we accept the work submissions, store it and retrieve it must be redesigned. We may want to use the Blobstore property, which was added to Google Appengine recently, to achieve this.

**Automated Winner selection**
  * Melange should be able to automatically select winners and runners up from the data we have. The winners and runners up should be selectable organization wise and overall for a programme. The number of winners and runners up are already configurable through the programme configuration page. Melange should pick the winners based on this.

**Extending GHOP Test suite**
  * GHOP almost doesn't have any tests except a couple of unit tests written for GHOPTask view. It is required to have an extensive and exhaustive test suite for GHOP module like it is required for GSoC module. The tests must include Unit and Functional tests.

### Skills

Skills are more or less same as mentioned at the top.

### Useful Links

  * [GHOP TODO page](http://code.google.com/p/soc/wiki/GHOPTODO)
  * [GHOP Requirements Document](http://code.google.com/p/soc/wiki/GHOP)
  * [Implementation and Design document](http://code.google.com/p/soc/wiki/GHOPImplementationDesign)
  * http://code.google.com/p/soc/wiki/LifeOfaGhopTask

### Difficulty

Moderate

### Mentors

Madhusudan (madrazr on #melange)


---


# Other ideas

  * Write a Wiki module, that adds Wiki functionality to Melange
  * integrate OpenSocial into Melange
  * add functional tests using twill
  * Profiling and Caching developer tools
  * extend functionality of our buildbot (post commit hooks, pylint integration, application deployment to testing App Engine instance)
  * add features that will enable to organize GSoC/GHOP Meetings (creating new events, managing participants, integration with Google Calendar API),
  * Melange API allowing any external page to list current status of tasks and tasks list, participating projects etc.
  * generating pdfs, docs of student applications
  * integrating export functionality of tables, proposals with Google Docs (use Google Docs API)
  * upload of student presentations (storage, viewer)
  * work on selected issues from Melange Issue Tracker
  * Non US students should be able to upload their Tax forms via their Student dashboard page (no more faxing or sending via email)
  * Melange should enable admins/host to easily autogenerate CPT letter or letter of acceptance if one is needed/requested by student. This would generate pdf file ready to print based on the data from student profile (including program logo).
  * User (Roles) profiles (mentor/admin/student/organization admin/) with profile photo, functionality to share profile information with other GSoCers ) - privacy settings for your profile
  * dates that are setup in GHOP and GSoC Melange configuration page can be later automatically put into faq and terms of program in specific places
  * Melange survey module should have autosave forms functionality (just like in gmail)\
  * Dashboard for mentor, org admin, host, student, developer with nice information/status box, updates, stats depending on the Role
  * Google Calendar API support for events planning
  * Adding other GSoCers as friends to your profile,
  * Sharing profile data with other social network users
  * Messaging module allowing to send messages to other users (emails) (Way to improve communication between GSoCers, GHOPers)
  * Requesting profile data access
  * Better geo location features
  * Nice upload of profile photo with crop functionality via JS library.

# Some Rough Notes

  * Did we mention that we have an active IRC channel, #melange?
  * Some words for you, to inspire more ideas: **[Automated Testing](http://code.google.com/p/soc/wiki/TestingGuidelines)**, **World Domination** (ask), **Access Control Module**, **Profiling**, **Log Analysis**, **[Issue Tracker](http://code.google.com/p/soc/issues/list?can=2&q=&sort=-id)**, **[Security](http://code.google.com/p/soc/wiki/AccessControl)**, **Optimization(s)**, **Mentor Summit**, **Wiki**.