[SciPy-dev] a modest proposal for technology previews

[Travis E. Oliphant]

> Currently, the problem is that someone proposes or writes something
> that we agree should be part of scipy.  We discuss on the list perhaps
> where the code should go or what it should be called.  We may discuss
> the API.  Then the code is included in the trunk and we make a
> release.  For a large number of scipy user, this may be the first time
> they have been made aware of the new code and its API.  They may find
> that the code doesn't meet their needs.  Also even, though, the code
> has been discussed on the list, most of us our so busy we don't have
> very much time to closely look at the code.  So when we agree to
> include it, we only have a general sense that the code has a
> reasonable API.
>
> I was proposing scipy.preview to try an address these and other
> concerns.  It seems doubtful to me that scikits addresses this
> problem.  And I don't think that we currently have enough resources to
> make scikits better serve this purpose.  I don't have time to work on
> scikits and I don't pay much attention to them unfortunately.  If
> someone was to step forward and start pushing scikits that would be
> great and I would be happy to see that happen.  But even if that was
> to happen, we would still need a process to incorporate a scikit into
> scipy if we decided we wanted to.  My proposal is aimed at solving
> that problem.
>
>   
My biggest point is "why call it scipy.preview when scikits.forscipy 
works just as well"

In other words, create a *single* scikit that is the equivalent of 
scipy.preview.  What is the benefit of having it in scipy.preview?

-Travis