On Mon, 23 Jan 2017 at 11:50 Paul Moore email@example.com wrote:
On 23 January 2017 at 19:31, Brett Cannon firstname.lastname@example.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
PRs and what will be kept on bpo (e.g. we will more than likely label
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).
You can look at the test issue at https://bugs.python.org/issue2771 to see what's there so far (specifically the Pull Requests section and the latest PR listed there).
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
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).
You will need to have email notifications turned on with GitHub and watch the cpython repository once we migrate. I think that will be enough if you want it through GitHub.
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.
You could try training a deep neural network to pick up on the things you care about <half-wink>.
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
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 :-))?
It actually says you can choose: https://cpython-devguide.readthedocs.io/en/latest/coredev.html?highlight=new...