WE NEED YOUR HELP!
This is a distributed, volunteer project with many contributors. The best way to join our effort is to browse around, read the last section of this page to learn about our vision and plans, and then announce your intent to help on one of the developer Mailing Lists or contact any of the folks listed on this page.
SciPy is managed by a broad community of diverse users. The mailing lists are the best way to get to know the currently active community. The github activity logs also shows who has been active in the community. Respect might be given to original code authors if they are still active on the lists. But, as a community project, development of SciPy is governed by the most active current contributors.
Make contributions (e.g. code patches), feature requests and file bug reports by submitting a "ticket" on the Trac pages linked below. Because of spam abuse, you must create an account on our Trac in order to submit a ticket, then click on the "New Ticket" tab that only appears when you have logged in. Please give as much information as you can in the ticket. Also specify the component, the version you are referring to and the milestone. Report bugs to the appropriate Trac instance (there is one for NumPy and a different one for SciPy). There are read-only mailing lists for tracking the status of your bug ticket.
Note that NumPy contains the most basic numerical functionality, and SciPy is layered on top of NumPy to provide a much wider range of capability. You need NumPy for SciPy to work.
Developer's wiki (Git)
Developer's wiki (Trac)
People interested in making code contributions to Numpy should take a look at the Numpy Developer Guide.
Interested people can also get repository write access as well. This usually requires a developer "vouching" for you, which happens more easily if you already made a number of contributions.
See Packaging, below, for the process of building and making releases.
Source Code Team
Take a look at http://github.com/scipy to see the current active team.
If you have some new code you'd like to see included in SciPy, the first thing to do is make a SciKit. A SciKit is a stand-alone package including your code (including complete reference and user documentation). SciKits are distributed here:
This site is currently still in early construction phases, and will be moved (and linked) to the main page of this site when it is ready to accept new SciKits. Right now users and developers are encouraged to view the site and comment on <email@example.com> to ensure it serves your needs.
Once you get some use experience, the community may decide to include your SciKit in SciPy. These decisions are based on many factors, including maturity of the code API and the docs, ease of building it on all platforms, how many people use it, how well it is integrated into SciPy, etc.
Because it must remain small and easy to build, new additions of entire packages to NumPy are extremely rare. Contact the Steering Committee or post on the <firstname.lastname@example.org> mailing list if you think you have a compelling case.
For the majority of users who do not want to build the code from source, binary installers that "just work" are the key to using SciPy. Producing these after the coding is finished is the Packaging Team's job.
Making Source and Binary Releases
A releaseable tarball gets made from the sources following a straightforward procedure (see http://projects.scipy.org/numpy/wiki/MakingReleases). To make an official release to the community, someone on the packaging team, usually Jarrod Millman, makes a series of test releases and announces them on the mailing lists. After getting feedback, the team makes a final release, posts it, and announces it on the mailing lists.
FILL IN: Packaging Team, please fill in more detail on how you cut releases and where you need help. Describe the build system, standards for accepting a release candidate, what systems are tested, who does what, use of Trac for bugs, etc.
Getting Releases Into Distribution
Linux distributions and many others pick up our packages and deliver them to users as part of larger collections. To ensure that they are distributing our latest and best, we record on the Distros page what's needed to trigger them to pick up a new release. This could mean contacting an individual, posting on a mailing list, or doing something on a web site. WE NEED YOUR HELP! If you know the proper way to get a distro to pick up a new version of a package, please document it under Distros.
Debian - Ondrej Certik (<ondrej AT certik DOT cz>) and Debian Python Modules Team (DPMT)
Ubuntu - Scott Kitterman and others
- numpy.distutils - Pearu Peterson
- Documentation is currently our weakest area, but we are working on it as part of the Documentation Marathon 2008+. The marathon addresses some of the current shortcomings:
- After that we will still need:
- A book-length User Manual
- Discipline- and package-specific user manuals
- More Cookbook recipes
Reference documentation: Each function, module, and class has a "docstring" that is printed when you say help(functionname). It is contained within the actual function/module/class definition. There is now a doc wiki to make it easy to add/edit docstrings. We also need a "Getting Started" document that is ~10 pages long and takes a completely new user (no programming experience) through generating some simple array data, doing some math on it, slicing it, plotting a sine wave, defining a one-line function, and reading and writing data from an ASCII text file. Then it should list the general topic areas handled by numpy/scipy, and explain how to get more information and connect to the community. It should not go into detail on anything! It should be readable by an inexperienced user in 20 minutes. If you are writing a doc, please link it under Projects, and give your contact info as well.
- Scipy Cookbook
- Converting from Numeric: numpy changes some of Numeric's default behaviors. Incompatibilities should be documented here for reference.
- Using Python for Interactive Data Analysis This is a combination tutorial and quick reference on how to use Python for data manipulation and visualization. Currently it is focused on astronomical analysis, but most of it does not require any special knowledge of astronomy and serves to illustrate the basic principles for most scientific and engineering uses. Written by Perry Greenfield ( email@example.com ) and Robert Jedrzejewski ( firstname.lastname@example.org )
- Numpy Glossary: Definitions of terms. This needs to be filled in and reviewed by experts (correctness) and novices (readability) before moving to the Documentation page.
- Data sets and examples: Add standard data sets and examples to !SciPy.
Discussion and a straw poll in November 2004 led to the selection of LyX (a GUI for editing LaTeX format) as the preferred tool for book-length SciPy documentation. You can also generate LaTeX files by using converters for other popular file formats, or by editing by hand in a text editor. See Documentation Tools for info and links.
The issue of clear documentation has come up often enough that we are including these points here for all to consider. Our community is blessed with many skilled technical programmers who are not necessarily close to our typical audience of new users. Here are some things everyone should remember when writing docs, and especially introductions, whether they are in docstrings, modules, or web pages for full packages. The only difference is that shorter items get shorter intros.
- At the end of the intro, all readers should know basically what the software is, whether it's appropriate for their problem, and what it might feel like to use it. They should not have unanswered fundamental questions (like, Why is this needed?, How can this possibly work?, etc.).
- The numpy audience includes many ~19-year-old college students who are technically oriented but not yet deeply educated in numerical analysis or the details of how computers carry out computations. These students are likely our most fertile recruiting ground, so intros (and all but the most technical sections of docs) should be readable by them.
- Browsing users arrive with about a 90-second attention span. What they encounter in those 90 seconds must be relatively straightforward to read, must answer their basic questions, and must interest them to spend 10 more minutes digging in. Those 10 minutes must convince them to install it and spend an hour trying it. By the way, this is a basic result of marketing research: the 90-second rule applies even to people buying a house!
The latest doc snapshots are available under the Documentation page. If you are debugging the documentation and want to build the HTML or PDF yourself, do this: For Scipy:
- svn co http://svn.scipy.org/svn/scipy/scipy-docs/trunk scipy-docs
- cd scipy-docs
- export PYTHONPATH=/wherever/your/scipy/is/installed
- make html
and for Numpy:
- git clone git://github.com/numpy/numpy.git numpy
- cd numpy/doc
- export PYTHONPATH=/wherever/your/numpy/is/installed
- make html
Other output targets than html are listed by typing simply "make". Note that you need Sphinx 1.0.1, and to actually compile Numpy or Scipy first. You can get Sphinx from http://sphinx.pocoo.org/
- Many have volunteered, but few have listed themselves here. We need to know what projects we can start and finish this summer. Please list your name and email address under projects of interest. You can spam-obscure the email address if you like.
- Geoff Kuhn <email@example.com>
- Joe Harrington <firstname.lastname@example.org>
- Reference pages for the functions, modules, and classes - 20 people are not too few here * Stefan van der Walt <email@example.com> * Perry Greenfield <firstname.lastname@example.org> * Pauli Virtanen * Emmanuelle Guillart * Scott Sinclair * Aaron Altman <email@example.com>
- A Getting Started document (about 10 pages) - 1-2 people can do this * Stefan van der Walt * Aaron Altman
- A book-length user manual - many have tried...hard to do alone, unless we divvy up the chapters?
- Discipline- and package-specific user manuals * Astronomy -- Perry Greenfield and Robert Jedrzejewsky * matplotlib -- John Hunter
- More Cookbook recipes
Please list yourself if you are willing to proofread whatever anyone has written, have prepared manuscripts for publication, AND consider yourself an English grammarian. If you know when to use "which" and when to use "that" when introducing relative clauses, and if "different than" stimulates you like nails on a blackboard, sign up here!
You are invited to make improvements to any area of this wiki except the front page. Front page changes should be proposed on the firstname.lastname@example.org mailing list, which is also a good place to post suggestions for other pages.
You will need to make an account on this wiki to edit pages here. Click the login button, above, to do that.
Website tasks pending
Information on editing this Wiki
Old Plone website deprecated now in favor of this site. To get to the wiki pages on the old site, you have to iteratively click toward your destination and then edit the word "old" back into your URL. Each attempt will take you to the new site. For example, the old Topical wiki is http://old.scipy.org/wikis/topical_software/TopicalSoftware. To get from there to Perry Greenfield's Tutorial, click on the tutorial link, wait for the corresponding page on the new site to load, then edit the word "old" back into the URL and go there. Hopefully this will be fixed soon.
Web Site Team
Lead - FILL IN who can edit the front page - <email@example.com>
Developer Zone - Joe Harrington <jharring at physics.ucf.edu>
A page curator's job is to keep a page current, either by direct editing or by recruiting others to help. Curation does NOT mean only the curator or those they contact may edit it!
FILL IN and move above this line in nav order.
Documentation - FILL IN - <firstname.lastname@example.org>
Download - FILL IN - <email@example.com>
Installing - FILL IN - <firstname.lastname@example.org>
Topical Software - FILL IN - <email@example.com>
Cookbook - FILL IN - <firstname.lastname@example.org>
The following were listed on the old site. If your name is here, please move it to the appropriate place above this paragraph.
Jonathan Taylor jonathan.taylorNOSPAMatutoronto.ca (Getting Started with SciPy)
SteveRogers (Conference Pages)
POLISHING SCIPY: THE ACCESSIBLE SCIPY PROJECT (ASP)
ASP is a roadmap for making Python-as-a-tool-for-science usable and friendly ("accessible") to as many people as possible. This page is the open-but-not-in-the-way workplace for the projects that will accomplish that goal. The roadmap identifies three areas of effort: documentation, packaging, and the web site. Discussion of the roadmap, project direction, and specific efforts takes place on email@example.com . More recently, we discussed a proposal for Wiki workflow that is designed to take advantage of the Wiki Way for developing without having the site look like a perpetual construction zone.
The rest of this page serves as both a place for projects to live before they're ready for prime time and for willing help to meet new projects. If you are currently or potentially working on the non-code aspects of NumPy or SciPy, please enter your name and contact info above so people can find you. If you are interested in extending one of the three main efforts (e.g., writing a new doc, starting a new area of the web site, or taking on package testing for a particular architecture), please describe that new effort above in an appropriate place. Linking your new page or project here will attract the attention of people who are willing to help. Once your project is ready to go public, please ask for a review on the scipy-dev mailing list. When the community is happy, make a link to your page from one of the main pages of the site. After your project is stable and you are no longer seeking additional help, remove the link from this page. Small projects (a screen page or few) can pretty much be posted here, announced, reviewed, and go live in a matter of hours. The goal is to ensure that what is before the public is consistent, complete at some level, well presented, and correct.
Finally, we're all learning on the job here. Some resources (please post more):
Producing Open Source Software by Karl Fogel