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 <sho...@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.har...@gmail.com> > wrote: > >> On Thu, Mar 8, 2018 at 11:26 PM, Ralf Gommers <ralf.gomm...@gmail.com> >> wrote: >> >>> >>> >>> On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith <n...@pobox.com> wrote: >>> >>>> On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk >>>> <m.h.vankerkw...@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@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
