KEYNOTE: Improving Contributor Experience & Broadening Contributor Scope

Speaker 1: Good morning everyone. Glad to see everyone here. It's nice to see folks in person again. Oh, my slide. There we go. There you see. Uh again, my name is Kojo, and here's my talk, Improving Contributor Experience and Broadening Contributor Scope. It could also have been called uh improving maintainer experience, but we'll get into that. Um The talk's a little bit tight on time, so let me do this. Set a 15-minute timer. That might not work because The iPhone this is connected to is not behaving well. It's meant to do it the old-fashioned way. There we go. Alright. So as we said before, um

Speaker 1: some of you may have if you've been to Django Khan US or other things in North America, you may might have seen me. But I am this is actually my first time in Mainland Europe, Europe proper. I'm not sure what to call it. I'm not sure what you want to call it here, but this is my first time really in Europe, so I'm glad to be here. I am uh From the US, I am based in Houston, but again, I am one of the organizers for DjangoCon US, and so lots of people have seen me there. I work for a company called RevSys. I'm a software engineer there. We do mostly Python and Django stuff. You'll hear more about them a little bit later. I am the DEFNA North American Ambassador. DEFNA is the Django Offensive Foundation North America. That's the nonprofit that puts on Django Khan US. And so if you've been to a Django Khan US, you may have seen me or

Speaker 1: my uh my various teammates there. Def NATO is uh the Twitter account for DEFNA. So if you have if you're coming to North America and are looking for Django type events, feel free to get in touch. Before I was a software engineer, I was an accountant and I got an MBA and that sort of becomes pertinent a little bit later in the talk. So let's get on. So the a couple of points that I want to focus on more in my bio, the fact that I'm a January Kind US organizer. Specifically, I've been the orientation chair since 2016, the Lightning Talk chair since 2016, and the Development Sprints chair since 2017. The uh-oh there will become pertinent later. Um there's some issues that have come up as far as uh how those things have been run.

Speaker 1: Um W well uh there's some things I need to explain. With regard to that, but we'll get into that a little bit later. Um and As a determined North American ambassador, a few pieces of business that I need to point out. One, we would be thrilled to see any and all of you, maybe not all of you, Uh but as as many as possible. Uh at DjangoCon US if you're able to c attend in person or if you're able to attend virtually. So the tickets are still available. You can attend Django Con US virtually or in person. I realize we're like Four weeks out. So it's a little late to maybe perhaps to plan a physical trip to North America, but in any event, you're welcome. Also, the nation the uh the issue of Greenland. So As the definite North American ambassador, I use the United Nations definition of North America.

Speaker 1: That includes Greenland. And while Greenland is part of the Kingdom of Denmark, it is geographically considered part of Uh of North America, so if anyone, is anyone here from Greenland? So If anyone knows of people who are in the Python Android Django communities in Greenland, I would be thrilled to speak to them. So please point them my way. You can see on all the slides, my name is there and then my Twitter handle uh in the upper right hand corner. If you know any Pythonistas or Django Nuts in or from Greenland, please feel free to let them know I'm looking for my people. So the company I work for is Repsis. It's a small company. There's eight of us total. You'll hear more about us later, but the reason I bring that up is because we do a lot of work

Speaker 1: Um so the the actual business, and I have to be clear on this, I've confused people sometimes, the actual business is we build things in Python and Django for clients. But as a result, we've got lots of members who are heavily involved in open source in various capacities. And so you'll hear more about that a little bit later in the talk. So what's the motivation in context for sort of this talk? Um the see There are some points in the talk that are you know that may be a bit contentious, but we'll talk about sort of how I got started. I've been active in the Python community. Again, I came from a different career. I've been active in the Python community since about 2013. and I focused on trying to increase the number of contributors. I thought that was my way to make a contribution to the community.

Speaker 1: But what I've realized over time is that we don't just need more contributors. What we actually need is perhaps different types of contributors. And we also have to protect the attention and energy of the current contributors and maintainers that we have within the open source community from one of the number one problems that's facing those contributors and maintainers, which is burning out. So how did I get here? How did I get to this point where I'm giving this talk? So the ideas I'm going to be sharing today are sort of a combination of different things. From wanting to grow contributors and meeting different people, I ended up meeting different maintainers and made a few small contributions to open source projects myself In my role as the DEF CON North American Ambassador, I've gone to a number of different events and met more maintainers in that way

Speaker 1: and sort of built friendships with them. And while I continue to want to grow contributors, uh oh, am I going to step back for the mics? Bring you a step closer to the mics. So one of the contributors , as I met Mormon Tenders and sort of built friendships with them, I had a slightly more personal stake. My I I recognized that my friends needed help. And so what do I do then to help my friends? And that's where sort of things become a little sort of touch-in or emotional. It's it's an issue, it's not Really just an academic issue for me. A lot of it is motivated by this desire to help my friends because I I see them needing help So if

Speaker 1: we look at some of the different contributions I made I've made to some of my interactions with maintainers, my first uh C Python commit was uh committed on January 20th, 2017. And Mariata Vijaya, who is one of the Python core contributors, helped me with that. And she ended up spending a decent amount of time helping me with that by way of Twitter DNs. which was you know a lot of effort and and very helpful. And as much as I appreciate her for that, I also, as time went on, I you recognize, okay, that's not sustainable. Like that that's that's not gonna work. You can't like that model itself going forward doesn't work. But unfortunately the the maintainers of these projects are often the people who are task it's fantastic I have this coin got it from my friend Russell because I made a contribution to his project

Speaker 1: because he made it really easy for me to do so. Um what I have realized over time is I've not done a whole lot more to help my friend Russell with his project. And so that's not good. Very happy at the coin, but my friend still needs more help. And an issue that's come up in the past few months that is a little such for some people is the nature of PyPI and switching PyPI switching to two uh requirement two-factor authentication for some packages. The reality is, for most of us who are Python or Django developers, PyPI is basically a magical wish list. It lets us just make this requirements. txt file and just write down all the software we want, and then bam, like magic, it just shows up. and the things that we build.

Speaker 1: It it it lets us write a magical wish list and it just works all the time. But the people who are working to maintain that volunteers uh primarily and some people are paid It's a lot of work and it's a lot of effort. Those people need help as well. And so I am looking for help for my friends for partially selfish reasons because you know they are they build and maintain the software that we all use, but my friends are also your friends. I'm assuming if you're here at DjangoCon Europe, you use Django or would like to use Django or like Django and also do things with Python and People who are maintaining these projects are doing it not just for me. They're not just doing it for me because they're my personal friends. They're doing it for all of us. And so we need help. We need to help these people. Make sure they don't get overwhelmed.

Speaker 1: So, what are some things that I've been wrong? What are some mistakes that have been made? I thought encouraging more people to contribute to open source would get my friends the help that they needed. But as I spoke to different maintainers and reflected also on my own contributions, as I pointed out before, I started to realize that my approach could be improved. One of the conversations I had was with a man named Paul Gansel, who is the maintainer of the date time uh package for Core Python. Paul I I live in Houston, Texas currently. Paul used to live in Houston. We used to go to the Houston Python meetup, so I've known him since that. I spoke to him at Pi Texas in April and he reminded me of a book called Working in Public. that I'll be talking about here in the next few slides. Let's see, somebody somebody's read Working in Public.

Speaker 1: And next to the book, which I'll be talking about here in my next few slides, and some of the ideas from that book inform this talk. So work in public, the slides for this section are orange because the book has a bright orange cover and I am super original. So there we go. Nightie Eggball is the author. I had a chance to meet her at PyCon US in 2016. Very nice person, uh, and she's done a lot of work, a lot of research into understanding open source software, how it gets made, and what how it can be made sustainably, which is important. Um so these next few ideas came from reading that book. Um It's a great book and I'll only be touching on a small portion of the book, mostly focusing on chapter 5, but if you have an opportunity to read the book, uh I I would I would recommend it. Listen to the audiobook, but then the the actual physic book itself

Speaker 1: is very well presented. So one of the concepts that uh comes up in that book, especially in chapter five, is the idea of producer attention. And so open source contributors and really all of us in general have a limited amount of attention that we can devote to anything. So our open source maintainers and contributors are already giving up a lot of their free time and and you know bits and pieces of their personal lives to maintain the software that the rest of us use and also to organize events like this. among various other contributions get made. It's a major use of their attention, and Ekval points out four ways to manage this producer attention in her book. So the idea of reducing upfront cost, the first two options that we see here

Speaker 1: are options that are are familiar to most software developers. Automated testing, using bots, style guides. templates, things of that nature are examples of reducing upfront costs as far as uh producer attention for contributions. Um the second point is uh can be problematic sometimes. Reducing maintainer availability can sometimes just mean the maintainer just ignores input from people uh altogether. But you have other methods such as a sort of a feature complete policy like a DRF has the Django Rest work, the Django REST framework. has a policy of essentially feeling that DR is feature complete so it's not really looking for new feature requests.

Speaker 1: So those are examples of of of those two. I'll be focusing on the last two points. Distributing the attention cost to users and increasing total attention. So distributing costs here , she focuses on spreading the need uh for attention to other members of the user base, not just having it focused on the maintainers themselves. So the examples that she uses for cost distribution are a moderation system, sort of similar to having moderators in a chat room for streaming services. I don't know how popular Twitch is in Europe. Is that is that a thing that people here watch or are familiar with? So if you're in in things like that, uh moderators as you would have in a chat room, or user support forums like many of us are familiar with. She also draws a parallel to those streaming services

Speaker 1: as is as content creation and comparing that to how open source software is also content creation, just a different type of content. So for increasing attention, these are changes that allow the attention to be separated and focused into different areas. um instead of it ha it just being concentrated on the maintainers. It's interesting that one of her examples is uh is DEP0007, uh or Django enhancement proposal uh 0007, which is the official Django projects. Which is the idea of taking things that are important to the Django ecosystem but aren't going to be included in Django Core and making them their own separate things. And that way those things can be maintained separately uh from the core django itself and then that way the core django developers

Speaker 1: or maintainers don't have to focus on those things other developers can focus on those things so this allows you to increase the tension But both of these ideas, increasing attention and distributing costs, sort of come down to the same idea of adding more people, but the right people, not just throwing more people at the problem blindly. She also points out this the issue of casual contributors. She defines casual contributors as one-time contributors who are not interested in making ongoing contributions. The comparison she makes is to, and again this might be I'm not sure how s how specific this is to North America, but uh we see this a lot in North America, people who might, you know, ha have their cell phones and take video footage of an event that's happening and then submit it to a news station.

Speaker 1: Is that a thing here in Europe as well? Like, yes? No, okay, no. So people are like, why would you do that? I can tell you in the America from which I come, uh it it happens all the time and so news stations sort of rely on that. But those people, you know, maybe then when near an event they were, you know, at a car crash, at a at a at a thing, at a at a fire or, you know, what have you. that near a tornado and so they might take footage on their phones and then submit that to the news stations, news stations will use that. The people who were submitting that footage, however, They don't want to become full-time reporters. They don't want to become full-time videographers. They just happen to be in a situation where, oh, you know, I'm at this event. I will record it and I have recorded it, so I'll send it into the news station.

Speaker 1: So that's what she defines as casual contributors. I can trust in so you know so those people might make one contribution and then move on and never make another one. Or they might make another one at some point sporadically. And so I contrast this with new contributors who are people who might want to make ongoing contributions, but they have to start somewhere. And so the difference, part of the trick here is casual intercontributions. As you can see by the gradient, I'm moving away from the center. section where I talked about it. Because again, I'm a I'm a graphical genius. So in practice, the the trick is it's hard for a maintainer to know the difference between a casual contributor and a new contributor because initially they're identical.

Speaker 1: And so this comes down to this issue of attention and where to focus your attention. In some cases, these new and or casual contributors can extract a large amount of maintainer attention. Iqbal refers to this as sort of as extractive contributions versus non-extractive contributions. Um with the proper systems in place, these new contributors don't expect that much attention. Um but practices that primarily encourage casual contribution can create this adverse cycle where you have this rotating cast of casual contributors who show up, draw a lot of attention, and then go away never to be seen again. Um the good news there is that those practices can be adjusted to be less abstractive, less extractive And so now the ugly truth, um well

Speaker 1: an ugly truth, not not the only one, but one. And this is sort of similarly related to what we were just talking about. There's definitely a set of people who only want to make open source contributions or you know help organize conference or you know be on the PSF or DSF board or what have you because it's something that will quote look good on the resume. Again, is that a thing here Well I say the European class and media's like yes. That's what we do here. Um and so this is a thing that we have experienced and we've encountered. So there are people who are wanting to make these contributions in some form, not because they are motivated to make a contribution to the community, but because they are trying to do something that will make them look good. I personally think this behavior is detrimental to the community.

Speaker 1: So the question is, how do we protect how do we protect our community maintainers' attention from people of this type? I think I have an idea that might be helpful here. We will see. And so, as I mentioned before, one of the big problems that we have is burnout. I'm sure you've heard about this. But if you do a go to a search engine, type in maintainer burnout, you'll find all the examples that you more examples than we'd want to see, really. I'll get into this in a little more detail in a bit, but there's a distinction between in the one of the difficult points in this talk. had been some of the verbiage as far as sort of maintainers versus contributors. There are contributions that are made that require code and use

Speaker 1: code, and there are contributions that are made to our community that do not require code at all. And so the code contributions, the people who make the code contributions uh are often known as the maintainers Other people who make contributions that don't require code sometimes which refer to as contributors, but what is the same across both of those is that People suffer a burnout and we've all heard many, many stories about different open source configurations burning out and not wanting to maintain their projects anymore. Um what is perhaps less frequently heard about are people who are making contributions that don't require code who also suffer similar burnout. Conference organizers, people on boards, people who organize local meetups and and things of that nature.

Speaker 1: So how do we help our contributors, you know, not burn out? How do we get them the help that they need? I'm going to propose a solution. First, I'm going to talk about how the solution can work for software maintainers, and then I'll look at applying it to that other group of contributors. So here Trying to avoid upsetting the microphones. Um so so here we're looking at contributions That require writing code or making changes to documentation. And I've got those lumped together because they are nearly identical. It's just a matter of what language you're typing in. So this is the first category contributions I'm going to talk about. These are things that most developers are familiar with.

Speaker 1: They're also usually the first and often the only things that come to mind when people think you're contributing to open source. And that in and of itself is part of the problem. When people think about contributing to open source communities, they often only think about code contributions. And those aren't the only contributions that get made. But I'll go into that in more detail a little bit later. So, this idea of contributor mentors is what I think Can help ease some of the burden on our current set of maintainers. And truthfully, I'm sort of still sort of struggling with a name for this role. As you'll see later, there can't there Either can be some problems with it or it's the perfect name. And it it depends on sort of

Speaker 1: on the mindset. So let's see how that works out over time. So you might ask, well Kojo, like what is you know you put these words on the screen, Kojo, but like well I don't know what that is, and and you're not in from our continent. We do we don't know what you're talking about. Um So to me, a contributor mentor, the way I've defined this is someone who takes on two roles within an open source community. One, they are a contributor in the to the open to the open source community in some way, whether it be by code or whether it be by a non-code, as we'll see later. But they are also, more specifically, a mentor to casual and new contributors. And so they are minimizing that the burden. uh of dealing with those casual and new contributors on the core maintainers. So that the core maintainers, in this case if we're looking at a software

Speaker 1: example, the core maintainers can focus on What they're doing and the co the contributor mentors can help deal with some of the other activities. So why is this needed? Currently our project maintainers have the responsibility of maintaining the projects that we need, so maintaining the software that we need, making sure we get was it Python 311 which is on its way now? I was just watching uh something from P Python. Who is going to Python UK? I was just watching a PyCon UK video this morning talking about new features coming in Python 3. 11. So you know those maintainers have to make sure that that's coming out or that the new version of Django is coming out. Um but they also in keeping PyPI running and that sort of thing, but they also have to help onboard these new and casual contributors and that leads to

Speaker 1: a bit of a scaling problem. So a picture is worth a thousand words or Again, as as you can see, I'm a graph my graphical genius continues. Please try not to be overwhelmed. It's I understand. So what we currently have is a small number of project maintainers, the blue squares , who have to devote large amounts of time to help onboard many new enthusiastic contributors, the green squares. in addition to maintaining our software. So they're having to do that in addition to the responsibilities of maintaining the open source software that we depend on. That add to that to the fact that this large number of new contributors keeps trending, thus the arrows, and so all that effort had to be repeated over time. So this is sort of the current situation that we have now.

Speaker 1: So code does mean because sometimes it's necessary. The truth is what it is. So One of the harsh truths is that lots of enthusiastic new contributors are and end up being casual contributors. They don't become consistent contributors. That's not a terrible thing in and of itself, but it does represent a larger drain on the attention of the maintainers who just have limited time and attention like anyone like anyone else. Um so project maintainers spend a lot of time preparing to get people up to speed on the projects. That person makes one or two contracts contributions and commits and then never returns and the process repeats itself. Again, my pockets don't work.

Speaker 1: Again We got this coin. You know, and and and and like Russ is their friend, but there's the one contribution I've made to his project and not more. So when I say these casual contributors, hit me. Um so the the enemy is us and so one of the reasons this type of thing comes up is because unfortunately we've kind of created this this uh system The open source ethos promotes the idea that everyone can contribute, and then we run development sprints where we encourage people to take their first, to make their first open source contributions, and we celebrate that, woo, you made your first open source contribution. You're an open source contributor. And and it is it is exciting. It's wonderful when new people get involved.

Speaker 1: However, in our enthusiasm to be as inclusive as possible and and to bring in as many people as possible, we haven't considered the strain that this sort of activity puts on project maintainers. Again, just the effort doesn't scale well. But we continue to celebrate those initial uh contributions. And let me point out that when I say we run development sprints where we encourage people to make their first open source contributions, Remember the slide earlier with the uh-oh where I pointed out that who's been the DjangoCon US Development Sprint's chair since 2017? Again, it me. So um, you know, when I say we run development specifically, this sort of thing, I I've been a part of that. And so

Speaker 1: that's what informs some of these opinions. And so things like the you know onboarding or contributor docs can help, but those have to be maintained as the project changes. Um so in addition to changes in the core code and in the the the standard software maintenance responsibilities The maintainers have to also keep these things up to date. And so like case point, like you remember when Lots of Python development was done in virtual environments. And it still is to a certain extent, but now there's a lot more Docker, isn't there? And then all all all the the the up the getting started docs have to be changed and updated to replace to reflect these changes. So the good news is we as the community created the current system.

Speaker 1: We can also improve the current system. So the good news is the solution is inside us all along. So here is something a new proposal because as you can see with my graphical genius again the uh you get you can see the contributor mentors here and notice that they're changing from blue to green because they're the bridge between the the maintainers and the contributors. So so here you can see the contributor mentor is represented by the diamonds. The mentors would be contributors at varying levels of contribution expert uh experience, because that's important, um, but they'd have the added focus of helping casual and new contributors get onboarded and so the casual contributors who might make only one contribution or a sporadic contribution

Speaker 1: the the contributor maintainers contributor mentors, I'm sorry, would be responsible for helping those people as well as helping new contributors get started and then helping them move along with additional contributions as they they move through the cycle. These contributor mentors would also develop more expertise in the specific issues that new contributors and users face. So one of the things that a new contributor and a new user of your software is going to face is getting things started or you know are you are your getting started documents up to date. The contributor mentors would end up developing more expertise in these areas and also help to update the general documentation as well as the onboarding documentation. So things get a little hand-wavy here,

Speaker 1: and that is because I am talking I'm focusing a little more on Django and Python C Python, uh i as far as code projects here for for just a specific focus. But the reality is the things that you need from a contributor mentor are gonna vary dramatically from project to project. And so for instance, using uh Paul Gantzel as an example of someone that I know, if they if he has a contributor mentor who is helping him with date time he's gonna have different concerns or different needs than say Carleton who is here well point at who is one of our Django fellows um so someone who you know who's working on a larger project like Django but So there's going to be a lot of variation as far as what is needed from role to role from project to project.

Speaker 1: And then also with different contributor types as we'll see in the next section. So again, a larger project may have different use than a small one, but what I can do is I can very clearly define some of the attributes that a good contributor mentor will need. Contributor mentor needs to be patient, needs to be altruistic, they need to have an actual genuine desire to support our current maintainers and they have to have a genuine desire to help others to support our community. So first and foremost the desire to help. part of what you want to do, then being a contributor mentor is not a role for you. It's not a, you know, make this look good on my resume type of thing that you'd want to do. Um I'd also point out that if you are someone

Speaker 1: when we talk about roles like this, people often think they need this advanced level of expertise. I would point out that if you're someone who has made maybe your second or third contribution to an open source project you would be an excellent contributor mentor because you'd be working with people you know who have you who'd be trying to make their first and you're in a perfect position to help mentor those people. So you don't have to be this advanced developer or someone who's made 150 contributions to a project to be a contributor mentor. What's most important is the actual desire to help. And if that seems A little a little like you know Shangri-La Paliana, you know, utopia to you, I would point you to uh the 2022 keynote by Naomi Cedar, Salty Get Economy. Um for those who are not familiar with Naomi

Speaker 1: in in very short order. She's a former Python Software Foundation board chair and a general Python Luminary has written at least one book on Python, uh but in her keynote from Python US 2022, she she you know points out the fact that The Python community is a gift culture and should or a gift economy and should remain that way. And a gift economy is one where people share and exchange gifts. It's not a transactional thing. So it's what we're already doing. It's how we have Python and Django and all these other things for free But I am uh if we go but look at look at our intro slide well not but in addition uh I've got an academy degree, I've got an MBA, I am professionally trained in capitalism.

Speaker 1: And so So if there's one thing that I know, it's that there are lots of people who aren't in a rush to just do things because it's nice. And so there's the issue of sort of a business case, you know, the the what's in it for me, but this can also be looked at another way. This can also be looked at, again, we go back to the issue of attention. We all have limited attention, we all have limited energy you choose what you're going to do and what you're not going to do. So the question is, okay, well, why would I make this choice? You know, this this man has come on the stage and you essentially outlined more work for me to do. And Okay, but why Kojo? Well why should I do that? And so so here 's the business case. By being a contributor mentor, you can become a better software engineer

Speaker 1: While also supporting the community that supports you. And again, here we're looking specifically at the code contribution case. So this idea of a gift economy Combined with directed self-interest leads you to being a contributor mentor. So how does that actually play itself out? How do you actually benefit from being a contributor mentor? Well, as a contributor mentor, you're someone who'd be making consistent contributions to an open source project from a coach perspective. So you'd be working on, again, I'm using Python and Django here as sort of the primary examples, but there are a lot of different pieces of software. You'd be working on some of the largest, most widely used projects possible. For almost all values of you, there I don't think there are many people in this room who are working on something, say in their jobs or in their personal projects, that are as widely used as Python or Django.

Speaker 1: Just just by show of hands. Is there anyone working on something more widely used than Python? No? Or Django? No no one? Um so that's gonna be a benefit to you. Exposure to working on projects Consistently making contributions to projects of this size, with this level of complexity, with this level of use, is going to expose you to engineering practices and skills that you would not have seen otherwise, that you might not have even considered. And this is going to enhance your own individual engineering skills. And you're going to learn about the different design principles that have been used to guide these projects. And you're also going to sort of learn things like what went right, what went wrong, and how those things were dealt with. There are all sorts of design decisions that go into both Python and Django

Speaker 1: that most of us as individual software engineers never have to consider because we don't work on anything. It's that large or is that widely used or has to solve that many instances. So by contributing to these projects on a consistent basis, it's going to improve your software engineering skills. Then there's the onboarding mentoring task. How many of you have a job and work at a place with other people? And then sometimes a new people shows up. And that new people has to figure out what you other people do. And sometimes that goes well and sometimes it's like You can sort of continue to set

Speaker 1: up try to figure that out with your coworkers and be confused, or you could actually spend a consistent amount of time and effort Helping to onboard new new and casual contributors to one of these large complex pieces of software. And then at work, you're the fancy person. So just something to consider Also, going back to the idea of the gift economy, you'll actively be supporting the maintainers. As a result of doing that, you'd be working with people who have been maintaining these large, complex pieces of software that I've talked about before. What are the things you can learn from someone who's been maintaining Python or Django for years?

Speaker 1: What insights do they have about software engineering and design principles that that you could benefit from? So that's sort of a streamlined version of the business case. It's still something I'm sort of I'm working on fleshing out, but that's sort of a streamlined version of how being a contributor mentor for code contributors could benefit you. Um but what about contributions that don't require code? And so again, um This is you know some place where I'm I've sort of struggled with some of the verbiage, but in the prior part of the talk I focused on contributions by way of writing code or documentation. But code contributions are only a subset of the ways that people contribute to our community. And again,

Speaker 1: the language there is a little tricky and I'm trying to sort of sort it out. And I will just be I'll be honest. One of the reasons I struggle with some language around this is because we will hear and see terms like technical talks versus non-technical talks or soft skills versus hard skills and it's a bit of it's a false dichotomy Again, as a professionally trained capitalist, a lot of the skills that have served me well have been what people will call soft skills. And on almost every job description you see, you know, someone with leadership qualities or, you know, whatever it's uh, you know, so Th there's there's that sort of false dichotomy around like what is hard and technical and what is not. And so that's why I've sort of struggled with that.

Speaker 1: But what I have decided to do here is um So this is the part of the talk we're talking about broadening the contributor scope. And to sort of try to get around that issue of trying to sort that out in words, I have decided to use some examples. And let's see if this works. Uh-huh. Let's see. Let's try There we are. So use some examples and I'm gonna use this my company RevSys as I talked about earlier. Um and I'm gonna talk about some of my coworkers and specifically I'm gonna talk about Jeff, Lacey, Frank, and Catherine, four of my co-workers.

Speaker 1: Um Bottom right is Frank, bottom left is Jeff, and the middle is Jacob Kaplan-Moss, who some of you may or may not be familiar with Uh at work we call him Capitol Moscow if we have two Jacobs. So in I'm sort of going through them in the Carolac World that I met them. So Jeff is one of the founders of DEFNA. And I'm focusing on these people because these are all people who have made tremendous contributions, largely to the Django ecosystem, but also to the Python system, without writing code. There's no code involved. So Jeff is the founder of DEFNA, the nonprofit that has been put on DjangoCon US since 2015. He is Also, he's still a board member of DEFNA. He is currently on the board of directors for the Python Software Foundation.

Speaker 1: He was until very recently the Python Software Foundation's treasurer. has been a DjangoCon US chair and a co-chair, and as we speak, is currently helping organize Django Khan US for 2022. None of that involved him writing any code. But these are contributions that get made to the community. Lacey is another coworker. Lacey has been a Django Con US Chair and co-chair is currently helping organize DjangoCon US 2022, helped organize a number of different Django Girls events. Again, the Django Girl events involve a certain amount of coding, but again, most of these contributions don't involve writing any code.

Speaker 1: It's not necessary. Frank, who is the founder and president of Refsys. Jeff, by the way, also one of the also a partner of Refsis. Frank, the founding partner. Frank spent five years as the president of the Django Software Foundation, so the nonprofit that oversees a lot of the intellectual property for Django. And as the president of Repsys, RefSys also funds, it also helps sponsor a number of different events. So we sponsor PyCon US and Django US, various other things. Again, none of that requiring code And then there's Catherine. So uh by show of hands, how many of you have attended a Django Conju S? One more few people

Speaker 1: maybe. So if you've attended Jangokan US since maybe 2017, definitely 2018, you have into you have benefited from Catherine. Um Catherine I think her technical title is assistant at Repsys, but Catherine makes a lot of things go in the background. So during the time when Frank was the the Django Software Foundation president. Katherine helped make a lot of things happen administratively during the time that DEFNIT has been around and organizing Django Khan US. Catherine has helped make a lot of things happen. So if you attended DjangoCon US, you have benefited from Catherine and from her help. So we

Speaker 2: go back to this.

Speaker 1: There we go. So we talk talking about the four people. Of the four people that I pointed out, three of them are our software developers. Catherine is not, but most a lot of their contributions have involved no code at all. And this is the issue. And there are many contributors who fall into this space. The problem for those contributors who aren't contributing with code is also burnout. Again, it won't show up as quickly on a Google search for contributor burnout, as quickly as open source maintainer burnout or maintainer burnout will. But this is also an issue for conference organizers. Um are me is meetup a thing here in Europe? Yeah, okay. And so you all have like your local like Python meetups or Django meetup

Speaker 1: or insert technology here meetup, yes? So so I I'm very very old. So so back in the old days, we used to have what we call like user groups. So they were like there were what we call pugs, Python user group or or like Linux user group lugs, but now they're on meetups When you get home, talk to your local meetup. So how many people how many people here actually organize a local meetup in in back home? Could you all use some more help? And so for the rest of you, when you get home and you go to your next local meetup, ask them, ask that person who organized it or those people if they could use more help. I can tell you the answer would be yes. I already know, but you don't know. So this is your homework. When you get home, ask these people, and they'll they'll tell you

Speaker 1: and then tell them. An axe man named Kodo told me this. I'm just here to verify. But so so this this is an issue. There's an issue with burnout even in these contributions that don't require code. And so Again, was needed more help, but again, it's not just throwing more people at it, it's a certain type of help. And and so there 's also the issue of people doing things just sort of for the resume item again, people who will want to be on a board or help organize the conference or or what have you. So how do we deal with these issues? Where do we find more help? Again, the idea is having contributor mentors for these these contributions go beyond code as well. It's just that this this space is a little less well-defined.

Speaker 1: If you look at contributions that require code, those kind those space those problems are well-defined. We have the issue trackers. You can just look and see where the contributions are needed. But here uh it's a little trickier. The good news is I've already done a few different talks that sort of cover this. So where do we get this out? I've given two different keynotes, one at PyGotham 2019 and one at PyTexus this year, uh what I call the Python Use Spectrum and Python community growth. I'm gonna sort of move through this this next section a little bit faster because this is from uh from talks that I've already given and you can Look at those online. They're on YouTube if you search for those titles. So the question who's gonna help our contribute to

Speaker 1: making contributions beyond code. There are two necessary conditions. For someone to make a contribution to a Python or Django community, they have to A use Python to solve problems and so they they actually see some sort of value in it, Python or Django. And then two, they need to actually feel included in the community. Like they're actually welcome and valued enough members of the community to contribute. And so the good news is Python is growing very quickly and it's now one of the most popular programming languages, and this means there are a lot more people who are using Python to solve their problems and see its actual value. This slide and the next one make a variety of people angry in different ways. And so

Speaker 1: we will see what happens. So I've come this town of Python use spectrum, and even while preparing this talk I've realized I need to change this a little bit. But the idea here is that people use Python along a spectrum. One end we've got programming, the other end software engineering. It's a sort of a continuum. The sort of the the the the short circuit version of the try not to try to make some people less angry at other people angrier. is that software engineering is a subset of programming. So what this is not is a like real programmers and not real programmers thing. This is just a continuum of use All software engineers are programmers. All programmers are not software engineers, and they don't need to be. We'll see why on the next slide.

Speaker 1: So so how do I define these things, these these ends of the spectrum? Almost everyone who uses Python exists somewhere here along the spectrum and the focal points as we look at the bullet points going down focus around who writes the code. Who's running the code and who's going to be reading the code later? Who do we expect to actually run the code? Who's actually going to be running the code? And then What are you after? What is your goal? Are you after you know what 's the actual product that you want? And then finally, why are you writing code? So programmers usually are people who are writing code by themselves. They're the ones who are running the code. They're running the code while they look at it. And what they're after is they don't care about the code itself, they care about the output of the code.

Speaker 1: And the reason they're writing code is because it provides them with some sort of utility. I use myself as an example. I used to be an accountant, and so in my prior career, I wrote code that helped me with that job. That was all I cared about. I didn't care about the code itself. I just cared about the result of the output. Software engineering on the other end, you've got code written in Teams. It's being run or read by other people. It's supposed to run in isolation. The actual product is the code itself. And you're writing code because it's your job. It's your profession. So two very different use cases and different motivations And so the big problem we have here is that our community culture is heavily biased towards software engineering. Our community culture sort of works from this assumption

Speaker 1: that software engineering is the one true way to write software and That's not the only useful way to write software. If you're a software engineer, that's what you do, but there are lots of people getting value from Python, not using that full set of tools. And again, if we look at these criteria, there are certain there's there's extra tooling that we professional software engineers use because of these requirements that people who are programmers don't need. They don't need all those tools And so why would they use them? And so we have this bias. Why does that matter? The bias is a problem because the bias towards software engineering tends to show up as a bias against programming. And so what you have is a situation where people who are using Python to solve their problems

Speaker 1: When they encounter who are on the programming end of the spectrum, when they encounter software engineers who are maybe more experienced Python people that they go to to ask questions, they're being told that they're doing it wrong because they haven't installed Docker or because they don't have CI set up But if you're not in a s in a in a context that needs that, why would you do that? So Python is growing faster data science and other non-engineering, non-software engineering areas And there are lots of people who are using Python to solve problems for themselves. And as such, these people can bring the skills that they have from their non-software engineering careers to make contributions to our community because those are the skills that we lack. The software engineering skills we have plenty of, but there are other skills from our software community that we need.

Speaker 1: I'm going to move this a little quickly. You've got sort of three common use cases here. People who were not coders who became a programmer, and this is the area of maximum growth, of maximum sort of like new potential Computer community, data scientists, which is the fastest growing there. You hear about that all the time. And then software engineers, which we're all familiar with, the current community bias. Um the nice thing about this is Python is simple enough where it lets you, just to use the cooking analogy, Python lets you cook things without having to become a professional chef. And so the common denominator among those three roles is that all three of those people use Python as a solution to their problems. All three of them are potential contributors to the Python or Django ecosystems. Unless we push away the people who are not software engineers because we think that they're not doing it the right way

Speaker 1: or they're not, you know, they don't have enough test coverage. for the two scripts that they wrote that handle a lot of the chemistry work that they do or or what have you. And so this is important. So we need to avoid pushing people away who aren't doing the full software engineering task. Unless that's something that they actually need to do. And I'm gonna also refer to you to another talk, this is where another set of ideas came from. Russell, Keith McGee, the person who gave me this coin, he did uh a keynote of PyCon 2019, PyCon US 2019. Wait, he talked about a number of different things, but I'm going to focus on the last section. It's an excellent talk that looks at the future of PyCon, of Python, but I'm only picking out the parts of the end

Speaker 1: that are relevant for my purposes here, there's this idea of paying professionals to support your project or building a team who has contribution skills beyond just writing code. And so Russ points out some d some important things. What? Money makes things happen. True. Expertise costs. So if you want people who actually know how to do things They're not inclined to just show up and do it for free because they can get paid to do that stuff in other places. And then he he points out a number of different things that need to get done that aren't just writing code or writing tests. So who does all these different things? So there are a number of different things to get done here. What stood out to me during Russ 's talk was this question. What separates the Python community from any other potential client for someone who has skills that we need?

Speaker 1: Again, expertise costs. Everyone else's money is just as green as the PSFs or the DSFs. The separation comes from the idea of does this person think that they're a member of our community or not? And If they are, they're more inclined to help us. But again, that's where that bias towards software engineering becomes a bit of an issue. So what do I want you to do here? What's the call to action here? If you're looking at contributing with code and wanting to try to become a contributor mentor , Start with finding the project you want to contribute to. Take a look at the contribution docs and the issues that are there. But most importantly, that's why it's in bold.

Speaker 1: Prepare yourself to try to try to help other people do the same thing. This is the key. The approach is a little less defined. This approach is more well defined, but it's the last step is sort of the new part. And if you're looking at trying to become a contributor mentor to people to people who make contributions beyond code, again, this is a little uh less to find because there's so many differ different options here. Don't undervalue your non-coding skills. Start with volunteering at a at a at a meetup or a local conference. And then also recognize that code contributions are a subset of overall contributions And prepare yourself to help others. There's some different inconsistencies and limits here in the talk. I'm aware of those and we can talk about those later.

Speaker 1: But I am interested in hearing feedback from people, hearing different people's ideas. You can reach me on Twitter, it's probably the best way. I will probably be going back to my hotel relatively soon today because I've been awake for the better part of about 48 hours. Um so I'll probably be going directly soon but I'll be here sort of throughout the conference. I am happy to to hear input from people, hear feedback from people, or you can click me on the internet Thank you very much for your time.