 Hi, everyone, welcome. Thank you for coming. Now, before I get started, who here was actually involved with Adopt Pytest Month? All right, so most of my little Adopt Pytest Month cruise over here. And who here is a contributor to an open source project? One or more? All right, so nearly everyone. Great. So it probably won't surprise you to know that I love Pytest. I've been a Pytest user for a few years. I've contributed a few patches. And I generally find it a total joy to use. And it was founded by Holger Krekel, who gave this morning's keynote. It's been around since 2009. It's a very mature, stable project, full of features, and has around 170 plug-ins to match all kinds of frameworks. And so in January at the FOSDEM conference in Brussels, we had a little Pytest meetup. And it was lots of fun. We got to talk about all kinds of things we were excited about doing or fixing in Pytest. And I thought to myself, why doesn't everyone use Pytest? Like, there's some libraries, for example, requests. Everyone uses requests. And everyone says, just use requests. But that's not really the case with Pytest. It has many, many fans. And many people strongly recommend it. But it's not really in the situation that people say, just use Pytest. End of story. I mean, we even heard, even Guido sticks with the unit test. So why doesn't everyone use Pytest? Well, there's a few reasons that I can think of. And some of them are out of our control. We will never be able to satisfy them. But there are some that the Pytest community, the Pytest contributors, could do something about to encourage more people to use Pytest. So at FOSDEM, I had this idea that we could pair up open source maintainers who were interested in getting started with Pytest with experienced Pytest users or developers. And they could work together for a limited period. So it's not too much of a commitment to help them really get started and get off on the right foot with Pytest. And that would help overcome knowing where to start, knowing if you're doing it right, and really taking advantage of all the best features of Pytest. And with any luck, at the end of a month, we'd have a host of new Pytest users, which would be great. I decided to organize it for April. And so I wrote up a page on the Pytest website, describing what we were planning. And I made some surveys to sign up the Pytest helpers and also the open source maintainers. And first, I tried to sign up the Pytest helpers because I thought, well, if we are inundated with open source projects, we want to make sure that we have helpers for everybody. And so I asked the Pytest helpers, what was their experience? They didn't have to be a Pytest developer, so they did not have to have contributed code to Pytest. But they had to feel that they were experienced and knew most of the most important features of Pytest. And I asked them about their experience with other areas of Python programming, like frameworks like Django or Pyramid or scientific programming, so that I could try to pair people with appropriate interests and experience. And we had 26 Pytest helpers sign up, which was a lot more than I was actually expecting. You saw at the Pytest Meetup, there was six of us at Fosdome. And so I was really surprised. We had 26 people volunteer to help other people learn Pytest. And only nine of those people were people who had actually contributed code to Pytest before. So I'd found 15 new people who were keen to advocate for Pytest. And then next, I tried to sign up the open source projects. I wanted to reach open source projects that were fairly well established. And so initially, we had a requirement that they should have more than one core contributor. And after a couple of weeks, we did not have many sign ups. And we thought, OK, maybe we can relax this requirement. And so projects with just one contributor, that's fine as well. And the main way that projects actually found out about Adopt Pytest Month and took part in it is by being approached by Pytest users. So we asked the Pytest community to look at other projects that they were part of or aware of and maybe ask them on their GitHub issues or on their mailing list if they would be interested in taking part in Adopt Pytest Month. And that was by far the most effective way to find people who were interested to take part. And in the end, we had eight projects that kind of officially took part in Adopt Pytest Month. And there was another four that kind of informally took part in that they said, yeah, sure. If you send me a pull request, I'll accept it. But they were not really committed to kind of working closely with the Pytest helper. And so the projects we had were Bidict, which is a library which provides a bidirectional dictionary. Gessit is a command line utility to extract information from media filenames. Callithea is a source code management system similar to GitLab, which supports both Git and Mercurial. Qt Browser is a keyboard-driven browser based on PyQt5 that you can control in a similar way to VIM. Trump is a framework built on pandas that aims to centralize the management of data feeds. Akestra is an extension to Django that provides semantic web publishing and is used by a bunch of organizations, including the recent DjangoCon in the UK. Nefrotari is a REST API framework sitting on top of Pyramid and Elasticsearch. And Coursera.dl is a command line utility for downloading Coursera.org videos. And Trump and Nefrotari were both open-sourced by different companies, specifically in order to take advantage of AdoptPytest Month. So there are companies that were thinking about open-sourcing their project or planning to eventually do that, but AdoptPytest Month was really the trigger for them to actually do it. And informally, we had Jason Pickle, Cookiecutter, Django, Ginger2, and Pelican. And the last three actually accepted pull requests before April even began. So they kind of, as I said, informally took part. They did benefit and PyTest did benefit from contacting them, but they did not really work through the month. And so given that every project would be in a different place with regards to their testing, I left it up to the PyTest Helper and the maintainers themselves to decide what activities would be appropriate, what would they, how much would they try to get done during the month. But I just suggested to work in incremental steps that built on each other rather than trying to change everything in one big bang. And to do lots and lots of code reviews, like very intensive code reviews. And to spend a lot of time just talking about the PyTest features and kind of wondering out loud, is this possible? Can you do this? And having an opportunity to learn through discussion. And so after the month was over, I sent a survey out to all the participants to ask them what they did and how did it go. So the PyTest helpers did things of course like updating tests, changing unit tests, cert equal statements to plain assert statements, changing the layout of code and tests and docs to, well I'm not sure if that was for PyTest or just kind of incident or cleanup. Removing boiler plate code that they didn't need anymore, fixing minor bugs that they actually discovered through this process, converting tests, tests to use parameterize, making custom fixtures, custom markers, and introducing the use of various PyTest plugins. And so self-reported, I asked them how much time did you spend on adopt PyTest month? Initially I advised maybe two to four hours a week was the time commitment, not really knowing if that was a lot of time or not very much time. And really varied. I'm not really sure how accurate these numbers are because estimating, remembering back how much time you spent can be quite difficult. But five of the PyTesters said they would definitely take part in it again. Five said they might take part and one person said they probably would not. And I asked them how do you feel about the PyTest community now after the month? And five said they were more positive and keen to be involved in the community. And five said they will have a similar level of commitment which might already be quite high in fairness. And they also reported learning about different features of PyTest that they hadn't been exposed to before. From various plugins to how to run doc tests, how to support PyTest in various continuous integration servers and more about PyTest support for unit tests and knows test suites. And then I asked the maintainers to tell me what they did. And of course they reported discussing the plans over email or chat. One project used a Gitoo chat room which is built on top of GitHub. Others used email or just the issue tracker in GitHub itself. They wrote new tests and put pull requests for the PyTest helpers to give them feedback. And one enterprising maintainer actually updated a PyTest plugin to work with QT5. And one project, Coursera DL, made a PyPy release for the first time. So it's a very, Coursera DL is actually a very popular project but the number of users is not proportional to the number of contributors, which is not uncommon. And the maintainers, in one case 80 hours, I thought it's really going above and beyond and that time varied a lot. So five maintainers responded. Others did not respond to my survey. And four of them said they were definitely or they would recommend taking part in Adopt PyTest Month to other open source projects. One said maybe. And they reported that how they felt about PyTest now that they had a good grasp of the basics but they were also aware that there was really a lot more that they could learn. And they felt very positive about PyTest actually. And they all indicated that they're going to keep using PyTest in their project. And two of them told me that they have actually introduced PyTest in other projects that they contribute to, which I think is really cool. So even though we directly only worked with eight projects because many open source contributors work in multiple projects, we have a multiplier effect. And in general, the people who responded to me told me that they really enjoyed it and they were really grateful for the opportunity. And so maybe some who didn't reply didn't have such a good time, which is not a surprise that they didn't fill out the survey. But just based on my observations of looking at the activity in the various projects, of course, they were not all runaway successes. So this is my observations about some of the areas where people struggled. And they're not really surprising. They're the kind of problems that we face in open source in general all the time. So you get excited about something. You think you're going to devote a lot of time to it, but real life intervenes and you end up not being able to do anything. So some Pytest helpers didn't really show up. And I mean, I knew nothing about them except they have completed a survey for me. And some of them showed up, but we're not really able to make much progress in their project. And some of the maintainers were extremely busy and were not really able to work with their helpers either. So I wanted to think about what are some things that we've learned from this that if we do it again, we could take into account to try to have a better experience for everyone. Because even though I've told everyone, you know, it's all volunteers and we hope that it works out, people were very understanding, but at the same time, it's kind of disappointing if you think you're going to work with somebody but then they don't actually show up or you don't get done what you wanted to get done. So how can we have realistic expectations about what we're doing? So the first thing I learned is that you don't really know how many people are lurking in your community. So for those of us who are experienced in open source, we kind of know that the way to get into it is to just march right in, sit right down, start working on something, submit a pull request and that's fine. That's actually the way it works. But when you are outside the circle, it's not very clear how do you get in, how do you start and it's kind of intimidating. So giving a foothold to people to say, this is the thing that you could do and this is like a very clear expectation about how you take part in this activity was a really helpful thing to do. And one of the Pytest helpers said this. They said that it was the first time they contributed code to someone else's open source project. So I think that's super cool. We were able to bring someone inside the circle. And to me this was a really important revelation of doing adopt Pytest month, that there's a lot of value in making a space for users to be advocates of your software. So by advocates I mean people who are excited about bringing other people on board to your project. They don't have to be contributing code. In companies they often have positions called evangelists, developer evangelists, they'll come and give talks at conferences and tell you how great this library is that you should totally use. And in open source projects that are not corporate backed or company backed, that's usually left to the developers. But there's real value in recognizing the work of advocates in our open source projects. It's not only good for the community, but it's good for the users of your software. And so the third thing is that code review is maybe not just important but actually amazing. So I called my talk the realities of open source testing and this is actually what I'm talking about. Because the majority of open source projects, probably the median number of contributors is one. So there's a real long tail distribution of open source projects. And at the head we've got really popular projects like Python, Django, even PyTest is fairly far up the head of the graph. But there's just this long tail of hundreds of projects that have one contributor. And even a popular project like Coursera DL I mentioned only has one person who's really developing code. So for them it's incredibly valuable to have someone reading their code, engaging with it, and able to give them specialized advice about the way they're using a particular library. And a testing library is something that you really rely heavily on. Your test code might be 40% of your whole code base. So you really wanna make sure that you're getting the most out of it. I mean the parameterized marker in PyTest is a good example of that. You can easily write very repetitive tests without realizing that it even exists. But if someone tells you, hey, this exists, you can condense 500 lines into 50 lines that will just blow you away. And so the last thing is that something I really underestimated is that this kind of project, I was thinking a lot about how we are teaching or mentoring the open source maintainers about PyTest. But it was really also a case that for each helper they would need to be mentored or onboarded onto their specific partner project. And I didn't really emphasize this to the project maintainers. Of course in hindsight I can say, of course it makes sense that you need to understand the domain of a piece of software, the concepts and the functionality most of all before you can effectively test it. And you need to have documentation in place to support all that, which is more than just having doc strings. So this is something that I would be aware of if I was to do this again. And so my question to the open source maintainers in the room is can you make a space for advocates in your project or do you recognize the work that advocates are doing in your project? And could you offer a kind of targeted code review program to users of your library? And if you were interested in doing something like that, this is a few suggestions. And something important is that you don't necessarily need to do this with new users as we did with Adopt PyTest Months. It would actually work probably even better with existing users, just helping them really make the most of using the library. And I put here, encourage people to say, sorry, I haven't done that yet, or I'm not sure where to start. And I think it's very common that when we are blocked and or if we procrastinate and we don't finish something that we told someone we would do and they write an email and they're like, hey, how's that thing coming along? It's kind of, it's very hard to reply and say, yeah, I haven't done that yet. And it's much easier to just kind of ignore the email and then another week goes by and it's a real loss of time in a short period of a project like this, which only runs for one month. So making it much, trying to tell people it's really okay to say either I haven't done that yet or I don't know where to start would help to overcome some of those communication barriers or uneven contributions. And I think it's really important to recognize your advocates and try to recognize people who are doing work in your project that are not, that's not contributing code. So something important for me was I made the point of writing LinkedIn recommendations for the advocates as a way of acknowledging that they'd done really good, really valuable and really important work for PyTest. And definitely don't schedule it in the same months as PyCon US, which is what I did. Take note. So to conclude, it was a very interesting experiment and I think it's been really exciting to meet some of the people who took part in it here at EuroPython and one of our project maintainers actually delivered the PyTest training that we had on Monday. So in the space of less than two months, he's gone from not knowing or not really knowing PyTest at all to delivering training on it and updating plug-ins and all kinds of things. So I think it was really valuable and interesting positive experience for PyTest and I'd encourage other projects to think about if it is something that they could do in some way. And so thank you very much to the PyTest contributors who kind of supported trying this in the first place as well as the helpers and the project maintainers who had a lot of patience as we were kind of trying this thing and we were not really sure how it was going to work. And I just wanted to mention that tomorrow there are two talks from the two PyTest helpers and talking about slightly related things and there's more information including a PDF report about PyTest Month in case you want to get all the details about it at those addresses. So thank you. We have a minute or two for one or two questions if there are any. First of all, thanks a lot. I'm one of those guys who do use PyTest but I don't contribute, sorry. But again, thanks a lot. That's just inspiring. My question is how do you feel about the effort that could be spent on advertising a product, especially at DevLibrary through social media? For example, if I search Twitter for PyTest, I got Twitter.org with not as many followers and so on. So do you feel if that is important to maintain such a channel as Twitter, Facebook and so on for developers or GitHub is just enough? Thanks. Haven't thought about if it's important in general but I started the PyTest.org Twitter account about the time that we started thinking about Adopt PyTest Month and I tried to use it to advertise the concept on Twitter which worked okay. But actually something really great about the Twitter account is that many people just post tweets saying about how much they love PyTest or they're giving a talk about PyTest at their user group that we had no idea about. Like there's talks being given in Portuguese, Japanese, Thai, all around the world and just having a search set up for any mention of PyTest has revealed all these things to me which is really so nice to see that people love something that you are part of and we had a meeting yesterday we're actually talking about setting up a blog to gather that kind of information as well. So I don't know if I would say it's essential but I think it's a positive thing and I think having a blog where we can post links to tutorials and things will also help users to see that there is a vibrant community around PyTest and I think that's something that people take into account and they're evaluating whether to use a library or not. It's good to be able to show that you have a lot of users, you have people who are keen to help you if you need help. Okay, I'm afraid we're out of time now but thank you very much, Brianna again.