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.
These are, in order, the most likely or best mentors for this project idea.
‘Easy’, ‘Moderate’ or ‘Hard’. Hard is not necessarily better! We are risk averse!
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.
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.
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.
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.
Moderate, but requires a lot of effort
Sverre Rabbelier (SRabbelier on #Melange)
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.
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)
one global calendar to show social events like unofficial student meetings, interesting open source conferences, etc.
one private calendar for each accepted organization
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:
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.
Moderate/Hard (depending on the final goals)
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 to address Issue 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, 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?
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.
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.
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.
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.
Notification system for GHOP: (This may make use of feeds module)
Statistics and visualization for GHOP: (May make use of the work Merio and Daniel have done during last GSoC)
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
Automated Winner selection
Extending GHOP Test suite
Skills are more or less same as mentioned at the top.
Madhusudan (madrazr on #melange)