[python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

Brett Cannon brett at python.org
Mon Jan 23 14:31:04 EST 2017


On Sun, 22 Jan 2017 at 14:26 Paul Moore <p.f.moore at gmail.com> wrote:

> On 22 January 2017 at 21:59, Barry Warsaw <barry at python.org> wrote:
> > On Jan 22, 2017, at 12:22 PM, Brian Curtin wrote:
> >
> >>I've been on the sidelines for a while myself for a number of reasons,
> >>but the shift to GitHub will pull me back in for sure, at least in
> >>terms of code review. I look forward to actually contributing code
> >>again soon, but easier tooling on reviews—rather, a shiny new one, as
> >>I'm aware of Reitveld—is enough of a carrot to bring me back in.
> >
> > I feel exactly the same way.  I'm very excited about the move to git and
> > GitHub and look forward to ramping my contributions back up.  Thank you
> Brett
> > and everyone else working so hard to make this as smooth and timely a
> > transition as possible.
>
> One question (and apologies if this has been discussed on another list
> somewhere) - my biggest bottleneck is the sheer number of python-bugs
> emails, and the difficulty of identifying ones I can contribute. Will
> we be moving to the github issue tracker, and/or are there any likely
> changes to more closely classify issues (ideally in a way that can be
> handled via mail filters)?


As Barry pointed out we are not moving the issue tracker. I thought about
it but I instantly got pushback on the idea and I only have so much time
and patience. :)


> Specifically, I'm interested in being able
> to restrict issue traffic by:
>
> * Pure Python, C, or "not code" (docs, etc).
> * Windows/Unix
> * Relevant stdlib module
>

Do you want this to search issues or PRs by? Since the migration has not
happened yet there isn't any emerged practice yet of what will be labeled
on PRs and what will be kept on bpo (e.g. we will more than likely label
what versions of Python a PR should be applied to, but should we also add
the type of labels you mention above?).

Someone could also write a bot to help with this, e.g. automatically add
people to a PR for a review if a module mentioned in
https://cpython-devguide.readthedocs.io/en/latest/experts.html#stdlib is a
part of the PR.


>
> (Or at least have some means of scanning issue emails to quickly spot
> which ones fall into which classification).
>

As Barry said, you can always follow new-bugs-announce or have a saved
search on bpo that sorts open issues by creation date and you check that
regularly (I do the latter and look at issues created the day previously
and just glance at their titles to decide if I should have a look).


>
> That's a long way beyond simply "switching to github which is a
> workflow I'm more familiar with" and while I hope github will help me
> to contribute more, I do think that ultimately the issue is simply
> that Python is a large and complex system, and people like me have
> limited time - and too much of it gets wasted playing "spot something
> I can work on", but that's inherent in the nature of a system this
> size.
>

Sure, but there are also things we can try to do to minimize the burden
(and anything that can be automated is best :) .

-Brett


>
> Paul
>
> PS I know there's searches and labels. But the "push" nature of email
> has its own benefits for me, so there's still a trade off there.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170123/3236611f/attachment.html>


More information about the python-committers mailing list