<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sat., 29 Sep. 2018, 7:40 pm Łukasz Langa, <<a href="mailto:lukasz@langa.pl" target="_blank" rel="noreferrer">lukasz@langa.pl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><div dir="ltr">On Sep 29, 2018, at 09:53, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" rel="noreferrer noreferrer" target="_blank">ncoghlan@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="auto"><span style="font-family:sans-serif">Especially on the eve of critical governance discussions that will heavily impact the future of python-dev.</span></div></div></blockquote><div><br></div><div>Ironically it's the very gravity of those upcoming discussions that made us decide to move fast on this.</div><div><br></div><div>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.</div><div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>Discourse is a chance to address the problems that contributed to the BDFL stepping down.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><br><blockquote type="cite"><div dir="ltr"><div dir="auto"><font face="sans-serif">arbitrary decision making</font></div></div></blockquote>...<br><blockquote type="cite"><div dir="ltr"><div dir="auto"><font face="sans-serif">insufficiently representative group</font></div></div></blockquote><div>...</div><blockquote type="cite"><div dir="ltr"><div dir="auto"><font face="sans-serif">without involving most of the people affected</font></div></div></blockquote>...<div><br></div><div>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 <i>sufficiently</i> representative and involved <i>most</i> of the people affected.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The governance discussions affect, and need to involve *all* committers, not just the currently active ones.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>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 <span style="background-color:rgba(255,255,255,0)">you have committer unanimity in mind, that's not something that was feasible regardless of the forum.</span></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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".</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">In this case I was surprised twice over:</div><div dir="auto"><br></div><div dir="auto">* a core workflow change was proposed and implemented without even being mentioned on the core-workflow mailing list</div><div dir="auto">* 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</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">- a cpython-governance subforum will be set up on <a href="http://discuss.python.org">discuss.python.org</a></div><div dir="auto">- a service account will be set up so all traffic in that subforum is mirrored to python-committers</div><div dir="auto"><br></div><div dir="auto">Actually posting to the discussions would require going to the forum site, but nothing would need to change if just reading them.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nick.</div><div dir="auto"><br></div><div dir="auto">[1] <a href="https://opensource.com/open-organization/resources/open-decision-framework">https://opensource.com/open-organization/resources/open-decision-framework</a></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>- Ł</div></div></blockquote></div></div></div>