A call to improve SSC participation

[Zsailer]

(This was originally posted in the private SSC google group, but I was encouraged to open this discussion here.)

I'm opening this issue to express some urgency around our SSC role.

I've seen a much lower participation than I expected from this group; admittedly, I've participated less than I should, so I'm speaking to myself as much as the group.

View this message as a call-to-action from a friend 😃.

I think we need to set some minimum expectations for ourselves. We can revisit these expectations regularly and tune them as needed.

For now, I propose the following minimum expectations.

1. Everyone should subscribe and actively participate in three places:

   • Here, the SSC Google group, for private communication/discussion
   • The SSC team-compass repo, for public communication/discussion
   • The Enhancement Proposal repo.

2. Everyone should spend a minimum of 2 hours/week engaging (reviewing, responding, etc.) these three channels. There is enough traffic on these three channels to fill your time, trust me 🙂 . Please budget this time into your calendars—we need it. If you cannot meet this expectation, let the team know so we can figure out what to do.

   One great place to spend time is the weekly Software Steering Council working meeting on Mondays. While not everyone can attend, it's a great place to knock out some work and see some familiar faces. If you feel like your participation has been low, I strongly encourage you to come to these meetings.

3. Finally, if you're going to be out-of-office for more than a week, please let this council know using the google group (it's private; I promise we won't prank you while you're away 😉). It's helpful to know so that we can pause any voting while members are away.

Settings expectations is a touchy topic to discuss. I highly encourage everyone to review their responses for appropriate tone before sending. Further, let's read one another's messages graciously—we all know that tone is not easy to convey 🙂 .

Finally, leaving you with some homework to spark discussion. Please respond so that we know you're watching this channel 😉

• What are your thoughts on three expectations listed above (numbered)? Are these expectations too high/low? Anything missing?
• What might be stopping you from meeting these expectations regularly?
• What is one thing you believe we are doing well as the SSC?
• What is one thing you think we could do today that would improve the SSC?

Thank you, all, for your commitment to this council and to Project Jupyter. We're working on something truly special—I know we all believe this; that's why we're here. I look forward to pressing on together.

[Zsailer]

As we all know, Jupyter is hugely popular project that represents a broad audience.

(One sub-population that is personally near-and-dear to my heart is the scientific community. In graduate school, I saw Jupyter empower incredible science by enabling historically underrepresented research groups "get in the game". I love this project and hope to see it sustain it's place in the scientific world for the foreseeable future.)

I would attribute much of Jupyter's early success to its open, neutral-standing development.

That said, Jupyter isn't invincible.

Due to its popularity, Jupyter exposed a need (i.e. market opportunity) for high-quality science/data-science tools. This market opportunity has generated competition. The competition is fast, agile, skilled, and (unsurprisingly) highly resourced. (I've seen this first-hand at Apple, as many of you have at your companies.)

How can open-source Jupyter compete?

I believe Jupyter's open, neutral standing development process is its greatest asset. Queue the famous quote: "If you want to go fast, go alone. If you want to go far, go together." Because we invite anyone to participate in its development (not perfectly, but set this point aside for the moment), it attracts individual, non-corporate participation that then shapes the corporate engagements.

That said, Jupyter's open, neutral development process is not enough to compete—we have to be efficient with our resources. Just because we represent a community does not mean we have to be slow (slower, maybe; but not slow.) We (the SSC) need to hone our skills at guiding the community.

At the very least, the governing bodies (SSC and EC) cannot be the blocker for the community. When something is proposed (e.g. a JEP) by the community, the Jupyter governing bodies need to act swiftly (without sacrificing rigor) to enable the community to proceed.

Today, we are the blocker.

From Jupyter's point-of-view, the SSC membership is a critical role. We gate-keep major changes to the project and its future. If we aren't efficient, the Project will stall and its competition will likely overshadow it. I hope this doesn't happen, but I felt the need to express these concerns.

[Zsailer]

Pinging the @jupyter/software-steering-council and @jupyter/executive-council for visibility.

[minrk]

I think these are reasonable expectations. Personally, I've found GitHub activity very hard to stay on top of, and have an elaborate set of gmail filters to try to make sure I notice the ones I need to (600 GitHub emails this month so far), but I'm not always successful.

Your [points](#7 (comment) about time budgets and specific tasks are useful. I think it would really help if we could have a mechanism to have shared priorities of "Let's focus on X, Y, Z this week". Working on a process for us to stay on top of JEPs so we can efficiently move things through the process without letting them stagnate seems like the best use of our very limited time.

Everyone should spend a minimum of 2 hours/week engaging (reviewing, responding, etc.) these three channels.

I think one thing missed here is that it's less our responsibility as the SSC to review proposals, and more to make sure they are reviewed by the community. Most folks do not watch the enhancement proposal repo, and it's the SSC's responsibility to make sure that proposals get the attention of the folks who have the most relevant expertise/experience/responsibility. In particular, I think that means (the main) part of our work is to think about who those people are, and try to bring individual JEPs to the attention of the appropriate individuals and groups across the community.

What might be stopping you from meeting these expectations regularly?

I'm putting in the time, but it's been hard to focus limited time on the right task, in part because it's unclear where others are focusing to keep things moving. If I could attend meetings, this might help, but since I ~always have a conflict that's not possible, and coordination is not really happening outside the meetings.

What is one thing you believe we are doing well as the SSC?

Going through some JEPs, and in particular refreshing the JEP process has gone well, I think.

What is one thing you think we could do today that would improve the SSC?

Try to set an agenda together, publicly, here.

[echarles]

What are your thoughts on three expectations listed above (numbered)? Are these expectations too high/low? Anything missing?

On my side, I maintain my inbox under control without filters (I have used that strategy before but the mails were just stacking up in the various folders) and prefer to be tagged in an issue instead of watching all the repos in which I am involved. The amount of involvement and reporting should just mean and soft indication, I am not really interested to know that X is on holiday for 4 weeks, of that Y has effectively honoured his duties, so I would say those kind of enforcements (not the expectations) are too high for me.

What might be stopping you from meeting these expectations regularly?

Lack of time for async interactions.
Too many meetings for the weekly sync calls (I was joining the SSC calls at the beginning, but as the number of daily calls has raised, I had to make choices), and to be honest, I have the same level of information reading GitHub.

What is one thing you believe we are doing well as the SSC?

Raising attention to open JEPs, merging a few ones, creating a culture of specifications, the creation of the https://github.com/jupyter-standards organisation, introspecting to make the SSC better.

What is one thing you think we could do today that would improve the SSC?

• Tagging the SSC GitHub group in the minutes SSC meeting minutes 2023 #2 so we receive notifications, for now I receive nothing and have to take the initiative from time to time to read the minutes.
• Maintaining a table with open actions with a responsible and a deadline a.k.a. Project Management, sorry for the pun.
• Taking decisions faster and don't try to get around. Picking the Mermaid example Adopting a text-based diagram syntax in Jupyter Markdown enhancement-proposals#101 we have everything to close that, but in the meantime, JupyterLab has enough votes to make Mermaid a reality Vote on Mermaid graph renderer for Markdown cells jupyterlab/frontends-team-compass#208 "FYI there is a related JEP opened: Adopting a text-based diagram syntax in Jupyter Markdown enhancement-proposals#101 - that will probably not make it. T...(snipped)". PS: To make it clear, I am fan of mermaid, but as SSC member, I think I need to look at the general Markdown question to give my Yes, so would love to see the https://github.com/jupyter-standards/markdown placeholder created 1 month ago to be seeded with content.
• Asking people to be less shy and not to be afraid to raise arguments even if you disagree.
• Giving feedback when you are asked for, see e.g. my answer to Zach question on Adopting a text-based diagram syntax in Jupyter Markdown enhancement-proposals#101 (comment) which has not been followed-up. We are in holiday period, still I dont' feel a lot of interest in that Q/A.
• Justify the Yes/No/Abstain with a simple sentence, this will help to clearly understand the reasons of the vote, e.g. No because it is going to ruin my project, No because the JEP is phrased in a way to does not take into account the broader landscape, No because I have another solution but need time to work it out, Abstain, because I am not interested in that area, Abstain because I had no time to review, Abstain because I don't have the technical skills to give a informed opinion, Yes because I have read every words, understand and agree with them, Yes because I have tested the companion POC, Yes because X is a good friend and has voted Yes... Note the last example is a very bad example and I hope it is not happening in real life.

In summary, assign owner to actions, prioritising the right/global questions before the details, be faster to close, agree to disagree and to make people unhappy, be more transparent for the reasons of the vote, don't try to get around.

Today, we are the blocker.

We are the blocker to get JEP merged, but I believe there is enough imagination and freedom in the projects to advance and do their own things.

[Zsailer]

Thanks, @minrk and @echarles. I'll respond a bit more later, but wanted to quickly respond to one point from @minrk:

I think it would really help if we could have a mechanism to have shared priorities of "Let's focus on X, Y, Z this week". Working on a process for us to stay on top of JEPs so we can efficiently move things through the process without letting them stagnate seems like the best use of our very limited time.

Since we have a few of us in a weekly "working" meeting synchronously, maybe that's a good place to set an agenda for the rest of the council. Would you feel comfortable with that?

I think one thing that is awkward about our current state is that we don't have a explicit leader/manager on the council that can focus our attention as a group. Instead of picking a person, maybe letting the synchronous meeting select our shared priority each week would be a good move.

[ivanov]

quickly responding to @Zsailer's quick response:

Would you feel comfortable with that?
...
Instead of picking a person, maybe letting the synchronous meeting select our shared priority each week would be a good move.

Why not do this asynchronously, as well? Otherwise, how would those who can't make the meetings participate in the prioritization?

[Zsailer]

Why not do this asynchronously, as well?

😅 honestly—just to "pick up the pace" of our role 🤣

I think the most obvious downside to fully asynchronous work is the slowness it creates. Moving slow in fine when we're discussing heavy weight items like JEPs.

Picking where the SSC should focus their attention for the next week seems like (1) a decision that should probably take more than one person, (2) but it likely doesn't need everyone to vote (3) and certainly shouldn't take a week (or more, due to async slowness) to agree upon.

It seemed to me like using the synchronous meeting to make a lightweight decision on where to focus energy as the group for the given week would be a nice way to get some momentum.

I don't have a strong opinion here 🙂 Just trying to propose ideas that ensure we're making progress.

[fcollonval]

Hey all

First to answer the requested questions 🙂

What are your thoughts on three expectations listed above (numbered)? Are these expectations too high/low? Anything missing?

They sounds reasonable for me.

What might be stopping you from meeting these expectations regularly?

Mostly I'm falling behind to follow-up discussion the github repo because I have not protect enough time to do so.

What is one thing you believe we are doing well as the SSC?

We have make some progress in reviewing and approving JEP. And we are pushing to improve standard visibility.

What is one thing you think we could do today that would improve the SSC?

We should settle on a process to review and address JEPs that the council can commit too. This is mandatory to keep the open community the best place for defining standards and avoid outsider stakeholders to dictate their point of views.

---

The propose prioritization of tasks sound great. I'm backing @Zsailer on the sync working meeting as a good place to review and prioritize the work items. In particular it was pointed out elsewhere one of the troubles of fully async coordination is the ease of forget about some actions. At lease with a meeting, there is a place and time for a council member (or anyone as we do the call publicly) to emphasize on an action item.

Regarding the previous comment and to support the ability of asynchronous participation, I would be in favor of using a GitHub project to create the action items. And at the call, we will indeed be able to triage those.

Some kind of table with category:

• New action item
• on-hold action (need maturation, to lift a blocker,...)
• Mid term action (decision required within ~ 1 month)
• Short term action (decision required within ~ 1 week)

And I guess to be sure to get follow-up, we should have a champion for each action.

[echarles]

I would be in favor of using a GitHub project to create the action items

+1 - GitHub projects has been a great move for me as combining table/kanban view with github issue/pr comments.

we should have a champion for each action.

+1

and a champion to maintain the GitHub project board.

[ivanov]

What are your thoughts on three expectations listed above (numbered)? Are
these expectations too high/low? Anything missing?

One great place to spend time is the weekly Software Steering Council working
meeting on Mondays. While not everyone can attend, it's a great place to knock
out some work and see some familiar faces. If you feel like your participation
has been low, I strongly encourage you to come to these meetings.

If the expectation is 2 hours per week, and one of those hours is spent in
Monday's synchronous meeting, then we only have 1 hour left for other work.

What might be stopping you from meeting these expectations regularly?

I have stopped attending the meetings. Part of the reason is because I found
myself unable to participate in them fully, as I was busy trying to take
detailed minutes of what was being discussed.

What is one thing you believe we are doing well as the SSC?

I think we're doing a reasonable job trying to figure out how to proceed in this
new landscape for the project.

What is one thing you think we could do today that would improve the SSC?

I would encourage us to take a wider view when evaluating how we are doing as a
project. It's not just about the work that gets done, and how it gets done, it's
also about how we are growing (or not) as a project. I don't mean just
individual growth of those involved, but also are we attracting new comers and
retaining the ability of everyone to stay involved.

From Jupyter's point-of-view, the SSC membership is a critical role. We
gate-keep major changes to the project and its future. If we aren't efficient,
the Project will stall and its competition will likely overshadow it.

The flip side of that worry is what if the way we achieve or maintain
"efficiency" comes at the cost of losing current and not gaining new
contributors.

I think the most obvious downside to fully asynchronous work is the slowness
it creates. Moving slow in fine when we're discussing heavy weight items like
JEPs.

Picking where the SSC should focus their attention for the next week seems
like (1) a decision that should probably take more than one person, (2) but it
likely doesn't need everyone to vote (3) and certainly shouldn't take a week
(or more, due to async slowness) to agree upon.

It seemed to me like using the synchronous meeting to make a lightweight
decision on where to focus energy as the group for the given week would be a
nice way to get some momentum.

I see no reason why we can't make lightweight decisions asynchronously. Async
doesn't mean we cannot have deadlines, we can still say "Weekly direction will be
determined by 9am Pacific time every Monday" and still not require any decision
making to happen at a synchronous meeting.

[Zsailer]

We are actively improving our process to encourage active participation. #16 codifies some of our operational mechanics.

Let's move all further discussion to #7, where we are brainstorming ways to better work asynchronously.