[Numpy-discussion] Documentation Team meeting - Monday January 4

[Melissa Mendonça]

Hi all! Happy new year!

Our next Documentation Team meeting will be on *Monday, January 4* at ***4PM
UTC***. All are welcome - you don't need to already be a contributor to
join. If you have questions or are curious about what we're doing, we'll be
happy to meet you!

If you wish to join on Zoom, use this link:

https://zoom.us/j/96219574921?pwd=VTRNeGwwOUlrYVNYSENpVVBRRjlkZz09


Here's the permanent hackmd document with the meeting notes (still being
updated in the next few days!):

https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg


Hope to see you around!

** You can click this link to get the correct time at your timezone:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20210104T16&p1=1440&ah=1


- Melissa
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] updated backwards compatibility and deprecation policy NEP

[Ralf Gommers]

On Sat, Jan 2, 2021 at 3:55 AM Sebastian Berg 
wrote:

> On Wed, 2020-12-30 at 11:43 -0600, Sebastian Berg wrote:
>
> On Wed, 2020-12-30 at 16:27 +0100, Ralf Gommers wrote:
>
> 
>
>
> That's very hard to describe, since it relies so much on previous
> experience and qualitative judgements. That's the main reason why I
> had
> more examples before, but they just led to more discussion about
> those
> examples - so that didn't quite have the intended effect.
>
> 
>
> I only took a short course and used this very little. I am sure there
> are many here with industry experience where the use of Q&A is every
> day work.
>
>
Thanks for thinking about this Sebastian.

I used to use such a risk management approach fairly regularly, and it can
be useful. In general it's something you do for a larger design change or
new product, rather than for an individual change. It helps get an overview
of the main risks, and prompts thinking about risks you may have missed.


>
> One concept from there is to create a risk/danger and probability
> assessment, which can be ad-hoc for your product.  An example just to
> make something up:
>
>
>
> I am not sure anyone finds this interesting or if fits to the NEP
> specifically [1], but I truly think it can be useful (although maybe it
> doesn't need to be formalized). So I fleshed it out:
> https://hackmd.io/WuS1rCzrTYOTgzUfRJUOnw (also pasted it below)
>

I'd be happy to try it. It does feel a bit too much to put all that content
into the NEP though. Maybe we can just add a more brief "assess severity
and likelihood and severity of your proposed change, and include that
assessment when proposing a deprecation. See  for more details". And
then we can link to a wiki page or separate doc page, that we can then
easily update without it being a NEP revision.

Cheers,
Ralf


> My reasoning for suggesting it is that a process/formalism (no matter how
> ridiculous it may seem at first) for how to assess the impact of a backward
> compatible change can be helpful by: conceptualizing, clearly separating
> backward incompatible impact assessment from benefits assessment, making it
> easier to follow a decision/thought processes, and allowing some nuance [2].
>
> I actually believe that it can help with difficult decisions, even if only
> applied occasionally, and that it is not a burden because it provides
> fairly steps. Will it be useful often? Maybe not. But every time there is a
> proposal and we pause and hesitate because it is unclear whether it is
> worth the backcompat impact, I think this can provide a way to discuss it
> and come to a decision as objectively as possible. (And no, I do not think
> that any of the categories or mitigation strategies are an exact science.)
>
> Cheers,
>
> Sebastian
>
>
> [1] This is additional to the proposed promises such as a two releases of
> deprecations and discussing most/all deprecations on the mailing list,
> which are unrelated. It is rather to provide a formalism where currently
> only the examples give points of reference.
> [2] There is a reason that also the Python version is short and
> intentionally fuzzy: https://www.python.org/dev/peps/pep-0387/ and
> https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 There
> are just few definite rules that can be formalized, so a framework for
> diligent assessment seems the best we can do (if we want to).
>
>
>
>
>
> Assessing impact
> Here “impact” means how unmodified code may be negatively affected by a
> change ignoring any deprecation period.
>
> To get an idea about how much impact a change has, try to list all
> potential impacts. This will often be just a single item (user of function
>  x has to replace it with y), but it could be multiple different ones.
> *After* listing all potential impacts rank them on the following two
> scales (do not yet think about how to make the transition easier):
>
>1. *Severity* (How bad is the impact for an affected user?)
>- Minor: A performance regression or change in (undocumented)
>   warning/error category will fall here. This type of change would 
> normally
>   not require a deprecation cycle or special consideration.
>   - Typical: Code must be updated to avoid an error, the update is
>   simple to do in a way that works both on existing and future NumPy 
> versions.
>   - Severe: Code will error or crash, and there is no simple work
>   around or fix.
>   - Critical: Code returns incorrect results. A change requiring
>   massive effort may fall here. A hard crash (e.g. segfault) in itself is
>   typically *not* critical.
>2. *Likelihood* (How many users does the change affect?)
>- Rare: Change has very few impacted users (or even no known users
>   after a code search). The normal assumption is that there is always 
> someone
>   affected, but a rarely used keyword argument of an already rarely used
>   function will fall here.
>   - Limited: Change is in a rar

Re: [Numpy-discussion] updated backwards compatibility and deprecation policy NEP

[Sebastian Berg]

On Sat, 2021-01-02 at 18:06 +0100, Ralf Gommers wrote:
> On Sat, Jan 2, 2021 at 3:55 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
> 
> > On Wed, 2020-12-30 at 11:43 -0600, Sebastian Berg wrote:
> > 
> > On Wed, 2020-12-30 at 16:27 +0100, Ralf Gommers wrote:
> > 
> > 
> > 
> > 
> > That's very hard to describe, since it relies so much on previous
> > experience and qualitative judgements. That's the main reason why I
> > had
> > more examples before, but they just led to more discussion about
> > those
> > examples - so that didn't quite have the intended effect.
> > 
> > 
> > 
> > I only took a short course and used this very little. I am sure
> > there
> > are many here with industry experience where the use of Q&A is
> > every
> > day work.
> > 
> > 
> Thanks for thinking about this Sebastian.
> 
> I used to use such a risk management approach fairly regularly, and
> it can
> be useful. In general it's something you do for a larger design
> change or
> new product, rather than for an individual change. It helps get an
> overview
> of the main risks, and prompts thinking about risks you may have
> missed.
> 

Yeah, I guess its for new products mostly, to compile many risks and
make it easier to compare them.  And yes, we do not have "many" risks,
unless you would compile this for the complete changelog between one or
more versions.

> 
> > 
> > One concept from there is to create a risk/danger and probability
> > assessment, which can be ad-hoc for your product.  An example just
> > to
> > make something up:
> > 
> > 
> > 
> > I am not sure anyone finds this interesting or if fits to the NEP
> > specifically [1], but I truly think it can be useful (although
> > maybe it
> > doesn't need to be formalized). So I fleshed it out:
> > https://hackmd.io/WuS1rCzrTYOTgzUfRJUOnw (also pasted it below)
> > 
> 
> I'd be happy to try it. It does feel a bit too much to put all that
> content
> into the NEP though. Maybe we can just add a more brief "assess
> severity
> and likelihood and severity of your proposed change, and include that
> assessment when proposing a deprecation. See  for more
> details". And
> then we can link to a wiki page or separate doc page, that we can
> then
> easily update without it being a NEP revision.

Yes, it adds a lot of content and I don't want to force it on anyone or
into the NEP, in that sense it is more brainstorming than a very
concrete proposal.  And I am also fine with just dropping it, whatever
others think is useful.  I fleshed it out a bit, because I actually
think it ends up representing fairly well how I currently try to
approach this and I think it may be useful when a proposal gets stuck
because it is unclear whether it is worth the pain/risk.

Cheers,

Sebastian

> 
> Cheers,
> Ralf
> 
> 
> > My reasoning for suggesting it is that a process/formalism (no
> > matter how
> > ridiculous it may seem at first) for how to assess the impact of a
> > backward
> > compatible change can be helpful by: conceptualizing, clearly
> > separating
> > backward incompatible impact assessment from benefits assessment,
> > making it
> > easier to follow a decision/thought processes, and allowing some
> > nuance [2].
> > 
> > I actually believe that it can help with difficult decisions, even
> > if only
> > applied occasionally, and that it is not a burden because it
> > provides
> > fairly steps. Will it be useful often? Maybe not. But every time
> > there is a
> > proposal and we pause and hesitate because it is unclear whether it
> > is
> > worth the backcompat impact, I think this can provide a way to
> > discuss it
> > and come to a decision as objectively as possible. (And no, I do
> > not think
> > that any of the categories or mitigation strategies are an exact
> > science.)
> > 
> > Cheers,
> > 
> > Sebastian
> > 
> > 
> > [1] This is additional to the proposed promises such as a two
> > releases of
> > deprecations and discussing most/all deprecations on the mailing
> > list,
> > which are unrelated. It is rather to provide a formalism where
> > currently
> > only the examples give points of reference.
> > [2] There is a reason that also the Python version is short and
> > intentionally fuzzy: https://www.python.org/dev/peps/pep-0387/ and
> >  
> > https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421
> >  There
> > are just few definite rules that can be formalized, so a framework
> > for
> > diligent assessment seems the best we can do (if we want to).
> > 
> > 
> > 
> > 
> > 
> > Assessing impact
> > Here “impact” means how unmodified code may be negatively affected
> > by a
> > change ignoring any deprecation period.
> > 
> > To get an idea about how much impact a change has, try to list all
> > potential impacts. This will often be just a single item (user of
> > function
> >  x has to replace it with y), but it could be multiple different
> > ones.
> > *After* listing all potential impacts rank them on the following
> > two
> > scales (do not 

Re: [Numpy-discussion] proposal for NumPy sponsorship guidelines (NEP 46)

[Matti Picus]

On 12/29/20 1:27 PM, Ralf Gommers wrote:

Entities who fall under "significant active supporter" we'll call Sponsor.
The minimum level of support given to NumPy to be considered a Sponsor 
are:


- $30,000/yr for unrestricted financial contributions
- $60,000/yr for financial contributions for a particular purpose
- $100,000/yr for in-kind contributions



How would this work for one-time contributions, or for sponsors that 
stop contributing? For instance, if an entity gives a $60,000 one-time 
unrestricted contribution (unlikely, but who knows?) would they be 
listed as sponsors for 24 months after the contribution and then have 
their name removed?



Also, the implementation should explicitly mention a mechanism to keep 
track of received contributions.



Matti

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion