Re: [python-committers] Idea: Create subteams?

[Andrew Svetlov]

Agree with Yuri. We have not big amount of non-committer contributions into
asyncio, and every non-trivial change requires very careful review.

On Thu, Apr 26, 2018, 17:32 Yury Selivanov  wrote:

> On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner 
> 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/
>
-- 
Thanks,
Andrew Svetlov
___
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/

Re: [python-committers] Idea: Create subteams?

[Brett Cannon]

On Thu, 26 Apr 2018 at 07:41 Victor Stinner  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 :
> > On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner 
> 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/

Re: [python-committers] Idea: Create subteams?

[Victor Stinner]

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 :
> On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner  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/

Re: [python-committers] Idea: Create subteams?

[Yury Selivanov]

On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner  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] Idea: Create subteams?

[Victor Stinner]

Hi,

While thinking about how to get more contributors onboard, I
identified that one bottleneck is building trust. Currently, a vote to
promote a contributor as a core dev requires the approval of almost
all active core developers, and this list is quite large (50 people?
more?). It takes a lot of time until a contributor is known by enough
people to start the process to promote them as a core dev.

My idea is to create subteams which would have less permission than
"everything": restrict changes to specific directories. It seems like
in practice, we already have such subteams: Documentation, IDLE and
asyncio have a dedicated Component in the bug tracker, their own
directories, a group of people focused on these components, and
even... a dedicated mailing list!

The restriction would be the ability to merge a pull request. Since
miss-ilington recently got the power of merging a PR, it makes me
think that it's doable to allow "non core" people to merge a change
under certain conditions. For example, let's say that a contributor
called "Alice" is part of a subteam. If Alice approves a change in the
review, added the "approved" label and the CI pass: a bot can merge
the change, since Alice is allowed to merge a PR modifying specific
directories.If Alice doesn't have the power, the bot may notice Alice
that she lacks permission and the bot may remove the label.

IMHO it's better to have two steps to merge: approval in the review
and a label, sometimes a change looks good but should not be merged
yet, or you don't want to take the responsibility to merge it
yourself.

What about current core developers? No change for them, they keep
their "super power" to modify everything.

If a member of a subteam shows interest to do more than only working
in a subteam, the usual promotion process with a vote on
python-committers can be followed.

My expectation is that it will be faster to promote a contributor into
a subteam. It's easier to trust someone if they is only allowed to
modify some directories. In my experience, people with the same
interest find their way to meet other people working on the same
topic. The trust is built naturally in a component.

You may see a parallel with the Linux kernel hierarchy and Linux
subsystems, but the proposed organization is different. In Python, the
tradition is that everybody works in the same repository. I don't want
to change that.

What do you think? Do you like the idea of subteams? Is it feasible
(the label and the bot things)?

I identified 3 obvious subteams:

* Documentation
* IDLE
* asyncio

Maybe you see more candidates?

Victor
___
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/