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

[Paul Moore]

On 23 January 2017 at 19:31, Brett Cannon <brett at python.org> wrote:
> 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?).

Hmm, issues and PRs on separate trackers? That might be interesting...
(Although I'm sure you've thought it through and it'll be fine).

I think the real issue here is that I really don't work well with
systems where I have to go and look for stuff (I get distracted, or
don't bother). Email is a huge win for me because I'm always looking
at it, so things arriving by email get my attention. But of course,
the converse of that is that too *much* traffic swamps me and I just
start ignoring that folder (which is basically what happens with
"Python bugs" and "Python checkins"). So I need to manage that, and
bpo traffic is far away the highest-traffic thing I receive, so I
haven't really evolved strategies for dealing well with that level of
traffic.

> 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.

If PRs will come on github, I guess that as a member of the python-dev
group I'll get the emails by default (like with pip, or other projects
I contribute to). I'd probably just start by seeing how well skimming
those emails would work (I imagine traffic on actual PRs would be
notably less than on bugs as a whole).

The trouble is, it's not really the experts list that matters to me. I
get Windows issues from bpo at the moment, and while I'm interested in
most of them, I don't often have much to contribute in terms of actual
code reviews (because they tend to be C issues). I've no idea what
facilities github has for anything in between "get everything" and
"get nothing except what I subscribe to explicitly" as I've never yet
needed to use anything but the former. And while a custom bot might be
interesting, it's not going to pick up the sorts of things I get by
skimming stuff.

> 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).

new-bugs-announce might be a better list for me than the full bpo
stream. I might try that. IIRC, I joined the bpo and python checkins
lists because the "guidelines for new core devs" said I should. Maybe
there should be a qualification in there that the traffic is high, and
if you have limited time, lower-traffic options might be better (or
maybe there is and I ignored it :-))?

Paul