My concern with fully automated tools is that they tend to be overly stringent.
There's many places where we violate PEP8 for valid stylistic reasons, e.g. to
align the values of an array literal.
btw Stéfan, how's the PR for using PEP8speaks only for the diff?
On 15 Apr 2017, 9:40 AM +1000, St
On Fri, Apr 14, 2017, at 15:23, Nathaniel Smith wrote:
> On Apr 14, 2017 9:12 AM, "Stefan van der Walt"
> wrote:
>> On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote:
>> > I wonder if it would be worthwhile to have a bot that
>> > automatically
>> > pushes formatting fixes to submitted PR
On Apr 14, 2017 9:12 AM, "Stefan van der Walt" wrote:
On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote:
> On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux
> wrote:
> > Hello,
> >
> > For style-changes (such as pep8/flake8) elements, I find that very
often new
> > contributors don't know the
> This should be added to the contributor guidelines, potentially as a
> separate doc linked in. Would you mind taking lead on that?
>
I started a PR with a blank file to get a place for comments. I'll start
to throw few ideas in it soon.
https://github.com/scikit-image/scikit-image/pull/2616
-
On Thu, Apr 13, 2017, at 21:30, Vighnesh Birodkar wrote:
> But apart from this the PR does what the algorithm it implements
> correctly. Can we merge such a PR in master and keep it as a private
> unexposed function while raising an issue to address it's shortcomings
> ? The function can de decora
On Thu, Apr 13, 2017, at 23:56, François Boulogne wrote:
> In addition, standard rules for our API would help (standard names of
> variables, standard checks, typical default values etc), even just for
> the reviewers. It will shortcut debates. Perhaps we can multiply these
> discussions:
> https:/
Hi Vighnesh
On Thu, Apr 13, 2017, at 23:34, Vighnesh Birodkar wrote:
> I understand where you are coming from. But don't you think there are
> instances when a contributor , after working on a new feature or
> function, does not have the time or energy to drive their work towards
> completion.
On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote:
> On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux
> wrote:
> > Hello,
> >
> > For style-changes (such as pep8/flake8) elements, I find that very often new
> > contributors don't know they can configure their text editors to display the
> > pe
On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux
wrote:
> Hello,
>
> For style-changes (such as pep8/flake8) elements, I find that very often new
> contributors don't know they can configure their text editors to display the
> pep8/pyflakes violations. Very often, it is a question of mentoring the
Dear all,
As Juan, I believe that merging unpolished features is just displacing
the problem. Like a messy desk tidy up by dumping everything in the drawers.
Side remarks, It seems to me that the magic box is not ticked for our
oldest PR. So we need to ask the contributor sometimes to do it. I tr
Hey Juan
I understand where you are coming from. But don't you think there are
instances when a contributor , after working on a new feature or function,
does not have the time or energy to drive their work towards completion.
The pending work might be too much for a single developer but it may be
Hey Vighnesh,
I'm -1 on this level of optimism. =P I think code in master should reflect with
probability 1 the best that we can make it. What that means is that "quick fix"
PRs can get merged because the maintainer who merges it can issue a fix
instantly. For large fixes, the most likely scena
Hello
I wonder if the scope of optimistic merging can be broader. Let's say we
have a working implementation of an algorithm which is not the best for one
or more of the following reasons.
- Suboptimal data structure choice (linear instead of logarithmic
complexity) which results in a minor speed
>
> For style-changes (such as pep8/flake8) elements, I find that very often
> new contributors don't know they can configure their text editors to
> display the pep8/pyflakes violations. Very often, it is a question of
> mentoring them through the process of configuring their text editors.
>
>
>
>
On Thu, Apr 13, 2017, at 15:45, Nelle Varoquaux wrote:
> On 13 April 2017 at 15:36, Stefan van der Walt
> wrote:
>> __
>>
>> On Thu, Apr 13, 2017, at 15:28, Nelle Varoquaux wrote:
>>> For style-changes (such as pep8/flake8) elements, I find that very
>>> often new contributors don't know they
On 13 April 2017 at 15:36, Stefan van der Walt wrote:
> On Thu, Apr 13, 2017, at 15:28, Nelle Varoquaux wrote:
>
> For style-changes (such as pep8/flake8) elements, I find that very often
> new contributors don't know they can configure their text editors to
> display the pep8/pyflakes violations
Hi Juan
On Wed, Apr 12, 2017, at 23:39, Juan Nunez-Iglesias wrote:
> One thing I don’t know what to do is figure out whether a contributor
> has turned on “collaboration”. What am I missing? I can see when
> *I’ve* turned it on, but for other pull requests I can’t get any info.
> Is the only wa
On Thu, Apr 13, 2017, at 15:28, Nelle Varoquaux wrote:
> For style-changes (such as pep8/flake8) elements, I find that very
> often new contributors don't know they can configure their text
> editors to display the pep8/pyflakes violations. Very often, it is a
> question of mentoring them through
Hello,
For style-changes (such as pep8/flake8) elements, I find that very often
new contributors don't know they can configure their text editors to
display the pep8/pyflakes violations. Very often, it is a question of
mentoring them through the process of configuring their text editors.
Recently,
Hello,
I agree with most of the points put by Juan. Here are some points that I
would like to put forward-
1) If there is a PR which has a merge conflict in a single file, we can
tell the contributor to fix it through Github PR through the merge conflict
button.
2) If the problem of merge is sev
Hi Stéfan,
I think figuring this out is certainly a high priority when it comes to being
contributor-friendly.
One thing I don’t know what to do is figure out whether a contributor has
turned on “collaboration”. What am I missing? I can see when *I’ve* turned it
on, but for other pull requests
Hi everyone, and especially devs
This afternoon, Nelle Varoquaux gave a short presentation at BIDS on
optimistic merging, a workflow suggested by the late Pieter Hintjens.
In optimistic merging, all PRs are merged into a project, and fixes
happen via additional patches or reverts. While, in my m
22 matches
Mail list logo
