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

[Stephan Hoyer]

I'll note that we basically used GitHub for revising __array_ufunc__ NEP,
and I think that worked out better for everyone involved. The discussion
was a little too specialized and high volume to be well handled on the
mailing list.

On Fri, Mar 9, 2018 at 8:58 AM Stephan Hoyer <shoyer at gmail.com> wrote:

> I also have a slight preference for managing the discussion on GitHub,
> which is a bit more fully featured than email for long discussion (e.g., it
> supports code formatting and editing comments). But I'm really OK either
> way as long as discussion is kept in one place.
>
> We could still stipulate that NEPs are advertised on the mailing list:
> first, to announce them, and second, before merging them marked as
> accepted. We could even still merge rejected/abandoned NEPs as long as they
> are clearly marked.
>
> On Fri, Mar 9, 2018 at 7:24 AM Charles R Harris <charlesr.harris at gmail.com>
> wrote:
>
>> On Thu, Mar 8, 2018 at 11: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.
>>>
>>>
>> I have a slight preference for managing the discussion on Github. Note
>> that I added a `component: NEP` label and that discussion can take place on
>> merged/closed PRs, the index could also contain links to proposed NEP PRs.
>> If we just left PR open until acceptance/rejection the label would allow
>> the proposed NEPs to be easily found, especially if we include the NEP
>> number in the title, something like `NEP-10111: ` .
>>
>> Chuck
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180309/fc58c60f/attachment.html>