On Sun, 22 Jan 2017 at 14:26 Paul Moore <p.f.moore@gmail.com> wrote:
On 22 January 2017 at 21:59, Barry Warsaw <barry@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/