On 6 June 2018 at 15:02, Donald Stufft donald@stufft.io wrote:
Comments on the proposal itself below, but I wanted to sort of diverge a bit here first.
I think our first order of business should basically be to figure out some sort of long term decision making process. In my eyes, things like some sort of communication (realtime, async, whatever) or any of our other really open questions sort of should generally a back seat to the question of how do we, as a group, make decisions. We currently have the “BDFRN” distinction, but I view that as a fairly adhoc idea, sort of like “emergency powers” where the ultimate goal should be to to define our real decision making process, and then transition us to that. Once we have that, then I think we should start focusing on communication and other structure.
Agreed on this.
## Model
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.
Structure of meeting TBD, but a something along the lines of: Announcements, Old Business, New Business.
A moderator and minute-taker would be responsible for summarizing the meeting, collecting project updates, and publishing minutes and updates for archival purposes and public review. Meeting note publication method TBD.
Adherence to the PyPA Code of Conduct would be required for all attendees.
This sounds reasonably OK to me as long as we tune the recurrence correctly. My primary concern is that the PyPA is getting larger (and is likely to continue to do so), and we have members from all across the globe, so scheduling a single time when everyone who wants to participate is able to could prove difficult. To my knowledge we basically have people on complete opposite ends of the world, and everywhere in between now.
We likely also want to add in some mechanism to prevent these from becoming very long or trying to boil the ocean (particularly the first couple are likely to be more prone to this).
I'm personally not keen on the key process being a real-time one. My personal open source time is structured in such a way that I'd basically never be able to attend something like this. I assume/hope that there would be some sort of mechanism for whatever was discussed to be available to everyone (ideally by being mailed out - I prefer push-style communications over pull-style "the logs are here, go & look") with a means for people who didn't attend (but are valid "participants" as per the description) to comment/contribute after the fact. But as currently stated, there doesn't seem to be anything like that, which bothers me.
My personal preference would be that we stick to an asynchronous means of discussion/communication, like email. I've seen no evidence that real-time discussions as a *general* mechanism[1] produce better results, and I have definitely seen evidence that they leave people unable to attend feeling at least somewhat disenfranchised. But I'm happy to go with the majority, as long as attendance is not necessary in order to be involved and listened to on an equal footing with people who *do* attend.
Paul
[1] Having a chat-style option for cases where real-time communication is useful would be fine. But I'm not sure I see evidence that the PyPA is big enough or has sufficiently urgent issues to warrant something like that.