<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 26 Apr 2018 at 07:41 Victor Stinner <<a href="mailto:vstinner@redhat.com">vstinner@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, maybe asyncio is not a good candidate to experiment. I know that<br>
asyncio internals are complex, and asynchronous programming is hard.<br>
<br>
Sure, the risk of regression in the Documentation is lower :-) But it<br>
doesn't mean that we should accept any change in the doc. I already<br>
saw people proposing to fix the doc, whereas they misunderstood<br>
something and the doc was plain right :-)<br></blockquote><div><br></div><div>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. ;)<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Victor<br>
<br>
2018-04-26 16:31 GMT+02:00 Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>>:<br>
> On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner <<a href="mailto:vstinner@redhat.com" target="_blank">vstinner@redhat.com</a>> wrote:<br>
> [..]<br>
>> I identified 3 obvious subteams:<br>
><br>
>> * Documentation<br>
>> * IDLE<br>
>> * asyncio<br>
><br>
> Sorry, asyncio isn't an obvious choice for me. There are not so many<br>
> low-hanging fruits left in asyncio except improvements to its<br>
> documentation. I'm a firm -1 to allow people to merge without Andrew's or<br>
> my review at this point, almost no PRs are fine when they are submitted<br>
> (including our own). There's a lot of complexity in asyncio which isn't<br>
> immediately evident to people who are not working with its internals on a<br>
> daily basis.<br>
><br>
> Now, people who report and submit asyncio PRs seem to do that just fine<br>
> without subteams. Although it's rare to see people contributing more than<br>
> once, but that's not an asyncio-specific pattern, I see it in every big and<br>
> complex project I happen to contribute to.  Even having a dedicated asyncio<br>
> mailing list doesn't help to get people to contribute to asyncio more<br>
> frequently.<br>
><br>
> Don't get me wrong, Andrew and I would certainly welcome any help we can<br>
> get, but I'd be against running a public experiment with asyncio to see if<br>
> 2 of us can handle the management of the new sub-teams idea.  Unfortunately<br>
> 2 of us just don't have capacity for that.<br>
><br>
> Please pick another project for your idea. Maybe we should try it for<br>
> documentation first, where we have a lot of core devs who can help with PR<br>
> reviews and management of "subteams".<br>
><br>
> Yury<br>
_______________________________________________<br>
python-committers mailing list<br>
<a href="mailto:python-committers@python.org" target="_blank">python-committers@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>