Jupyter Blog - diversity

Lessons learned from Jupyter’s Contributor in Residence pilot

2021-03-11T20:22:00+00:00

By Georgiana Dolocan and Chris Holdgraf

Project Jupyter, like most open source communities, often lacks the time and people power to maintain existing projects. Existing maintainers are often overloaded with work, while new volunteer contributions are often driven by the excitement of new feature development. Although on-boarding new maintainers is a sustained long-term team effort, it is something necessary and beneficial not only for the project, but also for existing maintainers and new contributors alike.

For this reason, we decided to pilot a Contributor in Residence program that was generously funded for a year through CZI’s Essential Open Source Science program. Last year we ran the first iteration of the JupyterHub Contributor in Residence role. This post is a short report about what we learned, in the hopes that it guides other projects in pursuing similar programs.

tl;dr

The Contributor in Residence program is a great way to:

Introduce new members into your community
Create pathways for others to get more experience, and grow in their role and leadership
Get a lot of work done that is hard to motivate volunteers to do
Spend time thinking at a “meta” level about how to improve dynamics in the community
Have a paid opportunity to support individuals who can’t contribute via volunteerism alone

However, doing this well requires planning ahead of time and attention throughout the program. It is crucial that you develop a plan and pathways for integrating the CIR into your community, and ensuring that they have the right perspective to support the community. If you do this, the CIR program can be a fantastic win-win situation for everyone involved.

What is the Contributor in Residence?

The Contributor in Residence (CIR) carries out a variety of technical and community-focused actions, looking for opportunities to keep momentum moving forward in conversations, improving infrastructure to minimize human toil and streamline information, and making improvements to the codebase that are focused more around sustainability, stability, and understandability.

For more information about our CIR program, check out these blog posts:

The JupyterHub welcome bot image, hand-drawn by our first Contributor in Residence, Georgiana

How management and planning worked

We didn’t define explicit “metrics-based” outcomes for this Contributor in Residence pilot, as we were not sure the behaviors that would be most beneficial in the long-run. Instead, Georgiana kept track of the activities that she worked on throughout the year, and reflected with us often in identifying challenges to overcome, and opportunities to improve the work she was doing.

In practice, Georgiana did not have a sole formal ongoing mentor providing her regular guidance throughout the project. She received mentorship from a variety of JupyterHub Team members across the repositories, and via participation in issues in GitHub (more on that later).

Georgiana kept track of her actions at this GitHub project. This contains a collection of issues, to-do items, and pull-requests throughout the JupyterHub community, and is a public record of much of the work that she focused on. While we scoped the CIR to cover all of the JupyterHub repositories, these efforts had a general focus on The Littlest JupyterHub, where she is now the primary maintainer and community liaison for the project. In addition to these development-focused efforts, Georgiana also spent a lot of time improving infrastructure and team processes at the JupyterHub-wide level, generally via the JupyterHub Team Compass.

Tips for running a CIR program

The following are a few best-practices that we picked up during our pilot.

Define an explicit work plan and system for managing tasks

The biggest challenge Georgiana faced was in identifying specific projects to work on, and working through the ambiguity of a position that explicitly had no single clear workstream. To get around this, Georgiana sought out guidance and advice from others in the community, and over time gained an understanding of ways that she could contribute. This will be a challenge for any Contributor in Residence moving forward, and we will need to think of new ways to support this role with concrete suggestions. Georgiana wrote a bit about this experience in her CIR update blog post.

Dedicate management and mentorship

A related challenge was in ensuring that the CIR felt like they had a clear idea of their expectations, to-do items, and progress. In future iterations, we would like to dedicate more resources towards providing mentorship and management of the person. This role shouldn’t be a “task giver,” but rather someone to help guide, triage, and prioritize for the benefit of the community. They should have regular touch-points with the CIR to make sure they are supported in their role.

Have an onboarding session to help them navigate your project

Regardless of ongoing mentorship, you should definitely have an onboarding session. Many open source communities have multiple projects, varying stages of contributor documentation, different spaces for conversation and interaction. Moreover, the technical infrastructure may have underlying architectures and organization that is hard to learn on your own. Have a core maintainer (or the mentor if you’re using one) go over your technology’s structure and layout, and double-check the things the CIR is unsure of, and introduce them to various discussions and action points to learn from. This may require multiple meetings in the first few weeks/months.

Assess your current strategy every 3 months and adjust based on current needs

Choose a time interval when you revisit your plan. Project needs, community dynamics, and time availability will change over time, so take the time to think about what parts of the plan need to be modified to fit the situation at hand. An option could be bringing this up during team meetings to brainstorm ideas and get feedback, then write it down to put everything in order and make it real. Consider writing 3-month blog posts of your progress and status — these become public records of the experience gained from the program, and are good opportunities to reflect on how things are going.

Actively invite them into the community

Remember that most open source communities are just that — communities. Take time to make sure others in the community know who the CIR is, invite them to participate in community conversations, welcome them in gitter/slack/issues/etc. Anything you can do to make them feel welcome is great. Make sure that you keep doing this over time, not just once at the beginning of their fellowship. When someone feels that they are welcome and a part of a community, they will be much more comfortable at navigating how to support it themselves.

Tailor the role to fit the CIR as a person too

The CIR responsibilities are usually already sketched up before actually having a person to fill the role. Having an overall plan is an awesome idea and a very useful program compass. However, once the CIR is identified, it is important to re-address the overall focus and goals of the role to ensure that it aligns with the interests and skillsets of the incoming CIR. This includes things like familiarity with the project, future career directions for the CIR, and working styles for people involved.

Start slower

Jumping directly into a new project with a lot of complexity and many sub-projects is not sustainable. In our initial plan, we decided to track about 10 main repositories in the first three months of the CIR pilot. This was not sustainable, and led to an overwhelming feeling because of the constant influx of new issues, questions, etc. Especially for someone new to the community and their new role, this led to a feeling of “I’m not learning fast enough,” and difficulty concentrating on the plan. So please, start slow, take the time to acclimate to the project and go repository-by-repository.

Remember that knowing everything was never part of the role

Being a CIR for a complex project can be very overwhelming. There may be different sub-projects, technology stacks, and team processes across a community. It is crucial to consider the CIR program as a two-way street — it is primarily a learning experience and a chance to grow for the CIR, as well as an opportunity for the project to get some much-needed assistance. The CIR should not be expected to know or do everything either at the beginning or the end of their tenure — instead, celebrate the process and the learning that has come from it.

Ideas for things the CIR can work on

Here are a few things that we found particularly useful for the CIR’s workstream, that will likely be portable across other communities as well.

Identify automation and standardization action points

Observe whether a repetitive task could be performed by an automated system like a bot or a CI system, as this has the potential to ease the workload for maintainers.

For example, the JupyterHub GitHub org has about 60 repositories. Some of them had issue and pull requests templates, but most of them didn’t. Some had instructions of how to make a new release of the project, others didn’t. Some had their instructions written in a README and others had documentation, etc.

When the CIR project took off, the JupyterHub and Binder team already started the quest of automating and standardizing its sub-projects. The CIR’s job was to help the other team members propagate the changes (bots setup, templates, badges, docs) to as many repositories as possible.

Research and discover best-practices from other communities

CIRs can also act as helpful eyes and ears to watch other communities and understand the practices that they adopt. Many practices are useful across projects, and a person serving in this “meta” role is in a good position to think at a high level about opportunities.

For example — a simple “thank you” to a contributor can boost their experience a lot, especially when it is their first time contributing to a project. GitHub has a mechanism of letting you know when someone opens an issue or a PR to a project for the first time, but that little notification can be missed when under a huge load of work. For this, there is “the welcome bot” that can be set up to express the community’s gratitude towards their first time contributors.

Our CIR noticed that “The Turing Way” — an open source community-driven guide to reproducible, ethical, inclusive and collaborative data science — made excellent use of GitHub’s welcome bot, including illustrations to make the message even more pleasant and celebratory. Georgiana was inspired by this, which led to adding welcome bots across the JupyterHub repository (including our own hand-drawn images!). Every time a contributor reacts with a ❤ to the bot’s message reinforces the feeling that the bot has its desired, positive effect.

Welcome images that Georgiana drew for the “welcome bots” that she deployed across the JupyterHub repositories.

Spend time on fixing bugs and improving testing infrastructure

Having a working testing infrastructure helps maintainers and contributors alike. Various updates to the underlying infrastructure of the CI system, or even something as simple as a dependency version bump, can break it. So keeping an eye on the health of the testing infrastructure is something that should concern a CIR. This is particularly useful as the world of “maintenance automation” changes very rapidly, with new frameworks, plugins, and standards. Having a pair of eyes constantly thinking about how to improve this process is very helpful.

Having just a handful of people knowing how to to release a new version of a project is not scalable and puts an enormous pressure on that group. Instead, each project should have public instructions on how to do this, so that other contributors that have the permissions can cut a new project release.

The process of creating RELEASE.md files with these instructions for JupyterHub sub-projects, just like the standardization process, had already been started inside the JupyterHub org by the team members before the CIR started. The CIR’s job was to extend this idea to as many sub-projects as possible. This standardization and improvement quest continues to move forward thanks to the CIR and to Erik’s and Simon’s coordination efforts!

More generally — the CIR is often someone relatively new to a project, which makes them a valuable perspective to understand where team documentation is unclear to newcomers. Use the fresh eyes of the CIR to understand how to make the project more welcoming and easy to navigate, and it will clear a pathway for more to join the project in the future.

What we still haven’t figured out

While we learned a lot during this pilot phase, there are a few things we still haven’t figured out.

How to define a pipeline for new CIRs

The tenure of a CIR seems like it will be relatively short — maybe one to two years on average. This means that we need a pipeline of new individuals that are ready to learn and take on this role once a previous CIR moves on. Being effective as a CIR was only possible for someone with some context for the JupyterHub repositories and team processes, and we likely would not have had success hiring someone on a one-year contract who had never worked in the JupyterHub community before. In future iterations we will need a reliable pipeline of newcomers to the project to potentially serve as CIRs. Programs like Outreachy and Google Summer of Code are excellent sources of future CIRs, but we need to think about the “pipeline” for gracefully using them to power the CIR project.

Find mentorship that isn’t “nights and weekends”

While we may be able to find funding for mentorship and management, many people in the JupyterHub community already had full-time jobs. Having funding to pay for a part of someone’s time is helpful, but this is only possible if you can actually buy out part of somebody’s time (often not possible in certain careers and roles). It may be possible to spend extra time on mentorship in the evenings and weekends, but a sustainable model for this program will require somebody dedicating part of their “FTE time” on mentorship. We need to identify certain kinds of roles / individuals that have this flexibility in their work-load, and bake it into the strategy of the program.

Define a funding mechanism for CIRs

Finally, this CIR pilot was funded by a one-year grant from CZI. In future iterations we will need to have a strategy for funding this position in a reliable manner (or at least, in a repeatable manner). To make this sustainable, we must define a pattern to follow and require resources to do a good job. This will both reduce the amount of effort needed to plan a new round for the CIR, and will make it easier for other organizations to understand how their financial contributions could help fund another round of the program. Perhaps this can be an ongoing fundraising effort, similar to how other programs have “target funding levels” in their annual giving strategy, or perhaps it can be a coordinated effort across projects to join resources together for these positions. Either way, it will be important to have reliable funding to ensure that the CIR program isn’t in a constant state of sputtering and jumpstarting.

We hope that this post was an informative and useful set of lessons-learned from the JupyterHub team. If you’ve got any suggestions, comments, or questions for us, we’d love to chat. Feel free to open up an issue in the Jupyter Community Forum! We look forward to continuing this experiment, and hope to see other communities experimenting with the same model in the future.

Tema Okun

2020-10-12T16:21:00+00:00

JupyterCon 2020 keynote speaker announcement

JupyerCon Keynote Talk

Tackling Toxic Culture in Tech: Racism and Its Legacy

Tema Okun

Tema Okun has spent over 30 years working with and for organizations, schools, and community-based institutions as a trainer, facilitator, and coach focused on issues of racial justice and equity. Dr. Okun currently co-leads the Teaching for Equity Fellows Program at Duke University, which works with faculty seeking to develop stronger skills both teaching about race and racism and across lines of race, class, and gender. She also facilitates, coaches, and consults with leaders and organizations nationwide.

Tema was a member of the Educational Leadership faculty at National Louis University in Chicago and has taught undergraduate, master’s, and doctoral level students in educational leadership and education. She is the author of the award-winning The Emperor Has No Clothes: Teaching About Race and Racism to People Who Don’t Want to Know (2010, IAP) and the widely used article White Supremacy Culture. She publishes regularly on the pedagogy of racial and social justice.

Tema is a participant in the Living School for Action and Contemplation and a member of the Bhumisphara Sangha under the leadership of Lama Rod Owens. She is an artist, a poet, and a writer. She lives in Durham NC where she is fortunate to reside among beloved community. Her current project is deepening her ability to love her neighbor as herself. She is finding the instruction easy and the follow through challenging, given how we live in a culture that is afraid to help us do either or both.

Tema Okun at JupyterCon 2020

Three years ago, I was searching for career advice and discovered the Transform Your Workplace podcast with Brandon Laws and Megan Leatherman. I connected with Megan Leatherman and signed up for her newsletter. In Megan’s June 2020 newsletter, she included a reference to Tema’s podcast which really resonated with me.

The JupyterCon leadership had a vision for this conference to invite us to come together as a community, and think how we can make it better. We have strived to focus our attention on diversity and inclusion in all aspects of our programming. We also decided to accentuate equity and social justice in a dedicated keynote speech, and we are delighted to host Tema Okun in this role.

Book

Podcasts

Love and Humility: Finding Refuge (Sep 2020)

04. Love & Humility - Michelle Johnson

White Supremacy Culture at Work (Jul 2020)

248 : White Supremacy Culture at Work (w/ Dr. Tema Okun)

Unleashing Social Change

A tweet by @billions_inst, no longer available

A tweet by @reshamas, no longer available

Resources

Dismantling Racism

The JupyterHub and Binder Contributor in Residence!

2019-11-26T19:52:00+00:00

The Chan Zuckerberg Initiative and Project Jupyter are teaming up to pilot a new role in the Jupyter community: the JupyterHub Contributor in Residence

Thanks to funding from the CZI Essential Open Source Software for Science initiative we are welcoming Georgiana Elena as our first Contributor in Residence!

Managing a codebase that spans many repositories and sub-projects as well as operating mybinder.org is a significant effort. Over time we have identified a need for dedicated support to ensure that activity and communication within these repositories is efficient and productive. Driven by this need and inspired by the Django Fellowship model, we shaped the idea of a JupyterHub/Binder Contributor in Residence (CIR).

Thanks to the Chan Zuckerberg Initiative, a Contributor in Residence within the community is now possible. Starting this year, CZI launched the Essential Open Source Software for Science grant program. It is aimed at helping open source communities that make up the core foundation of the scientific stack. We applaud CZI in providing support for core infrastructure across the sciences, and we’re honored to be part of CZI’s vision of funding maintenance, growth, development, and community engagement for open-source projects.

In this post we’ll introduce the community to our first Contributor in Residence (Georgiana) and her mentor (Tim)! The rest of this post is in the form of a conversation between Georgiana and Tim. We hope you enjoy it and that it let’s you get to know the team a bit better.

Tim: Hello Georgiana. Congrats on becoming the inaugural CIR. We’ve been lucky to have you already as a contributor on JupyterHub especially your work adding support for using Traefik as a proxy.
Geo: Hey Tim! Thank you, it’s been a really amazing experience to work on JupyterHub. I’m really excited for this next year’s journey.
Tim: You are the very first Contributor in Residence. Can you explain a little what this means?
Geo: The CIR role is about helping make the little things around the projects be amazing. Little things like answering newly opened issues, guide people towards the right place for discussion, improve bits of documentation or code, helping with releases, give people the right tools to make great contributions. And I have a great team of existing contributors to work with.
Tim: That’s right! My role in all this is to be a mentor and guide. JupyterHub and Binder have a small team that does a good job looking after the main repositories, but the universe of JupyterHub and Binder repositories is huge. So sometimes things get overlooked or missed. For example Pull Requests or Issues in one of the less-popular repositories can go for a long time without getting attention. This may hold up progress somewhere else, and people have a bad experience contributing to the project.
Geo: Hopefully we can improve on this a bit so that more people have a great experience when contributing.

Tim: Let’s find out a bit more about you. What did you do before getting involved with JupyterHub?
Geo: I studied computer science in Bucharest spending the last semester developing my bachelor’s project as an Erasmus exchange student in Madrid. During summers I worked in the industry, doing a few internships abroad. I tried to gain as much practical experience as possible, to get in touch with different people and cultures, and interning seemed like the right move.
Tim: How did you get involved with JupyterHub?
Geo: I got involved with JupyterHub thanks to the amazing Outreachy community. The Outreachy program introduced me to the world of opensource and guided me through my first steps. I now feel very lucky to have applied for the Outreachy internship at the same time that JupyterHub came up with two amazing projects. I chose JupyterHub because I “clicked” with the TraefikProxy project and I was happy to find a very welcoming community that made contributing a very pleasant and not at all a scary experience.
Tim: Have you turned into someone who spends all their time contributing or do you still have other hobbies?
Georgiana: Because I currently live in the busiest/loudest city of Romania, I love to escape it at the end of the week and spend some time in nature. My favorite place to be is the village I grew up in, where I recharge my batteries walking my dogs and cooking with my mother and sister. I like painting and photography and sometimes I do both using the photos I take as an inspiration for my paintings.

Tim: Moving on to the things you will be doing as CIR, have you already picked out something to get started with?
Geo: At first, I will be focusing on trying to get an overview of what issues are feature requests, support questions and which have been solved already. I will also spend some time getting familiar with more of the JH/Binder projects. And what better way to learn about a project than to try and use it, and to be a first time contributor.
Tim: If you had to name the top three goals you hope to achieve while being contributor in residence, what would those be?
Geo: From the perspective of someone with still a lot to learn and figure out, I would be extremely happy if during this year I will grow to be the CIR this community needs. I would love to help improve the contributing experience, increase the overall productivity of the projects and become a better contributor myself.

Tim: How can people interact with you?
Geo: People can use the usual community communication channels, GitHub, Gitter and Discourse to provide feedback or ask questions and I’ll do my best to help out.
Tim: Now that we have a CIR, do people still need to contribute to the projects?
Geo: Definitely! People are always welcome to contribute. The CIR role wasn’t created to replace anything, but to be an extra pair of hands helping the daily activities around the community become more efficient.
Tim: How can people stay engaged with the CIR program or the broader JupyterHub community moving forward?
Geo: As the CIR, I am a team member just like anyone else, and the best way to stay connected is to connect is through our team channels — we have team discussions in the Jupyter Community Forum, and team information in the JupyterHub Team Compass repository (including monthly team meetings that anyone is welcome to join).

Outreachy & Jupyter: Supporting diversity in open communities

2018-11-28T17:26:00+00:00

Project Jupyter has accepted 2 interns through the Outreachy program, which supports open community members from under-represented backgrounds. Our Outreachy interns will work on important problems in the JupyterHub community with help from 2 mentors from December 2018 through March 2019. This is a short post describing why Jupyter is committing to this program, as well as what we’ll be working on with our Outreachy participants.

We are grateful to the Berkeley Institute for Data Science & NumFocus for jointly sponsoring our interns. This article is cross-posted with the Berkeley Institute for Data Science blog.

Why focus on diversity and inclusion?

The tech industry isn’t doing great on diversity, and the Open Source community is doing worse . This limits the community’s ability to tackle challenging, diverse projects. The amount of responsibility and power held by open source communities is increasing, so we have a responsibility to be more representative of the diversity present in our world. Many projects grow their community by encouraging people to start making small patches on their own. However, requiring uncompensated work is a big barrier to getting more diverse representation in our open source communities. Paid internships with dedicated mentors are a great way to help people break through this particular barrier and make the open source community more diverse.

What is Outreachy?

Outreachy is an internship program coordinated by the Software Freedom Conservancy. It is run twice a year with a goal to bring people from underrepresented backgrounds in tech into open source projects. 21 open source organizations are participating in this round, and will be working with a total of 46–47 interns. Importantly, these are paid internships, which make them more viable for a much broader slice of the population. Jupyter and BIDS will both contribute funding and mentorship for two Outreachy interns.

Our Interns and Mentors

We have two amazing interns for this Outreachy round, working on important projects in the JupyterHub ecosystem. Below we’ll describe the projects that they’ll work on.

A highly Available Proxy for JupyterHub (link)

Georgiana Dolocan will be mentored by Min RK and Yuvi Panda in building a highly available & scalable proxy for JupyterHub using the Traefik project. This will help JupyterHub deployments scale more easily for thousands of active users with minimal service disruptions. Georgiana will be working from Bucharest, Romania where she likes to paint and explore the city and the villages nearby alongside her dog and camera.

Improvements to user management (link)

Leticia Portella will be mentored by Yuvi Panda and Min RK in building better native user management features into JupyterHub. Small to medium installations of JupyterHub that do not want to depend entirely on an external authentication provider will benefit greatly from this. Leticia will be working from Dublin, Ireland (although she used to live in Florianópolis, Brazil), where she likes to read a lot (especially The Chronicles of Ice and Fire), to swim, and to work on her podcast (the first Brazilian podcast specialized in Data Science topics), Pizza de Dados (Data Pizza, free translation).

About our mentors

Outreachy requires more than just funding, but also mentorship. Two members of the JupyterHub community have offered their time to help mentor our Outreachy contributors, some information about them is below!

Min RK is a research engineer at Simula Research Laboratory in Norway and has been working on the IPython and Jupyter open source projects since joining in 2006 as an undergraduate in Engineering Physics at Santa Clara University with Brian Granger, one of the founders of the Jupyter project. Min currently focuses on JupyterHub, and is excited to welcome new folks to the Jupyter team.

Yuvi Panda is an operations engineer at University of California, Berkeley. He works at the Berkeley Institute for Data Science, where he maintains the JupyterHub infrastructure for the Division of Data Sciences. He has been involved in various Open Source communities in the last ten years, spending time in the GNOME, Wikimedia & Jupyter communities. His life was changed drastically by participating as a student in Google Summer of Code 2010, and he’s excited to give back to the Open Source community.

We would like to thank everyone who applied to JupyterHub for this round of Outreachy. We received a number of robust proposals, out of which we were only able to accept two. JupyterHub mentors spent quite a lot of time mentoring candidates during the application period, in reviewing their pull requests, and giving them feedback on their proposals. We look forward to bringing these new open source contributors into our community, and hope that we can set a path that other open source projects may follow in the future. Open source works best when it is diverse and inclusive, we think this is a small step in that direction.

Thanks to Orianna DeMasi, Sara Stoudt, Chris Holdgraf & others for contributing heavily to this blog post.

Contribute to your first open source project

2018-10-22T18:13:00+00:00

This Friday, 10/26, NumFOCUS DISC is excited to host a first of its kind Open Source Inclusion Sprint — no prior experience necessary!

JupyterLab is the next-generation web-based user interface for Project Jupyter.

Join us at the Two Sigma offices in lovely SoHo NYC for a day of fun and learning. Core contributors from the JupyterLab project will be on-site to get you setup and help trouble-shoot your code.

If you’ve never contributed to open source this event is for you.

Breakfast and lunch provided.

What to bring:

Laptop
Charger
Curiosity

Schedule

8:30 am — 9:00 am: Breakfast with GitHub and technical setup (optional)
9:00 am — 9:30 am: Introduction to Project Jupyter and JupyterLab
9:30 am — 1:00 pm: Coding
1:00 pm — 2:00 pm: Lunch will be provided
2:00 pm — 6:00 pm: Coding

Featured Hacks:

Not confident in your coding chops? Want to learn more about how to use Jupyter? Have something else in mind? No problem! Let us know what you’d like to learn and we’ll show you how Jupyter can make the experience easier.

Based on interest we’ll create workshops focused on the below topics. If you have something else in mind feel free to email Sam Brice.

Let’s Make an xkcd JupyterLab Extension (Beginner)

Create your own JupyterLab Extension and publish it to GitHub and NPM.
Prerequisites: Some programming experience. No prior Python or JupyterLab experience necessary.

Practical machine learning with Jupyter Notebook (Intermediate)

Walk through developing a machine learning pipeline, from prototyping to production, with the Jupyter platform.
Prerequisites: Python programming experience, basic familiarity with math (e.g. linear algebra), and data analysis.

Get Started with TensorFlow (Advanced)

Learn and use ML by going through some beginner-friendly notebook examples. We’ll go through training a neural network to classify images and text.
Prerequisites: Python programming experience, basic familiarity with math (e.g. linear algebra), and data analysis.

For More Information

Please visit the event GitHub for details or contact Sam Brice with any questions.

Openness, Diversity and Dignity: a Foundation for Global Collaboration

2017-01-31T12:04:00+00:00

A statement from Project Jupyter regarding the January 27 United States Executive Order on immigration

A statement of principles

Project Jupyter is an open, international collaboration that builds open-source software used by millions in research, education, industry, media and beyond. It has received funding from private individuals, philanthropic foundations, US companies and government agencies from the US and the EU. Its software has been developed openly by hundreds of people, from many nations, creeds, and walks of life.

We, the Project Jupyter Steering Council, see the January 27 United States Executive Order on immigration as deeply disturbing and an affront to principles we hold dear. By targeting Muslims, immigrants and refugees from a few countries, the complete, abrupt travel ban and ill-prepared, harsh implementation are inhumane, racist, immoral and wrong as a matter of principle. We hereby reiterate our commitment to the principles of equality and non-discrimination for all, regardless of creed or national origin.

This statement is about protecting openness, diversity and fundamental human dignity as foundations for global collaboration. It is not about party affiliations or political leanings. It is not meant as an attack on US citizens or society for their political ideas. Here, we are speaking out against the Executive Order itself and the Trump administration’s actions surrounding it. We stand against the polarization of society, upon which populism and fascism thrive, and seek to engage individuals and groups from a wide variety of backgrounds and perspectives, to clarify how and why these actions by the Trump administration are deeply harmful.

In addition to our moral objection to the ban, we believe it will have negative practical impacts. The open collaboration necessitated by Project Jupyter benefits US society in a variety of ways, and the Executive Order hinders our work significantly. Beyond Jupyter, this ban will negatively impact US society as a whole by, among other effects, driving away creative talent in research, education and technical development.

A personal note from Fernando Pérez

While the rest of this statement comes from the Jupyter Steering Council as a whole, this section highlights how these issues are more than a discussion of abstract principles: they impact us personally in ways that go back to the origin of the project itself.

In 1996, I (Fernando Pérez) left Colombia, my country of birth, to pursue my graduate studies in physics at the University of Colorado in Boulder. Colombia at the time was ravaged by the war with the drug cartels; Medellín, where I grew up, was known as the “murder capital of the world” (Narcos is a reasonably accurate dramatization of that period). Colombians were regularly targeted at immigration checkpoints anywhere in the world because the Colombian passport was taken as a symbol for “drug dealer”. We were the universal “bad guys” at airports before 9/11.

I had the option of going to graduate school in Europe, but I decided to come to the US because of its openness towards foreigners. I knew that if I wanted to build my scientific career here after my PhD, there were strong traditions welcoming that. My path here was also woven with that of immigrants: my PhD advisor was a Hungarian theoretical physicist and my postdoc advisor a Russian mathematician.

In a culture that always made me feel welcome, I created IPython, became involved with the scientific Python ecosystem, co-founded NumFOCUS, BIDS at UC Berkeley and Jupyter, and have continued to contribute to open science. The idea that the US was a beacon of openness, tolerance and cultural diversity was central in the genesis of Jupyter. But if I was making those decisions today instead of 1996, I’m pretty sure I would go elsewhere.

This ban isn’t merely an “inconvenience to 1% of travelers”, as Ms. Conway put it or a discussion about abstract ideas. It has a direct impact on human beings, the lives they lead and the things they create.

Practical considerations

In addition to our opposition to this executive order on principle, the immigration ban will also have detrimental practical consequences for our project. While Project Jupyter is an international community of contributors from many different countries, much of the project is US-centered. Our bi-annual developer meetings have traditionally been held within the US; the conferences we usually attend (such as SciPy and PyData) are generally within the US; and we are planning the first JupyterCon to be held in New York City. Because so much of the project is US-centered, this means the ban will hurt us both directly and indirectly.

Directly, it will mean that contributors from the affected countries cannot come to our events if we hold them in the US. However, if we hold them outside the US, it means that contributors from those countries who are currently residing in the US also cannot attend. Either way, this ban directly affects our ability to be a community that is accessible and welcoming to all.

Indirectly, the ban is already having a major impact on science in the US. These effects will be felt downstream by projects — such as Project Jupyter — which rely on the support and engagement of US-based scientists, both as users and contributors.

Finally, the impact reaches all non-US citizens: some of us have already received legal guidance from US universities advising against all foreign travel, regardless of country of origin. Others who live abroad, including US citizens, are finding it morally objectionable to deal with an immigration system that is so openly discriminatory, and therefore may not participate in US-based events in the future.

Moving forward

This situation is evolving rapidly, and we’ll continue to monitor it. For now, we want to communicate our unwavering commitment to principles of human dignity and respect, and our opposition, with whatever voice and means we have, to these inhumane policies.

If anyone engaged with the project does need to visit the US for activities involving Jupyter, please get in touch with us (publicly on the mailing list or email anyone from the steering council directly), and we’ll do our best to assist you.

Given the fluid situation, we don’t yet have solutions for those who may be unable or unwilling to attend events such as JupyterCon. We will be working in the coming weeks to find ways to help. We will explore solutions such as enhanced telepresence, streaming and more. Stay tuned.

What can I do?

If you are a US citizen, when the time comes, cast your vote. Even outside election time, please contact your representatives and senators and let them know your concerns. The Electronic Frontier Foundation also has good information on how to contact your representatives. If you are not a US citizen, we encourage you to contact your government and impress upon them how this Order hinders international collaboration.

Regardless of nationality, you may also consider making a donation to the American Civil Liberties Union.

Finally, if you’d like to add your signature to express your support for this statement as a member of the Jupyter community, please do so by using this form.

This statement has been prepared and signed by the Project Jupyter Steering Council (in alphabetical order):

Damian Avila Matthias Bussonnier Sylvain Corlay Jonathan Frederic Brian Granger Jason Grout Jessica Hamrick Paul Ivanov Thomas Kluyver Kyle Kelley Peter Parente Fernando Pérez Min Ragan-Kelley Steven Silvester Carol Willing

Jupyter Blog - diversity

Lessons learned from Jupyter’s Contributor in Residence pilot

tl;dr

What is the Contributor in Residence?

How management and planning worked

Tips for running a CIR program

Define an explicit work plan and system for managing tasks

Dedicate management and mentorship

Have an onboarding session to help them navigate your project

Assess your current strategy every 3 months and adjust based on current needs

Actively invite them into the community

Tailor the role to fit the CIR as a person too

Start slower

Remember that knowing everything was never part of the role

Ideas for things the CIR can work on

Identify automation and standardization action points

Research and discover best-practices from other communities

Spend time on fixing bugs and improving testing infrastructure

Share maintainer knowledge by improving the docs

What we still haven’t figured out

How to define a pipeline for new CIRs

Find mentorship that isn’t “nights and weekends”

Define a funding mechanism for CIRs

Tema Okun

JupyerCon Keynote Talk

Tackling Toxic Culture in Tech: Racism and Its Legacy

Tema Okun at JupyterCon 2020

Book

Podcasts

Love and Humility: Finding Refuge (Sep 2020)

White Supremacy Culture at Work (Jul 2020)

Unleashing Social Change: Tema Okun (Jan 2020)

Resources

The JupyterHub and Binder Contributor in Residence!

Outreachy & Jupyter: Supporting diversity in open communities

Why focus on diversity and inclusion?

What is Outreachy?

Our Interns and Mentors

A highly Available Proxy for JupyterHub (link)

Improvements to user management (link)

About our mentors

Contribute to your first open source project

What to bring:

Schedule

Featured Hacks:

Let’s Make an xkcd JupyterLab Extension (Beginner)

Practical machine learning with Jupyter Notebook (Intermediate)

Get Started with TensorFlow (Advanced)

For More Information

Openness, Diversity and Dignity: a Foundation for Global Collaboration

A statement of principles

A personal note from Fernando Pérez

Practical considerations

Moving forward

What can I do?