On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote:

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk 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. Ralf

On Thu, Mar 8, 2018 at 11:26 PM, Ralf Gommers wrote:

On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote:

...

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk 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

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 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 wrote:

...

On Thu, Mar 8, 2018 at 11:26 PM, Ralf Gommers wrote:

...

On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote:

...

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk 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

Hi Nathaniel, astropy is an example of a project that does essentially all discussion of its "Astropy Proposals for Enhancement" on github. I actually like the numpy approach of sending anything to the mailing list that deserves community input (which includes NEP by their very nature). I don't think it has to be either/or, though; maybe the preferred approach is in fact a combination, where the draft is send to the mailing list, initial general comments are incorporated, and then discussion moves to github when one is past the "general interest" stage. When exactly this happens will be somewhat subjective, but probably is not important to nail down anyway. All the best, Marten p.s. I think the __array_ufunc__ discussion indeed showed that github can work, but only once the general ideas are agreed upon - the initial discussion become hopeless to follow (though I'm not sure a mailing list discussion would have been any better).

On Fri, Mar 9, 2018 at 12:00 AM, Nathaniel Smith wrote:

On Thu, Mar 8, 2018 at 10:26 PM, Ralf Gommers wrote:

...

On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote:

...

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk 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

Reviving this discussion -- I don't really care what our policy is, but can we make a decision one way or the other about where we discuss NEPs? We've had a revival of NEP writing recently, so this is very timely. Previously, I was in slight favor of doing discussion on GitHub. Now that I've started doing a bit of NEP writing, I've started to swing the other way, since it would be nice to be able to reference draft/rejected NEPs in a consistent way -- and rendered HTML is more readable than raw RST in pull requests. On Wed, Mar 14, 2018 at 6:52 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:

Apparently, where and how to discuss enhancement proposals was recently a topic on the python mailing list as well -- see the write-up at LWN: https://lwn.net/SubscriberLink/749200/4343911ee71e35cf/ The conclusion seems to be that one should switch to mailman3... -- Marten _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

On Tue, May 29, 2018 at 9:24 AM, Charles R Harris

wrote:

On Tue, May 29, 2018 at 9:46 AM, Stephan Hoyer wrote:

...

Reviving this discussion -- I don't really care what our policy is, but can we make a decision one way or the other about where we discuss NEPs? We've had a revival of NEP writing recently, so this is very timely.

Previously, I was in slight favor of doing discussion on GitHub. Now that I've started doing a bit of NEP writing, I've started to swing the other way, since it would be nice to be able to reference draft/rejected NEPs in a consistent way -- and rendered HTML is more readable than raw RST in pull requests.

My understanding of the discussion at the sprint was that we favored quick commits of NEPs with extended discussions of them on the list. Updates and changes would go in through the normal PR process. In practice, I expect there will be some overlap, I think the important thing is the quick commit with the understanding that the NEPs are only proposals until formally adopted. I think the formal adoption process is not well defined...

For the formal adoption part, how about: 1. When discussions/disagreements appear to have been resolved, a NEP author or a core developer may propose that the NEP is formally adopted. 2. The formal decision is made by consensus, according to https://docs.scipy.org/doc/numpy/dev/governance/governance.html#consensus-ba... (which also covers how to handle consensus not being reached). Ralf