 So far we've been focusing on sustainability of open source and showing the different ways outside of development that people can contribute to open source communities. This next talk will dive deeper into the designer role and show what you can learn from design contributors and how to help them be more successful. When applauded across your community, the lessons shared here will make your community more diverse and more inclusive. Erl is a returning speaker and we're so happy to have them back on the virtual commit stage. Enjoy. Hi everyone. I'm here to talk briefly about mentoring in open source software in a design capacity or as a designer in open source. So I'm Erl. My pronouns are they then you can find me online on Twitter and get lab on the username at Erl does design and Erl is spelled E R I O L. A little bit more about me. Who is this person? Why are they talking about open source and design? So I've been working in the design industry for around 11 years now, and I've been doing design work within NGOs and third sector organizations and charitable organizations for about the last four years. Sorry, eight years. And I've been in open source software for the last four years. So I'm also a PhD student. I'm researching humanitarian open source software and how designers can contribute to humanitarian open source software. And the different kinds of open source software that I've contributed to in my time being involved in open source. Our projects like Ushahidi and Mozilla open food network, mutual aid projects, Linux public health and open source design and sustain open source software and humanitarian open street map and loads more. So this is just a sample of the different open source software that I've contributed to and some of the ones that I've contributed to more regularly or more actively. So for the open source software maintainers, developers, the people that are involved in projects for those of you who maintain projects or who work on different projects. Those of you who are watching, I just want to make sure that this is really, really clear and make sure that I cover this just in case you don't know. Designers really want to participate in open source software and they want to participate in open source software in many, many different ways. So this can be with visual design. This can be with user interface design. It can be through writing and documentation and making sure that documentation, writing and information is really readable and really usable or even just writing documentation like how everybody else would write documentation in open source. They might want to do work on information architecture and how you structure different parts of your project. They might want to help you to make sure that your project is really findable that users or people that are trying to look for your project or navigate around your project are finding that really easy. They might want to work on, like I said, the usability of documentation, but also the usability of the software generally. So is it accessible and usable by all different kinds of people, not just the kind of people that have maintained it historically or the people that have worked on the code base. So when we're thinking about developer tools, is it usable for developers that have been working on that open source tool for many, many years? Maybe the people that maintained it, but is it also usable and accessible to new developers, people learning that new coding language? So these are just some of the ways that designers want to participate in open source software. And I can tell you and I can say with the utmost confidence that this is true. Designers want to participate and offer these kinds of things. But you might be thinking about why designers might care about open source software. And I think this is really important to cover before we go into the mentoring aspect so that you can better understand the places that designers are coming from when you want to try and mentor them. When you want to make a mentoring relationship happen between a designer and another person within the open source software. So you want to understand why they care about open source and why one of the many, some of the many reasons why they can care about open source. So designers often see how they can learn, grow, collaborate and communicate when they work on open source software or when they're contributing to open source software. So it's not too different to how anybody else who contributes to open source software values in gets something out of it. It's a lot of the same things that a lot of people get out of open source software. But for some testimonials, for some real first person accounts, I asked members of the open source design community to comment on why they value open source and why they want to be participating in open source software as designers. And I've got two comments from two different members. But you can find out more about why designers are involved in open source software at the open source design.net website and the community there that posts a lot on the forum. But this is just two accounts from two different members. So this is Franklin who is relatively new to open source software. So he's been contributing I think now for about a year and a half, two years. He says that designers have the opportunity to learn and collaborate with other designers. So this is actually something that is really rare for designers to get experience of, especially if they're early career or they haven't worked in big organizations or maybe if they're freelance. There's lots of different reasons why designers haven't had the opportunity to collaborate with other designers before. And this is even something that happens quite late in some designers careers as well. So designers, especially if they are working for small organizations or even if they are hired by open source organizations, a lot of open source organizations will have a reasonably constrained design team. One's on possibly on staff. So they don't actually get a lot of chance to collaborate with other designers and it's really, really beneficial to us as our career growth for designers. So the opportunity to collaborate with lots of different designers all across the world is something that Franklin was talking about. Benefiting him and his learning and his opportunities to grow using open source software or contributing to open source software and being able to really grow his career in that way in design. So there's also a aspect of open source software where designers feel like they can do some things which maybe they aren't able to do in some of their regular day jobs or regular careers. So they see this space where they can really openly center human needs within the tech and by the virtue of open source software being mostly communicated openly. So a lot of the documentation, a lot of the issues, a lot of the needs are documented, documented openly. A lot of designers really see the opportunity to do what they do regularly, but on an open platform with the ability to be a lot more vocal about why it's important to center humans needs within software and within different projects. So this is Florian who's a designer who's been contributing now I think to open source software about two and a half years, a little bit longer than Franklin. And Florian came into open source software through a mutual aid project. And he is part of the design team at the mutual aid app project. And Florian says that open source software is a part of our everyday lives, and it deserves the same treatment that non open source software gets, which is a proper user centered design process, which I think is really, really powerful. Why are we not giving open source software the same benefits that we do proprietary commercial closed source software? Why are designers finding it so hard to participate? And why does designers not necessarily see it as a space where they can enter in and really participate and contribute? And why are open source projects not seeing that this is something that designers want to do? So it can get very frustrating. And so much open source software could really benefit from design support and designers want to offer it that there are so many barriers in place for them to participate. So to move on to some of the mentoring aspects, because a lot of these mentoring tactics or a lot of these mentoring experiences that I'm going to talk about are ways in which we can begin to remove the barriers that I briefly talked about designers having when they want to contribute to open source software. And I do mentoring regularly. I do this as part of how I actually contribute to open source software projects generally. So I see my contribution to open source software projects, often not only the things that I'm contributing as an individual, but the ways in which I'm structuring good mentoring experiences for the other designers that want to participate and contribute as well. So these are some of the things that I've been asked by designers on how to help them essentially. So designers that have been looking to contribute to open source software and they've reached out to me with these different questions. So these are some of the requests I've had. And these mostly from having spoken a lot about designing within open source software spaces or being very visible in the community. So things like can you review my article about design and open source software? So designers writing articles about their experiences or trying to write guides for other designers on how to participate. Can we meet up and you tell me about design and open source generally. So a lot of designers are really curious to see the different projects that are going on and learn about open source software, but they really want to meet up with another designer or another person that they can connect to that they can relate to and talk about design and open source generally and how the two intersect. It's really, really comforting for those designers to really understand what the history of open source is from somebody that has a reasonably similar background to them, i.e. another designer. There's a project I'd like to contribute to, but I'm not quite sure how to start. I get this one quite a lot. A lot of designers actually know what projects they really want to contribute to or at least they have an idea of what kind of project that they would want to contribute to. But they absolutely have no idea how to start with these projects. Sure, you can say we've got a readme, we've got a contributing file, but a lot of designers really do struggle to find that specific way that a lot of people that do code for open source projects take for granted that we inherently kind of know that these are the ways in which we can contribute. So often when some designers come up to me and say they have a project they want to contribute to and they don't know how to start, I'll coach them slowly and ask them what they want to get out of the project. So I'll show them a few of the things that are shared universally around open source projects to try and help them get that confidence boost to just start. And these are all great questions. There's loads more questions on the screen at the moment than other than the ones that I've called out. And these are great. I love these questions and it's part of the reason why I still am very active in the open source software community as a designer and why I speak about design and open source. So I can help these designers understand open source software, help open source software understand designers and how I can better bridge the gap between the two so that one can contribute to the other and the other can give a great experience for those people that want to contribute. But this is quite a lot just for me and I'm not saying that it's just me out there doing this. There are actually a lot of designers doing very similar things to what I'm doing, but not enough. So we need more open source software design mentors. And this is a numbers problem really. So it's a problem about how many people we have doing this and how effectively they're using their time. So it's really hard to find designers with experience of open source software and also who want to mentor. Because choosing to be a mentor isn't a decision that people take lightly or make lightly as mentoring is very, very different for each mentee. It's very, very different for each mentor. So it's a lot of responsibility. It's something to really deeply consider whether you want to take it on. But it's not just for design mentoring. It's not just about having that experience and it's not just about wanting to mentor. Sometimes it's about a lot of other things. And I've got a few silly vendor grounds up on the screen at the moment about the intersecting things that we need or we could ask for from designers who want to mentor within open source software. So here we have a couple of other intersecting needs around having the time and support from workplaces in your primary role as a designer to be able to mentor designers within specifically within open source software. And being able to be paid as part of their role to actually mentor those designers. So not added in this diagram as well are a lot of other things. But we've got a few different things that we can think about when we want to increase the number of open source software design mentors. So we can think about designers with experience in open source software. We can think about designers that want to mentor. We can think about designers that have time to mentor and we can think about designers that are encouraged within their paid roles to actually do that mentoring process. So we can think about those aspects. But not added in this diagram are other things like how long and how in depth the effort it takes to find an open source project that is welcoming and ready to have a designer participate. So there might be a lot of projects that designers want to contribute to but they might not be quite ready to receive those design contributions. And it might be a process of mentoring through helping that project to get ready. But that is often much easier. Those first few steps those first few things about when a project isn't quite ready for a designer to be contributing actively with design related issues. When you're helping an open source project to get ready for contributions from a designer that wants to contribute is much, much easier for that designer that wants to contribute when you have a mentor to guide you through common information, common places to find the community, common ways that open source projects communicate, common processes that they use and generally a sort of shared history about what open source system and how it functions. So it's not just math. It's not just about how many of these designers we have with these intersecting skills and these these time issues and these abilities and experiences. But it is also about how there can't necessarily be one single way of doing design mentoring for each for every open source software project so they can't be just a cookie cutter process of you know you take this mentoring process and you put it on this open source software and you take the designer from that completely different background and you do the same process because open source software is so diverse. There are so many different kinds of projects and there are so many different kinds of designers and there are so many different kinds of things that each project would need that when you try and standardize this approach it becomes really really difficult becomes even more intersecting Venn diagrams of different kinds of needs. For example when I think about three different open source software projects I work on each has a different way that they work on design. How much they know about design as well. So they've got a different way that they work on design if they do indeed work on design they've got a different capacity of knowledge and the team size and ability to receive those design contributions and take them through a development process is very very different. So these are just three projects that I can think of as examples of projects that I've contributed to simultaneously in my time as a design open source design contributor and design mentor. And thinking particularly about the processes that these three three projects uses even more complicated when we really think about it and I even worked on these projects so these are projects I knew individually each process very very well and very much in depth. And there are processes that are good and there are processes that are maybe not so good and maybe ones processes that started in one project that actually when you're contributing to one project might you might think that it would work really well in a different project so a process using project one might work really well for project three. But unless you know all of these different things from these different projects quite well. You won't necessarily know how you can how to mentor very well for each of these projects and you won't necessarily know that there's different things that can be transferred per project that are different mentoring processes or different processes that the open source software project could try in order to receive different kinds of contributions when you have a designer come up and want to contribute something to the project that's never had a particular contribution before. So say project one has had UI design contributions before and they've got a really great process for that but project three hasn't got a process for that they've never received design contributions for that before but you've got another designer that really wants to contribute to that project. If you're not doing lots of different design mentoring across different projects you wouldn't know that there was a process that works really well for one project that could potentially be tried out in another project. So your ability to mentor and the capacity to mentor really does grow with the different kinds of projects that you yourself have been involved in as a design mentor. But that you know it's really really tricky so again there there are all these different kinds of criteria that you need as a designer to be able to mentor. But there's also a lot of experience a lot of length of service in some of these projects that that really help when you're trying to not only mentor the designers they're contributing but trying to I guess mentoring the projects as well in order to receive better design contributions or more design contributions essentially. And if just me explaining the complexities of doing design mentoring so from receiving the different kinds of requests that I get or the different kinds of experience that I have that I modeled what I think is needed or what might be needed or in a design mentoring relationship. And then the different kinds of projects and the different kinds of transferable knowledge across different projects and different mentoring experiences even if just listening to that has kind of made you go phew. Gosh okay that sounds like a lot then it is it is a lot and burnout is is very real and very very difficult when you are limited resource within a particular community and when you're you're one of few numbers that are that are doing this. Actively and it can it can get really really hard to maintain that support for your mentees. And the different kinds of things that designers can often get burnt out on if you want to pay attention to these kinds of signs and signals if you have designers mentoring other designers or if you have designers that want to step up into a mentoring position or even if you're you know not a designer and you want to be able to mentor. Or designers just realizing that these are the kinds of things that that can become aspects of burnout are is really useful so you can get burnt out on design as a subject so just being just being part of a design process can be really difficult you can get burnt out on repeating info. To different people the same information to different people. You can get completely burnt out on sharing a lot of designers aren't used to sharing processes so it can can really produce a lot of burnout for us when we're doing these new kinds of processes. You can absolutely get burnt out on open source software and the kind of intricacies and the histories that we haven't been necessarily privy to until recently. You can get absolutely burnt out on planning for lots and lots of different experiences and different kinds of needs for your mentees. And you can get absolutely burnt out on speaking about the different kinds of things that we've learned and trying to share this knowledge that there's lots and lots of things that these few designers within the open source software space doing mentoring can really struggle with or that can be really really difficult for them to maintain the energy for. And I just want to talk a little bit about some of the some of the things that I've done for these designers when they so a little bit about what I've been requested of and a little bit about what I think we need from design mentors as we grow the numbers of design mentors or people that are mentoring designers because you don't have to necessarily be a designer to be able to mentor designers. But these are some of the ways in which I've mentored designers so I kicked off discussion so so a lot of the time it's about bringing together designers and open source projects into that first discussion and it might be asynchronous it might be synchronous it might be a meeting it might be a discussion thread but some way of kicking off that discussion and being confident in kicking off that discussion so being able to open up that space. And that doesn't have that's not necessarily a design skill but it you know it can be somebody that something that any any position could do is kick off that discussion between the open source software and the designers. I facilitated workshops around design related topics but also just around like needs finding and needs gathering and actually trying to understand what what is wanted from a open source project which is a part of design. I've reviewed a lot of design works a lot of designers that have come up to me and asked for a quick look at what they've been doing for this open source project before they submit it just so that they get that little confidence boost from a peer. I've chatted a lot about what I understand from open source software history I didn't have the full in depth knowledge of everything that's happened but I definitely have my own perspective and I've done a whole heap of reading around open source software history so I talk about the history of open source software with designers. I've contributed with them so I've done work alongside them so design work or any kind of you know documentation that I've done so I've contributed alongside them to make sure that they've got a peer they're pairing with them essentially doing pair work. I've suggested a lot of structures and processes for the designers to review to think about and then pitch to the open source software project so this is a lot about design strategy. I've written a lot of issues for the designers to actually work on when a project has been like yeah we'd love to have somebody work on the design but we don't know what first is like we do that process of understanding and then I've written the issues for the designers. So I've written smaller pieces of work for designers to be able to work on and it also fits within the format of open source a lot of the time. I've helped submit PRs for from designers I've edited a lot of files and I formulated research documents oh there's loads more but these are just some of the ways in which I've worked alongside and alongside designers as they've gone through their experience contributing to open source software and been a very active mentor in that in that relationship. So as we round out the the talk time that we have about this quite complicated topic I would like to talk a little bit about how we might improve mentoring in open source software for designers. So I've got a few ideas about how we can actually improve this this process and how we can improve this. And I think the investment in existing open source software designers mentoring so they can do it as part of their roles if you have designers in your organizations. Hey how can you support them to do mentoring for other designers in open source are you allowing them to do it on their on their on their paid time. Are you allowing it to be part of their role if they wanted to be. There's a lot of you know things that we need to think about when we do come up with ideas so with this investment in designers doing mentoring. You can think about who does fund this and how. And for what amount of time and for what kinds of activities so it's really good to think about not just going hey we want you to mentor designers but maybe actually coming up with a real. Clear understanding of what kind of mentoring and what kind of activities both those entities want to do. Programs like Google Summer of Code and Outreachy and other fellowships and internships that focus more on open source software and design so design projects for these programs would be to see more. I've seen some over the years but to see more would be amazing and to even see a specific fellowship around designers in open source software would be fantastic and to see it well funded would be amazing and well supported. But again you know we've got questions around exactly who funds this and what kind of structure is actually needed for those designers in open source software. So in these other programs there's a lot of mentoring that happens a lot of resources that are internal to the the organizations pitching the projects. Do they have enough resources in order to mentor these designers on these design projects effectively and what would they need to be able to do that better or feel more comfortable. I would love to have more of the mentees mentoring a mentee so paying it forward once they feel comfortable to mentor. So I always do do my mentoring with the idea that hey one day you know these these designers can mentor other designers but when would a mentee feel ready to mentor and what if they really don't want to ever do a mentoring process and is this really an inclusive way of doing a mentoring process. I'm not quite sure but these are the questions that we need to ask when we think about mentees doing a mentoring process eventually within their journey. Resources and documentation and recording things so yeah this is the one that I consistently remind myself of that we don't necessarily do a lot of the documentation ourselves when we're doing the mentoring process. The mentoring is time consuming in and of itself and when do we get time to document so being able to give us more resources and more ability to document more clearly and more space and more encouragement to do our documentation will end up helping more designers in the long run. So as I run out of time just to say again that this is a you know a big topic and I'm completely out of time but I really would really like to continue the conversation if other people want to. So I've got a shared document a shared anonymous document on screen right now it's a bitly link. So the link is bit.ly slash O S D dash mentoring. So if you'd like to head on over to that URL there's a few question prompts in this open document and it's great for thinking about how you might want to participate in this this design mentoring aspect of open source and please join me if you feel comfortable and we can carry on the discussion there. Thank you.