Hey all - for the next several weeks @Carreau and I are participating in the Mozilla Open Leaders program - it aims to help projects build open, inclusive communities.
- Here’s a link to the program syllabus in case you’d like to check it out
- Here’s a link to another GH issue on community structures/governance
As a part of the program, we’re working on a project associated with the community we represent. For our project, our goal is to increase the focus on the Jupyter community. Our hope is to come up with ideas to increase the transparency of how others can contribute to the various projects in Jupyter, and to build some team tools and norms for how we can be a more inclusive community.
We’d love any thoughts or input from folks as we move forward on this project. I’ll keep updating this thread periodically as we find interesting information or brainstorm any new ideas. <3
This post is cross-listed with this github issue. I’ll keep both of them updated moving forward, feel free to contribute to one, or the other, or both! However, I’ll keep this issue for “updates” and will leave the “todo” items on the github version only.
NOTE: The updates will be in reverse chronological order. So, newest updates up top, oldest updates towards the bottom.
Week 8: Mountains of Engagement and community communication
This week we covered an interesting way of thinking about how open communities are organized. It’s called the “Mountain of Engagement”. Briefly, it is a way to structure the many different ways that people can interact with an open community, with a focus on defining the “low-touch” contributors from the “high-touch” contributors. The goal is to make it possible to identify ways that people can be encouraged to act at each level, and to move upwards between levels.
Mountain of Engagement for Binder
I started a short exercise thinking about Mountain of Engagement for one community related to JupyterHub: Binder. @yuvipanda spent a bit of time thinking about the many ways that people interact with the world of Binder, and we started organizing it in this google doc:
It is still unfinished! I’ll spend some more time thinking about it this week, but if any of you would like to jump in and add your comments, thoughts, etc, then I’d love to see them! I’m hoping this is just the fist time we do an MoE exercise for Jupyter, and that we include as many folks as possible.
The JupyterHub Discourse page
Another thing that has often been a challenge in the Jupyter community is facilitating many different kinds of communication between a diverse community. Some of it is specific and technical, others is generic, non-technical, or more usecase-specific. Moreover, one thing that the OL6 program has focused on is the value that communities can create for themselves, if provided the right channels to do so.
So, with that in mind, we set up an experimental JupyterHub Discourse page:
https://discourse.jupyter.org/
We’ll see if this becomes a positive force in the JupyterHub / Binder communities. The goal is for it to encourage more fluid communication bother between “Jupyter core” people and the community as well as amongst community members. If it works well, perhaps it’ll be worth generalizing this place to “Jupyter as a whole” rather than just JupyterHub.
Week 6: governance structures and safety
Hey all - a quick update for folks. This week the Mozilla group met again, this time to discuss diversity, inclusion, and safety in the context of open projects and specifically for events. There was a lot of interesting material in there. The Mozilla accessibility notes for mozfest were pretty cool, and it turns out that NUMFocus has a guide to increasing diversity in events.
In addition, I followed up a bit on a previous week’s topic and started looking into governance models + community structure for several other open source projects. There’s a lot of interesting stuff out there! I even wrote up a short blog post about Rust’s governance structure. But it makes me think that perhaps keeping a separate issue for researching governance stuff is a good idea, so I’ll do that here: Researching other open communities: Governance + Structure · Issue #60 · jupyter/governance · GitHub
Week 4: value exchanges and community member pathways
It’s been two weeks since the last update, so here’s a quick update on what we’ve covered so far. Last week we covered a pretty interesting topic - value exchanges. Here’s a link to the full session notes:
- link to notes with group discussions and more links from Mozilla.
- Here are the slides from a section that covers a lot of community interaction topics
- Here’s a taxonomy of value exchanges - useful in thinking about why value exchanges are important and how to refine our thinking around them.
Community interactions and value exchanges
One of the main topics covered thus far has been value exchanges. The way I interpret this is that “value” simply means “something that a person gets out of participating in an open project”. For open projects to be successful, there needs to be a clear value exchange for both the project community as well as the contributor. For example, say somebody fixes a bug or adds a new feature. The project community benefits from a better tool, and the contributor would receive a shout-out/recognition for their contribution, and maybe a warm fuzzy feeling. Another example: somebody routinely responds to first-time contributors in project repositories. The project community benefits because there’s a healthier community churn of contributors, the person responding to issues benefits because the project recognizes their work for the community and they get the experience of growing that community (there’s also another value exchange embedded in here for the new contributor as well).
The point is, we need to make sure that there are benefits on both sides of the equation. At first I was a little bit put off by this idea because it felt sort of “transactional”. But now I feel like it’s just making something explicit (“what is the value you derive from interacting with this community”) instead of implicit.
Community member pathways
Tying in with “value exchanges” is the question “what kind of pathways do people take through the Jupyter community?”. For example, if you’re a developer, user, leader, documenter, learner, what opportunities are there for you to interact with Jupyter? Has Jupyter made these opportunities clear and actionable (and recognized)? Part of this involves some brainstorming about ways to contribute that aren’t initially obvious. Thinking about this from the perspective of user/contributor stories, with people of differing skillsets, backgrounds, demographics, etc, is a way to make some of these pathways more explicit and design around them.
Random tidbits
- People from many communities were specifically interested in the topic of “planned leadership churn” in order to avoid burnout and bottlenecking on a single person. I heard that the p5js project tried this as a part of last year’s OLF project, maybe worth looking into that!
Week 2: Open roadmaps and a project canvas
This week focused on some high-level conversations around structuring projects so that they have a clear vision and obvious points of contact with the community.
- Weekly meeting notes - with some nice discussion around “examples of open projects” for inspiration.
Open by Design
One of the core mantras of the Mozilla program is to be “Open by Design” rather than “Open by Default”. To me, this means that the design of the project and any organization associated with the project has treated the community as a first-class citizen. Most projects assume that if they put their code on GitHub then they are “open”. In a sense, yes, but Mozilla would call this “Open by Default”. Instead, those projects could take care to craft documentation, community practices, and organizational roles to encourage others to join the project or participate in the community. These are “open by design”.
- Here’s a page on the Mozilla Open Leadership Framework that talks about some of this stuff
Storytelling
We also had a conversation around storytelling in the community. The takeaway for me was that it’s more effective to inspire communities (or newcomers) by showing and recognizing what it means to interact with the community. It’s more productive to show people what it means to be successful in an open community rather than telling them what they must do.
At the same time, storytelling is useful to consider in the context of how we interact with each other in the community. Think about a person’s trajectory interacting with Jupyter (whether it be a newcomer, core dev, etc) - what kind of valence does it have? Is it a good story? Does it have a moral, or a lesson-learned? How could it have been different to better-support the community? Stories are often “felt” more than “remembered”, so consider this in how we structure interactions with our community.
Another takeaway quote from this section for me:
People don’t remember what you say, they remember how you made them feel.
Project structures and planning
We also discussed the importance of being explicit about planning and goals for a project. Oftentimes people want to know what the future of a project looks like in order to decide if / how they can help out. We discussed the importance of structuring this in a clear way as well as making this “plan” available for the community to see. Importantly, this doesn’t mean that you’re committing to a specific plan or dates, but that you’re being explicit and structured about your thinking as a community (in the current moment).
As a start, we put together this canvas, which tries to lay out some of our thinking for this project.