SciPy.in 2010 Sprint Topics

Please specify the topics for sprints that you would like the participants to work on. Where ever relevant, please add links to the bug-tracker or mailing list discussion. Also, it would be nice, if the topics can be classified based on the skill level required to work on them.

scikits.image

We have tasks for everyone from beginners to seasoned coders. We need people to write tutorials, to test code, to implement new features, to adapt source code already available, etc.

Please refer to our development website for a more detailed list!

Textbook Conversion

Textbook Conversion page has details on the textbooks that you can work on during the sprints

IPython

I'm interested

• Madhu, FOSSEE
• Nishanth, FOSSEE
• Amit, FOSSEE

We have a number of possible things to work on for IPython.

* HTML notebook. There is currently an open pull request with a draft implementation, but its author has been busy and could use help.

* HTML5 backend support for matplotlib in the html notebook. John Hunter is also coming to the conference/sprints, so this would make a perfect topic for joint work. Though I'd love to have finished merging James' branch before that happens...

* Implementing proper history support in the new Qt console. This is really important for day to day usability, and not terribly hard.

* Website work: I'd like to move us away from the Moin wiki as our main site into a standalone, sphinx-generated website. The wiki could continue to exist in a reduced form for purely wiki-type things (cookbook recipes, etc), but the bulk of the site would be much better as a sphinx-generated site, hopefully with a nice theme that differentiates it visually from the standard documentation themes.

This project has the advantage of requiring less/no knowledge of the core codebase, while being very useful to the project at large.

* Attacking any of the critical bug fixes we have listed on the site, in particular working on the unicode mess.

* Documentation audit/update. Our docs have fallen badly behind and need a solid audit to identify the problems, as well as good tutorials to be written for some of the new features (qt console, new paralllel branch, etc). Again, very useful and not requiring detailed knowledge of the codebase. This audit should goes through our docs and label each section with a set of classifiers like: delete, update, rewrite, add, ...

* Updating the docs for the sections that describe completely stable code, APIs and interfaces. There are huge sections of the docs that have not been touched for years and have not even been fully updated to use all that Sphinx has to offer.

* Improving test coverage (and implementing coverage reporting in the first place, so we know where we stand).

* Auditing and triaging the bug list for obsolete/incomplete bugs that don't apply to trunk anymore, closing them as needed. Right now we have a lot of 'weed growth' in the bug list.

* Commenting on the existing open pull requests so that we can move them forward or merge if ready.

* Create a more full blown QtApp for the qtconsole with useful menus, etc.

* Add new sub widgets that for example show the state of the kernel and have buttons for restarting, etc.

* Allowing the new Qt console to work in a single process. This may appear paradoxical (since we did all that work to be able to run in *two* processes), but there are scenarios where someone may want to embed an IPython rich widget inside an existing application that has a namespace to be interactively manipulated. Mayavi is a prime example that does that, and right now it would not be able to use our console, since the Qt widget expects to be a separate process.

* Develop a curses frontend. Wendell Smith discussed this a while ago and has some thoughts on the matter, but I don't know if he has made significant inroads; you may want to ping him first.

* Start experimenting with ZeroMQ to familiarize yourself with this system, as it is at the heart of much of our new system.

If you are interested in any of these, I strongly suggest you read in advance our development guidelines so that you arrive at the sprints reasonably ready to start doing productive work.