 Good. So for those who don't know, all the faces here other than me are very prominent people in the community. You should be knowing them already. But Justin is open source advisor at Vinicef. He's been doing a lot of things in Federa for many, many years. He was founding member of PEI in Comops and so many things. I said quick introduction. So many things to pick from. Marie is our Federa community accident impact coordinator. She works on a lot of things in the community but also leads DEI and design side of things. Sumonthro has been a Federa Kiwi member who was also the one to introduce me to Federa long time. And you would have seen him sending emails a lot around test days and things. But he would also be doing Google summer of port side of mentorship or GADMIN since 2018 if I'm not wrong. And Ankur has started neuro Federa join. He was a package that has been around for almost a decade, maybe more than a decade. I don't know. It's been a long, long, more than a decade. Exactly. And Ankur has been mentoring a lot of people every day as part of not just neuro Federa but Federa join. Which we all point to whenever someone new comes. I'm really interested in hearing all of your perspective. So why don't we go around and you tell us about yourself a little bit. I would start with Justin since I see him on my left hand side, the first person here. Yeah, thanks. So my name is Justin. I've been involved with Federa since probably 2015. I guess my mentorship journey. So inside Federa, I was originally a GSOC 2016 student when I was 18 or 19. I was an outreach mentor in 2019 for the Federa happiness packets project. And then I've just been various connected to various different mentoring and initiatives throughout Federa like comm ops where we've spent a lot of time thinking about mentorship as well. Outside Federa, I've also done been more involved with mentorship on doing student programs at my former university where we had a really big open source community there. And I also do mentorship as a job these days. What I do in my role is I actually work with different startup companies from around the world that are building open source tech and I teach them and provide mentorship on open source best practices licenses and legal. A lot of things that I've actually learned from being around in Federa. So I'll go ahead and pass it over to Sumantro. So thanks Justin. First of all, you know, most of the stuff is available. Nothing much to add there. I joined as a contributor back in 16. I was like, I would look up to uncle Justin, many other books, Matthew, specifically, read on five things about what's going on. Things have changed a long since then. Now, now I'm moving some of these things. But yeah, I, as a part of my data of my host test days, I take charge of the Federa for the best side of things. And so, you know, testing most of these things and working towards making Federa more stable or commercial. I also kind of run a lot of right known kind of test cases for different packages, which we introduced to Federa. So something new in norm comes. I usually go out and write some of these test cases based on common runs. I used to do a lot of cheese hot stuff, which has not been happening now with a lot of COVID and Federa not being there as a part of our unfortunately. But yeah, the idea here is to, you know, take the mentorship skills and still try to fit in to multiple brands as well. So I collaborate mostly with the public. I used to do a lot of these things with X or VR. And currently I'm reading this objective with Murray and Mariana for the community outreach repair. Where they go around trying to fix the industry program that we teach everyday for the industry program. We had a nice one about it yesterday. Any other speaker who is over here, if you want to join me, who can put a recording for me? That's all about me. I'm going to pass it down to... Thanks, Sumato. Yeah, as Vipul said, I've been around for a while. And I wouldn't be here if I hadn't been mentored when I started. So other folks that have been around for a while would have heard of Kushaldas and Rahul Sundaram. These are all people that work for Red Hat. And they were extremely active in the federal industry side of things. And a lot of us started because they held tutorials and workshops regularly. And they were always there to mentor us. And that's how so many of us are still around, because they didn't just teach us the skills. They taught us how to be part of the community. They also organized food con and pune, you know, the food con days, which you don't have anymore. And that's how Matthew just noted that Rahul and Kushal also came from community parts, which is true. And yeah, so basically they didn't just teach us all the tech bits about Fedora, but they taught us the importance of community and the importance of sharing all the knowledge you gain. And I guess that's why I end up on all of these forums just randomly answering questions here and asking questions here and there. Unfortunately, my day job now is not very closely related to software development and now work in academia. So it's a lot of science. Yeah, and the time is short in academia. I think everybody knows it will be underpaid and overworked. And that does apply in my job also. But the good thing is that my job has a massive open science component. And the whole idea of having your Fedora was to try and find something common between my Fedora family and work. So that, you know, I could do something that sort of benefited both. Yeah, so, yeah, looking forward to speaking to all of you about all your experiences. And I'm sure I'll learn something from everybody. Marie, I guess you're the next one. Thanks. Hi, I'm Marie Norden. I am Fedora's Community Action and Impact Coordinator. And I could say without a doubt I wouldn't be here without being mentored in the Fedora community. So had a huge impact on my life and kind of where I went with my career. But since then I've also started to be a mentor and I've mentored through the outreach program. I think I'm in my fourth session of mentoring and they've all been graphic design, whether it's for the outreach revamp or we did a Fedora's Dean. And this time around we're revamping the badge artwork. So a lot of fun brand type stuff for Fedora, which I always feel like we're lacking. So I love to put some energy and time into that area. And yeah, otherwise I do badges, I've done badges for a very long time. And as FK, I'm pretty much all over on the mind share side of Fedora, helping and supporting everything on that side of the teams, but then just in general doing events and budget stuff and all kinds of logistics for the community. Great. Okay, thank you. I can hear you now. My mic was showing off. I guess it's not a good day for me with Hopin. So we were just in Mike's keynote and he was talking about how what mentorship is and how it benefits others. Continuing on that conversation I want to ask, what are some common misconceptions about mentorships? And how can we combat those? It's about mentoring or being mentored. What are the expectations that usually people have? Is there anything that jumps out to you? These are very generic misconceptions about that. I have one. And with mentoring, I mean, I had this before I started mentoring. And my misconception was, and this is because I've seen people ment in different ways. And my misconception was that mentoring is a passive process, where it is pretty much responding to queries. So people ask you, send you emails or ask you questions, and your job is to answer questions. And then at some point I started teaching a little bit and then I've done outreach previously. I've done Google Summer of Code previously. I'm doing outreach again, not with Fedora from work, on both sides of the fence here. But what I realized was that mentoring is a very active process, where you have to ask all your candidates how they're doing, how they're feeling, are the tasks good enough do we need to scale back the difficulty of tasks or increase difficulty, that kind of thing. So it's not just about waiting for all your candidates to reach out to you. You need to actively reach out to them. And it also works in a way to make sure that they are actually actively working on things. And if they have questions, they know that you're always there for them. Yeah, so my misconception was that it's a passive process. It really isn't. It needs to be an active process, and the mentor needs to put aside time and resources to make sure that they can reach out regularly to all their candidates and see how they're doing. That was my one. I'll think of more. I'm sure I have many. That's the first one. And that's a very good one. I can relate to that. I have been mentored and even I have been, when I go into some of the conversations, a lot of the time I do not have agendas or I just go into those thinking I'll be told something which is not exactly the right way to do that as Mike was telling earlier in the keynote. So that was my misconception that we'll figure out together what to work on. It should also come from mentee and what would they like to say. Do we have anyone else who would like to share something? So I had a problem. So first of all, I think, you know, when I looked at mentorship previously, there was one of these very usual factors is if it is easy for me, it is easy to do almost anything. That's a very unconscious bias that comes into picture when everyone, you know, back in the day when all this was happening. If I can do this under one and a half hour, this should be easily done by anybody in one and a half hour. That's not actually what we were expecting to do. While you were deciding on deadlines, so we used to decide those deadlines for GSOC cutouts, weekly cutouts for what we were supposed to do. And, you know, setting some of these hard deadlines just because it's delivery was not actually a very good precedent to set the deadline. So that's one of my learnings when it came to, you know, okay, everyone has their own way of doing things, navigating things, and that should be respected. Also, terms that come with, you know, a lot of accessibility factors. So I am someone who is, who supports time go from an ancient deficit sort of problem. So I can understand when somebody comes to me and says, hey, can you keep this thing for two and a half hours? That's not making it. I would probably take that two and a half hours into multiple chunks and do it. So, you know, having accessibility in mind when you are mentoring is one of those very key things you can do to make your mentee's life much easier. So it's also, it comes attached with the process and it also comes attached with the explanation. So that, those are the key things that I thought was very easy to do. But then when I got getting things done, I got it from them. That's the question. I have something to add here. He's? Yeah. So I guess, I'm not sure I have this misconception, but I think it might be a common one, is that mentorship is a one-on, it needs to be a one-on-one situation. And it really doesn't. Group mentorship is a great way to approach this. And it takes some of the pressure off of like all one person, you know, always needing to be there in the channel, always needing to be able to respond. So, you know, co-mentoring in a very official capacity is great, but like if you look at the joint dig, we have just a group of people who are ready to support like 24 hours a day. So that's a great example of how group mentorship works, and it works for Fedora. Yeah. Justin? Yeah, and just to build on that, I think like was mentioned in Mike's keynote, you know, there's different kinds of mentorship and what misconceptions or best practices make sense for one type of mentorship might not make sense for another one. Like say, if you're mentoring someone on their career, which is kind of a much more personal mentorship versus like I'm working with this person on a project together and I'm kind of like mentoring them on this technical task. So I think looking at it from the Fedora context, I think one of the misconceptions that I sometimes have noticed, I think on that project side of mentorship is, you know, that there's one way of doing things that there's a certain fixed direction you have to go, but I think really keeping it flexible, both as a mentor and the perspective of being flexible and easy, quick to adapt and make changes as needed, but also with the mentee making sure that they can, if you're working on a project and you have goals together that you're having that open communication and making sure that it's meeting the needs of the mentee, but also making sure that you can sustain the mentorship as the mentor. That's amazing. And I remember Sumantra was talking about communication and you mentioned sustainability of contributors. So we'll come back to both of them. I wanted to ask each one of you, what is your preferred way of communication to your mentees? We'll start with Sumantra again. Sorry, uncle again. If it's Fedora work, I default to open. So we almost didn't have any private communication, any private emails. Everything happened, for example, for the first round of our teaching, we had a ticket on the near Fedora bagger instance and all our communications happened through that. So every week, we would decide what tasks we were going to do that week and at the end of the week, we would review these. Everything including blog posts, troubleshooting, everything happened on the ticket. And of course, for synchronous communication, we had the near Fedora channel. And as Marie said, the advantage of this was that it wasn't just me answering questions. So all the package maintainers that are part of the near Fedora SIG were always replying and helping out in the channel. And especially in the, now this is a little specific to our treaty and may not apply to all mentoring, well, projects, but our treaty initially, we tend to get a lot of candidates. So for near Fedora, we had almost 40 candidates, unfortunately for only one position. But the good thing was because we mentored them as a community, they helped each other. There was so much discussion between candidates helping themselves out. So we were scrolling up and down the chat logs because they were running into similar issues, so they could just go back and see what was going on. And even though we only took on one candidate, we actually had four people who got sponsored to the package maintainers team as part of this outreach. So we did everything in the open, no private communication. And that way, not only does the near Fedora team know what's going on, anybody who wants to see what's going on just goes to the ticket or goes to the chat channel and they'll see all of our outreach candidates just actively going package A, package B, put a request here. It is really, really nice to do it that way. Sumanthu. So, yeah, exactly like Uncle said, I defect to open, but then I have, I kind of profiled a lot of candidates. So when I look at my 90s and I'm kind of sure these are going to be topical, I would probably go ahead and ask them how do they feel. So if they're like three time zones away and probably have a very bad internet connection and horrible restrictions and if they use the work laptop or incognito mode or something like that. In that case, I would probably ask them to reach out or whatever they have or something like that. Just to help them out with regular communication so that they don't have to go through the whole process of setting up new end software is just to communicate with them. That's the problem. But yeah, in most of the cases, government agencies play a great part in mentoring which also means the faster you reply, the more attention span you have and the mind shape you have. But then it's as a project in Fedora, whenever I look at somebody who has to work with Shreddy and three or four other teams, then I would probably ask this one person to reach out to four other people either on a public list or directly on a public platform and then establish a laptop before getting neckdip inside something. That has been my motto, my mode of telling people how to get started. Thank you. I like a hybrid approach. I actually really enjoy video calls with my mentees. I do establish, you can chat me if you want once the intern has been chosen through Outreachy but everything I do at the beginning is in the channel there's a lot of common questions. So we keep that whole application period right there in the channel. Then otherwise I kind of personalize the approach just to mattress that and I ask them, what's the best fit for you? I've had people not prefer to do video calls. I'll join and do audio but I don't like sharing my video and that's totally fine. I think that the video call really brings a personal connection between you and the mentee and allows you to build the relationship. Also with some of the work that I do, it's less code repo based work and it's design and a lot of it, there's a lot of right answers. So I want to help my mentee find their right answer. So oftentimes that means giving demos. And taking some of that time on a video call to really get into how do I use this tool in Inkscape and I'll also watch them work in Inkscape and say, hey, did you know you could do the shortcut or this is actually going to be a much simpler way to approach the problem you're looking at or just really link down to the basics of working with vector graphics. So I like the video chats but I also tailor to each intern or each mentee. I definitely relate to that. I have also felt a lot of the times on video calls or when you are meeting a little bit more privately, you tend to feel more connected to people and default to Open Inkscape obviously because it helps so many people but sometimes I would also prefer to connect more with my mentees just also looking from the sustainable perspective of them in long term. But Justin, what do you think? Yeah, I kind of feel like there's three parts I feel for this question and kind of prefacing like specific tools I think around communication in general, the best communication is the one that happens. One of the biggest misconceptions that I see around interns or around internships in general or mentorship is being afraid to ask that question or that the mentor is going to be really busy or I always try to break that misconception or just try to make sure that there's an open, safe, comfortable environment where people can ask questions and get that clarity they need to be successful in their own work. So I really try to encourage that, I think kind of building on that piece around open communication in public groups and public chats that can really help with that if you have a community and a bit of an active chat there. But for me and my own mentorships, I kind of split it up between formal and informal ways of engagement. So when I'm working with someone more formally like on a project or something that's kind of more tied to work, that might look like having daily standups just over a text message or a chat, maybe having weekly video calls to check in because I do agree kind of building out what Marie said. I do think that's a really important part for getting that connection. And then I also put spreadsheets because I think spreadsheets are almost like one kind of love language, especially in project management and mentorship is it can just help keep some kind of clarity or whether it's a project board or spreadsheet, but just having some kind of organization to keep things on track and make sure that you and your mentee are consistently going through things together and reviewing things that need to be worked on. But more informally, it could just be chat, it could be video, it could be a Twitter message, it could be LinkedIn, things communication can happen in all kind of different places. And I think on part, one part is meeting people where they're at and trying to help bring them into the fold. So sometimes you might have to do a little bit of one-on-one chat because sometimes people are more comfortable in that way, but ultimately trying to bring them into the fold of the community too. But I think kind of the essence of the question, it's about communication method. I think open communication is good and mentorship doesn't have to happen within a project or with a direct colleague of yours, and that can change what that pace of mentorship might look like. So if you're working with someone more regularly, maybe that's a daily check-in that you're chatting with them on video or on call or on text. But if it's something a little less formal or maybe on a different direction than say a project you're both immediately working on, you can find a pace that works best for you. Like maybe it's a monthly check-in chat or just emailing back and forth here and there. But I think the key thing is that the pace is always going to be contextual but just make sure that you're keeping that spark alive between mentor and mentee. Thank you. Great answers and I'm loving it. Now I wanted to jump into some of your personal experiences. Do you remember a specific experience during your mentorship duration where you wished you had done something differently? Or if you had to do it over, how would you do it differently? We are not going to follow the same pattern here. Whoever wants to speak first can go. So, yeah. So everything. Back in the days, I used to mentor people about how to mentor. And previously, when I used to mentor, there used to be a guidebook where I used to guide how most of these things fit into the equation. And that used to be crazy fun because you get to smell nice markers after the end of the day. But jokes aside, back in the day, there was a certain speed that I used to play. And again, that came from the bias that if I can go at this speed and cover XYZ, PQRs, things under three days, four days, seven months, it should be a very easy thing to grab. And that's not always, that wasn't always the point. The other thing is mentorship for me was always like, if people have taught me something, then I need to give this back to them. That used to be a thing back in the mind when I was doing it. So a lot of times I used to, what happened was when I used to put a lot of important people in the room or others, some of them might be in the room and I don't personally enjoy mentoring them because I am doing it because I think I'm giving back to them. And I used to rush through things and that's not ideally the best way to get things done. Now, if I were to do it opposite, now do it. I probably spent an awful lot of time understanding my mentors. What are their final goals with it? Exactly like Mike said, at least try to understand what your mentors' final goals are. Don't try to put decisions on them or take decisions from them. So because writing a shell script for you probably is like the two-minute task when you do them, you cripple them out of their choice or their journey to write their first shell script out there. And that's not a very good thing. So if I were to actually go about remendering some of these people, I would give them the liberty to write awful wrong things, whatever they felt like, just to profile them for good sometimes and tell them, you won't even go here. There are multiple ways to go there, not just one. And I would give them that choice to choose their choice one. That would be the remodeling. But this time I would be focusing more on how they would try to reach it rather than the clear vision that I have in my brain to push them towards it. So that's one remodeling. I wish I could tend to back in four years for the other people, for thousands of people that I haven't mentored. So yeah. Thank you. Anyone else? So I think I have one here. It's important to get on the same page with your team before you start mentoring someone in that team. Just to make sure, like they're prepared and they know that people are coming. Without Regi specifically, it's a huge influx of people. And if everyone isn't prepared for that, that can be very disconcerting for other folks on your team. So I think one time I really was not as clear as I should have been. This is about to happen. People are like, what's happened? There's all these people here. So it wasn't necessarily related to that person's work. It was something we were doing kind of separately. So it just didn't, you know, it was one of those things like, man, I really probably should have had a talk. You know, we're going to be using this channel. So just making sure that other people are aware of what you're doing in the project. This one's not mine personally, but one that I've seen happen is kind of building off what Sumatra said is, basically thinking that the interns are going to get through more than they are. Writing out too much work for a three-month internship, because it's really, at least the first month is just them figuring things out. And then it's like the second and third month when they truly become productive and you can actually be like, look how far you've come and they feel it too. But trying to put too much down for the project is maybe one of our shortcomings in Fedora, right? Like we say, hey, I know we had the badges back in intern once. And like, I could not find out what that person did or how it translated to the website. And so I think, you know, maybe there was just too much in that scope. I can follow on that too. Just thinking of one thing that happened in 2019 with the Fedora internship. So I guess the high-level piece here is just on mentor to mentor communication and networking. So in 2019, we had Outreachy and GSOC projects. And that year we actually had selected for one of the internships, the same person for a GSOC and an Outreachy internship. And we were like, oh wait, and then we had to go back and like go through things and we had to kind of go back to the organizations about how we were going to select the interns. But, you know, I think that point of that was that both among mentors, we always weren't coordinating or synced up with each other. But more generally, I think being able to have that mentor-to-mentor networking and just connections and check-ins, that's really helpful to build those feedback loops out between mentors. And I see it both from a logistics point of view that like, you know, you're having different people participating in both projects. And you should probably be on the same page about your selections for the project in a larger community. But also, looking at common tools and approaches that the mentors can share, I think that's probably one of the, and this isn't just in Fedora, but in a lot of communities I see this, that when you have more of a sustained networking program, just making sure that as the mentors, you're building out common resources or tools so that you can be more consistent and standard on certain approaches. Like say, how do you bring someone into the Fedora community, making sure all the mentors have the same general processes for that. So everyone's more aligned and using the same information and the same resources. So we're all steering someone in the right direction. So I think that's probably one of the biggest areas and we've been making a lot of strides in that direction too. Like I think this mentor summit is a really awesome example of that, of really trying to bring mentors and folks who are doing this kind of work together and have these conversations. But I think that's a really important part and I see this becoming more and more important also outside of a Fedora context. So I guess just really making sure that in a mentorship program that your mentors are actually talking with each other and that they're working on solving common problems based on whatever's going on in the organization or for the projects over. So listening to everyone on, from what I get the most out of it is scoping the project is one of the very important things and that also contains mentors talking to each other and defining exactly what their project is. As Murray was saying, conflicting answers can often confuse people. This is a very open-ended question and from what I'm taking from this specific thing is to find some resources on how can I guide mentors to scope projects better as someone who is doing mentorship projects in Fedora project, right? But from your experiences of mentorship, what are some of the things you follow to scope a project well? Well, the way we did it was we tried to break, I mean, luckily our project is it's packaging, right? It's lots of small tasks rather than one massive task and the way we tried to do it was we tried to break all of these tasks down into the smallest possible tasks that can be done and that way we were able to spread out individual tasks over the complete period, right? So, I mean, packaging a software can sometimes take two days, sometimes it can take four weeks, but there are multiple steps doing it and the way we assigned tasks, well, the way we agreed on tasks with our candidates was to say this stage of this task is missing and if you can do that, then that's a successful week and only then do we think about next stage. So we tried to break it down into small bits. We did not have a list of tasks that must be completed. We just had lots of tasks and we said just keep going through them as you will and the number of tasks that you've completed is not a metric you're going to use to decide whether or not your candidate period was successful or not, right? So we completely did not take that metric into account. We didn't actually have a metric. The way I did it with Vanessa was did she think she was getting work done? She thinks she was learning and of course with the package review process I tried my best to push them into requesting reviews from people who were not me. So go and reach out to other package maintainers from the community and get them to review and that way all of this stuff was already being checked in the standard peer review fashioned by everybody else. So try and break it down into small tasks. Scoping the project is very, very hard. So it helped me not overestimate the amount of work that can be done in a week because these are small tasks. So I think that had worked quite well for me. But yeah, I mean that caveats to all of this. If a task is too small and the candidate doesn't think that they're being given a task of sufficient complexity then you know then sometimes the confidence can it's a constant back and forth between communication is key before setting tasks on a every scale. So ideally when a task is being decided or any milestone is taken upon three factors. The first thing is usually an idea with all the resources of the online and community by your side. What is the ideal time to get this particular next task is going to be? The first factor, the second factor is always the impact of the project. So how much part of actual work have to be able to complete if you were able to nail down the first 10 tasks? It's like writing the question paper with the questions having the most number of marks first so that you know you have answered the most. You have nailed down most of the people correct. That's the way that I would put it. It's a twisted exam analogy that we have people might relate. That's the way. The second thing and third thing is obviously going to be more about how can you go about finding resources. One thing that I have found out over time is there are too many resources and too many options are confusing. Giving them a pool of free resources by your mentor always helps because the mentor speaks the same dingo as the mentee and they kind of know what exact thing they are talking about. So when I say watch this video, read this article, practice and look at this code and if the mentee has done that sequentially I probably know exactly where they are going to get stuck and if they are not going to get stuck what else can be These are the three usual ways that I look about when I define a task or whatever. Anything that requires two hours I usually take it like should take at least six hours the pressure every mentee is in. One thing that we almost forget is when we do our days out as mentors we forget that mentees are under a lot of pressure to kind of prove that they can do something and that pressure keeps building up if they start failing on the deadlines and that's one thing that's one thing that I keep in mind when I design tasks that they have they have a time they can go back and fix it and they end up the project Looking at that time I want us to move a little because I have a few interesting questions that I want to ask just for myself and learn about it and also in the end if we have more questions for others I can try to go quick I can try to go quick I have a few points so when I look at these design projects which sometimes are big projects or cluster of small projects I have my like base minimum and then I have a bunch of extras that aren't necessarily out there it's not something intern even knows that I have ready to go but I have it just it depends on how quickly they learn and just presenting that first task and like saying okay now we're going to move to the next and if they're prolific and they're just like getting here all this stuff I have a bunch of stuff ready to go that I've already thought about and said this is the bonus work that can happen if we get to that point I think the other thing that I like to just point out and have people think about is for me yes I have the goal of getting this task done but I have other goals and my other goals are one the intern get something out of it so that's really important you want them to have a positive experience but number two that they have an amazing experience with the Fedora community so I want the mentorship and all of that to feel so welcoming and positive for them that they want to stay involved in Fedora and they want to continue to hang out and see the value in it and because they've gotten something rewarding out of it I'm going to stop there to keep it brief Justin would you like to add something Justin I was asking you if you would like to add something me unmute I think you're with us now yeah now you're unmuted I can hear you now well maybe let's move to the next question yes let's move to the next question this is a pretty difficult question because I'm asking on the face what are some of the bottlenecks in our current way of mentoring what are some of the things in Fedora project we can improve right now Marie why don't you say yes so I think it might be just not knowing that it's an option and not knowing that like most people can do this with some small amount of training and I think what adds to that is the time commitment people are afraid that this is going to take too much time and that it's all going to be on them right so we talked about co-mentoring as an option which is great so there's less pressure on you so I think letting people know that this can happen but I think it takes a little bit even more of a personalized approach like actually thinking about who would be a good mentor who might be a good fit for this and talking with them one on one about their doubts about their fears about why they can't do it and helping them to break through those and come up with some solutions to move past it so that's kind of my thought yeah anyone else what are the bottlenecks or challenges we have right now or how can we improve our mentorship in the Fedora project just in one I think one one way to do that is very nicely incentivize and reward the mentors for spending their time with mentors one thing that we essentially have not done before is we have gamified incentivized people over the board across everything except mentors and we have relied on the fact that Google does that for Google mentor summit and the only problem that mentor summit previously GCI was the same was Google in 80% of the times had already two slots for mentors and only 1% of people right and Fedora would not have a project for them and most of our very important mentors in fact Daniel Welch mentor for Fedora once it would be nice to have him grab power that's one thing I think would be a good scheme we can do that's true I guess also a lot about how mentors see the reward mechanism what works for them I was talking to Pingu yesterday and he was mentioning how at this point in his life in his career he shouldn't say swag or a trip because his family he may not want to travel with all these things that's not necessarily the reward he's looking at and he's doing it because he's at the point in his career where he would like to help out and he was saying because I was talking to him something similar I was discussing the panel discussion and he said if you are early in your career and you are mentoring then your reward is that you get to talk about it you get to talk about you learn how to mentor but yes after this question I would definitely like to jump back on some of the reward ways and mechanism and how to incentivize mentors but focusing on this current question because I do want to identify certain pain points in our current way of mentoring what everyone else thinks here I can build on that thinking of some bottlenecks that I've seen in Fedora mentorship I kind of more broadly do here three common threads which is one I think something we've kind of talked about a lot on and off throughout this panel but being in silos that networking and that connection making sure that your mentorship isn't happening in a pressure cooker isolated from the rest of the project I think is really important another one that I mentioned previously was just on having more mentor to mentor networking and connections but my last one is also I think especially on the sustainability factor like being able to have a graceful exit or having permission to leave I think that's something that people really love to be in the project and be involved and sometimes it's just there's life happens, things change you have a family so I think always being able to give people that option to have that graceful exit just like we do in other parts of the project too with mentorship I think is really important for the reward mechanism of mentorship I think maybe there's some things that can be pulled out here too but I see it kind of as some intrinsic ones but also on the career side like on the intrinsic side you get to have that option to really work with someone and empower another person in their own journey whether that's for a career or for personal growth whatever kind of direction it is and also you gain a new perspective to some kind of work like you know especially when you're in a project like Matthew said earlier Fedora's been around for 20 years when you've been in that mix for even just a couple years you start to see things in a different way so having someone who's a total newcomer and hasn't seen these kind of things before that's a really helpful perspective and lastly I'll try to leave some room for everyone else to come in here but there's three things that I was thinking about that we could do to better attract mentors and Fedora is one is around acknowledgement and recognition which I think ties into some of Marie's work around the rise initiative but really being able to acknowledge the work that mentors do and provide some kind of acknowledgement or endorsement of their participation with the community in this way second is community and connection just making sure that we're building that community of mentors and mentees like this mentor summit I think is a great example and then finally just continuing to foster mentor-mentee interactions like at previous flocks you know we'd have meet and greets for the interns or there'd be the internship presentation panel and even candy swaps I remember people talking like when you do those at flocks people bring candy from all over the world and we swap them with each other people actually have a lot of really great interactions and get to know people in a different way there than just like here's the project and see that we're working on and this is more to the community than that so I see those three things as ways that would help us attract more mentors in Fedora and yes the poll the Swedish candies are everyone has to try those everyone it's an experience uncle I just wanted to before going on next question I wanted to hear your thoughts well I think I think I'll just be echoing what everybody else has said but yeah I think mentoring as a community as opposed to individuals would be would be very very nice and I think we are moving in that direction because I think we do now channel all our catalysts to the Fedora joint process and everybody has a welcome to Fedora ticket so they by default get lots of people answering questions and helping them out but it will be good if we can encourage more community members to just be involved right I mean don't become they don't have to become a mentor officially as the central point of contact but just keeping an eye on these tickets and helping people out so that a as people have said it takes the pressure off the primary mentor and the co-mentor but it also helps integrate the candidate better with the whole community right they're not always talking to the same two people so yeah I think we are we are moving in that direction because we are I mean if anybody goes to the welcome to Fedora Pager project I'll drop a link you'll see that for candidates we now have a tag that says mentoring which clearly says that all of these people are interested in Outreachy or Google Summer of Colors on and so forth so if you can subscribe to that just you'll get notifications and be simple questions if you're a community member you will usually know the answer just help people out I think that would be a good way of going about it we have three minutes and I have sorry suddenly my inter so I was saying I didn't scope this panel discussion very well I have way too many questions prepared and two minutes time I wanted to ask is there anything we are leaving out that needs to be addressed right now to everyone so I think you're asking in context of Fedora specific mentorship programs sure if that's what you want to talk about I just want to ask you did you have any expectation from this panel discussion that we are leaving out which would be have been very important I think this is interesting as a participant so this has been an interesting conversation I think just my closing thought is that mentorship is always a journey and that it's something that there's no one size fits all approach and I think just keeping that in mind as we continue to work on some of these ways to improve our mentorship approach will be really helpful for our own mentorship program but also for Fedora more widely as a project in community over I guess I'd just like to see some of these ideas and conversations translated into some process improvements or updates for our mentorship program for our documentation so I love this conversation and I think it would be helpful for more folks than who are just here with us today to hear some of us and see it for our own community Perfect, thank you very much we are out of the time unfortunately out of love to keep going