On Wed, Feb 7, 2018 at 11:29 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Wed, 07 Feb 2018 14:26:37 -0700, Charles R Harris wrote:
> I was thinking about things to do to simplify the NumPy development
> process. One thing that came to mind was our use of prefixes on commits,
> BUG, TST, etc. Those prefixes were originally introduced by David
> Cournapeau when he was managing releases in order help him track commits
> that might need backports. I like the prefixes, but now that we are
> organized by PRs, rather than commits, the only place we really need them,
> for some meaning of "need", is in the commit titles, and maintainers can
> change and edit those without problems. So I would like to propose that we
> no longer be picky about having them in the commit summary line.

+1 we got more picky over time, and that was never the intention. They're still useful, but we shouldn't request rework for such a minor thing.

> Furthermore, that got me thinking that there are probably other things we
> could do to simplify the development process. So I'd like folks to weigh in
> with other ideas for simplification or complaints about nit picky things
> that have annoyed them.

For scikit-image, we've started a policy of pushing minor edits
(spelling corrections, sentence restructuring, etc.) directly to the PR
branch, instead of flagging those during a review (we also have a PEP8
bot that mentions PEP8 issues, which makes the human reviews less
nitpicky).

+1. Especially useful for docstring formatting, that doesn't get picked up by a PEP8 bot

Ralf


To avoid users having to rebase, we now squash all PRs before merge
(and, typically, remove the commit messages).  This also means we can
allow merges with master to exist in the PR history.  Of course, if it
is clear that a user took particular care to hand-craft each patch we
don't squash, but those cases seem to be in the minority.

Thank you for bringing this up, Chuck; on projects with very limited
developer hours (almost any open source project?) whatever we can do to
lower the contribution barrier helps a great deal.

Best regards
Stéfan
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion