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 :-)
Victor
2018-04-26 16:31 GMT+02:00 Yury Selivanov <yselivanov.ml@gmail.com>:
On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner <vstinner@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