By the time we met—which was, I think, in 2012 or 2013—you were already involved in Python. I'm curious about when you started getting involved, how you became a core developer, what the timeline was for you.

Well, this will be an interesting story for you. I think meeting you at AdaCamp was probably my intro to Python. Because OpenHatch was the first time I had done a project in Python. Before that, I had been involved with the San Diego Python User Group and San Diego PyLadies and was just sort of learning and doing outreach. It was the Fab Lab in San Diego, the open hardware stuff, that pulled me into these other communities. And then OpenHatch and San Diego Python were the two places that got me started with Python.

With San Diego Python, I was basically holding a Saturday study group with lots of members in the community. It started off with people who were laid off, and me helping them install Python, because back then, it was challenging to install. [The study group’s] still going strong today. It was people just working together. It was very organic. They're actually leading things and have gone on to do tutorials at PyCon. It's really great to see how a small action like, “hey, I'll meet you at the coffee shop, we can go and install Python”, where it can go when there's people and interest. I might have been the catalyst for the original thing, but certainly that whole core team of San Diego Python organizers were the people that helped grow it.

OpenHatch was a big part of it because we kept teaching people how to make their first contribution in Python. Not necessarily Python the language, but Python projects. For me, it was learning Django on the fly and you and Asheesh [Laroia] kind of coaching me through everything that I didn't know, which was a lot. I think you and I in particular, we really jammed on the documentation and teaching side of things and recognizing how valuable that was. Because at the time, GitHub didn't have all their tutorials, other organizations didn't have their tutorials. It was a big mystery until that first presentation you put together.

That's where my Python story started. It was never really to be a core developer or key person in the language.

I had met Jessica McKellar through OpenHatch and she was really good at talking me into submitting a poster and a talk and also sitting on the program committee and reading hundreds and hundreds of talk proposals. You get an appreciation for the breadth of what Python had to offer. Then helping out at PyCon and then helping with the tutorials… that was like trial by fire up in Montreal. And people were just great. I'd been in technical communities before, but there was something different about the Python community. Naomi Cedar, who is wonderful in many ways, she was doing that really phenomenal talk about Python and two genders. The background work to take the risk to accept a talk like that and make it so it was safe for the person giving the talk and valuable for the audience…I knew there was something special about the community.

So yeah, that's what got me hooked. It was really more about the people. I had been in other communities before, like the Linux community and other language stuff earlier on in my career, but Python—I think it was that education focus combined with being decent to people and the ability with the language and the tools to get meaningful work done quickly. That really just sucked me in.

I’m interested in getting the history, because you ended up on the very first Steering Council. What was the next step in the journey?

There certainly was no plan to the journey. If you had asked me when I started, I'd be like, no. [laughter]

I think the core development stuff came out of the Sprints at PyCon, in, I think, Montreal. Realizing that we could do a better job of onboarding people and making the tooling easier for people to use, making the developer documentation for the language itself more people friendly. Through that, I met some of the core developers, like Alyssa Coghlan and Brett Cannon.

The following year, I actually did a talk about contributing to core Python when you're not a core developer. I was really trying to put educational materials together around that topic. I learned a lot about Python's process in terms of how PRs get merged and decisions got made and things like that.

Guido [van Rossum, the creator of Python] had at—I think it was Montreal the second year—he got up and said, I want to have a certain number of women as core developers. And at the time, Selena Decklemann had gone to the core development Sprint, and I kind of wanted to be in the room because I felt like I had value. The following year and the years after that, I was in the room at the Core Language Summit.

I've been in tech. I graduated MIT in ‘89. For most of my career, women were a minority. There was something about the fact that there were no women core developers that really just wasn't representative of the talent that I knew was out there. I'm like, “Why? What's wrong with the process that it's not attracting that talent?” Mariata [Wijaya] and I were the early push-the-envelope folks when it came to women in the community.

I won't say it was easy. I don't know that it was hard. I think there were a lot of individuals that had really good intentions and wanted to see it happen. I think, though, when you get 70 something people on any one topic, you're going to have different viewpoints.

One of the things that's hard when you're maintaining a language is who do you trust to be the maintainers? There's very different philosophies. Like, on Interact, if you make one pull request that gets accepted we ask you if you want to be a committer, because we feel like the tooling now is such that a lot of that risk gets mitigated. But Python is used in so many different spaces. From a security and reliance of the community standpoint, you do need a certain code standard. That said, it didn't pencil out in my mind that there wasn't a clear path with which somebody became a core developer and there was some ad hocness to that. In some ways, there still is. But there's more of a process now than there was.

I think when you're the first in anything, there are barriers you have to overcome. Oftentimes it's people. As people started learning the barriers that I faced, or Mariatta faced, those barriers started to come down and have continued to come down.

I think at the end of the day, I saw through the education work that I did in open source and open hardware, the power of Python as a language. I've done talks on its readability and its accessibility and its rich ecosystem of libraries, and I felt like we could make a difference with Python in the world. From there, I got involved in the scientific Python community because that's where my interests in open science lie. At the time, IPython and IPython notebooks were gaining traction and I got involved with that project and have continued to see that forward.

How do we use these tools to educate more people, or people that don't have the same ready access that we do in the west, or the Global North versus the Global South? I think PyLadies has been incredibly rewarding from that standpoint because it's grassroots. How do you empower people throughout the world to make things better than they were yesterday? That's a really humbling thing when you think about it.

So how did you end up on the Steering Council?

With the steering council, when Guido resigned, Michael Kennedy invited Brett and I to be on a podcast to sort of help reassure the greater Python community that the language is not going anywhere. That we would figure out the governance, because he had left it to the core developers to figure out.

At the time [Guido] got a little slack for it. I think it was the right decision. I think it was purely from a capacity standpoint. There were five of us on the first Steering Council, including Guido, and I was astounded by the amount of work it was. The fact that one person was doing that before was even more bonkers.

Basically, in reassuring the community that we both really care a lot about, we made the commitment that we would see it through. We had the core development sprints in Microsoft's campus and spent a lot of time talking about governance. Some of us had been involved in governance, in other projects. Even before that, we sat down and did some PEPs about What Governance was like in other communities.

Yeah, I love that PEP [8002]! The one that you co-authored, the open source governance survey?

Yes. I think that was good because it gave people different flavors of how things could be organized.

At the Core Development Sprint, Guido pulled me aside and asked me if I would moderate or help facilitate the discussion on governance. We did some 'around the circle' kind of things, like, each person needs to say three things: What are you most proud of in Python? What do you think needs to change? What do you most value about the community and the language?

Going through that set the stage for collaboration. Folks went off into little subgroups and kind of came up with different models. We came back together and had everybody present their model. Then we took a break, came back the next day and talked about it.

The way I tried to frame it was: it's less about the governance you pick, and more about being clear and transparent and open about what you're doing, and considering other people.

As we went around the room and we looked at each of these models, there were a lot of similarities. That was the thing that I tried to leverage, was, hey, these are not that different at the core. All of them have the objective of making Python sustainable long term. Whichever one gets chosen, if we commit to it, will be successful.

After that, we left the core development sprint. Nathaniel Smith and Donald Stufft wrote a PEP that eventually was the one that got accepted. It combined elements from some of the different PEPs.

After that, I did some keynotes around the world, sharing just the process we went through and what the governance was going to be even before we elected anybody.

I don't know that I would have chosen to run had it not been for a lot of folks that came to me asking me to. And I'm glad I did. I think that first year we really set the foundations for how the Steering Council would work.

One of the first things we did was have repos that talked about, like, okay, what are the best practices? Like, you can't wear two different hats. You can't be a steering council person and pushing your own agenda at the expense of other people's agendas. You should just be an individual contributor at that point.

One of the big things that we tackled, and I don't know that we started out intending to tackle it, was the culture in core development. There was always the joke about the Python Dev mailing list, the hostility, because it's very easy to send an inflammatory message out. And how does that serve everybody? I think we were reestablishing that core development had more of the elements of the global Python community than just a club of people.

So that's sort of my story. In between that, I was on the Python Software Foundation Board before I ever was on the Python core development. Naomi and I started at the same time, again, encouraged by a number of really amazing women and people in the Python community. I learned a lot doing that and was able to leverage the nonprofit education governance experience I already had. Story turned out pretty good, I think.

I’m curious about that experience of being on the Steering Council right after the first election. Guido was on it, too, for one year, right? Presumably for continuity and transition-related reasons.

I think initially he might not have thought that he wanted to be on it, but then I think he did once he started seeing the group of individuals. Let's face it, we made the commitment partially because we respected Guido as a person, Brett and I.

And I think it made sense. He had knowledge. He did it for a year and then decided that he really wanted, I think, to be more involved with the technical side of things and less involved with the governance because he's always read all the PSF minutes and everything, like he sits on the PSF board as an honorary member or something.

So I think it was good. I think it was a good group of people, everybody who really put themselves second to what was best for the language and the community and helping the transition go smoothly.

You said a little while back that you were astonished at how much Guido was doing that the Steering Council took over. What kinds of information, process, responsibilities, etc, was transferred?

Pretty much everything got transferred to the Steering Council.

One of the things that, after the whole Walrus operator kerfuffle, really needed to be looked at is: how are we handling PEPs? We tried to have the Steering Council provide more lightweight process around it so that the technical things could be addressed. Instead of polarizing, we try to work to bring people to a better solution. Great, you have this technical idea, you have that technical idea, there's merit either way. We probably could do either one. What happens if we sit down and discuss? Can we come up with something better still?

A big part of the Steering Council was sustainability of the language, which involved money. Not just money, but the ability to have continuity on core things [where] it's asking a lot of a volunteer to do time and time again. I might say, okay, I'll take care of triaging issues on the bug tracker, but I get sick or I go on vacation or whatever. As a volunteer, that would just not get done for a week or two. That was something that wasn't serving the community well. Mariata had the idea of doing a triage team and getting people into that as a way of learning. I think it started opening the door for other onramps into core development.

There's always things about the language that people would like to change. Performance was one, and performance is funny because I look at performance in different ways. There's like, how fast can Python execute a command in isolation versus having a very readable language that's easy to work with. My time to development is super fast. I can get something done quickly because of Python's ease of use and rich ecosystem of libraries, and then I can go back and optimize as much as possible the core spots that are slow.

It's a 30 year old language. There were things that if Guido was designing the language now, probably would do differently, some not.

I think finding the resources to really both identify what should be done, needs to be done and then resourcing the developer-in-residence, meant more to a lot of the infrastructure, the process stuff, the bugs.

We got really lucky with Łukasz [Langa, Python’s first developer-in-residence] because of his experience in the trenches with real development at scale. He's added a ton. Also [former PSF Executive Director] Ewa Jodlowska was a really integral part of the Steering Council because she sat as a non voting member on the steering council and helped provide perspective and organization. The five other council members really valued that. I don't know how it is today because Ewa and I are both not there, but I assume that they're still meeting with [current PSF Executive Director] Deb [Nicholson] on a regular basis and working together as a team.

Then there's all the little things, like some controversy starts happening in the community. Somebody needs to respond. How do you respond and how do you respond as one voice and not just one voice, but one thoughtful voice? I think that's a lot when you're one person. It was hard enough with five people.

At the end of the day, I think we have a good thing going.

You mentioned that you tried to develop an approach for dealing with conflict so that things never got as fighty as they did over the walrus operator. I'm curious about that. What did you do? Do you feel like it was effective?

I think so, because we had some issues with typing as I was leaving the steering council, that was a big deal because it would have broken compatibility for Fast API and Pydantic, which were rapidly growing. That would have been a really sad thing because Python is used in so many different areas, and part of the sustainability is having growth in some areas while maturing in other areas.

The way I approach things is, hey, let's get the context first. Why is this person asking for this thing? Why is that person asking for that thing? Really encouraging listening and making it about the issue at hand and not polarizing or making it personal. That never ends well. And with polarization, you wind up anchored in your position, and you don't move forward. As a language, we still need to move forward. Even if we make the wrong decision moving forward, at least we need to move forward.

What you're trying to do is make the best decision. So we tried to be very transparent. Early on, we decided, okay, we want to communicate out what the Steering Council is doing. We did it in various ways, with various effectiveness, but we also had a public GitHub repo for people to communicate with the Steering Council, and that also got baked into the PEP process like requesting review of PEPs. There is also a private Steering Council repo where all of the agendas, meeting agendas, ongoing things that really are focused on Steering Council work that gets reported out later. Because a good chunk of it was either just working stuff that nobody would have cared about, or sensitive people issues, or fundraising things that hadn't closed yet or whatnot.

I thought it was really important to have those, like, have an agenda and have minutes for every meeting from day one. That's what we did. I think that served us well because we had the history of how it worked. People who then became part of the Steering Council could see the GitHub repo.

I think we baked in a lot of best practices at the start. In terms of getting the community to come together, I think sometimes it's letting people have a voice and having that voice heard. If you do that, they might not be happy with the decision that you make, but the likelihood of them feeling disenfranchised and dismissed is far less. What we tried to do is be open, and foster openness, and try to catch things earlier versus later.

Was this more of an unwritten ethos? Or are there specific processes, like so-and-so from the Steering Council, it's their job to look out for this or that? Specific things you tried to help people feel heard or to catch issues early?

One of the things was that anybody could always come to us as individuals and email us, and some people did. They could go to Ewa, they certainly could go to the Code of Conduct Committee. Brett and I both sat on the Code of Conduct Committee in addition to being on the Steering Council. We would recuse ourselves if that was necessary, but I think it was helpful as the community as a whole was getting more experience there, leveraging the experience that we had.

You've done so much with community. You understand that you need to model the behavior that you want. You have to walk the talk.

The culture shifted over time. Is it perfect? No. Does it have work to do still? Sure. Is it better than it was? I think so. There may be people who have left the community that don't think that, but I think at the end of the day, we were following the mission of the PSF and recognizing that we want to sustain the language, we want to grow the language.

Some of the practices that served us 30 years ago probably no longer serve us the same way now. I mean, 30 years ago the internet was a baby. Worldwide web browsers - when I was in school, browsers were just being developed. There's been a lot of changes.

I think there's something to be said for a language and a community that can be sustained that long. It’s about going through the growing pains and being resilient and really committing to getting past conflict. Because 95% of the time there is no conflict. It's that 5% of the time where there's conflict. Usually when there's conflict there's knowledge from different perspectives. And there's validity to each perspective.

The challenge is how do you manage through that? It's going to vary depending on what the issue is. I don't know. That's a really hard question. But I think it's ad hoc. It's messaging out what the expectations are and continuing to reinforce. We knew being a heavy hand wasn't going to work. The best possible outcome is you encourage the community to behave the way that is most effective for the future of the language, whatever that might be.

You mentioned the Code of Conduct Committee. When did that come into existence? Was that there during the walrus operator conflict?

I don't think so. It started gaining traction around the same time that the Steering Council was being formulated. I would really have to go back and look. My sense is that I was involved with the Code of Conduct Committee before I was on the Steering Council but I honestly don't remember.

The Code of Conduct Committee has certainly grown and changed over time as well. If there’s like a decision that's made, like if we were to ban somebody, for example, that's not the first course of action. It's the last course of action that we would want to take. It's like when there are no other options and other people potentially are being harmed, maybe not physically harmed, but 1000 cuts. Again, it goes back to what's best for the language but what's best for the community, how do we grow it, how do we sustain it?

On what the expectations are...I know all five of us, whenever there was a letter, or [...] there was a correction, all of us were part of the drafting, editing. The amount of time it took was a lot but I think it was necessary, because we all have different viewpoints and we all bring different things.

I think the other thing that was super helpful with the Steering Council was everybody up front made the commitment that we weren't going to make it personal, we were going to listen and really stay focused on how what we're doing is for the best outcome for the language, for the core developers as people and our users. Sounds kind of sappy, but it's the truth.

I think it's easy to underestimate the impact of this ‘sappy’, softer, warm and fuzzy stuff, but we're human beings. We have emotions and social needs, and being able to articulate and make those kind of value commitments is important.

It's funny because I've never been a fan of the soft versus hard skills. I think communication is key. Whether you're communicating through the syntax of code or you're communicating with the syntax of words, clarity is important. I like to draw that connection, hey, this is more similar to code than you think.

I love the ‘explicit is better than implicit’ line in the Zen of Python because it so clearly applies to both code but also just regular communication. Maybe that helps validate the importance of explicit communication for people who might otherwise not care about communication outside of code.

I often will say my thing with human language communication is pronouns. If you throw around a bunch of pronouns like "this", "that", "the other" - references that aren't specific. You're making the assumption the other person understands the context. In the absence of understanding the context, they're going to draw their own context. What happens when you do that in code?

Bad things. Bugs.

Exactly. Or unexpected behavior. And it's the same thing in community. Much like we have CI CD in code processes, humans are equally important. It's also being humble enough to recognize that you don't know everything.

I have a billion more questions that I want to ask about Python, the Steering Council, etc. But I also wanted to talk a bit about iPython/Jupyter because I remember you were working on governance with them when we met up in DC several years ago.

In a nutshell, and there's far more behind it, but IPython started off as a fairly small academic research project and continued to grow. At the point where it went from IPython notebooks to Jupyter notebooks, we had a huge spike in the scientific Python and data science tools, all converging and being useful together. We saw growth in the notebook, but then also through JupyterHub and Binder, we also saw huge growth in the cloud side. We were able to offer access to notebooks at no cost from an education standpoint. And data science grew a ton and is going to continue to grow.

As all of those things grew, you started having corporate interest in projects. I did a SciPy keynote about the importance of academia, government, enterprise, all working together, inspired by Elinor Ostrom. How do you bring people together when you have this shared resource?

When we were in DC, it was clear the governance for Jupyter needed to change. We were at the early, what I'll call 'storming' phase, fleshing out: What needs to change? Why does it need to change? Who gets a seat at the table? And just now has the governance been fleshed out more. It took several years. I don't remember what year that was, but it was about the same time we were doing the Python governance. Python finished, and Jupyter was still in the gathering information stage.

It took a lot longer for a number of reasons. Some of it’s the time people had, some of it was competing interests. You can look in the GitHub repo, there's information on how it shook out. I'll be really blunt. I was more of the mindset that there's only so many models of governance. Pick one and move on. I think, much like in the world of security, there's that tip, don't roll your own security. I think that also applies to governance. There's a lot of knowledge already.

I kind of took a step back in terms of the governance side of Jupyter. I was still involved. I reviewed all the documents and stuff, but I didn't go to the meetings. There was a core group of people that kind of shepherded it over the years. I am part of the governance going forward, but...Sometimes with governance, you need to go through the process to really know what's going to work. It's hard to do when you're one of the hottest projects on the street.

But I think it's finding its footing. I think it has profoundly changed education. I can't be more proud of Binder and JupyterHub and the notebook itself in terms of providing access to information. Will something better come along in the future? Sure. For now, it's doing good stuff, and we'll see where it goes. It's funny because I always looked at the notebook less as a software thing and more as a communication tool that allows you to communicate using prose, computation, visualization, multimedia, interactivity. That ability to communicate as we go back to what I was talking about before is so key.

Darian, who's been on the Steering Council—he'd be a really good person to talk to. He took on the bulk of the shepherding everything through and getting voices heard. When you're taking years to create a governance, it's a labor of love, and it says a lot about his character because he did have to balance a lot of different interests. I think now we're kind of learning much like Python was in the first Steering Council, we're learning how to operate, getting the foundation of the new governance structure in place, and that's still kind of being formulated.

When I started researching governance in Python, I was thinking very much about the 2018 transition. The more I've researched it, the more I realized that so much of the relative ease and success of that transition is due to all of the groundwork that was already laid. For instance, being able to say we're going to use PEPs for most of this. Because there's already a PEPs process. It's been around for nearly 20 years. Oh, we need to hold a vote? Let's just ask the PSF to do it, because the PSF is this trusted, long standing body that’s been holding elections for ages.

I’ve been trying to figure out when and why these things came into being. The PSF started in 2001. What was the impetus? Why? Apparently in 2014, its bylaws drastically changed. That's when the member-elected board started. I love the member elected board. It's great. But I was not paying attention to the PSF before 2014 or so. I didn't realize that was brand new at the time. I just assumed it had always been that way. I'm really curious about 2001 because it’s when the PSF started and also when the PEP process began.

Barry Warsaw and Thomas Wouters would be good to talk to. Barry, in particular, has been instrumental with the PEPs, and Thomas has just such a long history, and he's a really good communicator.

I think governance itself has a life cycle. What serves you at one point in time, or one size, doesn’t always serve you later. Much like going from a startup to a corporation when you're 15 people and everybody can talk to everybody else. That network graph of interconnection is small. You can have a different governance than if you're 20,000 people, much less the whole entire country. That's another slippery slope that we won't even touch in this interview.

I think at the end of the day, to be in governance, you need to know why you're there. And for me, it was always clear. Education has always been at the core of everything that I've done. It is my guiding star. It's what rocks my world. It's not what rocks everybody's world, but that's who I am. I believe part of Python's huge success has been its 30 year emphasis on education and empowering people.