Proposal to require participation in a synchronous meeting

[Min RK]

Raising an Issue from the meeting minutes:

• [Open discussion] Require a (infrequent) synchronous meetings for all SSC representatives.
  • Why?
    • The SSC is still learning how to operate—synchronous meetings would help us evaluate our process and get better at it.
    • It’s been difficult to build momentum without all 11 members proactively engaging open JEPs together.
  • Possible cadence: once-a-month meeting.
  • Alternate times each month so that it equally inconveniences everyone. :)
  • It’s important that we do not reduce the importance of the weekly meetings, though.
    • These weekly meetings can become “working” meetings.

I'll add my response in a comment below.

[Min RK]

I would oppose any synchronous meeting requirement. As much as possible, I think it's very important that SSC activities be conducted through async communications. There's really close to nothing the SSC is responsible for that needs to be done with the level of inconvenience and exclusion created by trying to add more synchronous meetings across the world's time zones, and I think we can already see that the weekly meetings are discouraging asynchronous communication, given that approximately all emails and issues for this group so far are conclusions of the meetings, which means people are waiting for the meetings to bring things up, instead of bringing them up in an inclusive, immediate way via email/github.

I would encourage anyone at the Monday meetings to bring up anything they want to bring up at the meeting via email or this repo first, before bringing it to the meeting. Otherwise, it's not really being brought to the SSC. If folks aren't participating in email/github that's the real issue, and meetings don't solve it.

• Why?
  • The SSC is still learning how to operate—synchronous meetings would help us evaluate our process and get better at it.

I don't think this follows. Having actual, written records which we get from email or GitHub discussion (as opposed to brief summaries of minutes) would benefit this far more than synchronous meetings, where most of what people have to say isn't recorded, and most people don't get a chance to say anything. Synchronous meetings necessarily exclude folks unless we are all in the same place, which we never will be.

It’s been difficult to build momentum without all 11 members proactively engaging open JEPs together.

I think the synchronous meeting is part of the reason for this - we've chosen a process that most people can't participate in. It's not because people don't want to, it's because we can't.

It’s important that we do not reduce the importance of the weekly meetings, though.

I absolutely think we should reduce the importance of these meetings, but I won't begrudge members meeting each other when they want. People are free to meet whomever whenever they want, but it is important to acknowledge that every such meeting is necessarily exclusionary, and can't really ever represent the SSC as a whole.

Alternate times each month so that it equally inconveniences everyone. :)

We learned in JupyterHub that this doesn't really work for a decision-making meeting, but it can for a community meeting, which is what we've shifted to. This is because excluding a fraction of the team at every meeting means it's not really a useful venue for making any decisions, even if it is a nice environment for some discussions.

[Paul Ivanov]

I share Min's concerns and also oppose such a move. The meeting attendance has dropped off, and it would be better to have asynchronous discussions which allow for more thoughtful and nuanced participation that gets captured and attributed.

[Itay Dafna]

I would like to offer an additional point of view which supports a synchronous meeting. If my tone appears direct or combative - please note it is absolutely not my intention. It's difficult to accurately convey tone through written communication mediums.

Managing the various Jupyter projects takes a lot of effort - a non-trivial amount. Before signing up and standing for elections for my respective subproject, I reviewed the requirements and expected time commitment which, if I recall correctly, stood at a minimum of two hours per week. When my place was confirmed, I went to great lengths to make sure I have time carved out in my calendar for meeting with my fellow SSC members - asynchronous meetings didn't even cross my mind.
With the scale and complexity of the Jupyter project, I was worried that even this amount of time won't suffice for efficient governance, but I knew we would learn and adapt as we go along. Now that I've been here for a few months, I actually think that not having synchronous meetings undermines the ability of the SSC to carry out its duties. My rationale is outlined below.

The way I see it, Jupyter is on a critical mission to provide free Data Science (and beyond) tooling to communities around the world for free, and with no corporate agenda. We compete with for-profit behemoths who have multiple teams, if not entire internal organizations, who build similar tools to us. They operate with intensity and urgency. Now, I am not under any illusion that we can directly compete at that level - for a multitude of reasons. But I do know this: the SSC is one of the most important decision-making bodies in the Jupyter ecosystem. Joining the SSC was not a gift and is not a chore - we all chose to be here, and we all got here by being voted in via our sub-projects. Which leads me to this point -- it's impossible to run any kind of high-stakes governance body purely via asynchronous communication methods. There always should be some - perhaps even dominant - component of synchronous communication at any executive branch.

To Min's point, synchronous meetings necessarily exclude folks and, if I can be candid, I think that for a role at that level - they should! This goes back to my point above - the SSC is a senior, high stakes, executive role which we all chose to do. I don't think it's unreasonable to expect folks to attend one hour of synchronous meeting per week (or per month, although I believe weekly meetings are the right cadence). I argue that if a member of the SSC cannot attend a weekly one-hour meeting, then they are probably not assigning this role the priority it deserves, or they don't have the bandwidth to do the role. This is not to say that SSC members who cannot attend do not care about the project or are not contributing in their own ways (code, reviews etc.), it's just highlighting the misalignment between the required and perceived level of involvement this specific role requires. The SSC calls are not equivalent of community calls. To me, they are more akin to weekly leadership meetings in a high-stake environment. They should not be optional.

Being one of the newer faces in the Jupyter community, I was really excited by the prospect of meeting key members of the SSC during the calls (and in person), so we can slowly get to know each other on a more personal level and form a bond. Others may not share this point of view, but to me it's imperative for a team to have good chemistry before it can function well. The synchronous calls are a necessary condition for this to happen. Finally, what I wrote above is not to say that asynchronous communication is not useful or shouldn't be used in the SSC - it should complement the synchronous calls (not the other way around). It's also important to note that correctly executing asynchronous communication can - and often does - take a lot more time and effort compared to synchronous. Writing this post took me two hours, for example, whereas I could have probably articulated my opinion in a more succinct manner in a simple call with the rest of the SSC members on a call.

[Min RK]

Thanks for your perspective! I appreciate the points you've made, and can appreciate that some folks may prefer to communicate in meetings. I also especially appreciate that you're coming from a different point of view in terms of existing relationships with folks in the community. You're definitely right that async communication takes more time (both to do right in the first place, and especially to resolve discussions).

it's impossible to run any kind of high-stakes governance body purely via asynchronous communication methods. There always should be some - perhaps even dominant - component of synchronous communication at any executive branch.

I don't believe this point is true.

Approximately all of the work we do in the SSC must be recorded and communicated publicly anyway, and involves soliciting feedback from the Jupyter community, so anything done at a synchronous meeting needs to then be duplicated out into other communication channels, which is frequently not adequately addressed by meeting minutes, etc. We need to do the async communication anyway, whether we have the meetings or not.

For me, Jupyter is currently my job, and I place strict limits on when and how my job is allowed to encroach on the rest of my life. Standing meetings when I need to pick up or feed my kid is simply a deal breaker. I do not consider it a reasonable request to ask me to do my job outside standard work hours in my time zone, and I would never make it of anyone else.

I'll also add that if a weekly meeting were given as a requirement for SSC participation, I would not have signed up, and will step down when I can to make room for someone else who can, if that's how folks decide the SSC should operate. I don't want that to sound like a protest, rather as a practicality: conducting the SSC in that way would be a conscious choice to exclude folks with lives like mine from participating, so I should not be part of it.

[Frédéric Collonval]

Thanks @ibdafna for describing your perspective. Despite agreeing that with @minrk that the technical questions to be addressed by the SSC can be discussed and resolved asynchronously (and I agree with Min and Paul that we must improve on that point). I feel much like Itay that we are also a group of people. And as such getting acquainted with each other through more direct communication is necessary to ease asynchronous discussion - especially the hottest one that may be plagued by unintentional bad tone; after all we are no professional writer and some times even not native-English speaker.

To try to move forward and to bounce back to some ideas spoken or written (like #7), a clarification of the process followed by the council to define and progress on action items as well as the role and expectation for council members seem required. As this is the first year of the council, it will also help future candidate understanding the level of commitment before running for the council.

[Zachary Sailer]

We discussed this thread quite a bit in today's SSC working hour.

Some thoughts I had—

First, I feel it's important to acknowledge that @minrk is incredibly skilled, effective, and efficient at fully async work. (Sorry to single you out here, but couldn't pass on the opportunity to praise you 😉.) Though you aren't available during our working calls, you always follow up the next day and its extremely helpful+productive. I aspire to develop your level of discipline around async work. My guess is that it took you awhile to develop this discipline; I'm still in training 😃 .

I agree that SSC needs to become better at functioning asynchronously. I think it would be helpful develop some weekly expectations to which we all subscribe and remain accountable. Currently, I don't believe the SSC is participating enough to be effective. I've opened a discussion on google groups to hopefully improve here.

I also agree that meeting synchronously adds a personal relationship dimension that cannot happen asynchronously. And I'm inclined to believe that in order for this council to reach its highest potential, we need personal relationships/trust to be formed. Maybe it doesn't have to be through a standing meeting; but hopefully we can get folks to meet synchronously throughout the year in some form. If imposing such a meeting causes a lot of friction on the council, that's not helpful either. We should aim to work with the great people/resources we have today.

it's impossible to run any kind of high-stakes governance body purely via asynchronous communication methods. There always should be some - perhaps even dominant - component of synchronous communication at any executive branch.

I don't believe this point is true.

I see both sides here. I agree its not impossible to run asynchronously. But we must acknowledge—and I think this is what @ibdafna is feeling—that Jupyter is "in-the-ring" with organizations that are much more agile, efficient, highly-resourced and operate synchronously. I do believe their ability to make decisions quickly gives these organizations a major advantage.

To remain competitive, we must be efficient with the processes+resources we have. Maybe synchronous touch-points are not the answer (though, admittedly, they appear to be the easier band-aid solution right now); maybe we need to set expectations for a higher level of asynchronous engagement. Whatever it may be, we likely need to adjust quickly to keep from blocking the Project.

[Min RK]

I think one reason I keep coming back to async and public communication vs private, sync meetings is independent of the scheduling challenges, and instead about what the role of the SSC even is. We, the SSC, do not dictate any direction or decisions of the Jupyter project, so our agility is fundamentally limited. Jupyter is a community project, and every decision we make as the SSC must reflect feedback from the community. The SSC's principle responsibility is to solicit, receive, and interpret community input on proposals. Our decision-making capacity only exists as a mechanism to represent the public input of the community. We cannot make decisions quickly or in private while fulfilling our responsibilities. What we can do is set timelines on JEPs, send reminders, reach out to folks (not on the SSC) to try to make sure JEPs get seen and reviewed and decided upon in a reasonable amount of time, which I think is our current task at the moment. Our principle responsibility is not to solely review every JEP, but rather to facilitate and represent review by the wider community.

JEPs are not proposals to the SSC, they are proposals to the community and we are stewards of the process.

[Frédéric Collonval]

I created a draft project: https://github.com/orgs/jupyter/projects/10

i place all issues and PRs (if there were no related issues) for this repo and the JEP repo in the board. There are two fields for each items:

• Status:
  • Reflect items priority; so that you know on what to read/review depending on the time you have at hand for the SSC in the current week.
  • Open to suggestions to improve the current available status
• JEP status: Only for JEP - labels as defined in jupyter/enhancement-proposals#104

What I did not do:

• All actions are in status Need triage and my expectation is that the triage will happen on the coming Monday calls
• The project is private because it is just a proposal - but the all council has rights to change that when we like the structure
• There are no automation (like adding each new issues to the board) - happy to do it but only if I'm sure we are actually gonna use it.

[Paul Ivanov]

Thanks @fcollonval - I added this issue and a few other meta ones into the "Short term" column you created. I also have some suggestions that would allow for more asynchronous decision making and triage, but since this thread is about synchronous participation, I added them as a comment on #7

[Zachary Sailer]

Thank you, all, for participating in this discussion—I think it was quite fruitful!

We have attempted to capture the general consensus around our async/sync participation in #16. Let's continue any further discussion on that PR.