 Hello, this is building on ramps to open source for non technical contributors. Thank you for coming to this talk on the last day y'all heroes My name is Celeste, I think quite a few of you already know me, but I go by she her pronouns If you don't I currently work as a developer educator at Ivan We do database and sort of Apache flink and Kafka as a service type stuff So you might be thinking why are you at the Linux Foundation conference and not an Apache one? It's because I actually got my start in open source with the CNCF with a role that I worked from 2022 about 2022 and There I got involved in the kubernetes project in stig docs I worked on the code of conduct committee I started a little thing called the inclusive naming initiative when I was there And I was always just sort of interested in open source. So when the opportunity Arrows to join the LF after I was looking for a new role. I jumped at it and it has been a Transformational experience in my career that I've been super super happy with And hi everyone, my name is Natalie. I also have she her pronouns. I am an open source person at Cisco And I'm also the kubernetes stig docs co-chair And also involved in a couple of sigs here and there as well for the kubernetes project Thank you firstly also for all of you being here. We absolutely expected to be speaking to a room of just our friends Yeah, it's really really great that you're all here And then how I got into open source a good friend of mine kind of knocked on my door and said hey I'm doing some kubernetes work and I've got some friends there who um who desperately need some help And let me know a couple of things that they were working on and then you'd help with it in my manager kind of brain went Oh, I know how to do these things and take some stuff off their plate And I was able to get involved in specifically in the seat in sig off to help them do a lot of really cool things around bug triage And organizing how we actually get help for big features what we call and kept so Kubernetes enhancement proposals so that we could actually get folks working on the things that they needed to be worked on so that We could push new features That was something that they were very very Appreciative of and now we actually to this day still do weekly bug triage and issue triage so that we can actually get things flowing throughout the SIG and I realized oh that's actually something that a lot of different projects like they need and so trying to kind of push That throughout the rest of not only kubernetes But other projects that I work with has been something that's fun for me because I find it Worthwhile and kind of easy for my own skill set. So I want to actually help others who think it's not easy for them So We've talked a little bit about how we got into open source And then the topic of today's talk is about getting non-technical contributors into your project I mean we want to basically like you know rep them and say that they rock and part of the reason is that you've got a Lot of maintainers in projects and this is specifically from the tidalist survey the maintainer survey You have a lot of projects who are asking who are kind of desperate for specific kinds of contributions that That you may kind of be surprised about they want issue and bug triage They want documentation and they want succession planning and they actually want a better contributor experience and all of those things are things that actually they can Possibly could do themselves, but they probably want to let go of and get those non-technical contributors involved in so that in their project They can focus on the things that are going to be worthwhile for for everyone so that they can scale Get new contributors in and be able to kind of build what they want to build So we're here to rip the non-technical contributors and we're going to show you the benefits of why having them in your project is worthwhile So I've raging AGC. I'm gonna need to talk over what's happening here. Just as an FYI So because I can't deal with this It is easier now than ever to be a non-code contributor I don't think it was always easy to be not a developer in open source projects But specifically with the sort of advent of easy and free to very cheap synchronous communication It's easier than ever for people who aren't developers to get involved in open source. So like now is your time There's nothing getting in your way The difficult parts of open source projects I think anybody who's a maintainer can really attest to this It's the code is I don't want to say easy, but the project and the people management is really really difficult for a lot of people And most importantly synchronous communication helps I think synchronous communication also really helps in the places that non-technical contributors can contribute really well in things like project management Things like succession planning, etc So let's talk about the on ramps. How do you get people involved? The first step is that you need to actually have that willingness to get those folks folks on board in the first place That's like a super prerequisite and by that we mean that you need to kind of be out there and making room for these non-technical contributors We often hear a lot of hey contributions welcome But then like nothing else afterwards about how you get involved what you actually need help with what the onboarding is kind of Be looking like as well. So like getting giving over autonomy of saying hey We need help with these things here They are and also you're gonna own them eventually is actually gonna get more folks wanting to get involved versus just the kind of Sometimes empty contributions welcome kind of flag that you see in a lot of projects and so for maintainers specifically Not only do you want to be having the prerequisite of accepting help, but you want to actually purposely tell your World out there where the help is required Yesenia in the talk yesterday around security research did this really well in their talk where they actually put a slide up and say Help us here and here and here and that was actually really awesome in terms of in terms of The security research that they're doing but a lot of projects will just need to kind of underline exactly where the help is needed And then get contributors in that space Oh, do you want to jump in? I was gonna say Natalie's gonna tweet the slide later that she's talking about You want to be able to in terms of the maintainers also like I said onboarding people being able to say hey I've got like 20 or 30 minutes. Here's the area that we want to actually get you involved in Here's a quicker on ramp into how that can work and also feel free to ask us questions, you know Make a misstep or two. That's totally fine. Those kind of talks I know it specifically in the inner source and open source 10 inclusive tips yesterday talk that we listened to that was another Point that was pointed out in terms of like buddying, which we will also talk about later And then for the new contributors you often will come into a project and think okay There's gonna be set processes and steps instructions of what I need to do wrong wrong You may have to make your own role You may have to jump in and say hey I need to use a little bit of my own acumen here and actually do things that art laid out art plan for me But I can kind of jump in and help when I can and you're gonna have to deal with processes that aren't designed for you But hopefully you'll be able to actually influence change and get those processes updated and adapted for later as the project is Growing and scaling in its contribution base and finally be willing to learn I feel like we probably all think that that's an obvious thing But a lot of folks again if they're figuring out that instructions aren't there they realize Oh, I have to jump in and actually learn something new I didn't realize that this wouldn't be a like step-by-step process. I'm just having that willingness is also super important So this is one of my favorite points to bring up when I talk about how to get people involved into open source in general Which is you don't have to onboard people to your project. You have to onboard them to open source Enterprise collaboration and the ways that we work sort of internally in product teams do not equal the ways that we work in Open source. They are completely different. They are flipped on their heads Approvals and escalations are completely different when you're in an enterprise particularly if you're working in an enterprise product team regardless of your role Approvals and what gets done and what who decides would get done Tends to come from the top down the company set priorities and the team sets priorities Then your manager sets priorities and then you go to a sprint and you get a ticket and it's completely topsy-turvy and open source, right? Anybody really can propose a change or open a PR and then it gets approved based on certain circumstances Based on people who have certain levels of trust Etc. Etc. And I think for those of us who are really involved in open source those of us who are working in ospos We tend to forget how foreign that is to people and I think when you're talking about non-technical contributors, especially Who have less exposure to open source processes to begin with? That is not something they're going to be familiar with and you're going to have to walk them through like how do you get something done? Or how does somebody get something done so that they can know how to contribute? Decision-making is different we touched on this briefly, but again like who approves what is not intuitive if you're not used to open source like I Think a lot of people in this room would feel very comfortable going into a github repo and looking for an owner's file or like looking at Who the active contributors are but that's not an intuitive thing and knowing what an owner's file is and what it signifies in the project Isn't an intuitive thing either so if you're looking to attract these contributors you have to really step it back and say What would somebody who knows nothing need to know about this? The sort of last point that I'll bring up which again is I think really really foreign for people who are not used to working in open Source is that everybody in open source is a community manager and a people manager on top of whatever else it is that they're doing for their real job and a lot of people are not used to that level of Dealing with total strangers and answering their questions and knowing how to sort of be polite and be of service To people who aren't there are immediate co-workers This is where sort of like in-house Company like ospo's that are getting people into open source can be really helpful because they can sort of handle through that process Because that can be really draining to somebody who is not used to it a Okay, so to the point and there's some lovely people in the room for this particular slide that I'll call out Writing the contribution docs can absolutely help your path along this So one of the most common pieces of feedback I gave to CNCF projects when I was working with them is When are your meetings? Do you have a public Google calendar with your meetings? What is your mailing lists? And how do you expect that people will know to join those mailing lists and to join those meetings and to join those office hours? If you aren't actually publishing them like on your website or in a contributing document And it was stunning how many projects did not actually get this until they were told if you don't tell people where to show up They will not show up It's very very simple And similarly if you don't tell people the ways in which they can contribute in very specific ways They will not contribute because nobody wants to break a code base. That isn't their own And nobody especially if you're non-technical wants to get involved in the code project if it isn't their own So some basic things again public communications and meetings where when where are you publishing them? How do decisions get made who decides whether something gets merged or not? Who decides whether a proposal gets to go through or not? Who gets to make a proposal to begin with? Writing things these things out is super important So big shout out to Steven Augustus because I think that the work that CIG release did on the release handbooks and all the Rules that CIG release and Kubernetes had were quite transformational in this regard And I think are like the aspirational goal for any large project that said if you're a smaller project a Contributing MD is a good place to start and we'll talk a bit more about that later And so another area that non-technical contributors can really shine is this idea of project management your project as Small or big as it's going to be especially as it's going to stay at scale as Celeste's just mentioning around meetings and so on you're going to need help organizing those meetings taking those meeting notes and Organizing the deliverables that come out of meetings, you know at work We have meetings then we probably hate them because work has to happen after that It's the same as an open-source project, you know And so being able to organize those deliverables and and delegate those kind of tasks is also something that a non-technical contributor can can jump in on process improvements We mentioned before they may have to get uncomfortable with processes that aren't designed for them They get to improve them now that they're involved in the project And that's something that can often take a long time because the communication overhead on boarding people to those new Things is also actually part of that job I mean they're finally moderation and community again everyone in an open-source project is doing that community management You can actually get one person to have that as part of their role shout out I've got some YouTube admins around here for the Kubernetes project that are doing a lot of that I know that that's also really important And so those kinds of roles are something that also non-technical contributors can come in and own owning that work is super important So that they feel that they really are part of that team And it's also okay to suck at project management. I who rock at it are telling you to suck at it You want to be thinking about what is the most impactful use of your time as a maintainer and whatever is not impactful Give the rest away get other people doing that work because there's probably someone better than you at it And someone who wants to contribute in that way because their skill set is a great match for it Get those people involved give them autonomy and give and give them that welcoming environment So you can be like hey, we're on this team together as peers and we're owning this project owning this work You're going to get so many contributors involved in that way and then finally on the enterprise side We want to be thinking about how can like an ordinary enterprise team in the roles in that team be possibly replicated in your project Do you have a product manager? Does your project need a product manager or do you have someone who is doing? Operations does your project need that to those kind of roles can be replicated in a way and then scaled as your project grows as well And it will grow if you're really really Invested in getting those non-technical contributors on board Finally, this is also one of my favorites. It's buddying up onboarding is easier with a friend Something that I think a lot of people forget is that most people are afraid to ask for other people's time Particularly if you're thinking about an open source project and there's like five Maintainers or there's like a tiny little steering committee or it's a project with only five people people don't ask for that time Because they know that these people are busy And where a really good mentoring program can help is by giving somebody a designated person to ask questions to and a designated Person whose time they can take there's like a sort of very implicit or explicit rather Permission they're saying yes, you can be a little bit annoying The other thing that a good mentorship program does is it makes it lets people form at least one strong bond in the project and fundamentally like Those interpersonal bonds are what will keep the project going a lot of people do this just because they like the people They work on the project with So an example of this is when Natalie joined the Kubernetes project. I was her mentor I don't think I was a particularly good mentor, but Natalie is still here Natalie is still here. Look at us. We're on stage now. It works people Another great example of this now that I'm a little more involved in Apache Foundation stuff is when a new project comes into the Apache Foundation They will assign a maintainer from one of the old and typically more successful Apache products Who stays with that project for a period of almost a year sometimes if not longer? And that one person's entire goal is to teach that new project how to become an Apache Foundation project And it's really effective and they have a very strong sort of culture Internally within Apache Foundation projects as a result Thanks, buddy The other thing that you'll need to be wary of is being flexible to project change And so again, it's a point that I am harping on a lot about but you know Processes that are designed for you are absolutely able to be changed once you're jumping on board If you're willing to get in and do that work as well Something that from the Kubernetes project given that we have a lot of experience there That is part of that is you know looking at processes that might not work for every role or contribution path like organization membership we actually recently updated that in the Kubernetes project where You know shout out to Sieg docs my own Sieg where we do a lot of localization work And we have the documentation available in 15 different languages We helped to update the organization membership process so that draft work on localizing docs of which There is a lot of minimum documentation required to localize before your language can even go live that can actually count towards your membership So already the work that you're push putting in for your specific language can then be recognized and rewarded with them that Organization membership and the permission to LGTM as much as you want You know with the cave it's there too The other thing too in terms of your project Flexibility is being able to allow folks to be human and have lives and then retire or unretire from their contribution role We see this a lot throughout a lot of projects where you know Main main maintainers need a break and hopefully they've got other maintainers who can come in and pick up the slack that they That needs to be there But you need to be able to let them to have a breather have a break now and then and then hopefully come back as well And that's something that again if you're advertising that openly then you're gonna have a lot more people a Choosing to go down that path and also be coming back as well So that's a really healthy way to keep your contribution Contributor path flowing and and a lot more diverse as well. And then finally change requests contain more than code improvements the cap I think Stephen has been called out once or twice in this talk already And so the Kubernetes Kubernetes enhancement proposal process is something that we had to bring in because features got complicated man It was very hard to organize a lot of this stuff And who says yes and no like we need to push away that proposals can actually come in and get a lot of different input And and feedback from a lot of different areas of the project because Kubernetes itself is freaking huge And so those the kinds of changes are actually super impactful And then you eventually I actually can't remember a world without caps now It's kind of kind of weird And so those kinds of things are huge improvements that now become part of the way that you work that help your project grow in scale Okay, so we have talked a lot about you know all the on ramps now We want to talk about like the benefits or that we've peppered some of that through and I'm gonna give it away to my body Hello All right, so the first benefit we want to talk about is less toil So this is another graphic from the title of survey that we really like And I'll point out the headline of it Which is that maintainers spend less than 25% of their time writing code and they spend a whole bunch of time doing all This other stuff, which is what toil is toil is the work that you don't necessarily Want to do but that you have to get done to get the other stuff done The lovely thing about this is if you really start to read into some of these boxes like bug reports and fixes proactively managing technical debt reviewing contributions documentation Guiding the project strategic direction all of these are roles that you probably know if you've worked in any sort of tech company For a while. These are technical writers. These are developers and sort of TPM types. These are project managers These are skill sets that people have specialized and these are things that people enjoy doing and they are probably better at it than you might be So when you kind of attract these contributors You have less toil individually as a developer maintainer And you probably have somebody who's a little bit better at doing those specific jobs Doing the job and helping the project forward The other sort of half of this is that like a lot of these jobs are fantastic First contributor type jobs things like meeting notes anybody can take meeting notes And it's a really low barrier way for people to get involved in a project in a way that's like not intimidating The next benefit is more stability you have a lot more contributors owning a lot of different array of things in your project In and creating that stability there So engine is more trust into the project itself Which means more exposure of your work and more adopters and users of the of the work that you're creating That stability is something that every open source project is really really hungry for getting to that stable Stable place and having a lot more folks attention on your work and the things that you're going to be planning for the future Trust as well in terms of the contributors who are working and the work that they own is also super important there So the trust is on the project as well as it on the contributor level But at the same time that means you know you got a lot of folks involved doing a lot of stuff And you need to be watching out for burnout. That's a super important Topic in open source at the moment. We also had a couple of talks focusing on it at the conference this week And it's something that you know, you can watch out for it And you know buddy up with someone and say hey I might be you know doing a bit more work here that then I should be or I need to get rid of this certain area of work That I'm doing help me unload this. Let's find someone who can who can help out Because if you're overburdened your project will suffer. That's absolutely the definite truth And so you need to help share the load and that means sometimes scarily trusting someone who maybe isn't You know a maintainer from day one to come in and help with your project as well And then finally the stability aspect comes from the diversity of contributors that you have from either different Organizations of different places in the world having Opinions that aren't from only one or two big organizations is really important in your project as you get bigger in scale Especially for open source where we you know, we have a few big plays We say okay, we care about open source and want to drive products in this direction But actually having feedback from a wide variety of users and adopters is really worthwhile and comes and brings more stability to that project as well And then finally more diversity more diversity to your project There's a there's a lot of studies we could cite that say diverse teams are actually More creative they bring more financial stability and and revenue They bring more actual creative direction and actual better features coming out There's so much research out there that says this so I didn't link any because I believe that you all believe me But basically folks from underrepresented backgrounds and we do mean diversity in that sense of the word in the sense of you Know different backgrounds different religions and different sexual orientations Different countries time zones, etc That kind of diversity is really important for your project because open source is global and very async So you want to represent that in your project. It is hard It is super hard to actually get diversity and projects in particular You have to be very purposeful about wanting that and putting those Inclusivity statements out there I'm learning a lot from the conference this week and going out there and actually saying we want people from time Zones that aren't ours. We want people from countries that aren't ours. We want people with you know Religions that aren't ours, etc. Though that's super super important so that you're getting that diversity of Feedback and information and also actually feature development also in your work from their different shared experiences. It's great So have that reflected in your project too So just as a sort of concluding note to this talk because I think a lot of people who are sitting in the audience might be thinking to themselves This all sounds great, but kubernetes has something like hundreds of active contributors thousands of one-time contributors and My project doesn't have the scale or the resources to deploy things like a kubernetes enhancement proposal Moreover that would be too much process for us. I Think the average size of CNCF projects that I worked with had maybe about five maintainers on average The two projects that I work with That I've been sponsors sort of on its own I think one of them has about three to five maintainers. I think the other has maybe six And I think tidelift I couldn't find the statistic for this slide But I think one of tidelist survey says that the the average is five and the mean or like the middle point is something like one So not looking great. You probably don't want to cap for a one-person project, right? So You can scale down all of this thinking is how I personally feel about it. So where kubernetes has things like role Documentation of like thou shalt do x y and z for a given release and thou shalt like Proceed in a certain way cats my light meat cats one of the release leads and is currently responsible for thou shalt You can scale that down to be contributing that MD and really like the most important things that you need to have Contributing MD are we are looking for these kinds of Proposals if you want to propose a new feature, this is what needs to happen either you just open a PR But like you explain yourself or etc. If you do propose something new and big Who needs to approve it and like how much? Like processes are going to be involved One of my favorite pieces of advice is a good first issue Which I think everybody knows is a tag that you can do for issues in github But I think a lot of people don't really put the work into these that's required because they are a fantastic tool if you put the work in It's not enough to say go fix this bug because again This is a code base that people don't necessarily know how to interact with And they're not going to go in to something that they might break because most people are nervous But working with a project manager for example and saying well What is the behavior of the bug and describing that in your issue and saying what would did behavior be if that bug was fixed and Describing that in the issue and then saying where do we think the the offending code lies and describing that an issue is a somewhere You can get a project manager involved. That's going to be really really helpful for you And be a way to actually lower the barrier really easily I Think the other thing too is that good first issues don't need to just be code issues They can be things like we need to write a contributing MD But again, you sort of need to you need to on ramp people into that by saying like well, okay We need to write a contributing MD. What do we think it needs to include these major points? Who's going to have the information in their brains about those major points? Well, it's this person this person and this person and how can you get in contact with them? Like what's the best way to actually interface with them? Well, you probably have to do this synchronously So you want to join our slack or our discord and then you want to set up some time with them and like maybe here are their time zones or Maybe discussed with them offline how they would like to communicate It's not it's not enough just to throw people at an issue and say goodbye. It's not gonna work A point I always like to make in every talk I make specifically around non-technical contributions is to think about hiring My role in the CNCF existed because the Kubernetes project sort of petitioned for technical writers They decided that they needed that support, but not every project is going to have the leverage to do that However, I think particularly when you're looking at things like documentation and things like project management you There is I think a lot of very obvious benefits to developers to doing open-source work off of the sides like There are obvious ways in which that benefits their career And then if they choose to get involved in open-source in more of a full-time capacity That's something that they can do like that's a path that they can take But those paths don't exist internally inside our companies for non-technical contributors So you have a two-fold problem, which is one you're not gonna have the time People aren't gonna want to dedicate their time to it if they're a project manager or technical writer because they won't understand The benefits because they don't see people like them getting benefits from those things And two you're not gonna really be able to attract those people to do it in their spare time Because they won't necessarily know that that's even an option Some of the most successful open-source projects Hired those non-technical contributors and staffed those roles. So the Kubernetes project for example staffed a Team of technical writers from its inception for quite a few years after At Ivan we staff all of our open-source projects with technical writers like That's not actually my role. My role is to talk about them Finally think about project velocity and merge policies People don't want to contribute to things that they think are maybe inactive Nobody wants to open a PR or contribute code if they don't think it's gonna get merged So I think one of the most effective things that smaller projects can do is set themselves a very strict SLA for first response To a new PR or to a new proposal or to a new issue And then particularly for PRs try and set themselves in SLA to merge or an SLA to at least like we can think about merge Because again like from when you think about it from the outside particularly for a smaller project Showing that that project is being actively maintained the easiest way to do that is gonna be through your commit log And it's gonna be very hard to attract any kind of contributor if people don't see the commit log moving Last point is think about making yourself available in real time This is a super low calorie way of doing things, but holding office hours like once a week It's one hour of your time and it gives people Synchronous time to actually talk with you about things and to ask those questions That would maybe become a little too long-winded and weird in like an email thread or in github, etc, etc, etc I will say this again people are afraid and people are afraid of people taking people's time But if you make yourself available, they will come they will absolutely come and ask questions So we've reached the end. Thanks so much for sticking it out with us We've got information on how you can find us in various online places We're also sticking around for another 10 minutes to answer questions But ask Celeste about Ivan ask me about Cisco or my shirt Yeah, questions about you should also stick around because Don Foster's talk is after this And this is a two-for-one deal. We're advertising together Yeah We have a question in the back. Do we have a mic around? For the recording we may want a microphone. I believe Just for all our virtual folks out there Hi, thank you for the great talk. I Comaintain an old product open source project Java native access It's been around for 20 years and has hundreds of contributors and it has absolutely zero friendly onboarding or any contributors that are non-technical and Has been a benevolent Dictatorship since forever now. It's on its fourth benevolent dictator. I Am not one of them So you talk a lot about the benefits but for a project like this that feels that everything is going great What are the drawbacks? That's that's a great question And I think one of the drawbacks is going to be that you have gonna have a lot of people Let's say in a project with a benevolent dictatorship. I really liked that you use that term That will mean that it's going to ruffle feathers in a way that actually causes a bit of instability Before some stability comes back like you may actually have to accept As a drawback that there are changes that will happen or some maintainers that maybe start maintaining less Due to some of these changes that are coming in because of the long-term goal actually is worthwhile So short term you might actually find yourself losing a benevolent dictator or two or at least maybe having the grasp like you know Be loosened which for a project that only knows that would cause instability So that is a drawback that I see but at the same time being able to kind of Come with suggestions of this project does something that I'm Requesting that we do and look at how it turned out for them like actual examples out there that you would like to like replicate I think that's a worthwhile way of showing that actually the drawback might be worthwhile Yeah, I would say that the major drawback is you could potentially start a war in the project Which would be non-beneficial to the actual maintenance of the project and like project culture especially in like very long-established projects is Very difficult to either course correct on or change. So you want to weigh the You want to weigh that scale Question down here in the front If we could get Mike passed down from the back folks, that'd be great. Thank you So you talked a little bit about saying yes to new contributors And I think in especially in the small project situation. Can you talk about how you navigate the conversation of saying no? I don't want to merge this. I don't want to do this or this is not effective for the project Yes, okay So I'm a really effective way to do this in the first place is actually to have a road map already so that you can actually Reference a lot of the plans that are coming in so that your know could be backed up by It actually doesn't fit here at this time or no For now, where can we fit this in in future and having a conversation where the no can actually still lead to some kind of Resolution somewhere that you and the contributor coming in could benefit from I can see one example of them coming and saying hey We need more meetings when actually you don't want that you have enough for example And you can say hey, maybe we can just increase the meeting we currently have in time What about that little things where like your suggestion is no but or no here's a possible other solution I think is a great way to introduce no into the kind of maintain a vocabulary Where contributors aren't going to be frightened away by any new suggestion that they have I Mean, I think the other way to do that too is to like really define what you want up front From contributions because if you say like we want somebody to help us with project management with backlog management We want somebody to help us triage our bugs and we want to make sure that those bugs are actually Getting resolved and we're keeping like velocity That's like a very defined set of things that you want and so if somebody comes in Out of the side and they're like I would like to automate tests for you. It's a little easier to say like It's not yeah, it sounds me like for whatever reason maybe you don't want it. I'm not gonna But like it's a little easier to say like yes at some point in the future but right now what we're trying to focus on is this and like Maybe if you start with this list of things that we really want you to help with and we get that Situation under control then we can talk about the thing you really want to do Yeah, it's not really a question but the moral statement that Thing I notice is that especially for smaller broad projects that have a strong technical background and their They're like people Contributing contributors have a strong technical background sometimes it's a chicken-ack problem with with Being able to attract other people that are not technical people Without being not technical is really hard for the project. Yeah Yeah, I agree, but at the same time I think often there's a lot of assumptions that non-technical people also won't understand which is actually a big misconception You can still have technical discussions where you don't have to dive deep into The specifics of a certain feature or thing that you're willing looking to do but understanding can actually often still be there And I think we have to be willing to have the conversations first and you try and that's where we why we Underline that willingness being key having that very technical contributor have the discussion and they may actually uncover like oh These non-technical contributors actually understand the general thing of what we need what we're building and how we can go about it Yeah, and I actually want to say that like in my experience working with like smaller projects One of the things that I saw most with those extremely small and fairly technical maintainers is that they didn't know what they didn't know So a part of my role at the CNCF was to come into projects and to do reviews with them on their documentation and say okay like One of the CNCFs I think project requirements for graduating up the pyramid is That your documentation is at a certain part and I would talk to these very like I'm actually thinking of the tremor project at Wayfair where Natalie used to be Where I remember coming into this project and they were delightful maintainers and they were super technical and tremor was a Super technical project and they had no idea how to do their documentation and they sort of kind of knew it But they also had no idea how to start and they didn't know how to ask for the kind of help that they needed because they didn't know What was wrong and so I think like Enabling Encounters and realistically the cup the people in the company that you work with are actually going to be some of your easiest people to access in those regards like talking to your project manager and saying hey We were managing this project. It's an open-source project and like we're looking to improve But we don't know what we're doing wrong And then having them come in and do a review of your process They will come up with some juicy things for you. I promise And it's the same with your sort of documentation people Having somebody who's really good at documentation Come in and take a look at your documentation. I promise you there are some glaringly bad things you're doing I enjoyed this. I like a good. I like a I like to rant a little bit. So like this is a real fun job for me And I promise you you'll you'll have a technical writer who will either have a good time or who will gain white hairs and get Really stressed. Both of those are good reactions. So I'm gonna say to Is it on? Oh, there you go. If I were to Walk away today like walk out into the hacker space or whatever and like start working on one of these things each From like each of you which one should I like go add to my project at any scale really? I? would make sure your People know how to contribute to your project and I would make sure that they knew how to talk to you Yeah, yeah, because one like advertising when do meetings happen? What are our slack or discord channels etc and advertising them not just in those places, but you need to go out and be like Hey other project that works together with us tell your users and adopters where to find us etc So like thinking about where else you can market yourself so that you're getting those contributors in Just a comment to to the question before because I saw more layers to To to this I call it unconscious gatekeeping when you just don't allow people in that don't have that technical understanding or something I was missing that on the on the diversity slide there Because you avoid Well unconscious discrimination as well Starting to bake into your product if you don't diversify that early in contributions All right, this is gonna be my last soapbox, but it's a very important soapbox I truly think that this is one of the most powerful things any Ospo can do in the companies that they work with is to break down that You have to be a developer to do open source mentality And get other people involved because it's like it's really hard when somebody's out there in the world And when they're dealing with literal strangers from the internet to be like I think it's so easy to put people down and just notice they like oh you wouldn't understand this like even with other Developers in open source. There's a bit of a power Dynamic there between the sort of people who maintain the project and like somebody who isn't a part of that core maintainer team Who's trying to contribute there's already a power dynamic and both of these people are quote-unquote tactical, right? I think Ospo's can be very very key in Teaching other people how to contribute and bringing in people that like for example your project might already know because they work with Them in other contexts and so there's already a bit of trust there And I think once you start to that culture when a project is really really small It's easier to maintain that culture. It's a little hard to course correct when when the horse is out of the gate No, just Thanks so much for coming everyone stick around for Dawn's talk and again come and ask us questions if you've got any more Thank you