I think it's great to have some rough goal posts set out for 1.0. 
Regardless of exactly what 1.0 means, by making a giant todo
list you've made contributing to SciPy much more appealing - 
it now feels like there is a targeted effort to tidy the whole 
project up, and I for one would like to be a part of it.

My name is James Booth and I'm a Comp Sci PhD student. 
I'm part of a team at Imperial College London that is leaning 
heavily on Scipy for our research - I'll take a look through the list in 
detail and see if I can't help out in some way.

Best wishes,
James


On 22 September 2013 00:19, Pauli Virtanen <pav@iki.fi> wrote:
22.09.2013 01:35, Nathaniel Smith kirjoitti:
> On Sat, Sep 21, 2013 at 7:54 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
>> - topics like "do we need a roadmap?" or "what does 1.0-ready really mean?"
>> are discussed on this thread.
>
> I would be curious what the answers are to these questions :-).
>
> This looks like a big list with many good improvements on it, but I'm
> not sure what makes them "1.0 changes" instead of just "good changes
> we should do". Does 1.0 mean we can break a lot of stuff at once and
> get away with it? Does it mean that after that we're not allowed to
> change things like this ever again so we have to get it right (and
> maybe keep slipping the schedule until we're certain)?  Does it mean
> no more releases until all the below things happen? Or on the other
> extreme, does it mean that someone will keep an eye on this list, and
> at some point maybe in a few years when we notice that all of these
> things have happened, then the next release gets called "1.0" instead
> of "0.18" or whatever?
>
> I think when you start talking about "1.0" people have very strong
> conflicting assumptions about what this "obviously" means, so...

In my mind, "1.0" for Scipy means that we cover a basic set of features
needed for numerical science, and do it well. A definition via negative
is: at "1.0" we don't have

(i) stuff that's obviously crap
(ii) blank spots at commonly needed functionality
(iii) awkward usage patterns

It is of course a subjective matter what this means, but writing the
known issues down in the roadmap is one way to define it.


Regarding API deprecations: I think breaking a lot of stuff at "1.0" at
once is not a good idea, and I don't think that will happen. Rather,
things progress as we have done so far --- if something is horribly
awkward, a new API is introduced and the old one is deprecated. We can
perhaps be slightly more aggressive in the cleaning out crap at "1.0",
but I don't think there'll be a qualitative difference. This is also for
practical reasons, as we will not be able to fix everything in one go in
any case.

Rather, one day in the distant future, it turns out that the next
release is in a good enough shape to be called "1.0". The "0.x" roll up
to that point.

--
Pauli Virtanen

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev