On Thu, 26 Apr 2018 at 07:41 Victor Stinner <vstin...@redhat.com> wrote:
> Ok, maybe asyncio is not a good candidate to experiment. I know that > asyncio internals are complex, and asynchronous programming is hard. > > Sure, the risk of regression in the Documentation is lower :-) But it > doesn't mean that we should accept any change in the doc. I already > saw people proposing to fix the doc, whereas they misunderstood > something and the doc was plain right :-) > While I have no issue with the subteam concept (e.g. we have the import-team on GitHub that automatically get asked for PR reviews for relevant files), doing what you're asking will require some coding which is always hard to get people to do. ;) The other option is we follow our own traditional practice of granting people commit rights for subsets of the code base and trust them to not overstep their comfort zones. I don't see why we can't do the same for documentation. If we trust them enough to change our docs then we should trust them enough to not touch C code unless they have the appropriate experience. > > Victor > > 2018-04-26 16:31 GMT+02:00 Yury Selivanov <yselivanov...@gmail.com>: > > On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner <vstin...@redhat.com> > wrote: > > [..] > >> I identified 3 obvious subteams: > > > >> * Documentation > >> * IDLE > >> * asyncio > > > > Sorry, asyncio isn't an obvious choice for me. There are not so many > > low-hanging fruits left in asyncio except improvements to its > > documentation. I'm a firm -1 to allow people to merge without Andrew's or > > my review at this point, almost no PRs are fine when they are submitted > > (including our own). There's a lot of complexity in asyncio which isn't > > immediately evident to people who are not working with its internals on a > > daily basis. > > > > Now, people who report and submit asyncio PRs seem to do that just fine > > without subteams. Although it's rare to see people contributing more than > > once, but that's not an asyncio-specific pattern, I see it in every big > and > > complex project I happen to contribute to. Even having a dedicated > asyncio > > mailing list doesn't help to get people to contribute to asyncio more > > frequently. > > > > Don't get me wrong, Andrew and I would certainly welcome any help we can > > get, but I'd be against running a public experiment with asyncio to see > if > > 2 of us can handle the management of the new sub-teams idea. > Unfortunately > > 2 of us just don't have capacity for that. > > > > Please pick another project for your idea. Maybe we should try it for > > documentation first, where we have a lot of core devs who can help with > PR > > reviews and management of "subteams". > > > > Yury > _______________________________________________ > 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/ >
_______________________________________________ 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/