Mentoring designers in open Source Software.
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Fox, Eriol
Designers are still relatively rare in the FL/OSS space and those that have been around and active are burning out and struggling to peer support each other effectively. I see mentoring designers, new to open source software as a key way in which we can make FLOSS sustainable generally and specifically for the designer community in FLOSS. In this session, I'll be outlining what I've observed and done as a 'mentor' in the FLOSS design space. What I've tried to do to support designers new to FLOSS in order to 'boost' our numbers actively contributing and keeping our community and OSS healthy. But there's plenty of ground unexplored here, which is why I'd like to spend half of the session actively workshopping via a shared etherpad document how we can mentor designers more sustainably withing FLOS. What is needed by those that want mentoring? What do FLOSS projects need support with? How can mentors share resources and processes? and likely, many more questions to collaboratively work on.
 Hi everyone, I am here to talk briefly about mentoring in open source software in a design capacity. You can access these slides and the notes within them at the link on the screen at the moment which is a notice link so if you go to https.dot.st forward slash e-r-i-o-l f-o-x you'll find a link to these slides and the notes. A little bit about myself before I launch into mentoring in open source software from a design point of view. I am Errol, my pronouns are they them, I've been working in design for about 10 years, I've been doing humanitarian third sector and charity work for around seven of those years both paid and unpaid and I've been working on and contributing to open source software for around three years now so relatively new in open source software terms. I am also working towards a PhD that explores the relationship between designers and humanitarian focused or for good open source software projects and how the designers engage with and participate in those open source software projects. I am currently working at the open food network which is an open source food platform for producers who make food to sell their produce and it aims to shorten the food supply chain with open source software but I also help out a lot of other different open source software projects such as Mutual Aid World, the Linux Public Health special interest group for design at the moment, very new, open source design and many, many more in lots of different ways both large and small. So the first thing that I'm going to say is really to address people that are listening that aren't necessarily from the design side of things but are from the open source software side of things and are looking to learn more about designers within open source software. I usually always cover this in my talks but and I always make a point to cover it in case people don't know which is designers really, really want to participate in open source software. They want to participate in lots of different kinds of open source software in many different ways. So the chances are if you're thinking my open source software won't attract designers, designers don't want to work on my open source software chances are there is a designer or many more designers that want to work on that project with you no matter what the nature of the open source software is. And to back this up not just from my own point of view I've got a couple of comments from people in the open source design community here. So this is a comment around how the designers within open source software see a place where they can learn, grow, collaborate and communicate within open source and contributing to it. So this is a comment from Franklin who is relatively new to open source. He says that he'll and they will have an opportunity to learn and collaborate and work with other designers within open source software and looking forward to that idea of collaboration, that idea of contributing as part of a collective in open source software. Not only with the designers but with anybody that works on the open source project. Another reason, another way that designers interpret their contributions or think about their contributions to open source software is that they see a space where they can openly centre human needs within technology. So it's a space where they can explore this need of centering the people that use the technology and practice skills and work with that topic. And to more clearly explain that, here's a comment from Florian who's a designer again relatively new to open source software, part of the Mutual Aid World Open Source Software project in the design team. And Florian says that open source software is part of our everyday lives. It deserves the same treatment that non open source software gets, which is a proper user-centred design process. So these are some of the reasons that designers want to be part of open source software. Many of the designers that are listening to this talk already know these things but it's always good to cover for those of you that aren't from the design side of things. So to move into the main part of this talk, which is briefly going to talk about mentoring designers in open source software and my observations and some of my learnings and some of my suggestions. These are some of the requests that I've had since speaking about designing an open source software spaces and being a designer in open source software spaces. Some of these are, can you review my article about design and open source and beginning to contribute to open source as a designer? Can we meet up and you tell me about designing in open source software generally? Can you tell me about the history? Can you tell me about the challenges? Can you tell me about the specifics that you've faced as in myself, faced within open source software and contributing to it and working with it? And then things like there's a project that I'd like to contribute to but I'm not quite sure how to start or more often I want to contribute to a project. Where do I start and how do I find a project to contribute to that I know that I'm really passionate about and invested in? And these are great. I'm not putting these up to boast. I'm not putting these up to complain. I love receiving these questions and it's one of the reasons why I speak a lot about design in open source in a lot of different spaces so that I can help those people, those designers understand what open source software is a little bit better and how to be involved. But this is quite a lot for just me and just the designers doing this kind of advocacy and mentoring work within open source software. So we need more open source software design mentors. But there are lots of different problems with this statement and the need and growing the designers in open source software that can mentor and it's something of a math problem to begin with. So prepare yourself for a really bad Venn diagram. And here we have a Venn diagram with designers with open source software experience on one side and designers that want to mentor on the other and the overlapping being a very rare unicorn. It's really hard to find designers that have both the experience with open source software and want to mentor because choosing to be a mentor is not a decision that people can make lightly and mentoring is very different for each mentor and mentee and takes different skills, resources and access. And to make this Venn diagram a little bit more complicated, here are some more factors that should be considered when thinking about increasing design mentoring in open source because it's not just wanting to do the mentoring and having the experience. It's sometimes about the time that you have to dedicate to that and the support that designers who want to mentor have the time to mentor and have experience to being supported by their workplaces which may or may not be open source software workplaces and being given access to resources in order to do that so that it's not in purely their volunteer time to mentor. So here we've got a silly Venn diagram with many overlapping aspects of what we need from design mentors or what we could need from design mentors and how rare they can be. But it's not just about the math, it's not just about how many of these designers that we have with these different aspects that we need in order to produce mentors, it's about the very diverse nature of open source software and that cookie cutter mentoring schemes and resources might not work. So even in my own experience there's an example of three different projects with three different ways of doing design, one very deep and intentional with lots of different research, one that's more about volunteer management and UI design and the other that's about advocacy, UI, UX, visual and QA processes for design. These three open source projects that I work on are very, very different and they use different skills but they also use very different processes and I need to know these processes really well in order to mentor designers within these projects that they may want to contribute to. And one of the really tricky things when you're in these spaces, in these different open source projects as a designer, you learn about these processes that might be good for one project and you might want to move it over and then you need to communicate it well. But really this is to illustrate the complexity, the uniqueness of many different open source software projects and how being an effective mentor might mean knowing these projects inside out and knowing their processes inside out and also how to improve them. So the last thing that I'm just going to cover today around needing more open source software design mentors is burnout. Burnout happens so frequently, so often in lots of different ways and for open source software design contributors it can happen in the terms of design, they can get burnout on design as a subject, on repeating the same info and not having time to build resources and build written documentation, on generally sharing their insights with other people and communicating those, on speaking about this topic, on planning for the mentoring and the growth of a mentee and also burnout on open source software in general which can happen in lots of different ways. These are some of the ways in that I've mentored designers. So I've kicked off discussions with the open source software team and facilitated those, I've done workshops, I've reviewed design mockups, I've chatted about the open source software history generally, contributed alongside the design designers that I'm mentoring, reviewed structures and processes they can introduce, suggested issues, helped submit PRs, edited files which were design files and formulate research documents with the designers that have contributed. So I want to now move in in the last few minutes just to sum up my ideas on how we can address this need of needing more design mentors and how might we improve mentoring in open source software for designers as well as increasing the amount of mentors that we have. And these are just my ideas, so they will be flawed ideas. So some of the things that I've been thinking about were investment in existing open source software designers, so designers that are currently in open source software doing more mentoring and the investment of their time into mentoring as part of their role, so they can do it as part of their role. So mentoring becomes an aspect of the work that they do in open source. But the flaws are who would fund this and how and for what amount of time and for what kinds of activities, what kind of definition does this need to be given. And the second idea that I have is around programs like Google Summer of Code and Outreachy which already are creating internships around designers in the open source space and creating projects for designers, but how about some new fellowships that focus on mentoring in open source software design. So with this, with the Outreachies and with the Google Summer of Codes, how are the people, the designers applying for these internships being mentored as part of those and how can we create these new fellowships potentially that focus on supporting those designers there. But again, who funds this? What kind of structure is needed for both the designers and the open source software? The next one is a common thing within these kinds of structures like open source software structures. It's an idea of paying it forward. So mentees mentor a mentee. They pay it forward. So once they've reached a certain stage in their process of being mentored, they pay it forward by doing some mentoring themselves for a new open source designer or an existing one. But the flaws are here. When does a mentee feel ready to mentor and what if they don't want to? And is this an inclusive way of doing mentoring and does it only focus on the privileged few that are able to do mentoring that have access to resources, time, stability and those kinds of things. And the next one and the last one of this very short talk is resources and documentation and recording. And this is something that comes up all the time when I think about a new part of open source software as a designer. And really the flaw of this is doing the mentoring, taking the time to mentor is time consuming, it's hard. And getting the time to document, build resources and record things is a lot of time and effort as well. So when do we find the time to do the process of building our resources? So the last thing that I want to talk about at the end of this talk, really covering mentoring in open source software design very briefly is I'd like to invite you to collaborate on some of these questions, some of these ideas, some of these things that have been risen in a document that I've created. So the link on the screen at the moment will take you to an open collaborative etherpad document with some questions and some space for writing and collaboration. And the URL is http.dot.fordsash.by.ly. Fordsash.o s d dash mentoring. M e n t o r i n g. In there you'll find questions such as as a person being mentored, otherwise known as a mentee, what do you need and value in this mentoring relationship? And as a floss project or open source software project, what kind of support do you need when you have designers in your project that want guidance and or mentoring? And questions like how long should mentoring last? And how long do you want to be mentored for and mentoring another? And one of my personal favorites and I'm most curious about the what unique challenges do your open source software projects or open source software projects in general have when mentoring is involved? And how many of these challenges can apply to design? So with that, please take a look at the collaborative documents, spend some time in there, I'll be writing some ideas and writing some further thoughts in that document throughout the the FOSSTEM event. And the last thing I'd like to say is thank you for listening. And you can find me on the internet on these links on the screen. Errol does design on many different platforms. So come and have a conversation about mentoring designers in open source software with me. Thank you.
 Hi everyone, I am here to talk briefly about mentoring in open source software in a design  capacity. You can access these slides and the notes within them at the link on the screen  at the moment which is a notice link so if you go to https.dot.st forward slash e-r-i-o-l  f-o-x you'll find a link to these slides and the notes. A little bit about myself before  I launch into mentoring in open source software from a design point of view. I am Errol, my  pronouns are they them, I've been working in design for about 10 years, I've been doing  humanitarian third sector and charity work for around seven of those years both paid  and unpaid and I've been working on and contributing to open source software for around three years  now so relatively new in open source software terms. I am also working towards a PhD that  explores the relationship between designers and humanitarian focused or for good open  source software projects and how the designers engage with and participate in those open  source software projects. I am currently working at the open food network which is an open  source food platform for producers who make food to sell their produce and it aims to  shorten the food supply chain with open source software but I also help out a lot of other  different open source software projects such as Mutual Aid World, the Linux Public Health  special interest group for design at the moment, very new, open source design and many, many  more in lots of different ways both large and small. So the first thing that I'm going  to say is really to address people that are listening that aren't necessarily from the  design side of things but are from the open source software side of things and are looking  to learn more about designers within open source software. I usually always cover this  in my talks but and I always make a point to cover it in case people don't know which  is designers really, really want to participate in open source software. They want to participate  in lots of different kinds of open source software in many different ways. So the chances  are if you're thinking my open source software won't attract designers, designers don't want  to work on my open source software chances are there is a designer or many more designers  that want to work on that project with you no matter what the nature of the open source  software is. And to back this up not just from my own point of view I've got a couple  of comments from people in the open source design community here. So this is a comment  around how the designers within open source software see a place where they can learn,  grow, collaborate and communicate within open source and contributing to it. So this is  a comment from Franklin who is relatively new to open source. He says that he'll and  they will have an opportunity to learn and collaborate and work with other designers  within open source software and looking forward to that idea of collaboration, that idea of  contributing as part of a collective in open source software. Not only with the designers  but with anybody that works on the open source project. Another reason, another way that  designers interpret their contributions or think about their contributions to open source  software is that they see a space where they can openly centre human needs within technology.  So it's a space where they can explore this need of centering the people that use the  technology and practice skills and work with that topic. And to more clearly explain that,  here's a comment from Florian who's a designer again relatively new to open source software,  part of the Mutual Aid World Open Source Software project in the design team. And Florian says  that open source software is part of our everyday lives. It deserves the same treatment that  non open source software gets, which is a proper user-centred design process. So these are some  of the reasons that designers want to be part of open source software. Many of the designers  that are listening to this talk already know these things but it's always good to cover  for those of you that aren't from the design side of things. So to move into the main part  of this talk, which is briefly going to talk about mentoring designers in open source software  and my observations and some of my learnings and some of my suggestions. These are some  of the requests that I've had since speaking about designing an open source software spaces  and being a designer in open source software spaces. Some of these are, can you review  my article about design and open source and beginning to contribute to open source as  a designer? Can we meet up and you tell me about designing in open source software generally?  Can you tell me about the history? Can you tell me about the challenges? Can you tell  me about the specifics that you've faced as in myself, faced within open source software  and contributing to it and working with it? And then things like there's a project that  I'd like to contribute to but I'm not quite sure how to start or more often I want to  contribute to a project. Where do I start and how do I find a project to contribute to  that I know that I'm really passionate about and invested in? And these are great. I'm  not putting these up to boast. I'm not putting these up to complain. I love receiving these  questions and it's one of the reasons why I speak a lot about design in open source  in a lot of different spaces so that I can help those people, those designers understand  what open source software is a little bit better and how to be involved. But this is  quite a lot for just me and just the designers doing this kind of advocacy and mentoring  work within open source software. So we need more open source software design mentors.  But there are lots of different problems with this statement and the need and growing the  designers in open source software that can mentor and it's something of a math problem  to begin with. So prepare yourself for a really bad Venn diagram. And here we have a Venn  diagram with designers with open source software experience on one side and designers that  want to mentor on the other and the overlapping being a very rare unicorn. It's really hard  to find designers that have both the experience with open source software and want to mentor  because choosing to be a mentor is not a decision that people can make lightly and mentoring  is very different for each mentor and mentee and takes different skills, resources and  access. And to make this Venn diagram a little bit more complicated, here are some more factors  that should be considered when thinking about increasing design mentoring in open source  because it's not just wanting to do the mentoring and having the experience. It's sometimes  about the time that you have to dedicate to that and the support that designers who want  to mentor have the time to mentor and have experience to being supported by their workplaces  which may or may not be open source software workplaces and being given access to resources  in order to do that so that it's not in purely their volunteer time to mentor. So here we've  got a silly Venn diagram with many overlapping aspects of what we need from design mentors  or what we could need from design mentors and how rare they can be. But it's not just  about the math, it's not just about how many of these designers that we have with these  different aspects that we need in order to produce mentors, it's about the very diverse  nature of open source software and that cookie cutter mentoring schemes and resources might  not work. So even in my own experience there's an example of three different projects with  three different ways of doing design, one very deep and intentional with lots of different  research, one that's more about volunteer management and UI design and the other that's  about advocacy, UI, UX, visual and QA processes for design. These three open source projects  that I work on are very, very different and they use different skills but they also use  very different processes and I need to know these processes really well in order to mentor  designers within these projects that they may want to contribute to. And one of the  really tricky things when you're in these spaces, in these different open source projects  as a designer, you learn about these processes that might be good for one project and you  might want to move it over and then you need to communicate it well. But really this is  to illustrate the complexity, the uniqueness of many different open source software projects  and how being an effective mentor might mean knowing these projects inside out and knowing  their processes inside out and also how to improve them. So the last thing that I'm just  going to cover today around needing more open source software design mentors is burnout.  Burnout happens so frequently, so often in lots of different ways and for open source  software design contributors it can happen in the terms of design, they can get burnout  on design as a subject, on repeating the same info and not having time to build resources  and build written documentation, on generally sharing their insights with other people and  communicating those, on speaking about this topic, on planning for the mentoring and the  growth of a mentee and also burnout on open source software in general which can happen  in lots of different ways. These are some of the ways in that I've  mentored designers. So I've kicked off discussions with the open source software team and facilitated  those, I've done workshops, I've reviewed design mockups, I've chatted about the open  source software history generally, contributed alongside the design designers that I'm mentoring,  reviewed structures and processes they can introduce, suggested issues, helped submit  PRs, edited files which were design files and formulate research documents with the  designers that have contributed. So I want to now move in in the last few  minutes just to sum up my ideas on how we can address this need of needing more design  mentors and how might we improve mentoring in open source software for designers as well  as increasing the amount of mentors that we have.  And these are just my ideas, so they will be flawed ideas. So some of the things that  I've been thinking about were investment in existing open source software designers,  so designers that are currently in open source software doing more mentoring and the investment  of their time into mentoring as part of their role, so they can do it as part of their role.  So mentoring becomes an aspect of the work that they do in open source. But the flaws  are who would fund this and how and for what amount of time and for what kinds of activities,  what kind of definition does this need to be given.  And the second idea that I have is around programs like Google Summer of Code and Outreachy  which already are creating internships around designers in the open source space and creating  projects for designers, but how about some new fellowships that focus on mentoring in  open source software design. So with this, with the Outreachies and with the Google Summer  of Codes, how are the people, the designers applying for these internships being mentored  as part of those and how can we create these new fellowships potentially that focus on  supporting those designers there.  But again, who funds this? What kind of structure is needed for both the designers and the open  source software?  The next one is a common thing within these kinds of structures like open source software  structures. It's an idea of paying it forward. So mentees mentor a mentee. They pay it forward.  So once they've reached a certain stage in their process of being mentored, they pay  it forward by doing some mentoring themselves for a new open source designer or an existing  one. But the flaws are here. When does a mentee feel ready to mentor and what if they  don't want to? And is this an inclusive way of doing mentoring and does it only focus  on the privileged few that are able to do mentoring that have access to resources, time,  stability and those kinds of things.  And the next one and the last one of this very short talk is resources and documentation  and recording. And this is something that comes up all the time when I think about a  new part of open source software as a designer. And really the flaw of this is doing the mentoring,  taking the time to mentor is time consuming, it's hard. And getting the time to document,  build resources and record things is a lot of time and effort as well. So when do we  find the time to do the process of building our resources?  So the last thing that I want to talk about at the end of this talk, really covering mentoring  in open source software design very briefly is I'd like to invite you to collaborate on  some of these questions, some of these ideas, some of these things that have been risen in  a document that I've created. So the link on the screen at the moment will take you to  an open collaborative etherpad document with some questions and some space for writing  and collaboration. And the URL is http.dot.fordsash.by.ly. Fordsash.o s d dash mentoring. M e n t  o r i n g. In there you'll find questions such as as a person being mentored, otherwise  known as a mentee, what do you need and value in this mentoring relationship? And as a floss  project or open source software project, what kind of support do you need when you have  designers in your project that want guidance and or mentoring? And questions like how long  should mentoring last? And how long do you want to be mentored for and mentoring another?  And one of my personal favorites and I'm most curious about the what unique challenges do  your open source software projects or open source software projects in general have when  mentoring is involved? And how many of these challenges can apply to design? So with that,  please take a look at the collaborative documents, spend some time in there, I'll be writing some  ideas and writing some further thoughts in that document throughout the the FOSSTEM event.  And the last thing I'd like to say is thank you for listening. And you can find me on  the internet on these links on the screen. Errol does design on many different platforms.  So come and have a conversation about mentoring designers in open source software with me.  Thank you.
mentoring_designers_in_open_source_software_0_179.png mentoring_designers_in_open_source_software_180_947.png mentoring_designers_in_open_source_software_948_2999.png mentoring_designers_in_open_source_software_3000_4247.png mentoring_designers_in_open_source_software_4248_4727.png mentoring_designers_in_open_source_software_4728_5435.png mentoring_designers_in_open_source_software_5436_6059.png mentoring_designers_in_open_source_software_6060_7019.png mentoring_designers_in_open_source_software_7020_7319.png mentoring_designers_in_open_source_software_7320_9419.png mentoring_designers_in_open_source_software_9420_9551.png mentoring_designers_in_open_source_software_9552_9935.png mentoring_designers_in_open_source_software_9936_10751.png mentoring_designers_in_open_source_software_10752_12191.png mentoring_designers_in_open_source_software_12192_12647.png mentoring_designers_in_open_source_software_12648_13295.png mentoring_designers_in_open_source_software_13296_14471.png mentoring_designers_in_open_source_software_14472_14771.png mentoring_designers_in_open_source_software_14772_15623.png mentoring_designers_in_open_source_software_15624_16607.png mentoring_designers_in_open_source_software_16608_16979.png mentoring_designers_in_open_source_software_16980_17087.png mentoring_designers_in_open_source_software_17088_17915.png mentoring_designers_in_open_source_software_17916_19055.png mentoring_designers_in_open_source_software_19056_20207.png mentoring_designers_in_open_source_software_20208_21119.png mentoring_designers_in_open_source_software_21120_22271.png mentoring_designers_in_open_source_software_22272_22799.png mentoring_designers_in_open_source_software_22800_23843.png mentoring_designers_in_open_source_software_23844_24239.png mentoring_designers_in_open_source_software_24240_24527.png mentoring_designers_in_open_source_software_24528_24646.png