Building On-Ramps for Non-Code Contributors in Open Source
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 60 | |
| Author | ||
| License | CC Attribution 3.0 Unported: 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. | |
| Identifiers | 10.5446/66657 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Berlin Buzzwords 20238 / 60
5
12
20
23
33
34
35
46
49
00:00
Open sourceNormal (geometry)Lattice (order)CodeSoftware developerMusical ensembleSoftware developerTheory of relativityOpen sourcePhysical systemPoint cloudNP-hardService (economics)DatabaseStandard deviationMereologyDirection (geometry)NeuroinformatikDiagramLecture/ConferenceMeeting/Interview
01:36
Open sourceSoftware bugLattice (order)Software engineeringDisk read-and-write headData managementOpen sourceTerm (mathematics)AuthorizationMoment (mathematics)Video gameMereologyGroup actionProjective planePoint cloudSoftware bugWeb-DesignerStrategy gameOffice suiteComputer programmingWeb 2.0Lecture/Conference
03:19
Data managementTerm (mathematics)Projective planeArchaeological field surveySoftware maintenanceTouchscreenCodeOpen sourceMultiplication signMappingLecture/ConferenceMeeting/InterviewComputer animation
04:32
VideoconferencingOpen sourceMereologyTelecommunicationCodeData managementCASE <Informatik>VideoconferencingElectronic mailing listTelecommunicationQuicksortSoftware developerSoftwareProjective planeOpen sourceMetropolitan area networkData conversionRevision controlLecture/Conference
05:44
MathematicsGroup actionCodeSoftware developerTerm (mathematics)BitKey (cryptography)Online helpVideo gameSoftware maintenanceMultilaterationData managementTelecommunicationMereologyLattice (order)Group actionProjective planeIntelligent NetworkProcess (computing)NumberCycle (graph theory)Collaborationism2 (number)Inheritance (object-oriented programming)Lecture/ConferenceComputer animation
08:12
Open sourceEnterprise architectureCollaborationismDecision theoryProjective planeOpen source2 (number)Different (Kate Ryan album)Point (geometry)Slide ruleFrame problemChainSoftwareQuicksortCodeDecision theoryKey (cryptography)Inheritance (object-oriented programming)Data managementProduct (business)Computer programmingZoom lensLattice (order)Open setTelecommunicationObject (grammar)Electronic mailing listEmailLevel (video gaming)CollaborationismCycle (graph theory)Enterprise architectureMereologyProcess (computing)Group actionAreaStudent's t-testSoftware engineering1 (number)Lecture/ConferenceComputer animation
13:15
Data managementProcess (computing)Enterprise architectureProjective planeSystem callData managementOpen sourceMultiplication signProcess (computing)Group actionAreaInternet forumEnterprise architectureMessage passingLattice (order)Term (mathematics)Structural loadShared memoryProduct (business)Different (Kate Ryan album)Lecture/Conference
15:00
Data conversionOpen sourceNP-hardMereologyOpen setProjective planeForm (programming)Multiplication signFreewareHeat transferSoftware maintenanceSystem callSoftware bugData managementPhysical systemTerm (mathematics)AreaRevision controlLecture/ConferenceComputer animation
16:38
CodeElement (mathematics)Self-organizationAreaTerm (mathematics)Process (computing)Rule of inferenceSelf-organizationDifferent (Kate Ryan album)Element (mathematics)Multiplication signConsistencyMereologyOrder (biology)Projective planeCodeMathematicsOpen setCommitment schemePerformance appraisalEvent horizonPrandtl numberPoint cloudLecture/ConferenceComputer animation
19:29
CodeType theoryEvent horizonReading (process)Software maintenanceOpen sourceDisk read-and-write headInformationArchaeological field surveyWritingEntire functionPoint (geometry)QuicksortMathematicsLattice (order)SoftwareMultiplication signConnectivity (graph theory)Event horizonProjective planeType theoryLecture/ConferenceComputer animation
21:01
Open sourceStability theoryVariety (linguistics)Term (mathematics)Projective planeStability theoryPhysical systemReal-time operating systemFocus (optics)MereologyFactory (trading post)Scaling (geometry)Self-organizationStructural loadFlagSoftware maintenanceEvent horizonOpen sourceSoftware bugGroup actionInformation securityEnterprise architectureInformationVariety (linguistics)Shared memoryDivisorLecture/ConferenceComputer animation
24:00
Open sourceDifferent (Kate Ryan album)LengthSystem callDescriptive statisticsProjective planeProcess (computing)Image resolutionOpen sourcePhysical lawLecture/Conference
25:48
Descriptive statisticsBookmark (World Wide Web)Projective planeBlock (periodic table)FluxOpen sourceCuboidLine (geometry)BitSoftware maintenanceSpherical capTouchscreenOpen setLecture/Conference
27:17
VelocityPower (physics)Data managementComputer programmingSelf-organizationSoftware developerDifferent (Kate Ryan album)VelocityForceRule of inferenceMultiplication signOpen sourceProjective planeContext awarenessSoftware bugData conversionDot productMathematicsDependent and independent variablesSubsetInternetworkingOffice suiteLevel (video gaming)QuicksortReal-time operating systemPrandtl numberFront and back endsCuboidFluxNP-hardComputer animationLecture/Conference
30:08
TwitterHand fan2 (number)HypermediaOpen sourceProjective planePattern recognitionInheritance (object-oriented programming)Computer animationLecture/Conference
30:48
Celestial sphereTwitterExecution unitTerm (mathematics)Scaling (geometry)Group actionOpen sourceBitMetropolitan area networkSlide rulePattern recognitionToken ringOpen setLecture/ConferenceMeeting/Interview
32:03
Software developerEuler anglesPower (physics)Dependent and independent variablesProjective planeBitOpen sourceMeeting/InterviewLecture/Conference
32:38
TwitterLevel (video gaming)Computing platformProjective planeData conversionTerm (mathematics)Similarity (geometry)Group actionData managementField (computer science)Meeting/InterviewLecture/Conference
33:48
Maxima and minimaMereologyPresentation of a groupProjective planeBitLecture/Conference
34:26
QuicksortWordInclusion mapData managementComputer programmingLattice (order)Open sourceBitDependent and independent variablesAreaGroup actionProcess (computing)Lecture/ConferenceMeeting/Interview
35:59
Artificial neural networkConsistencyTelecommunicationGroup actionLattice (order)MereologyProjective planeTerm (mathematics)Lecture/Conference
37:17
Insertion lossMembrane keyboardMultiplication signSlide rulePresentation of a groupOnline helpMessage passingSoftware engineeringProcess (computing)CodeShift operatorSoftwareLecture/Conference
38:08
Pointer (computer programming)Multiplication signInformationValidity (statistics)Virtual machineCodeSoftwareCycle (graph theory)Video gameUniverse (mathematics)Message passingBitLecture/Conference
39:21
BuildingProcess (computing)Slide ruleMessage passingSoftware developerSoftware bugTraffic reportingProjective planeSet (mathematics)Direction (geometry)Theory of relativityPrincipal idealData managementLecture/ConferenceMeeting/Interview
40:05
Insertion lossMultiplication signGenderArithmetic progressionMereologyPhysical systemLecture/Conference
40:44
IcosahedronOpen sourceGroup actionConformal mapGenderProjective planeDisk read-and-write headTerm (mathematics)Physical systemMultiplication signMereologyLine (geometry)Inclusion mapOnline helpType theorySystem callParity (mathematics)Lecture/ConferenceMeeting/Interview
43:18
Musical ensembleDiagram
Transcript: English(auto-generated)
00:07
Hello, everybody. This is building on-ramps to open source for non-technical contributors. Hello, my name is Celeste Horgan. My pronouns are she, her.
00:21
I'm a developer educator on Ivan's developer relations team, and we are an open source data streaming and database company. We do that as a service for you if you don't want to deal with your own. My investment in open source is prior to working at Ivan, I worked at the Linux Foundation on their cloud native computing foundation projects for about two years, helping projects
00:45
large and small with their documentation, developer experience, and effectively how do we do the hard parts of open source. So I got into open source because I was always interested in it. I thought the idea of an open source operating system like Linux was just the coolest thing
01:01
ever when I encountered it as a teenager, and I was kind of always looking for an opportunity in my career to get into it because I just thought it was so cool that so many people could come together somewhat randomly and make something that actually works and has actual utility, so my entry into open source wasn't super normal in that I had kind
01:20
of direct sponsorship from the Linux Foundation to do the work that I'm doing, very much not the standard for open source contributors, but I stuck around, and now it's kind of a defining career thing for me where I only really like to work for companies that have heavy investments in open source. And hi everyone, my name is Natalie Vlatko, my pronouns are she, her also, and I'm currently
01:43
fun employed, up until recently I was the senior software engineering manager and head of the open source program office at Wayfair, and we were a team of engineers that basically shaped the open source strategy and general project work that we're doing upstream specifically in cloud native, and I'm also currently the co-chair for the special interest group
02:04
of documentation for the Kubernetes project, I share that role with many other folks, Ray Lohano and Divya Mohan as well, and I'm also sometimes involved in the authorizations special interest group as well, as part of the Kubernetes project, we're doing intros on how we got into open source, I am aging myself right now, but I grew up with GeoCities,
02:23
if anyone out there knows that, and so a lot of my getting into open source was actually a lot of it through web development, and generally being interested in wanting to tinker in various projects, I got introduced to some folks in Kubernetes and was able to start being involved this way, there was a really cool bug triage project that I helped
02:42
out with SigAuth to actually help them get organized in terms of what should you be prioritizing and working on in terms of their authorization work, and that really got me started in the Kubernetes world, it's also something that in terms of being able to choose to explore deeper, we'll go into this later, but something where open source for me was
03:02
something that I could kind of choose to come and go as I please, as long as I'm communicating that intent, and so this is something that I found really inspiring in terms of how I could use that to my advantage in terms of what was going on in my life and my employment at the moment as I take the summer off.
03:21
Alright, and so our talk as you may know is specifically focused on non-code contributors, given that Celeste and I are two of those, I sometimes code, but I'm a manager now so we know that doesn't happen anymore, and so with that we wanted to focus on specifically why we think non-code contributors are so great. In this specific graphic that you
03:44
can see on the screen, we lifted this from Tidelift, their maintainer survey, the top three in the question of what do you need the most help with in your project, the top three are docs, they are the user and contributor experience, and they are also
04:00
specifically triaging in terms of issues and PRs and general road mapping of what you should be working on, and the reason that we think non-code contributors rock is those are three things that non-code contributors can help you with today, right now in your projects in the work that you're doing, and it's something that hopefully throughout the rest of this talk we're going to help you understand how you can define and open up to getting
04:21
those non-code contributors coming in and helping your project work on things where you're using your time impactfully and they're able to get that intro into open source that they so desperately are looking for. So luckily for you, we are both of the opinion that it's easier now than ever to be a
04:44
old school Apache committers, sorry for calling you old school man, but some older sort of contributors to open source, and when you look at sort of traditional open source contribution methods, it's very mailing list focused, there's a lot of like
05:02
really arcane version control systems, and if you aren't like a really dedicated developer, it's really hard to break into, it's very arcane, and that's not really the case anymore, and I think one of the ways in which the Kubernetes project was so successful was adopting modern communication techniques, it's easier than ever to be synchronous with people across global and
05:24
distributed teams using things like slack and video calls, it's easier than ever to collaborate on software in the open with places like GitLab and GitHub being so readily available and readily free, so now is your opportunity, I guess is what I'm saying, and there's no reason to sort of cling to old methodologies in 2023, so let's talk about it, how do you get people involved
05:48
if they aren't developers? So I mentioned this a little bit earlier in terms of defining help, and generally how you get people involved is being willing to accept the help is really the
06:00
key here, and that willingness needs to actually come with intent and communication, and so what we wanted to really underline here in this kind of prerequisite step is that in a project you need to kind of own that non-code contributions are worthwhile, and they're worthwhile of giving someone autonomy and ownership over those contributions as well, if we treat project
06:21
management, meetings, note-taking, all the things that aren't code as second best, then it's going to be really hard to get worthwhile contributors and worthwhile contributions around those parts into your project, and so autonomy and ownership is really super key, Celeste will come over this a little bit later, but there's probably a lot of things in your
06:41
project you hate doing, that's going to be a really great marker of things that you can likely give away, and so for project maintainers we wanted to highlight that accepting help and as I've underlined defining where you need it is really going to be really important, this idea of contributions welcome and then there's like silence because no one knows where they
07:01
should start contributing or where they can start to help can kind of always catch you in terms of that contribution life cycle, so defining where you need it is really really key here, being open to changing processes or ownership groups once those contributions come in so that you can get that contribution life cycle kick-started, and onboarding people, we will go
07:21
into this a little bit later, but onboarding is super important, the definition of that is going to be completely up to you depending on your projects and scope, but onboarding even if it's just an introductory meeting it will work wonders. In terms of new contributors out there, number one is you need to be making your own role, you're not going to get everything spoon fed to you as you've just heard, we are just telling maintainers how to even help you in the
07:43
first place, so really being open to making your own role and dealing with processes that aren't designed for you is going to be something that you should come in expecting, but also being willing to learn, learn not necessarily specifically the ins and outs of the project which is kind of the first part, but more so learning about how you're working with others, how
08:03
these certain maintainers kind of communication hours work and how they best want to communicate with you and vice versa, little things like that are going to make collaboration really successful. Thank you, so I'm realizing that we maybe didn't make this clear in our introduction, so I'm going to step back for a second. Natalie and I, as you may have intuited, both met and were
08:23
large contributors to the Kubernetes project, which is a fairly large open source project within the Linux Foundation, and those two pieces of framing are key, especially as we get into this next slide of onboarding to people to open source. So something that I noticed very often when working with CNCF community projects and with
08:45
Kubernetes specifically is that it's not necessarily the work of the project that's hard, particularly for people who work in software. When you really get down to it, it's making software and we've all done that and we all sort of kind of know how to do it. One of the hardest parts is onboarding to open source itself. Enterprise collaboration and
09:04
the ways you work in an enterprise software team do not equal the ways that you work and collaborate in open source. The biggest one I can think of is that approvals and escalations are very different. They're typically made by consensus and very often by lazy consensus, so if nobody says no, we're going to do it this way. Another example of that is that
09:25
decision making is different. Typically when you're working in enterprise, you can kind of escalate up the chain if nobody knows what they're doing, and the unfortunate reality of open source but also the deep freeing reality of open source is that the escalation point is you
09:42
need to figure out what you want to do on your own. So the most important piece of advice that I have for onboarding non-technical contributors is that you would need to reframe how they work. More so than software engineers, I think, because I think software engineers come in expecting it to be a little bit different,
10:01
but when you're talking about program managers or product managers or documentation people, the idea of not having an escalation path is really, really hard to wrap your head around until you experience it, so setting aside some basics of how open source works is super important. Second point, everybody in open source is a community manager on top of the other thing
10:22
that they do, and I think this is the other sort of key point to underscore about open source collaboration is there's always a community management aspect of it, and developing those skills is really important because you are ultimately interfacing with random people on the internet, and that requires a certain level of people skills that you simply won't acquire
10:43
otherwise. Oh, this one's asking me. So on that note, one of the best ways that we like is writing the contribution docs. This is super, super important. This was the most common piece of advice I gave to the CNCF's 144 projects, which is if you don't tell people where and how
11:01
to get involved, they will not show up because they will not know where to go. It seems really obvious it is not every single project I work with I gave this piece of advice. Public communications, where are they? How are you doing it? At the CNCF, it was very common to have open community meetings via Slack or via Zoom. The Apache Foundation does most of its
11:24
work via mailing lists. How do decisions get made? So, for example, if you need lazy consensus on something, the idea that if no objections happen, we're going to go on a certain path, how many days does it take you to get lazy consensus? What happens if somebody does raise
11:42
an objection? At what point does an objection become a blocking or non-blocking concern? You need to write these things down or else you will get nothing done. Who can propose new things or work on existing proposals? How do they propose new things? I think most projects these days, particularly larger ones, have settled on the idea of an
12:03
enhancement proposal. But, again, writing these things down because a lot of smaller projects tend to use issues or GitHub discussions. But if I don't know to look in GitHub discussions, I will simply never click it on any project ever despite having worked in open source and understanding that people do it. Make it very obvious for people. The second is documenting
12:24
role titles is really important, particularly as the project gets larger. So, I think that the special interest group for release engineering in Kubernetes has done a fantastic job of this. They document every single person that they need to get a release
12:41
out. They document what that person is supposed to do, at what points during the release cycle. And this way, one, it's not dependent on an actual physical human being. It's dependent on a human being to fill the role. Two, because it's dependent on a human being to fill the role, that means that there's more opportunity for different kinds of people to get involved.
13:01
For past release cycles, we've actually had a lot of students fill these roles, and it's been fantastic for us. But you have to do the work. It's a lot of work to write this document. But you have to do it. And if you do, they will come. Another area that you can get NodCo contributors to help you is with all the stuff that you hate, as I like to call project management. Basically, your project, depending on the size,
13:26
and naturally, as Celeste mentioned, she and I have a lot of work and are still involved in Kubernetes quite a lot. And so, this large amount of project management in terms of meetings and deliverables is something that we get specific people to help with. Process improvements is another area, as well as moderation and community.
13:42
Those are all areas that we can kind of group under this project management idea of someone else can own that. Someone else can take that off of your hands, so that you can use your time in the most impactful way, which is generally the message that we're trying to kind of push a lot in in this talk. It's okay to suck at project management, especially in the teams that I lead.
14:04
I try and take that job away from my engineers as much as possible. Unless they happen to be better than me, highly doubtful. But that's the thing I try and take away from them, so that they can actually use their time better, which is building the stuff that we need to build. And so, generally, what we want to do is thinking about that. Give away the rest of what you don't need. It's okay not to own
14:22
everything. In fact, ownership should be shared. That's really the goal of open source. But at the same time, we mentioned a lot of how working at enterprise can be a bit different. But this is the way that we can think about it in a way that helps us in open source. Think about your enterprise team roles, and can that be replicated in your project?
14:41
You have product managers, project managers, et cetera. Can you replicate those kinds of roles or that kind of work and accountability in your project, too, to be able to divvy up the work and share the load? That's something that non-code contributors absolutely would love to help you with if you define and let them know that you want that.
15:01
Next up, Buddy Up. I think a lot of the hard part of open source, and it's funny because speaks to a conversation I had earlier today, is the fact that it's really hard to transfer leadership skills. And one of the most successful ways that I've seen that done is if a project is sufficiently large enough, a buddy or a mentoring system. I think particularly for the non-code
15:22
parts of project management, the things like bug triage, the things like how to decide whether things get done, things like conflict management, having an actual one-to-one mentor who will give you actual FaceTime or an actual phone call is about as good as it gets. There's simply things you cannot transmit in documentation, and I say this as a lifelong documentarian.
15:46
Asking the maintainer or the owner of a project in a smaller project, questions can be really scary because people can intuit very easily that this is somebody who does not have a lot of free time. And most people try not to be annoying. They try not to ask those questions. And if you have the opportunity to pair with somebody who is not that
16:07
key maintainer and bother them instead, most people feel like that's a far less intimidating way to ask questions. The other aspect is people form at least one strong relationship in the project, and if you plan to make a career out of open source, having relationships
16:22
is really key. As an example of that, Natalie and I met because I was her mentor in the Kubernetes project, and now she leads ZigDock. I don't think I had a lot to do with it. I think it's all Natalie, but now we're here. So... Yeah, thanks, buddy. Another area in terms of thinking about non-code contributors and what
16:45
you can do to help them be impactful is for yourself in the project being flexible to project and general your own ruling change. A lot of the time, your processes that you're thinking about at the start of your project may not scale with your project itself, and you have to be
17:01
flexible and open to opening that up with new contributors, non-code contributors, or just the size of your project and how big it's getting, or how much attention it's getting, which is another area too. And so a good example of this in the Kubernetes project, we will be referencing this a lot, obviously, because we work in it very actively, but in the Kubernetes project, in order
17:20
to have the permissions needed to LGTM a PR, we want you to be a member of the Kubernetes organization, so you've got to show that you've contributed a minimum five PRs or some kind of really impactful contribution path that you've endeavored to achieve, maybe being part of the release team for the three releases we have each year, but we ask for you to show that
17:42
membership and that consistency and commitment so that you get those privileges. But that's not going to work every time. We organize a contributor summit where we want to get our contributors together in the same room twice a year at the KubeCon Cloud, native cons that happen in Europe and North America, and making the volunteers of that summit also be members sometimes
18:02
isn't a great way to introduce new people to the project and to that specific event, so we have to sometimes be flexible, and that's something that we're open to. Another thing, specifically in SIG docs that we do, we let folks retire and unretire from their contribution paths. We have a title of emeritus in the Kubernetes project where you can basically step down from your tech
18:22
lead or your co-chair role because we are humans that have lives outside of these projects in our work, and sometimes you don't have the time or the spoons to give to that work anymore, so being able to step down, hopefully with a succession plan and people to take over that work, and then being able to possibly also come back when you do have the time, and this is where we are
18:43
flexible with that organization membership. We say, oh, you don't have to prove yourself again, you've done it before, and we believe you now, and you can come back and take on a role as a contributor. Finally, our enhancement proposals were already mentioned by Celeste, but being able to have change requests come through that are beyond code improvements, the enhancement proposal
19:02
process was itself a proposal as a process to have in rather than just saying, hey, let's build this feature, this sounds cool, and actually have it go through rigorous looking over reviewership and actual documentation and writing up what the feature will do, who will impact, who will use it, etc. And so this is something that, again, those requests coming in, being
19:23
flexible to those requests for your project, big or small, will make a huge, huge difference. So what are the benefits of everything that we've just discussed? Hopefully you've been able to have a look at, okay, certain things that we're suggesting, this makes sense, this is possibly really good, but what's in it for me? First things first, less toil. So this is another graphic from
19:47
the Tidelift 2021 maintainer survey, which is a fantastic read if you're like a weird open source head. The point that I want to make is that the vast majority of what project maintainers do, particularly in sort of large projects that are owned by the Apache or the Linux
20:01
Foundation, is not code. It's a pretty small component of what they do, but if you can find a way to welcome non-code contributors into your heart and into your project, those are things that they can do and that they might be better than you at doing.
20:21
More device contributor types basically means less toil, which means that you actually get to do more time writing the software. If you don't like taking meeting notes, somebody is happy to do that, and that is a fantastic new contributor thing to do. Do you not like organizing events? Amazing. There are tons of people in the world who really like doing this kind of stuff. That's
20:43
why we're here at Berlin Buzzwords. If you don't like doing docs, amazing. There's entire professions that do nothing but write documentation and give talks and do informative things, and they like doing it and they might be better at you than it, so if you can find a way to give them the chance, it usually works out pretty well. Another big plus for some of these
21:02
things that we're listening in terms of non-code contributions is more stability for your project. Stability means you're going to have more trust and thus you're going to be actually having more exposure and taking on more users, and thus hopefully that means more contributors to your project or generally being able to scale in the ways that you're planning via your roadmap.
21:20
Stability is really important, especially with bigger companies who possibly want to take on your work as something they want to plug into their already large ecosystem of open source projects they're adopting. That stability factor is going to get you a lot more exposure, which is really great, but it's also hopefully going to harden the parts of the project that need hardening, and a lot of that is also the non-code aspect. Something else we want to talk
21:42
about in terms of more stability, getting more contributors means that hopefully you, as a maintainer, often in open source there's a lot of sole maintainership and you're kind of flying the flag on your own, but you need to watch out for burnout. It's quite a huge problem in the open source atmosphere generally, and it's something that you don't have to
22:02
actively go out and do things alone. Open source is meant to be about community and global in its footprint, and so we do want to make sure that folks are watching out for burnout and you're opening the door to those contributors to help with that. If you're overburdened, your project will suffer. It's the be-all and end-all. If it's completely on you,
22:22
then one single straw on the camel's back, so to speak, is all that it needs to have it come tumbling down. Share the load, whatever that is, again, defining what it is to share it out really, really important to the stability of your project. And then finally, the stability aspect actually means that your variety of contributions that you're inviting in means a
22:42
variety of organizations adopting or putting focus on your project, which gives that more credibility and stability aspects to it as well. And when we talk about variety of orgs, we're talking about, for example, as well. Specifically with Wayfair, they have a project called
23:03
Tremor, a real-time data system where basically you're getting information that you can for groups that maybe are e-commerce to be able to triage security issues ASAP with real-time data written in Rust. Very, very cool. But this way, this growing of contributions in terms of
23:22
non-code was a way that we could get the CNCF's attention in terms of getting that project into the sandbox there. And that's something that it was such a huge achievement for us in the Tremor project that we're still pushing to this day where we opened up the contributions for docs. We opened up the contributions for a lot of the community events. We were able to organize really, really cool conferences around it. And that was actually the way that the CNCF
23:44
knocked on our door and said, hey, are you interested in applying for sandbox work here? So that stability aspect, it's absolutely played out in the open before, and it played out in our experience. And it's only something that I can further recommend if you're interested in getting a lot more eyes on your work. And then the final thing that we'll mention for
24:03
this talk, but not the final benefit of what this will give you, is more diversity for your project. Diverse teams are successful teams. You have likely heard this. If you're in the business of open source where there's money involved, if you've got a diverse team, you're going to make more money. You're going to have more successful
24:22
problems that you're solving and just generally more success. It's a proven data fact out there. But on top of that, it's actually just more efficient to have a lot more different thinkers, different minds looking at the work that you're trying to solve. If it's all the same people, you're going to put out the same stuff. Kind of boring, kind of lackluster,
24:41
get diverse out there and actually be creative with your problem solving. Another thing I wanted to point out is that people often from underrepresented or systemically oppressed backgrounds. And that's a wide breadth of things, the LGBTQI plus community, different racial or ethnic or religious backgrounds, or disabled folks. They're often not willing to take up roles in leadership because of those
25:03
systemic issues. And your project can be the difference in that. You can be open up. And a great example that you often see in job descriptions is that there'll be a call out to say, hey, we encourage folks from X community, Y community to apply. We encourage people from the LGBTQI plus community to come and talk to us. And you can do those same things
25:23
to encourage that diversity. And finally, open sources global, have that reflected in your project. It's not just a Berlin project. It's not just from Vancouver project. It's not just a Sydney via Croatia project. So it's really something that being global in this way
25:40
is going to open up not only the contributor path, but also the way that you solve problems and hopefully build for a global community. So as a bit of an ending note, you out there in the audience may be thinking, but I work or I'm a contributor on something which is nowhere near as large as Kubernetes, because Kubernetes is the outlier statistically for open source by having thousands of
26:05
maintainers. Most projects are under five, realistically. So I wanted to end off with kind of advice for smaller projects, because you may be looking at this thinking, we don't have the people to do any of this. And that is absolutely legitimate. But there are still things that you can do that can improve the contributor experience for people who are not
26:23
you. First off, my favorite piece of advice, think small. Tagging good first issues and flushing out issue descriptions is an incredibly important thing to do. It's not enough to tag a good first issue. So I helped a project that we sponsored here at
26:41
Ivan called Claw. They're a data governance tool for Kafka. And they were doing fantastic. They were tagging their good first issues. Love that for them. But they were tagging good first issues that had issue titles along the lines of fix flux box and no issue description or an issue description that maybe showed a screen cap of the inspector saying
27:01
flex box isn't working now and now we need to fix flux box. And that's not enough for a new first contributor. They are terrified of you. They are terrified of you because it's happening out in the open. And if they make a mistake, there's a chance somebody might laugh at it. And ultimately we're all humans. So I had a long conversation with them around what would you need if you were a junior developer who really has zero
27:24
context on this project. And that's the level you kind of have to think at. Is if you're asking for new contributions, again, this is kind of a random person from the Internet sometimes. Or it's somebody in your company who maybe doesn't really know what this project is. You need to flesh out for them. Because fixing flux box if
27:42
you're a frontend developer is actually not that hard. But fixing flux box in a project that you don't really know how it works and you don't know what the correct acceptance criteria for that would be, that's terrifying. I personally wouldn't do it. I wouldn't want to screw up. Second, think about hiring. This is my drum that I beat in every open
28:06
source talk that I give, which is the roles that get staffed on open source projects are the roles that somebody pays for. A question I got a lot when I was at the CNCF is how do I attract documentation contributors to my projects? And my answer always was
28:20
you need to talk to your hiring manager. Whoever hired you has the power to hire a documentation person. They have the power to hire program managers. They have the power to hire community managers. And some organizations do and some organizations don't. So think about if you have a hiring manager that you're working with, think about
28:41
what kinds of roles you really want to see. Think about what your project really needs. Because sometimes it's not a developer. Think about project velocity and merge velocities. People want to know that if they open a PR, it's going to get merged in some timely fashion.
29:00
So it's really nice if you can to document things like we review the PRs weekly. You will always get a response. We expect that you will implement any changes we request before we merge them dot. Because there's nothing worse than putting a bunch of work into something to putting a bunch of work into finding a bug and fixing it and the pain that
29:23
that sort of entails to open a PR upstream to a project and they never come back to it. That sucks. Write it down. Let people know so that they know what to expect. Third and final is think about making yourself available in realtime. Office hours are a fantastic way of spending one of your hours per week to interface with
29:44
people who are actually using your thing. And that has a lot of different benefits. One is it builds your credibility in the community because when you build relationships with those people, you can use their stories to promote your project. And projects that have adoption get more adoption. It's a snowball. So think about making yourself available in realtime.
30:05
I'm getting the 10-minute mark, which is fantastic because we're done. Thank you so much. This is where you can find us on social media. And we do have 10 minutes, so we're actually also open to answering any questions that you might have as well. Great. One second.
30:26
Firstly, thank you very much. An awesome talk. As somebody that has gone through this problem in a very, very big open source project, which still is around today kind of, how do you encourage recognition for people that do provide this kind of work?
30:48
Super great question. I want to jump in with my first answer being that on the Kubernetes side, I mentioned the contributor summit that we have twice a year. And we actually organize awards yearly specifically for that, where we call out contributors that are nominated per special
31:04
interest group. So we put it in the group's hands to say, who are the people that you want to highlight and nominate for that? But that's the scale of Kubernetes in terms of awards, where we can fund a cool trophy or something. Actually, not to brag, but I got an award once where we actually had a really, really cool plaque made. We all got our own constellation
31:22
kind of put on this amazing plaque with our name and our special interest group that we were nominated by. And little things like that, tokens like that of investment in this way really helped boost not only those contributors, but others who were thinking about making the step to be like, I could be recognized like that one day. So that's definitely one example
31:40
that has been awesome. Yeah, and I would say that the other thing to think about is that recognition doesn't necessarily need to be a reward. So we had the one slide about documenting your roles in open source, and we touched on it a little bit. So the person who implemented that is a guy called Steven Augustus. He's a very lovely man. And one of his big
32:03
reasons for documenting all these roles in the release team was those are things that people can put on their resumes. They can say, I led a Kubernetes release in this role, and I had these specific responsibilities. Particularly for a larger open source project, you can confer power from the project to the individual, and the individual can then have
32:24
something useful that they take away from the project itself. This is especially important for non-technical contributors, I think, because if they don't have titles, there's unfortunately a bit of an attitude problem that some development communities have, where they view that as lesser than. But if you give somebody the title to say, this is this team's project
32:43
manager, this is this team's community manager, this is the lead of our contributor experience working group, that confers a level of respect that can equalize the playing field, and again, can serve them later in their careers. Yeah, one thing we're also doing, investigating
33:01
the Kubernetes project, is we're trying to work with GitHub to also create badges specifically for our project as well. And I find that, for lack of a better term, this gamifying of these kinds of things is also really useful, where linking up to the platform that you generally use to try and create something like this, specifically in the retiring and un-retiring example that we listed, where someone can show what they had contributed
33:24
in the past and it doesn't go away just because they need to stop and step away from that contribution too. And so given that we've been able to speak to Kubernetes, sorry, Kubernetes has been able to speak to GitHub about creating something like that, I don't doubt that smaller projects will be able to do something similar and and kind of kickstart a conversation about what's a general contribution like badge,
33:44
for lack of a better term, that can be created in the same way. Questions? Just one here. Thank you both for a really interesting presentation. I have a question on this topic of titles. So earlier you mentioned giving people the room to define their own role
34:02
can be something empowering and give them credibility within the project. And I'm wondering how, if you're open to sharing, each of you decided how to define your own roles within the projects you've been a part of, or if you have any other really interesting examples of how other people defined their non-code roles?
34:25
Short answer, organically and with a little bit of pain. So I will give an example of a friend of both of ours, Laurie, because again, my entry into open source was a little unusual in that I was hired by the Linux Foundation to do the work that I did. That is not most people's
34:41
paths. So our lovely friend Laurie eventually became the program manager of SIG release and she started by showing up. She attended meetings for SIG release. She kind of lurked in the background. I think she started to see that they really had some program management problems that
35:01
needed solving. And by showing up, by doing the work, by being the person who volunteered to say I'll do that, I'll do that, I'll do that, like, yeah, sure, I'll help out with the enhancement proposal process. Eventually people started to realize that there was a certain area of responsibility that she had kind of staked out as useful. And the role evolved organically
35:23
after that because she sort of became known to the special interest groups leads who said you're doing amazing work, now how do we make it a little bit more official? I mean, open source is kind of an organic thing to begin with in that regards. I have found
35:41
myself at the helm of certain projects, one called the inclusive naming initiative. And that happened somewhat organically too. We decided we wanted to do something about words like master and slave and it snowballed and it snowballed and it snowballed. Yeah, it just sort of happens that way. Another example I want to give is
36:03
generally this idea of how our titles came about. So I'm the co-chair of SIG docs and what I basically did after showing up is show consistency in that showing up. So the showing up isn't just like a one-time thing and then all of a sudden you're
36:21
kind of given X title, but it very much is going to meetings and taking part in the way that made sense for me, whether that is via PRs, which is that at first, especially on a lot of the docs, but also then via, you know, sharing my opinion and whether that's in meetings with voice or like in the slack groups as well, like figuring out what your communication
36:41
style is and where that's going to fit is really worthwhile. And then with that consistency, when the opportunity arose to put in a whole new bunch of coaches because the old one was burnt out, I just kind of put my hand up and they were like, yes, we've seen you around, we see your contributions, we want to accept that your hand is kind of raised and ready for this role. So it was very much, and then I had to do six months worth of a bunch of
37:03
work to do that too. So it was very much the consistency aspect in terms of eventually to that title. And what you need to do is define what that consistency means to you first so that you can show that to the project. That would be the first step. I've got one question behind you, I'm so sorry. Hey, thanks for the presentation. I had more questions, but you answered most of
37:25
them during the talk. So I'm left with one and it's about the slide where like 25% of time is spent writing code. And yeah, I feel it's true, but as a software engineer, it's like kind of a native membrane that my job is about writing code and how to get out of this mindset
37:43
and think about the 10 Slack messages or asking for help or another documentation stuff is just as important and how to help other contributors to also get this mind shift about it. Yeah, look, that's a great question because, you know, I manage a lot of software engineers
38:01
and I tell them all the same thing. The higher you progress up in your career as an engineer, let's say to principle or distinguish, the less code you will write. Like that is, I think, a universal kind of thing, depending on what you're working on. And so what are you filling your time with the rest of the time as you progress in your career, you're filling it with mentorship, you're filling it with design, you're filling it with learning a lot from
38:24
industry to be able to give your very, very valid and senior opinion on things. You're doing it to lightly push back on certain suggestions and give reasons why and look for data and information to give a yes or no answer. I think if no one is going to say, oh, you're not coding
38:42
a lot of the time, but you're involved in all of these discussions that leads to code being written. Like that's, if you're thinking about it in this kind of aspect, then you're not really going to be thinking you're doing less code because a lot of what you're contributing does mean code in the end. It just doesn't come from nowhere. So if you think more about the holistic life cycle of software, not just your cog in the machine,
39:04
hopefully that helps you break out of that a little bit of, I have 10 Slack messages to look at, but I have to write all this and make sure it compiles today, et cetera. So think about it a bit more holistically, there's going to be days where you code a lot and days you code not at all, and that's completely okay too. So very quickly, because we are at five minutes,
39:24
all of the things, your 10 Slack messages, that's a job. And if we sort of look through this slide, this building new features, that's a job, it's called software developer. Bug reports and fixes, that's a job, it's called QA. Proactively managing technical debt, that's a job, it's called project management. Documentation, that's a job, it's called technical writer,
39:42
it's called developer relations. Guiding the project's strategic direction, that's a job, principal engineer. Reviewing contributors, that's a job, et cetera, et cetera, et cetera, et cetera, and when you start to think of these as jobs with distinct skill sets that have value and worth, that's the other half of it. They are not worth more than code. Okay.
40:04
I think we can do one more question, and this gentleman was up first. I've got one more at the back too. Okay, one more at the back and then we're set. Thank you. What's the right way to think about the gender disparity between coders and non-coders?
40:23
And how much time you got? Okay. Yeah. Look, that might have to be something we talk about after. But I mean, so gender disparity and I want to just put it out there, there's more than two genders, because obviously this is a very progressive couple of people, but the gender
40:43
disparity part is actually something where it's part of that big systemic issue of, it goes back to, oh, in my opinion, this kind of work is very, very valuable and systems of patriarchy means that, okay, it goes like this and how do we push that aside?
41:01
One of the easy solutions in terms of addressing that is just outwardly saying that you're actively trying to have parity and aim for that as much as you can in your project. And outwardly say it, call yourselves out on it, because I think as a woman, I am more willing to
41:21
join a project that is openly saying, hey, we have a lot of X type of people and we're looking to do more, have more X people and we want that help. Not everyone wants to be the first, maybe folks like Celeste and I maybe, but not everyone and so that's not going to be a silver bullet, but it's something you can actively do to call out, I'm part of the problem and want
41:43
to be a solution. The fact that you have two women up here talking about non-technical contributions, that's legitimate. How do I put it this way? I don't think it's necessarily a problem
42:02
for women to do the quote unquote non-technical work. I think the real problem is that maybe it's only the men doing the technical work. Does that make sense? I think you need to flip the problem on its head. I have met many, many, many female and non-traditional gender conformity
42:28
people who would love to take more leadership in open source and feel that they have been shut down. So my real question would be how do you start to lift those people up? This is where the actions of increasing diversity and inclusion and equity in a project start to get
42:48
really difficult for some people and for some audiences because the reality is you have to try twice as hard to lift those people up as you would like a straight male white engineer. You
43:01
have to find them, you have to mentor them, you have to spend a lot of one-on-one time with them, and you have to let them know that they can do it even though it doesn't feel like they can. So that's my opinion on it. Do you have any other thoughts? I think we're at time.