<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 7, 2016 at 11:19 AM, Pauli Virtanen <span dir="ltr"><<a href="mailto:pav@iki.fi" target="_blank">pav@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Tue, 06 Sep 2016 20:23:05 +0200, Sylvain Corlay kirjoitti:<br>
[clip]<br>
</span><span class="">> This sort of raises the question of the scope of scipy. Should scipy go<br>
> through the same sort of "big split" as Jupyter or more à la d3js? Is<br>
> amount of specialized knowledge required to understand a methods part of<br>
> what defines the line of division in what should be or not be in scipy?<br>
<br>
</span>To write a bit more on this, although I think it's difficult to give hard<br>
rules on what "generally useful and generally agreed to work" means, I<br>
would perhaps weigh the following against each other:<br>
<br>
- Is the method used/useful in different domains in practice?<br>
  How much domain-specific background knowledge is needed to use it<br>
  properly?<br>
<br>
- Consider the stuff already in the module.  Is what you are adding<br>
  an omission?  Does it solve a problem that you'd expect the module<br>
  be able to solve?  Does it supplement an existing feature in<br>
  a significant way?<br>
<br>
- Consider the equivalence class of similar methods / features usually<br>
  expected. Among them, what would in principle be the minimal set so<br>
  that there's not a glaring omission in the offered features remaining?<br>
  How much stuff would that be? Does including a representative one of<br>
  them cover most use cases? Would it in principle sound reasonable to<br>
  include everything from the minimal set in the module?<br>
<br>
- Is what you are adding something that is well understood in the<br>
  literature? If not, how sure are you that it will turn out well?<br>
  Does the method perform well compared to other similar ones?<br>
<br>
- Note that the twice-a-year release cycle and backward-compat<br>
  policy makes correcting things later on more difficult.<br>
<br>
The scopes of the submodules also vary, so it's probably best to consider<br>
each as if a separate project --- "numerical evaluation of special<br>
functions" is relatively well-defined, but "commonly needed optimization<br>
algorithms" less so.<br>
<br>
On a meta-level, it's probably also bad to be too restrictive on the<br>
scope, as telling people to go away can result to just that.<br></blockquote><div><br></div><div>Thanks Pauli, this and your other mail are the best summary yet of how to judge suitability for inclusion. I propose to stick this almost verbatim in the developer docs.<br><br></div><div>Ralf<br> <br></div></div><br></div></div>