On 7 June 2018 at 09:59, <dan@danryan.co> wrote:
> > Recurring (weekly, monthly, or quarterly) synchronous meeting of the
> PyPA via a communications channel TBD.  This channel should allow for a log
> of discussions and some moderation.

Two things -- I think some kind of synchronous communication is incredibly helpful, especially for those of us who don't really know each other yet.  The formality of email sometimes makes it difficult to develop a rapport, so I am a little worried that without any agreed-upon synchronous communication we will make it hard for people (like myself, as a newcomer to the PyPA) to collaborate and to feel empowered to assert a contrary position. Most of you probably have spoken to me at least once by now and know that I'm not exactly shy, but the rest of you, I'm not sure how I can get to know you personally without the aid of synchronous communication.

Right, having a common synchronous chat option (e.g. on python.zulipchat.com) is incredibly useful for folks that don't personally like using Twitter as a global asynchronous water cooler (and there are *heaps* of reasons for folks to prefer to avoid Twitter).
On the other hand, formal meetings are somewhat problematic themselves because they tend to favor the most dominant voices and I would hate to silence a good idea by never giving it the space to be articulated. And like Paul, I spend most of my day in meetings, so I'm not eager to put more of those on my calendar. If there were some way to have a communication platform that supported both synchronous and asynchronous communication, that would be ideal... I know slack and others like it claim to do this, but slack is really built for synchronous communication. I'm not sure if there is a good option in this space

Roughly speaking I don't think decisions should be made synchronously without allowing asynchronous input somewhere in the process.

Agreed (and I feel this especially keenly as someone that's essentially 8 hours out of sync with both the US and Europe, so it's personally and professionally routine for me to have async conversations with 24 hour turn-around times between messages).

Synchronous comms are useful for tactical decision making on the scale of hours or days where it doesn't really matter whether or not the conversation is inclusive (e.g. folks working on a targeted project like "Migrate PyPI to Warehouse and pypi.org" where the "Responsible & Accountable" lists are short, any required consultation happened up front, and it's OK for everyone else to just be informed of the outcomes after the decisions have already been made)

Synchronous comms also work well for collaborative discussion aimed at helping folks that are currently disagreeing with each other better understand each other's perspective (since you can work through many more active listening iterations in a given amount of time synchronously than you can asynchronously).

However, synchronous events are appallingly awful for strategic decision making in globally distributed communities. That's one of the reasons we effectively banned the Python Language Summit from actually making any binding language design decisions after the first couple: the folks missing from the in-person event significantly outnumber those that are present. (The other reason was a lack of search-engine-friendly records of the conversation, and that's a concern that applies to most electronic options as well: Google et al already struggle to give good search results from mailing lists, and they're even worse at finding relevant information in real time chat archives)


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia