On Mon, 23 Jan 2017 at 11:50 Paul Moore <p.f.mo...@gmail.com> wrote: > On 23 January 2017 at 19:31, Brett Cannon <br...@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). >
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 > 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). 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 > 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 :-))? > It actually says you can choose: https://cpython-devguide.readthedocs.io/en/latest/coredev.html?highlight=new-bugs-announce#mailing-lists -Brett > > Paul >
_______________________________________________ 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/
