|
Size: 1833
Comment:
|
← Revision 9 as of 2010-12-16 11:47:48 ⇥
Size: 4564
Comment: Added interested participants to Ipython sprints
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 11: | Line 11: |
| === textbooks === | === Textbook Conversion === |
| Line 13: | Line 13: |
| Our idea is to create an opportunity for the participants to apply the computational techniques they would have learnt during the tutorials. Keeping this in view, we have gathered a set of books with increasing complexity and level of prerequisites. Participants are expected to form groups and work on and finish off a textbook of interest during the sprints. These solutions, after a review, are kept available for everyone on the internet in the name of 'open source educational content'. | [[Scipy2010/TextBooks|Textbook Conversion]] page has details on the textbooks that you can work on during the sprints |
| Line 15: | Line 15: |
| For beginner of Python/Sage, we suggest the following books: | === IPython === |
| Line 17: | Line 17: |
| 1. Getting started with MATLAB - Rudra Pratap | ==== I'm interested ==== |
| Line 19: | Line 19: |
| 2. Calculus of One Variable - Keith E. Hirst | * Madhu, FOSSEE * Nishanth, FOSSEE * Amit, FOSSEE |
| Line 21: | Line 23: |
| For participants who knew to work on Python/Sage and would like to work on slightly mathematical material, we suggest: | We have a number of possible things to work on for IPython. |
| Line 23: | Line 25: |
| 3. Advanced Engineering Mathematics - Erwin Kreyszig [split into three parts] | * HTML notebook. There is currently an open [[https://github.com/ipython/ipython/pull/179|pull request]] with a draft implementation, but its author has been busy and could use help. |
| Line 25: | Line 27: |
| 4. Linear Algebra - Gilbert Strang | * 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... |
| Line 27: | Line 32: |
| 5. An Introduction to Partial Differential Equations with Matlab - Matthew P. Coleman | * Implementing proper history support in the new Qt console. This is really important for day to day usability, and not terribly hard. |
| Line 29: | Line 34: |
| For those who don't want to do anything but physics (!), we suggest: | * 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. |
| Line 31: | Line 41: |
| 6. Modern Physics - Kennith Krane | This project has the advantage of requiring less/no knowledge of the core codebase, while being very useful to the project at large. |
| Line 33: | Line 44: |
| 7. Introduction to Dynamics - Ian Percival, Derek Richards | * 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 [[http://ipython.scipy.org/doc/nightly/html/development/index.html|development guidelines]] so that you arrive at the sprints reasonably ready to start doing productive work. |
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.