draft proposal for asynchronous discussion instead of synchronous meetings

[ivanov]

This is a counter-proposal to #5, where instead of requiring attendance of synchronous meetings, we open issues here and discuss using comments. We can keep the current meetings and rename them as "optional work meeting" for those who are able to and wish to discuss, triage, or collaborate with others on cross project things, or just use it as an optional social opportunity, too.

@minrk outlined some of the benefits of doing away with synchronous meeting in #5, and an additional one for me is that even for those who are able to attend synchronously, a fixed meeting does not give everyone an equal opportunity to express their thoughts, given time constraints.

I am opening this up so we can flesh out how this might work.

[ivanov]

One idea would be that we could make date range-based issues to help keep track of and focus the attention of the SSC. So we'd have an issue with a title like "2023Q3 omnibus issue" and then leave comments in there pointing to the other issue we are raising or wishing to discuss in the third quarter of 2023 (July 1 - September 30). I think that would be about the right level of granularity, since a monthly issue would only cover 4 working meetings.

[minrk]

One issue with async communication relative to synchronous meetings is that they lack an agenda, resolution, etc. and unbounded things are vulnerable to getting put off indefinitely. But that doesn't have to be the case - we can still have a weekly agenda, and time-limited discussions, but the time scale should reflect reality - e.g. a week, rather than a single hour.

[Zsailer]

Thanks, y'all. Great stuff here.

I think setting some minimum expectations on the number of hours this role should take each week would be great too. That way, folks can budget that time into their schedule and ensure they meet those expectations.

I'll use myself as an example for practicality.

In my job, we use two week sprint cycles; every two weeks, we submit a budget for our time covering the next sprint cycle. These cycles are a negotiation process. I get asked precisely how much time I need for open-source work and how will I use that time.

In our current state, my time around the SSC often gets de-prioritized, because it isn't unclear to my employer what the expectation is.

If we had publicly posted expectations for the SSC, it would help me tremendously. Something simple like, "2 hours/week is the minimum expectation for this role". This public statement imposes a constraint on the role; if an employer aims to support their employee is this role, they will need to honor such a constraint.

I know that seems like a formality, but documentation can make e.g. my case easier. Others might feel similar.

[Zsailer]

One idea would be that we could make date range-based issues to help keep track of and focus the attention of the SSC. So we'd have an issue with a title like "2023Q3 omnibus issue" and then leave comments in there pointing to the other issue we are raising or wishing to discuss in the third quarter of 2023 (July 1 - September 30). I think that would be about the right level of granularity, since a monthly issue would only cover 4 working meetings.

I think this is a good idea; I'd find it useful to know where to spend time so that I overlap with other folks and maintain momentum on a thread/task.

[ivanov]

Another idea would be to use Github Discussion for async prioritization. Discussion can be threaded and can also be limited to only those with write access to a given repository, and still allow for emoji reactions from non-participants.

https://github.com/features/discussions https://docs.github.com/en/discussions https://docs.github.com/en/discussions/managing-discussions-for-your-community/moderating-discussions

[ivanov]

over on #5, Frédéric mentioned creating a draft project

All actions are in status Need triage and my expectation is that the triage will happen on the coming Monday calls

I think we can have additional columns, such as "Proposed Focus Items for Next Week" or "Proposed to be closed due to inactivity" where anyone on SSC can move items into those columns without having to be in a synchronous meeting. That way, if an item that was moved to "Proposed to be closed due to inactivity" and if there's no opposition to that proposed action within the following week, we can go ahead and take that action.

[ivanov]

And yet another way to propose an action on a given issue or JEP could be to place a SSC_propose_newstate label on it. For example, I just added the SSC_propose_deferred label on https://github.com/jupyter/enhancement-proposals/pull/49 due to inactivity for the past 3 years.

That was the only label I created, so far

[JohanMabille]

Hey all,

Sorry for the very late reply. It looks like:

• we are discussing more or less the same things (or at least very related things) in three different issues: this one, https://github.com/jupyter/software-steering-council-team-compass/issues/8 and https://github.com/jupyter/software-steering-council-team-compass/issues/5.
• While some of us have expressed arguments in favor of synchronous meetings, no one is opposed (to the point of resigning from the SSC) to asynchronous discussion and decisions, as long as we can still have meetings as "SSC working hours", with no participation requirements, nor taking any decision during these meetings.

Besides, @fcollonval has already created a Github project for working asynchronously and @ivanov has started to complete it, so what do you think of closing the other issues and continue the discussion in this one?