[Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

[Ralf Gommers]

On Fri, Mar 9, 2018 at 12:00 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Thu, Mar 8, 2018 at 10:26 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >
> >
> > On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk
> >> <m.h.vankerkwijk at gmail.com> wrote:
> >> > Hi Nathaniel,
> >> >
> >> > Overall, hugely in favour!  For detailed comments, it would be good to
> >> > have a link to a PR; could you put that up?
> >>
> >> Well, there's a PR here: https://github.com/numpy/numpy/pull/10706
> >>
> >> But, this raises a question :-). (One which also came up here:
> >> https://github.com/numpy/numpy/pull/10704#issuecomment-371684170)
> >>
> >> There are sensible two workflows we could use (or at least, two that I
> >> can think of):
> >>
> >> 1. We merge updates to the NEPs as we go, so that whatever's in the
> >> repo is the current draft. Anyone can go to the NEP webpage at
> >> http://numpy.org/neps (WIP, see #10702) to see the latest version of
> >> all NEPs, whether accepted, rejected, or in progress. Discussion
> >> happens on the mailing list, and line-by-line feedback can be done by
> >> quote-replying and commenting on individual lines. From time to time,
> >> the NEP author takes all the accumulated feedback, updates the
> >> document, and makes a new post to the list to let people know about
> >> the updated version.
> >>
> >> This is how python-dev handles PEPs.
> >>
> >> 2. We use Github itself to manage the review. The repo only contains
> >> "accepted" NEPs; draft NEPs are represented by open PRs, and rejected
> >> NEPs are represented by PRs that were closed-without-merging.
> >> Discussion uses Github's commenting/review tools, and happens in the
> >> PR itself.
> >>
> >> This is roughly how Rust handles their RFC process, for example:
> >> https://github.com/rust-lang/rfcs
> >>
> >> Trying to do some hybrid version of these seems like it would be
> >> pretty painful, so we should pick one.
> >>
> >> Given that historically we've tried to use the mailing list for
> >> substantive features/planning discussions, and that our NEP process
> >> has been much closer to workflow 1 than workflow 2 (e.g., there are
> >> already a bunch of old NEPs already in the repo that are effectively
> >> rejected/withdrawn), I think we should maybe continue that way, and
> >> keep discussions here?
> >>
> >> So my suggestion is discussion should happen on the list, and NEP
> >> updates should be merged promptly, or just self-merged. Sound good?
> >
> >
> > Agreed that overall (1) is better than (2), rejected NEPs should be
> visible.
> > However there's no need for super-quick self-merge, and I think it would
> be
> > counter-productive.
> >
> > Instead, just send a PR, leave it open for some discussion, and update
> for
> > detailed comments (as well as long in-depth discussions that only a
> couple
> > of people care about) in the Github UI and major ones on the list. Once
> it's
> > stabilized a bit, then merge with status "Draft" and update once in a
> while.
> > I think this is also much more in like with what python-dev does, I have
> > seen substantial discussion on Github and have not seen quick
> self-merges.
>
> Not sure what you mean about python-dev. Are you looking at the peps
> repository? https://github.com/python/peps


I was mostly thinking about packaging PEPs that are now also there, but
were separate. Stuff like
https://github.com/pypa/interoperability-peps/pull/54. There seems to be
significantly more comments on packaging things than on other PEPs.


>
>
> From a quick skim, it looks like of the last 37 commits, only 8 came
> in through PRs and the other 29 were pushed directly by committers
> without any review. 3 of the 8 PRs were self-merged immediately after
> submission, and of the remaining 5 PRs, 4 of them were from external
> contributors who didn't have commit rights, and the 1 other was a fix
> to the repo README, rather than an actual PEP change. I don't think
> I've ever seen any kind of substantive discussion in that repo -- any
> discussion is mostly restricted to helping new contributors with
> procedural stuff, maybe formatting issues or fixes to the PEP tooling.
>
> Anyway, just because python-dev does it that way doesn't mean that we
> have to too.
>
> But if we split discussions between GH and the mailing list, then
> we're definitely going to end up discussing substantive issues there
> (how do we know which discussions only a couple of people care
> about?), and trying to juggle that seems confusing to me, plus makes
> it harder to track down what happened later, after we've had multiple
> PRs each with their own comments...
>

It's not imho, because it's what we already do on this list. Github is a
superior review interface over mailing list, so my vote goes to using that
interface, while keeping this list in the loop on critical stuff and
decisions about to be made.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180309/b0f9f983/attachment-0001.html>