On Sat., 29 Sep. 2018, 7:40 pm Łukasz Langa, <luk...@langa.pl> wrote:
> > On Sep 29, 2018, at 09:53, Nick Coghlan <ncogh...@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 > - Ł >
_______________________________________________ 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/