Re: [Numpy-discussion] Adoption of a Code of Conduct
On July 27, 2018 17:04:23 Marten van Kerkwijk wrote: My ideal version would be substantially shorter, maybe just quote the golden rule, but I am happy with the suggestion to just adapt this text. Agreed! There's some basic ground that needs to be covered, though, and the result of exploring that fully is, practically, what you see here. I'm not opposed to modifying the document in principle, although I reckon it would be somewhat easier, from both a maintenance and adoption perspective, to use the same. Best regards, Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adoption of a Code of Conduct
I would be happy to adopt the SciPy code of conduct and code of conduct committee both. On Fri, Jul 27, 2018 at 5:04 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > My ideal version would be substantially shorter, maybe just quote the > golden rule, but I am happy with the suggestion to just adapt this text. I > particularly appreciate the lack of absolutism in the text, and the > acknowledgement that it is possible to have a bad day even while not > distracting from the overall message. > -- Marten > > On Fri, Jul 27, 2018 at 6:30 PM, Ralf Gommers > wrote: > >> >> >> On Fri, Jul 27, 2018 at 10:02 PM, Stefan van der Walt < >> stef...@berkeley.edu> wrote: >> >>> Hi everyone, >>> >>> A while ago, SciPy (the library) adopted its Code of Conduct: >>> >>> https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_of_conduct.html >>> >>> We worked hard to make that document friendly, while at the same time >>> stating clearly the kinds of behavior that would and would not be >>> tolerated. >>> >>> I propose that we adopt the SciPy code of conduct for NumPy as well. It >>> is a good way to signal to newcomers that this is a community that cares >>> about how people are treated. And I think we should do anything in our >>> power to make NumPy as attractive as possible! >>> >> >> +1 >> >> Maybe a bit of context: the SciPy code of conduct had quite a lot of >> discussion, and importantly in the end everyone involved in the discussion >> was happy with (or at least not displeased by) the final document. Hence I >> see it as a good document to adopt also by other projects. >> >> And here's what I wrote as the intro for that CoC discussion: >> As you probably know, Code of Conduct (CoC) documents are becoming more >> common every year for open source projects, and there are a number of good >> reasons to adopt a CoC: >> 1. It gives us the opportunity to explicitly express the values and >> behaviors we'd like to see in our community. >> 2. It is designed to make everyone feel welcome (and while I think we're >> a welcoming community anyway, not having a CoC may look explicitly >> unwelcoming to some potential contributors nowadays). >> 3. It gives us a tool to address a set of problems if and when they >> occur, as well as a way for anyone to report issues or behavior that is >> unacceptable to them (much better than having those people potentially >> leave the community). >> 4. SciPy is not yet a fiscally sponsored project of NumFOCUS, however I >> think we'd like to be in the near future. NumFOCUS has started to require >> having a CoC as a prerequisite for new projects joining it. The PSF has >> the same requirement for any sponsorship for events/projects that it gives. >> >> Note on (4): NumPy is a sponsored project of NumFOCUS, and I've been >> asked several times how it can be that NumPy is sponsored but does not have >> a CoC. >> >> Cheers, >> Ralf >> >> >>> If we adopt this document as policy, we will need to select a Code of >>> Conduct committee, to whom potential transgressions can be reported. >>> The individuals doing this for SciPy may very well be happy to do the >>> same for NumPy, but the community should decide whom will best serve >>> those roles. >>> >>> Let me know your thoughts. >>> >>> Thanks! >>> Stéfan >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >> >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adoption of a Code of Conduct
On Fri, Jul 27, 2018 at 6:03 PM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > My ideal version would be substantially shorter, maybe just quote the > golden rule, but I am happy with the suggestion to just adapt this text. I > particularly appreciate the lack of absolutism in the text, and the > acknowledgement that it is possible to have a bad day even while not > distracting from the overall message. > I tend to the shorter is better side as well, but need to reread what SciPy ended up with. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adoption of a Code of Conduct
My ideal version would be substantially shorter, maybe just quote the golden rule, but I am happy with the suggestion to just adapt this text. I particularly appreciate the lack of absolutism in the text, and the acknowledgement that it is possible to have a bad day even while not distracting from the overall message. -- Marten On Fri, Jul 27, 2018 at 6:30 PM, Ralf Gommers wrote: > > > On Fri, Jul 27, 2018 at 10:02 PM, Stefan van der Walt < > stef...@berkeley.edu> wrote: > >> Hi everyone, >> >> A while ago, SciPy (the library) adopted its Code of Conduct: >> https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_ >> of_conduct.html >> >> We worked hard to make that document friendly, while at the same time >> stating clearly the kinds of behavior that would and would not be >> tolerated. >> >> I propose that we adopt the SciPy code of conduct for NumPy as well. It >> is a good way to signal to newcomers that this is a community that cares >> about how people are treated. And I think we should do anything in our >> power to make NumPy as attractive as possible! >> > > +1 > > Maybe a bit of context: the SciPy code of conduct had quite a lot of > discussion, and importantly in the end everyone involved in the discussion > was happy with (or at least not displeased by) the final document. Hence I > see it as a good document to adopt also by other projects. > > And here's what I wrote as the intro for that CoC discussion: > As you probably know, Code of Conduct (CoC) documents are becoming more > common every year for open source projects, and there are a number of good > reasons to adopt a CoC: > 1. It gives us the opportunity to explicitly express the values and > behaviors we'd like to see in our community. > 2. It is designed to make everyone feel welcome (and while I think we're a > welcoming community anyway, not having a CoC may look explicitly > unwelcoming to some potential contributors nowadays). > 3. It gives us a tool to address a set of problems if and when they occur, > as well as a way for anyone to report issues or behavior that is > unacceptable to them (much better than having those people potentially > leave the community). > 4. SciPy is not yet a fiscally sponsored project of NumFOCUS, however I > think we'd like to be in the near future. NumFOCUS has started to require > having a CoC as a prerequisite for new projects joining it. The PSF has > the same requirement for any sponsorship for events/projects that it gives. > > Note on (4): NumPy is a sponsored project of NumFOCUS, and I've been asked > several times how it can be that NumPy is sponsored but does not have a > CoC. > > Cheers, > Ralf > > >> If we adopt this document as policy, we will need to select a Code of >> Conduct committee, to whom potential transgressions can be reported. >> The individuals doing this for SciPy may very well be happy to do the >> same for NumPy, but the community should decide whom will best serve >> those roles. >> >> Let me know your thoughts. >> >> Thanks! >> Stéfan >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adoption of a Code of Conduct
On Fri, Jul 27, 2018 at 10:02 PM, Stefan van der Walt wrote: > Hi everyone, > > A while ago, SciPy (the library) adopted its Code of Conduct: > https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_ > of_conduct.html > > We worked hard to make that document friendly, while at the same time > stating clearly the kinds of behavior that would and would not be > tolerated. > > I propose that we adopt the SciPy code of conduct for NumPy as well. It > is a good way to signal to newcomers that this is a community that cares > about how people are treated. And I think we should do anything in our > power to make NumPy as attractive as possible! > +1 Maybe a bit of context: the SciPy code of conduct had quite a lot of discussion, and importantly in the end everyone involved in the discussion was happy with (or at least not displeased by) the final document. Hence I see it as a good document to adopt also by other projects. And here's what I wrote as the intro for that CoC discussion: As you probably know, Code of Conduct (CoC) documents are becoming more common every year for open source projects, and there are a number of good reasons to adopt a CoC: 1. It gives us the opportunity to explicitly express the values and behaviors we'd like to see in our community. 2. It is designed to make everyone feel welcome (and while I think we're a welcoming community anyway, not having a CoC may look explicitly unwelcoming to some potential contributors nowadays). 3. It gives us a tool to address a set of problems if and when they occur, as well as a way for anyone to report issues or behavior that is unacceptable to them (much better than having those people potentially leave the community). 4. SciPy is not yet a fiscally sponsored project of NumFOCUS, however I think we'd like to be in the near future. NumFOCUS has started to require having a CoC as a prerequisite for new projects joining it. The PSF has the same requirement for any sponsorship for events/projects that it gives. Note on (4): NumPy is a sponsored project of NumFOCUS, and I've been asked several times how it can be that NumPy is sponsored but does not have a CoC. Cheers, Ralf > If we adopt this document as policy, we will need to select a Code of > Conduct committee, to whom potential transgressions can be reported. > The individuals doing this for SciPy may very well be happy to do the > same for NumPy, but the community should decide whom will best serve > those roles. > > Let me know your thoughts. > > Thanks! > Stéfan > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Adoption of a Code of Conduct
Hi everyone, A while ago, SciPy (the library) adopted its Code of Conduct: https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_of_conduct.html We worked hard to make that document friendly, while at the same time stating clearly the kinds of behavior that would and would not be tolerated. I propose that we adopt the SciPy code of conduct for NumPy as well. It is a good way to signal to newcomers that this is a community that cares about how people are treated. And I think we should do anything in our power to make NumPy as attractive as possible! If we adopt this document as policy, we will need to select a Code of Conduct committee, to whom potential transgressions can be reported. The individuals doing this for SciPy may very well be happy to do the same for NumPy, but the community should decide whom will best serve those roles. Let me know your thoughts. Thanks! Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] NEP 15, 20 implementations waiting for review
Two largish pull requests that implement approved NEPS are waiting for review: https://github.com/numpy/numpy/pull/11175 for expanded gufunc signatures (NEP 20) https://github.com/numpy/numpy/pull/10915 for merging multiarray and umath c-extension modules (NEP 15) I realize reviewer time is precious, and appreciate that these PRs are perhaps more complex to review than others, but it would be nice to keep the good momentum we have in the NEP process moving forward. Thanks, Matti ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP
On Tue, Jul 24, 2018 at 5:38 PM Ralf Gommers wrote: > This is very developer-centric view. We have lots of users and also lots > of no-longer-active contributors. The needs, interests and previous work > put into NumPy of those groups of people matter. > Yes, I suppose it is :). I tend to view NumPy's developers (interpreted somewhat broadly, including those who contribute to the project in other ways) as the ultimate representatives of NumPy's user base. > I like would suggest the following criteria for considering removing a >> NumPy submodule: >> > 1. It cannot be relied upon by other portions of NumPy. >> 2. Either >> (a) the submodule imposes a significant maintenance burden upon the rest >> of NumPy that is not balanced by the level of dedicated contributions, or >> (b) much better alternatives exist outside of NumPy >> > > To quote Nathaniel: "the rest of our policy is all about measuring > disruption based on effects on users". That's absent from your criteria. > Yes, "Can be achieved with minimum disruption for users" would be appropriate to add as another top level criteria. Why I would like to keep this point in is: > - the discussion does come up, see draft brainstorm roadmap list and > gh-11457. > - the outcome of such discussions is in practice 100% clear. > - I would like to avoid having drawn out discussions each time (this eats > up a lot of energy for me), and I *really* would like to avoid saying "I > don't have time to discuss, but this is just not going to happen" or > "consider it vetoed". > - Hence: just write it down, so we can refer to it. > I would rather we just say that the bar for deprecating or removing *any* functionality in NumPy is extremely high. np.matrix is probably the best example in recent times: - np.matrix is officially discouraged (which we prefer even to deprecation) - we *anticipate* deprecating it as soon as there's a viable alternative to scipy.sparse - even then, we will be very cautious about ever removing it, with the understanding that it is widely used As for updating this section of the NEP: - We could certainly note that to date NumPy has not removed any complete submodules (is this true?), and that these modules in particular, the cost-benefit ratio does not favor removal at this time. - Documenting the criteria we've come up with here, even though it hasn't been satisfied yet, might be helpful to demonstrate the high bar that is required. - I don't like rejecting the possibility of removing submodules entirely "simply not a good idea". It may become a good idea in the future, if some of the underlying facts change. I would also suggest highlighting two other strategies that NumPy uses in favor of deprecation/removal: - Official discouragement. Discouraging or deemphasizing in our docs is the preferred strategy for older APIs that still have well defined behavior but that are arguably less consistent with the rest of NumPy. Examples: isin vs in1d, stack/block vs hstack/dstack/vstack. - Benign neglect. This is our preferred strategy to removing submodules. Merely being in NumPy does not automatically guarantee that a module is well maintained, nor does it imply that a submodule is the best tool for the job. That's OK, as long as the incremental maintenance burden on the rest of NumPy is not too high. ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
