[python-committers] python-committers is dead, long live discuss.python.org

[Nick Coghlan]

On Sat., 29 Sep. 2018, 7:40 pm Łukasz Langa, <lukasz at langa.pl> wrote:

>
> On Sep 29, 2018, at 09:53, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> Especially on the eve of critical governance discussions that will heavily
> impact the future of python-dev.
>
>
> Ironically it's the very gravity of those upcoming discussions that made
> us decide to move fast on this.
>
> Part of why we are in this mess in the first place is due to inadequate
> moderation controls available on mailing lists and the way they invite
> thundering herds of answers and the combinatorial explosion of posts in
> trees of discussion. The PEP 572 process exercised this painfully well.
>

This is not a problem that applies to python-committers, since there are
less than a hundred people on the planet with permission to post to it.


> Discourse is a chance to address the problems that contributed to the BDFL
> stepping down.
>

For the generally accessible mailing lists, I agree completely, and if this
had been a post to core-workflow saying "We want to experiment with closing
python-ideas and moving it to a Discourse forum", I would been an
enthusiastic +1. The same goes for core-mentorship: I think we've given MM3
a fair go there, and my conclusion is that while it does improve several
aspects of the moderation process over MM2, it's still much weaker on that
front than Discourse.


That isn't what happened: the *first* I heard about this idea was a
peremptory *order* to say that I had to move *now*, which isn't how the
system works. Even when Guido was BDFL he wouldn't have been able to
declare "We're dropping the mailing lists and switching to web forums" and
make it stick - we'd have told him to write a PEP and make his case, just
like anyone else (akin to Mariatta's current excellent PEP laying out the
pros and cons of switching to a different issue tracker).

The closest equivalent I can think of would be when python-committers was
split out from python-dev (so that subscribing to python-dev could be made
optional), and even then most of the critical announcements continued to be
cross-posted to python-dev, and the discussions themselves didn't move.




>
> arbitrary decision making
>
> ...
>
> insufficiently representative group
>
> ...
>
> without involving most of the people affected
>
> ...
>
> Hold on. Out of the 30-something committers active in the past two
> releases, 20-something were at the sprint. (I can pull more detailed stats
> but I'm on the phone now.) Setting up Discourse with the intent of
> replacing the mailing lists met no opposition at the sprint. By all counts,
> the group was *sufficiently* representative and involved *most* of the
> people affected.
>

The governance discussions affect, and need to involve *all* committers,
not just the currently active ones.

One particular reason why I consider the group at in-person events to be
inherently insufficiently representative is that I was a core developer for
more than five years before I ever met another core dev in person, and
during that time I felt fully included in the decision making process.

I think that's less true now, and part of the reason for it is that more
discussions are taking place in contexts where the only folks present are
those in a position to devote several work days to CPython related travel.
Accounting for the opinions, perspectives, and feelings of those that
aren't present only happens through the deliberate effort of those that are
in the room.


>From 2011 to 2017, that "in the room" group pretty consistently included
me, since Red Hat were very permissive when it came to allowing time for
that kind of thing, and the PSF was willing to compensate for RH's
reluctance to provide travel funding.

But I never forgot what I'd needed to feel included in the process before
that job change, so I constantly asked myself not "who's here?" but rather
"Who *isn't* here?", and advocated for approaches that lessened the gap
between those two groups (most importantly: in-person events being for high
bandwidth discussions that would subsequently be summarised in writing, not
final decisions that would be handed down with no further asynchronous
online discussion to be entered into)



> I would prefer for everybody to be there, of course. Some decided against
> it, some could not be there even though they wanted to. This is
> unfortunate. But if you have committer unanimity in mind, that's not
> something that was feasible regardless of the forum.
>

No, it isn't about unanimity, it's about ensuring that folks have the
opportunity to be heard, rather than being explicitly told "You weren't
there at the time, so your point of view is irrelevant".

Red Hat had a good phrase for this in their Open Decision Making [1]
framework: affected associates may still be disappointed by an outcome, but
they shouldn't be surprised by it.

In this case I was surprised twice over:

* a core workflow change was proposed and implemented without even being
mentioned on the core-workflow mailing list
* the first I heard about it on python-committers was this peremptory order
to move, rather than an informational post describing the discussion that
was had at the sprints, and the potential problems the proposal was aiming
to solve

Now, if folks working on governance PEPs want to receive feedback through a
more structured forum than the python-committers mailing list offers, I
think that's an entirely reasonable request, but the approach I would
propose to tackle that is to add a section to PEP 8000 saying:

- a cpython-governance subforum will be set up on discuss.python.org
- a service account will be set up so all traffic in that subforum is
mirrored to python-committers

Actually posting to the discussions would require going to the forum site,
but nothing would need to change if just reading them.

That doesn't require changing the requirements for maintaining core commit
access the way the proposal at the start of this thread does, while still
avoiding the need to wrangle governance threads directly on the mailing
list.

Regards,
Nick.

[1]
https://opensource.com/open-organization/resources/open-decision-framework


> - Ł
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180930/65442062/attachment.html>