search

jupyter / governance

The governance process and model for Project Jupyter
https://jupyter.org/governance/index.html
Creative Commons Zero v1.0 Universal
82 stars 71 forks source link

Mozilla project: Jupyter community growth #57

Open choldgraf opened 5 years ago

choldgraf commented 5 years ago

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.

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 issue periodically as we find interesting information or brainstorm any new ideas. <3

Wrapping up: Overview and general thoughts

Hey all - last week we wrapped up this round of the Mozilla OL program. I just wanted to give a few parting thoughts on what I learned throughout the experience! I wrote up some of this in the Project Jupyter case study for the program. It covers some of the high-level challenges that we were trying to think about as we went through this program.

General takeaways

To me, the biggest takeaway from this process was appreciating the need for intentional design around the organization and community of open projects. One of my favorite quotes from this is "be open by design, not open by default". Many projects assume that they are "open" as long as they put their code on github w/ a permissive license. Now I think of open projects more like a dynamic process than a static thing that "is" or "is not" open. In reality open communities are complex, multi-layered communities that require constant and intentional cultivation.

So what does being "intentional" about an open community mean? This is what I think it means:

  1. Be explicit about the roles in your community, and be transparent about who fills those roles.
  2. Think about the perspectives and trajectories of your community. Why are they interacting with the community? What do they want out of it? What does "success" for them look like? (I think this is what mozilla thinks of as "user stories")
  3. Think about the structures that the community has set up to accommodate the user perspectives figured out in 2. Does the project set up clear pathways for people to get more engaged over time? And do these pathways map onto the complexity of the community? E.g., many projects give out merge rights for coders, but often don't think about giving other kinds of titles (or responsibilities) to community members to participate in non-coding ways.
  4. Treat the community as an ongoing and organic thing. The tensions, diversity, complexity, and interests of the community changes over time - particularly if the project undergoes some kind of growth or change in its scope. It's not enough to set up a structure and then leave it there - you have to continuously re-visit the current system and optimize it over time.

That said, what are some things that I think we could improve in the Jupyter world? Here are a few ideas:

  1. Make the sub-communities that currently exist in jupyter more explicit in terms of governance. Define how these communities can make their own decisions, and when they should interface w/ the broader jupyter project.
  2. Come up with specific roles and responsibilities within Jupyter, especially when it comes to non-coding things. For example, I'd love if the "Diversity and inclusion group" were "officially" recognized somewhere on the website. On that note I also think there should be a group whose role is to be stewards over the website.
  3. Come up with some more specific design processes for transparent and inclusive decision-making. For example, I really like the way that Rust makes decisions via a distributed Request for Comments process.
  4. Come up with explicit "phases" of Jupyter projects so that we can signal to the community what kind of interaction to expect. For example, the Mozilla archetypes of open source document describes some projects that move intentionally quickly at the risk of alienating the developer community ("Rocketship to Mars") vs. those that intentionally slow themselves down in order to be more inclusive, stable, and to start growing a community around it. I'd love if we had a way to signal something like this for Jupyter projects, and have a way to transfer from one project phase to another.
  5. Create a Jupyter community growth guide, for people who'd like to spend time helping out the Jupyter world. For example, @ivanov has been doing some really cool things around the idea of an "open studio". I'd love this model to be written down somewhere that another person could replicate it wherever they are. I'd also love to have suggestions for people that have small amounts of money (e.g. $100s to $1000s) that'd like to use it to support Jupyter (e.g. paying for an Outreachy intern, or covering conference travel for a newer jupyter community member).

Those are just a few thoughts :-)

I hope that this issue has been useful or interesting for folks in the Jupyter community! I'd love to see some of the stuff in here get fed back into the organization so that we can keep moving things in a positive direction. This whole thing has made me so much more appreciative of the work that many of you have done or are doing to keep Jupyter a healthy place. We have had plenty of challenges along the way, but I am confident in the direction we're headed.

If anybody wants to chat about any of this stuff, I'd love to do so. There's much more to be done in converting the high-level stuff I talked about here into specific, actionable things that we could do for the project.

See you all on the internet <3 Chris

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:

https://docs.google.com/document/d/1Ji8nwmh911rjBFQfIG7kQgx1Z13fPHyKTyrGv9U5E58/edit

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: https://github.com/jupyter/governance/issues/60

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:

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

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.

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".

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.

https://drive.google.com/open?id=1d661viUo6QDxRnyNBjaPq05GTs9Y0rrIp4qYzl6Qa-4

TODO

note - these items aren't actively being worked on anymore, but I'm leaving them here for posterity's sake. We got through most of them, though not all :-) This is a (growing and hopefully also shrinking) list of items to write about, think about, brainstorm, etc with Jupyter. I'll try to keep it updated over the weeks with links to issues etc.

NOTE: The updates will be in reverse chronological order. So, newest updates up top, oldest updates towards the bottom.

blink1073 commented 5 years ago

Hi @choldgraf and @Carreau, thank you for taking the lead on this. The canvas looks great!

Ruv7 commented 5 years ago

This sounds like an initiative with high potential for positive impact. I really like the format of the canvas and how it visually represents the information.

choldgraf commented 5 years ago

Hey all - I've restructured the top-level comment so that it's broken down by week in order to make it easier for people to follow-along with things. I'll keep posting here just to let people know, and also for comments/conversation etc.

To that extent: I just posted an update from the last community call! Some interesting notes on community interactions and value exchanges :-)

https://github.com/jupyter/governance/issues/57#issue-365718639

As always, if you'd like to talk about this stuff, brainstorm, etc w/ me then I'd love to do so!

choldgraf commented 5 years ago

Update from last week! (I'll post the updated text in the first comment too)

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: https://github.com/jupyter/governance/issues/60

choldgraf commented 5 years ago

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:

https://docs.google.com/document/d/1Ji8nwmh911rjBFQfIG7kQgx1Z13fPHyKTyrGv9U5E58/edit

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.

Final note: I'm going to copy/paste all of this over to the JupyterHub Discourse page, and will start updating both of these issues as time goes forward!

choldgraf commented 5 years ago

Wrapping up: Overview and general thoughts

Hey all - last week we wrapped up this round of the Mozilla OL program. I just wanted to give a few parting thoughts on what I learned throughout the experience! I wrote up some of this in the Project Jupyter case study for the program. It covers some of the high-level challenges that we were trying to think about as we went through this program.

General takeaways

To me, the biggest takeaway from this process was appreciating the need for intentional design around the organization and community of open projects. One of my favorite quotes from this is "be open by design, not open by default". Many projects assume that they are "open" as long as they put their code on github w/ a permissive license. Now I think of open projects more like a dynamic process than a static thing that "is" or "is not" open. In reality open communities are complex, multi-layered communities that require constant and intentional cultivation.

So what does being "intentional" about an open community mean? This is what I think it means:

  1. Be explicit about the roles in your community, and be transparent about who fills those roles.
  2. Think about the perspectives and trajectories of your community. Why are they interacting with the community? What do they want out of it? What does "success" for them look like? (I think this is what mozilla thinks of as "user stories")
  3. Think about the structures that the community has set up to accommodate the user perspectives figured out in 2. Does the project set up clear pathways for people to get more engaged over time? And do these pathways map onto the complexity of the community? E.g., many projects give out merge rights for coders, but often don't think about giving other kinds of titles (or responsibilities) to community members to participate in non-coding ways.
  4. Treat the community as an ongoing and organic thing. The tensions, diversity, complexity, and interests of the community changes over time - particularly if the project undergoes some kind of growth or change in its scope. It's not enough to set up a structure and then leave it there - you have to continuously re-visit the current system and optimize it over time.

That said, what are some things that I think we could improve in the Jupyter world? Here are a few ideas:

  1. Make the sub-communities that currently exist in jupyter more explicit in terms of governance. Define how these communities can make their own decisions, and when they should interface w/ the broader jupyter project.
  2. Come up with specific roles and responsibilities within Jupyter, especially when it comes to non-coding things. For example, I'd love if the "Diversity and inclusion group" were "officially" recognized somewhere on the website. On that note I also think there should be a group whose role is to be stewards over the website.
  3. Come up with some more specific design processes for transparent and inclusive decision-making. For example, I really like the way that Rust makes decisions via a distributed Request for Comments process.
  4. Come up with explicit "phases" of Jupyter projects so that we can signal to the community what kind of interaction to expect. For example, the Mozilla archetypes of open source document describes some projects that move intentionally quickly at the risk of alienating the developer community ("Rocketship to Mars") vs. those that intentionally slow themselves down in order to be more inclusive, stable, and to start growing a community around it. I'd love if we had a way to signal something like this for Jupyter projects, and have a way to transfer from one project phase to another.
  5. Create a Jupyter community growth guide, for people who'd like to spend time helping out the Jupyter world. For example, @ivanov has been doing some really cool things around the idea of an "open studio". I'd love this model to be written down somewhere that another person could replicate it wherever they are. I'd also love to have suggestions for people that have small amounts of money (e.g. $100s to $1000s) that'd like to use it to support Jupyter (e.g. paying for an Outreachy intern, or covering conference travel for a newer jupyter community member).

Those are just a few thoughts :-)

I hope that this issue has been useful or interesting for folks in the Jupyter community! I'd love to see some of the stuff in here get fed back into the organization so that we can keep moving things in a positive direction. This whole thing has made me so much more appreciative of the work that many of you have done or are doing to keep Jupyter a healthy place. We have had plenty of challenges along the way, but I am confident in the direction we're headed.

If anybody wants to chat about any of this stuff, I'd love to do so. There's much more to be done in converting the high-level stuff I talked about here into specific, actionable things that we could do for the project.

See you all on the internet <3 Chris

ellisonbg commented 5 years ago

Chris,

Thank you for participating in this program, and working hard to apply what you have learned to the Jupyter Community. I really appreciate that. Also, thank you for writing up these takeaways and sharing your case study with us. I will continue to read and ponder these ideas over the holiday and look forward to discussing them further in the new year.

Cheers,

Brian

On Fri, Dec 21, 2018 at 12:10 PM Chris Holdgraf notifications@github.com wrote:

Wrapping up: Overview and general thoughts

Hey all - last week we wrapped up this round of the Mozilla OL program. I just wanted to give a few parting thoughts on what I learned throughout the experience! I wrote up some of this in the Project Jupyter case study https://docs.google.com/document/d/1SPL5L3v0ZZ3yGa1ETWdcRZEakBgarAnYJ4_7TZIjGdo/edit#heading=h.ux2z11acevgf for the program. It covers some of the high-level challenges that we were trying to think about as we went through this program. General takeaways

To me, the biggest takeaway from this process was appreciating the need for intentional design around the organization and community of open projects. One of my favorite quotes from this is "be open by design, not open by default". Many projects assume that they are "open" as long as they put their code on github w/ a permissive license. Now I think of open projects more like a dynamic process than a static thing that "is" or "is not" open. In reality open communities are complex, multi-layered communities that require constant and intentional cultivation.

So what does being "intentional" about an open community mean? This is what I think it means:

  1. Be explicit about the roles in your community, and be transparent about who fills those roles.
  2. Think about the perspectives and trajectories of your community. Why are they interacting with the community? What do they want out of it? What does "success" for them look like? (I think this is what mozilla thinks of as "user stories")
  3. Think about the structures that the community has set up to accommodate the user perspectives figured out in 2. Does the project set up clear pathways for people to get more engaged over time? And do these pathways map onto the complexity of the community? E.g., many projects give out merge rights for coders, but often don't think about giving other kinds of titles (or responsibilities) to community members to participate in non-coding ways.
  4. Treat the community as an ongoing and organic thing. The tensions, diversity, complexity, and interests of the community changes over time - particularly if the project undergoes some kind of growth or change in its scope. It's not enough to set up a structure and then leave it there - you have to continuously re-visit the current system and optimize it over time.

That said, what are some things that I think we could improve in the Jupyter world? Here are a few ideas:

  1. Make the sub-communities that currently exist in jupyter more explicit in terms of governance. Define how these communities can make their own decisions, and when they should interface w/ the broader jupyter project.
  2. Come up with specific roles and responsibilities within Jupyter, especially when it comes to non-coding things. For example, I'd love if the "Diversity and inclusion group" were "officially" recognized somewhere on the website. On that note I also think there should be a group whose role is to be stewards over the website.
  3. Come up with some more specific design processes for transparent and inclusive decision-making. For example, I really like the way that Rust makes decisions https://rust-lang.github.io/rfcs/ via a distributed Request for Comments process.
  4. Come up with explicit "phases" of Jupyter projects so that we can signal to the community what kind of interaction to expect. For example, the Mozilla archetypes of open source https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf document describes some projects that move intentionally quickly at the risk of alienating the developer community ("Rocketship to Mars") vs. those that intentionally slow themselves down in order to be more inclusive, stable, and to start growing a community around it. I'd love if we had a way to signal something like this for Jupyter projects, and have a way to transfer from one project phase to another.
  5. Create a Jupyter community growth guide, for people who'd like to spend time helping out the Jupyter world. For example, @ivanov https://github.com/ivanov has been doing some really cool things around the idea of an "open studio". I'd love this model to be written down somewhere that another person could replicate it wherever they are. I'd also love to have suggestions for people that have small amounts of money (e.g. $100s to $1000s) that'd like to use it to support Jupyter (e.g. paying for an Outreachy intern, or covering conference travel for a newer jupyter community member).

Those are just a few thoughts :-)

I hope that this issue has been useful or interesting for folks in the Jupyter community! I'd love to see some of the stuff in here get fed back into the organization so that we can keep moving things in a positive direction. This whole thing has made me so much more appreciative of the work that many of you have done or are doing to keep Jupyter a healthy place. We have had plenty of challenges along the way, but I am confident in the direction we're headed.

If anybody wants to chat about any of this stuff, I'd love to do so. There's much more to be done in converting the high-level stuff I talked about here into specific, actionable things that we could do for the project.

See you all on the internet <3 Chris

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jupyter/governance/issues/57#issuecomment-449487017, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0CurQTZQz7mq-Xqm-FXQNBKPuTZ9ks5u7UAZgaJpZM4XDOwR .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com