Greater Than Code
Greater Than Code
#technology #psychology #tech #education #humanity #technology #business #society&culture

For a long time, tech culture has focused too narrowly on technical skills; this has resulted in a tech community that too often puts companies and code over people. Greater Than Code is a podcast that invites the voices of people who are not heard from enough in tech: women, people of color, trans and/or queer folks, to talk about the human side of software development and technology. Greater Than Code is providing a vital platform for these conversations, and developing new ideas of what it means to be a technologist beyond just the code. Featuring an ongoing panel of racially and gender diverse tech panelists, the majority of podcast guests so far have been women in tech! We’ve covered topics including imposter syndrome, mental illness, sexuality, unconscious bias and social justice. We also have a major focus on skill sets that tech too often devalues, like team-building, hiring, community organizing, mentorship and empathy. Each episode also includes a transcript. We have an active Slack community that members can join by pledging as little as $1 per month via Patreon. (https://www.patreon.com/greaterthancode)

259: Continuous Iteration, Continuous Improvement – Always Evolving Over Time with Rin Oliver

November 17, 2021 43:14 52.64 MB Downloads: 0

01:42 - Rin’s Superpower: Writing, Public Speaking, and Being Neurodivergent + Awesome!

02:18 - GitHub Actions

07:47 - Improving Developer Experience

11:33 - Neurodivergence + Autistic Burnout

17:04 - Mentoring and Reviewing for Kubernetes

20:49 - Open Source Contribution

29:04 - Mentoring (Cont’d)

32:46 - Evaluating Open Source Projects: Tips For Newbies

  • Contributor Licence Agreements (CLAs)
  • Codes of Conduct (CoCs)
  • Evaluate the Community

Reflections:

John: Technical Mentorship vs Social Mentorship.

Mando: Providing a welcoming sense of community for people with non-traditional backgrounds.

Rin: Being intentional about helping others, but also helping others means helping yourself.

John 2: The distinction between technical and autistic burnout.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

PRE-ROLL: Software is broken, but it can be fixed. Test Double’s superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater.

JOHN: Welcome to Greater Than Code. I'm John Sawers and I'm here with Mando Escamilla.

MANDO: Hi, John. Thanks. And I am here with our friend, Rin Oliver.

RIN: Hi, everyone. Thank you so much for having me. I really appreciate it. It's great to be here with you all.

MANDO: We're happy to have you, man.

Rin is a Technical Community Builder at Camunda. They enjoy discussing all things open source with a particular focus on improving hiring pipelines in the technology industry for those that are neurodivergent and improving the developer experience for new and returning open source contributors.

So Rin, we like to start off each of our episodes mostly the same way, which is to ask our new friend, what is your superpower and how did you arrive to it?

RIN: I’m solid at writing, pretty solid writing, and I've been writing since I was a kid. I'm somehow really good at public speaking and I never used to be good at that. That was just through repetition. Other than that, being neurodivergent and being awesome is another superpower.

[laughter]

MANDO: Absolutely.

RIN: Yeah, I would say writing and public speaking and generally just being awesome. In terms of programming languages, I'm still kind of learning a bunch of different things. I'm enjoying DevSecOps and I really enjoy GitHub Actions so CICD.

MANDO: Cool.
I think this might be the first time I've ever heard someone they enjoy GitHub Actions.

RIN: Oh, I think they're great.

MANDO: Oh, I mean, so I love them as well and I shouldn't say that. I should take that back because I very much enjoyed GitHub Actions for the first, I don't know, two, or three weeks that I was using them. [laughs] And then I started hitting the problems of trying to share bits and pieces of my jobs across other jobs and that became a non-stop frustration.

RIN: Do you mean by concurrent actions where you use a different piece of action and another action kind of thing?

MANDO: I don't know about concurrent necessarily, but more just like, I want to be able to run this reusable step across multiple different actions.

RIN: They fixed that. We had that problem, too. They fixed that very recently back in August and you can now use the uses and with keywords and action repeatedly. You don't have to have it just – you can have the uses word define more than once.

MANDO: Really?

RIN: Yeah.

MANDO: Huh. Man. All right. Well, this podcast – [overtalk]

RIN: Made your day.

MANDO: Just covered the price of admission [inaudible] guy. Thank you.

RIN: I know, right. You're welcome.

[laughter]

MANDO: Yeah. The solution that I had before was to pull that stuff out into some bash script, or…

RIN: That's what we did, too. We've got it in bash script right now, but we might go back in and refactor it so we can have that uses keyword come back in. Just do it that way. Yeah, but now you can do that.

MANDO: That’s great.

RIN: Yeah, they just fixed that in a patch back in August, early September.

MANDO: Oh man. That's fantastic.

RIN: Yeah. The words you're looking for is concurrent actions. That's what they call those.

MANDO: That's what they call it? Okay. Well, fantastic. That's great to hear.

RIN: I know, right?

MANDO: So what kinds of things are you doing with GitHub Actions? Like, is it just CICD, or are you doing other things with it as well?

RIN: It is mostly just CICD, but another thing that I've been working on along with our infra team was bringing in security into that CICD function in that we brought in Aqua Security Trivy to scan the automatic releases that we were doing using GitHub Actions for critical vulnerabilities before they could automatically release. So we brought Trivy in with a bash script and it says, “Hey, if you have a critical CVE, you cannot do that release. Go back, do not pass Go, do not collect your $100.”

MANDO: No, that's awesome. That's fantastic.

RIN: Yeah. I just gave a presentation about it a couple weeks ago at DevX Day, which was a KubeCon, cloud data con co-located events. So that was pretty cool. I will link you all the slides if you'd like.

MANDO: So was it doing actual scanning of the thing of the output artifact, or was it –? Can you go a little bit deeper into I guess, what you all were doing specifically around security scanning as part of your pipeline?

RIN: Specifically? So what we had Trivy doing was scanning that output artifact and flagging it for CVs and if it didn't return them, it would upload them to Trivy in SARIF format so that people could review them, the retainers could review those and be like, “Hey, here's that?” And they wouldn't be able to automatically release until they'd resolved that.

MANDO: Got you. What were these output artifacts like? Were they like Java JARs, or –?

RIN: They are. They are mainly Java JARs. Yes, that's correct. It was used for publishing artifacts that may have been central.

MANDO: Got you. Nice.

RIN: I will actually link it to you. It's in our community hub and that is my project that I've been working on for the entire time I've been at Camunda and I've been there for almost a year.

Camunda Community Hub is our open source GitHub organization where all of our community powered extensions live. That is their home and if that is where people can find all of the things that extend Camunda and make it better, that are powered by our wonderful community and it's a wonderful place. There's a 124 repositories in there as of today and one of them is our community-action-maven-release, which is this tool that we are using to allow some of our maintainers that opt to use it to release automatically to Maven Central. So I will drop a link and it's a wonderful tool.

It was a collaboration with myself and our infra team and a bunch of our other team members and the community itself. It was a whole bunch of people that came together to make this happen and make it better collaboration between Camunda, the community, and all of our wonderful people involved in this open source project to make it happen. The infra and developer experience team collaborated on that security piece and then we've also had a few people come to improve the tooling as of a whole in the DevRel team and the community as well in the last couple weeks too, which is great.

JOHN: Nice.

MANDO: I'm reading the README right now. [laughs]

RIN: Good. I'm glad. I'm glad I love a good README. That's wonderful. Good.

MANDO: Yeah. But it makes for not great podcasting [laughs].

RIN: That is true. That is true.

In summary, essentially, this GitHub Action supports the community extension release process for those individuals in our Camunda Community Hub that have extensions that are written in Java. So that workflow defines composite run steps to duplicate actions across repositories that allow for releasing to Maven Central and we do have a process workflow that shows that workflow as it stands in terms of both, the security scanning, how you use it, the prerequisites, and troubleshooting so that if you're interested in that and you want to undertake that option to release those artifacts to Maven Central automatically using this tool, you can do so.

JOHN: Nice. So I noticed in your bio, you talked a lot about improving the developer experience of new and returning contributors and open source and sounds like that's where you've been spending a lot of time with this community work that you've been doing. So tell me more about what it is that you feel needs to be worked on and what work have you been doing in that area?

RIN: The short version is that right now, I work in the Developer Experience team at Camunda, which is about again, obviously improving the developer experience, which is, for those people that are working with Camunda, ensuring they get the best experience possible. How can we make that experience better for those developers that are working with and extending out Camunda in that open source community? That's where I come in. And then Contributor Experience, how do we make the experience for our contributors, for our extension maintainers better? How can we improve that process as a continually improving function moving forward?

On the longer-term side, I actually am a member of Kubernetes and I got involved in Kubernetes in 2018 and I joined the Contributor Experience Special Interest Group. So that's where I do a lot of my behind this scenes work is in the Kubernetes Contributor Experience SIG and I've gotten a few people interested in Kubernetes who have gone on to actually speak at KubeCon + CloudNativeCon and have gone on to do wonderful things and just generally, amazing people and have been a pod mentor at Kubernetes at KubeCon + CloudNativeCon in the past—a few of them now—and just said, “You don't need a technical background,” and I hate to say technical. But you don't have to have a computer science background. You don't have to have a certain background to contribute to open source. Don't self-select out. You have an option to contribute to this community no matter what your background. You can write documentation. You can update READMEs. You can any number of things, you can be supportive of the open source community with and the Kubernetes community definitely needs your help.

JOHN: Very cool. So what sorts of things – you were talking about working behind the scenes. So tell me more about what those things are that you're doing to make that developer experience friendly, or smoother, or whatever their goals are there.

RIN: So for me, basically what I do, or I try to do anyway, is I do a lot of work improving, for example, contributor experience docs, building out that contributor ladder, making sure that there's unified READMEs and processes in general is what I'm hoping to build out at Camunda, unifying that contributing.md document, making sure that contributor journey is clearly laid out and everyone has the same experience regardless of where they come into that contributor journey and that there's a clearly defined pathway towards becoming a maintainer, et cetera. So that they know that this is what a commit message should look like, this is what's to be expected of code reviewers, this is what's to be expected of maintainers, et cetera. That experience is unified and cohesive across that platform.

Making sure that in terms of the broader spectrum, such as Kubernetes, just making sure that we're holding space for people and just making sure that we understand that not everybody learns in the same way, not everybody absorbs information in the same way. Starting those conversations about burnout and enabling people to come together and talk about those conversations; what does that look like, what does autistic burnout look like, how do we recognize that, et cetera.

MANDO: From a first time, or an early contributor for projects like the different Kubernetes and Cloud Native projects, Rin would you suggest that the CONTRIBUTING.md be kind of the first place that you start, if you are thinking about contributing code? Should you start there and do some research – [overtalk]

RIN: Absolutely.

MANDO: Before you start diving in?

RIN: Yeah, I would say hands down, go there first. Go to kubernetes.dev and then just go check out that welcome section and then check out, it says right there, “The first step is check out the contributor guide.” That's absolutely the first place you should go is always check out that contributor guide. That's your first point of call.

MANDO: Okay. For those of our friends listening right now who are neurodivergent, what are some things that you think they should be especially on the lookout for, or things that they should keep in mind before and during their journey down open source?

RIN: I would say if you haven't already, definitely check out the recording that Julia Simon did at KubeCon + CloudNativeCon North America 2021 a few weeks ago on burnout. Julia’s presentation was amazing and it was packed during that KubeCon and that was a reason for that is that we're talking about burnout. Julia started a burnout channel and the CNCF Slack. I would say, join that.

I've given some presentations on autistic burnout. I will link that. I would say autistic burnout, be aware of what that looks like because it's very different from how neurotypical people experience burnout. Be aware of autistic burnout, be aware of those signs and recognize them, and be sure that you're talking about it with your team, your community, your friends, and be sure that what that looks like for yourself.

JOHN: Yeah. That was going to be one of the questions I have on my list here is how does that differ from burnout in more neurotypical area?

Oh, actually before we get too deeply into that, I did actually want to talk have, if you could quickly talk about neurodivergence and what that means to you just in case there are listeners out there that are maybe not entirely clear on what that means.

RIN: Absolutely. So neurodivergence, basically that's an umbrella term that encompasses a variety of things. It relates to autism, ADD, ADHD, dyspraxia, dyscalculia, Tourette’s—there's a whole boatload of other things and it's very individual just because one person relates to neurodivergence another way. And also, it can relate to aspects of mental health as well. It can also be acquired; it doesn't have to be something you were born with. For example, CPTSD, or complex posttraumatic stress disorder is another form of neurodivergence and you don't have that necessarily at birth. That's something you acquire and that is a neurotype.

I'd say that there are plenty of – every neurotype and every combination of neurotypes is very unique to the individual. Nobody has the same neurotype. So I would always caution you that just because one person that is neurodiverted, you know just that one person. Definitely, you know just one person.

I myself am autistic, I have ADHD, I have dyspraxia, dyscalculia, and CPTSD so I have a whole boatload of things. I also have some ignored disabilities in that I have a bunch of metal in my left leg, but you wouldn't know it by looking at me. [chuckles] So it's just one of those wonderful things.

I navigate the world as someone who is also fat and trans. So those are also things. Visually impaired. So that's another one and the list goes on, but they're just some of the many facets that make up me and none of them fully define who I am. They're just aspects of who I am as we all are. We all facets of things that make up a whole and I would say that none of us are static. I would always be aware of that, that we are always ever evolving as individuals.

MANDO: Oh, I love that. Yeah, because it's absolutely true. The person we are today is not who we were yesterday.

RIN: Absolutely.

MANDO: Probably won't be the person that we are tomorrow, right?

RIN: No, I like to tell people that if you met me before I was like 32, we've had some updates to the system and all the bad codes have been patched down.

[laughter]

Be aware that there are further releases coming in the pipeline.

MANDO: [laughs] Yeah. Got to keep an eye out.

RIN: Exactly. Continuous improvement, continuous deployment of self.

JOHN: I have a conference talk where I talk about if you've got unhandled traumas, or emotional stuff that's stuck in there, that's emotional debt just like you have technical debt and you need therapeutic techniques in whatever stripe to do the work there and that's an update. Like you're clearing out all that old stuff; it leaves more room for all your current processes to run, they get more CPU, more RAM, or space to expand and really be the you that you want to be rather than you that's stuck in forever ago.

RIN: That is so true. I feel like also therapy is something that is very individual as well and I think that individual journey is just another, that's so unique to every individual and everyone has their own unique journey with therapy and the therapeutic process. I think that's something that's really challenging for neurodivergent people as well is to find a therapist that will listen to you and that's been a rough one, finding a good therapist

JOHN: Yeah. With CPTSD as well, there are so many forms of therapy, or therapists who aren't informed enough to actually be able to treat you well and it's a challenge to find someone to work with. Once you've gotten to the point where you've decided you want to work with someone, actually getting someone that's going to do some good for you is hard.

RIN: Absolutely. I found a therapist that finally specializes in EMDR and I'm just, just starting to say, I might want to explore that, maybe, eventually. Let's talk about that. She's been really respectful, but it took me months to find her and I'm like, “Okay, okay. This is good.” EMDR is pretty cool. But again, that's super unique and just because it might work for me. Check back with me in a few months.

[laughter]

MANDO: You never know given how our brains are in fact, individual snowflakes and – [overtalk]

RIN: Exactly.

MANDO: You don't know what medication is going to do to you necessarily. You don't know what different kinds, like you were saying, Rin of therapeutic approaches. Just because it did a certain thing for one person doesn't mean it's going to do it for you.

RIN: Exactly. You could take one medication and it could be fine for you, but it makes somebody else break out in hives.

MANDO: Yeah. So Rin, what areas of the Kubernetes project are you closely connected to right now, if any?

RIN: Closely connected to right now, I would say I'm actually working on becoming a reviewer so I'm in a mentoring project wherein I'm getting some mentorship and being involved with other mentors and learning how to become a reviewer for Kubernetes. The good part is you can take that at your own pace and I fully tend to do that because I do have a day job and contributing to open source is not my bread and butter. So I would do that on my free time, very slowly, and learning hopefully, how to review and become a reviewer in Kubernetes.

Another place that I'm contributing actively, or plan to is in our annual contributors’ summit, sort of contributor celebration event. We had a bakeoff last year, or the year before—my years are kind of blurry together—that I actually won, which was awesome. [laughs]

Yeah, won that, which was rad. That was super fun. But it was tough. I was up against a really stiff competition and it was a challenge for sure, but that was a really fun event.

This year my friend, that came in second. It was a dead tie; we actually had a vote off. Anyway, we're both going to be judging this year, if we have another bakeoff. So that's something that I'm hoping to be involved in and I will be. If we do end up having another bake off, I will be a judge on that and that is something that I'm hoping comes to fruition. Fingers crossed because that's cooking show judge has been my dream since I was a kid.

[laughter]

Please let this happen, please.

MANDO: Awesome.

JOHN: Yeah, can't go wrong with that.

RIN: I love it. It was during peak pandemic so we couldn't do it in person, but I wish we could have because it would've been so fun. It would've been just – and it was really, it was so fun. Even virtual, it was. We were all on Zoom and just cooking and it was chaotic, but it was fun and just getting to hang out with a bunch of my favorite people. Like I had somebody come up to me two weeks ago and they're like, “My kid thinks that you are their hero because the cake that you made at the bakeoff had candy that came out of it. It was a piñata cake and my kid loves you.” I'm like, “This is the best day of my life.”

[laughter]

MANDO: Oh.

[laughter]

JOHN: That's what you want to be known for.

RIN: I know, right. If I'm known for anything, please let be the piñata cake, I'm begging you.

MANDO: Well, best of luck that you'll be able to put another one together.

RIN: I know, right? Yeah, that's where I'm working is that area of being mentored to learn how to become a reviewer. I poke my hat in SIG counter backs, but I actually have taken a little bit of time off from open source because I am trying to focus all my new job, my new role here at Camunda. I want to learn to become a reviewer and be more active in that reviewer process. Also, I’m a mentor for KubeCon + CloudNativeCon as often as I can be. So I try to do that.

So yeah, that's where I'm most active and of course, I spoke at the last KubeCon + CloudNativeCon that just happened and I throw my hat in the ring for speaking every now and again at KubeCon. So in terms of being active in Kubernetes right now, I'm on that mentor short path and I'm taking it slow, but I've got to balance my time and I dip my head in every now and again and I try to do my best to be welcoming and positive when people do see me and they go, “Hey, it’s Rin.”

MANDO: Heck yeah. What did you speak on at the last?

RIN: At KubeCon + CloudNativeCon, I did the DevX Day co-located event for building secure open source communities from the ground up.

MANDO: Nice.

RIN: And then I did at CloudNativeCon itself was how did I get started in open source using your Kubernetes contributions, or building off your Kubernetes contributions to further your career sort of thing. I'm blanking on any of my own talk, but that's fine.

MANDO: Oh.

[laughter]

Yeah, absolutely.

RIN: Yeah, that's fine. Everything's fine.

MANDO: [laughs] That's something that I've seen, or at least I've felt like I've seen a shift in the way people understand open source contribution. And it might just be me getting older, but it seems to me and correct me if I'm wrong, or if you feel different, but it seems to me like people are walking into doing open source contributions now with maybe their eyes wide open a little bit more than they used to. What I mean by that is they're coming into these kind of contribution spaces looking not only to see how they can make – how they can improve the community and contribute to the community, I should say.

But they're also approaching it with a solid eye on like, how can they use this to further their career? How can they use this to get a better job? How can they use this to move into maybe a different direction that they were originally kind of started off in, or use it as a way to get their foot in the door? Maybe more of, I don't know, mutually beneficial path as opposed to the older school “altruistic path” of like, you're going to contribute open source software for the betterment of the community and then Apple takes your code and makes a bunch of money off of it and you're just kind of sitting around wishing you had more money.

RIN: That is true and that's something that I've had to conversations with a few people about now, about paying maintainers and saying we need to support our maintainers and make this experience better. I don't know what's going to come out of that conversation, but it's an ongoing one. Not my project, but I'm talking to people that are organizing a project around that so fingers cross that comes to fruition, because I'm always of the mind that we need to thank maintainers and pay maintainers. There's a GitHub sponsor button. It does great things, use it.

But in terms of people coming into open source with their eyes wide open, I think so. I think that's true. But I also think that yes, people used to contribute for altruistic reasons. You did that because you love the project, or because you want the maintainers to have an easier time, or because you genuinely see something wrong and you know how to fix the IT, or whatever. But I think that there's also a case for the fact that open source software contribution is a way for people that don't necessarily have access to a computer science career background sort of education, or they can't clear those gatekept hurdles to get involved and say, “No, I am enough and here's how.”

MANDO: Yeah, for sure. Absolutely and it was a refrain early on in my experience with open source was that this was a way, a path, a potential path and you would hear stories of folks who are coming from non-traditional backgrounds contributing to open source and then getting hired by some company based on their open source contributions.

RIN: That's what happened to me.

MANDO: Yeah. Do you feel like that's something that's well understood kind of in the – and this is so hard to say because I was thinking in the community of people who want to break into technology, but don't come from a traditional background. But okay, what cohort of people is that? [chuckles]

RIN: It's starting to be. It's starting to be because people like myself and a lot of people in the Kubernetes community and a lot of people in the broader open source community are saying if you come from a nontraditional background, make sure that you have your open source contributions on your LinkedIn, on your resume. Call it out, make sure that when you are applying for jobs, they know about it. Tell people and never stop telling people. Document those wins and say, “I have contributed to the following projects. These are my skills. This is what I'm doing. Here's my GitHub. Here's everything that I've done and the ways that I'm active in the community that might not necessarily be code. Here's the meetups I'm running. Here's the special interest group meetings I attend. Here's the projects that I'm helping on. Here's the mentoring I'm doing, or the mentoring I'm receiving,” et cetera.

MANDO: When we're talking about this area of technology specifically, like DevOps, DevSecOps that have that part of the community, in my mind that is a little bit of a, I don't know, harder task to experiment and play with this stuff on your own as opposed to sitting down and writing a Rails project, or a Spring project. Like there's more involved, in my mind, to doing DevOps-y kind of stuff, like building a lab and things like that.

Rin, what's your experience in helping people who aren't – maybe who are interested in doing that kind of work, but don't really know where to start. Like, do you point them toward like, I don't even know anymore. I know that there was MiniKube used to be a way that you could get a small Kubernetes cluster running on your laptop. What are the options for folks now?

RIN: Yeah, MiniKube is still a thing as far as I know. But for me, in terms of DevSecOps, where I actually turn people to is I'm actually a board member for The Diana Initiative, which is a non-profit for gender diverse individuals in technology that's focused on information security, DevSecOps, et cetera. They have an annual conference and they have a wonderfully active Slack full of a couple thousand people at least. And that's where I tell people to hang out and submit CFPs and generally meet that community and get them involved.

And I say, the CFP is going to be open in January, please submit. If you are a gender diverse person and interested in InfoSec, DevSecOps, et cetera, cybersecurity, all of those wonderful things, submit to The Diana Initiative. We'd love to read your CFP. [laughs]

JOHN: No, that's fantastic to have a spot that helps people land. That says, “This is for you. This is where you can come get that feedback on joining community, starting your speaking career, starting your open source contributions.”

RIN: Absolutely. And for that security side, it's full of just such helpful people, like the people that I met in The Diana Initiative InfoSec community are some of the most helpful people that I've ever met in this industry and they are people that you would never think would take 2 minutes to talk to you that have given me time out of their days to help me and to say, “Hey, here's some options.” I've met wonderful friends and wonderful community members. It's just a great place to be and they're always really helpful and really inspiring.

I'm glad to be a part of that community, be on that board, and to push that initiative forward into getting more gender diverse people, more non-binary people, more trans people be involved in that community and saying there's a place in for you in cybersecurity, there's a place for you in DevSecOps.

In terms that projects to work on. Honestly, for me, I'd say look at things like Aqua Security’s Trivy. How can you implement security scanning into tools that you're already using? You don't have to reinvent the wheel; look at how you can use DevOps and DevSecOps tools into things that you're already using.

MANDO: I love that. That's fantastic. Absolutely one of the things that is a constant struggle, especially when you're talking about building containerized workloads. How do you make sure that the containers that your engineers are building are running on the latest version of the operating system that they're pulling in, or make sure that they're doing the dependency scanning to make sure that they're not releasing something that has a recently discovered CVE?

All that work that you were talking about in the beginning, Rin beginning of the episode, the stuff that you had done spreading that gospel, [chuckles] if you will, to your engineering team, or I guess, your engineering friends, or whatever. That does sound like a pretty interesting and I don't know, I guess, relatively low friction way to start. You don't have to shove that in the middle of a process. You can kind of do that out of band and roll it out slowly rather than having to say, “We're going to stop the world and do this incredibly intrusive security audit and no one can release software until this third-party auditor has come through and gone through things.” Right?

RIN: Yeah, exactly, exactly. And in terms of auditing, that's another thing where people that have non-traditional backgrounds can get involved because you can be involved in an audit and not necessarily have to write code. You can look at docs. You can review things that you have access to. It depends on who your CSO is. It depends on your cybersecurity team. You can help them write the documentation. You can help them write their findings. You can help them check their grammar and their reports, et cetera. You can still help. Even if you necessarily aren't writing that hard cybersecurity code, you can still help.

JOHN: You mentioned mentoring at KubeCon and I'm curious is that mentoring first time speakers coming in, or is that mentoring attendees of the conference?

RIN: That is actually mentoring attendees of the conference and I will drop a link to that. KubeCon pod mentoring. “Pod mentoring gathers a group of mentors to help people get their Kubernetes-related questions answered quickly and efficiently.” So where I usually sit is in that community track, that's where I come in is I mentor in the community track because that's where I have a lot of expertise is the community side.

But there's people in – there's a technical track. There's a whole bunch of other things and people ask really – they ask some really solid questions and it's pretty great. It's available during KubeCon + CloudNativeCon events. You have to register for it individually for the event to be eligible for mentoring, but it's really cool. They're not run by Contributor Experience, actually run by the CNCF and Linux Foundation. They're not run by SIG Contributor Experience, but they do advise and the SIG Contributor Experience members do help out such as myself. So that is a CNCF/Linux Foundation initiative and it's great. I love doing it. Something that I will always do if I have time at every KubeCon I go to.

JOHN: That's so interesting because what you described there is completely different from what I was imagining, but in a way that's really interesting to me because I'm part of the scholarship organizing group at Ruby Central. So we do RubyConf and RailsConf.

RIN: Oh, cool.

JOHN: And so we have a scholarship where we get people who are either brand new and underrepresented to tech – [overtalk]

RIN: I know that.

JOHN: For scholarships to the conference. But then we also pair them up with a guide so that they have a conference buddy, someone who's more experienced, who possibly knows a bunch of people, can help introduce them, and also help just get plan through what they're going to do and get the most out of the conference. That was sort of what I was thinking.

As far as mentoring goes, we don't have anything like that in the Ruby conference world that I'm familiar with, where we have that technical question and answer like, “Hey, I'm stuck on this problem,” or “I don't really understand how this thing works.” That's a really interesting way of also like bringing developers in and helping support at them that I hadn't heard about and so, now I'm sort of spitting in my mind about what we could do there.

RIN: The good news is it's open source and you can use it as a framework.

JOHN: [laughs] Awesome.

RIN: If you want any help, I'm happy to help. That's something that I love doing and like I said, I'm getting interested in Ruby and poking around with Ruby and GitHub Actions, who knows maybe I could be a mentee this time.

JOHN: Yeah.

[laughter]

RIN: Switch it on me. I could actually get some help. [laughs]

But starting a mentorship program such as this one in any community, I think is really valuable because you have time for people to ask those questions and say, “I'm stuck,” and be in that supportive environment where they're not going to get downloaded on Stack Overflow, or some other terrible place and they're not going to get judged relentlessly. They can come to that safe space and get answers from the people that are actually doing the work on a daily basis and that might have more experience in a particular area and can help them get unstuck, or at least push them further towards a resolution.

JOHN: Yeah. That's super fantastic. I do some individual mentoring with people outside of the conference and I can definitely, in that experience, I can see how so often it would be so valuable to them if there was that technical resource where it's like senior developer on demand where you can go ask the questions like, “I don't quite work how this thing is doing for me,” or “Here's my code, why doesn't it do what I think it does?” I think that would make for a wonderfully welcoming community.

RIN: I agree. And I think making those community is welcoming. It's just a concept of, like we said, in the beginning of the show, continuous action, continuous improvement. Nothing is static; it always evolves over time.

JOHN: Cool. I think the other question I had was around again, working with so many people who are new to the industry and I think lot of them here, especially in the bootcamps. “You should have some open source on your resume. It's going to help out do the thing,” like we were saying earlier. And I hear the next thing out of their mouth is, but I have no idea where to start. I don't know what projects are out there and accepting which ones have been groomed with issues that are suitable for new developers. You don't have to be Mr. Expert, or Mrs. Expert to go in and jump on those issues and actually solve them and start getting that contribution count up.

So do you have any advice for people to sort of like, “Oh, I'm a bit lost in this whole world. Where is a good place to start looking, or how do I evaluate a project once I am interested to find out if it's going to toxic, or welcoming?”

RIN: I would say, first things first, always make sure that a project you're contributing to has a Code of Conduct and read it. Sign their Contributor License Agreement. If they have one, sign that CLA. Make sure that you adhere to that Code of Conduct, do your best to be a good human, just be a good person and if they have a CRC lined up – and CRC stands for Code of Conduct. If they have that Code of Conduct lined up, you know what you're in for, what to be is expected of you, what is expected of the people that you're going to be working with.

So read that and then from there, I would say, check out the issues. Are they labeled? Do they have that good first issue label? Are they using it well? And if they're not, see if you can go at it to some issues that you think are good first issues. That's a good place to start, too.

MANDO: You mentioned CLAs there. Real quick, could you give our listeners a quick definition of what a CLA is?

RIN: I can. CLA actually stands for Contributor License Agreement and it's an agreement that a lot of open source projects would ask that you sign and some people like them, some people don't, we don't have time to get into that. [chuckles] But CLAs in general are a tributed relations agreement that says by signing this, you are contributing to this project open source and it's a whole bunch of legal jargon. Essentially, read it. But that's basically what it is. It's an agreement between yourself and the project that you're contributing to that says you can do these things, but not necessarily some other things.

MANDO: Are there any things in the Code of Conducts, or the Contribute License Agreement that you think people should keep an eye out for? The things you have seen in the past that you'd equate to being like a red flag.

RIN: I would say not having a code of conduct. [laughs]

MANDO: Fair enough, yeah.

RIN: Is kind of a red flag. I'm sure that there's some projects even that might not have a code of conduct in our community up. I'd like to hope they all do. But on the other hand, it's not necessarily something that you can force people to do. It's something where you can say, “We recommend that you have this, we would prefer that you have this,” but we can't force anyone to have it. We would like to hope that people do. A lot of projects do have those, what they call default community health files, where they've automatically any repo that is created – actually in the community hub, if you create a repo from our template repo, you well automatically get a Code of Conduct IMD generated. So that is good. We have that in place that says you have to buy this Code of Conduct if you would like to be a participant in this organization. So we do have to adhere to our Code of Conduct to be a part of the community hub. So that is very important. [laughs]

But I would say not having one, or just not going to rattle off the many lists of things that would red flag because that's individual from me, what red flags for me are, I would say use your best judgment. If someplace feels unwelcoming, or seems like it's overly judgmental, or is just a negative place full of people that are saying things that aren't positive and not aren't welcoming, I would maybe not.

MANDO: Yeah. That's a really good point.

JOHN: And you would see those discussions and say, GitHub issues, like as things are going back and forth?

RIN: Exactly. Yeah. You watch the issues. There’s Stack Overflow, or Reddit, or wherever that discussion is taking place, or Twitter. You'll know if that conversation is ingenuine in any way.

MANDO: That's a really good thing to mention that when you're deciding to contribute your time and effort to a community, take a little bit of time. Just because you like using a piece of software doesn't necessarily mean that the community might be as open and welcoming as you would hope. It's not necessarily indicative of a community that you would want to spend time interacting inside. So it's worth going to Reddit and it's worth going and checking out their GitHub issues, or whatever they're using to track it. Look to see if they have a Slack, or a Discord. Just spend a little bit of time trying to get your thumb on the pulse of the community. That's a really good thing.

RIN: Absolutely. I would say try to get your feel for community before you start contributing. Get the lay of the land, explore some special interest groups, explore the Slack, see how things are run, figure out how things are done, how people respond to issues, what that contributor experience is like, see how people talk to each other, see how they treat each other and say, “Is this a place that I want to invest my time?”

JOHN: Yeah. Better to do that upfront than to have spent months working on code and then trying to perfect your submissions, and then discovering that it's going to be a real fight to get through your thing. Even though it's not that big a deal, or if you just getting being dismissive, or in intent, or whatever the dysfunctions of the community are. Knowing that beforehand, this is probably really valuable.

RIN: Exactly.

JOHN: It's funny that reminded me of – completely tangential. A friend of mine was trying to figure out what kind of dog breed to get and so, he spent a whole bunch of time going into different dog owner, like breed owner communities to see what the people that owned those kind of dogs were like, and use that as another data point to say like, “Oh God, I would never hang out with those people. I'm not going to get one of those dogs.” [laughs]

MANDO: It's not bad. Isn't that bad at all.

RIN: That's smart. Honestly, I wish I would've done that. That's really smart.

[laughter]

JOHN: So we've come to the time on our show when we do what we call our reflections, which is basically just each of us is going to reflect on this wonderful conversation we just had and talk about what it is that's going to stick with us, or we're going to be thinking about for the next couple of days, or new ideas things that we found.

And for me, I think looking into this different concept of technical mentorship versus social mentorship and especially in the conference context, but it could go into a lot of different areas, too and ways to expand that level of support within a community so that you not only have social support and mentorship on that level, but also, on the technical side, just to make that even more welcoming. I love that idea and I'm going to keep thinking about what we can do in the communities I'm in.

MANDO: Oh, that's awesome. Yeah.

The thing that struck me, I had thought about it some. It’s something that keeps kind of rolling around in my head here and there, but the idea of all of the different ways that we have, as a community, to allow folks from non-traditional backgrounds, maybe non-computer science backgrounds and how it's a bit of – it's a responsibility on us and Rin, you touched on this and this is what really made it stick in my head. It's a responsibility on us who are in the community to make sure that the wins that folks get, who come from non-traditional backgrounds, make sure that we keep track of those and make sure that we celebrate them so that we provide that welcoming sense of community, John, like you're saying. That we provide a way to say, “These are some paths that people have taken.” You can see kind of the fruits of their labor and where they started from and where they've gotten to and they didn't have to go through the traditional path.

It's on us to make sure that those things are brought out into the light and other people get to see them so that they can if not be inspired, at least have something that they can stumble across on the internet when they're feeling maybe a little down, or discouraged, or I'm never going to get in. I'm never going to get that job. They can come across these wins, maybe it'll give them a lift in the sales at the right time.

RIN: Absolutely. I'm going to be thinking about [chuckles] just continuous improvement and being intentional about where you spend your time, being intentional about helping others, taking time out of your day, but also understanding that you also sometimes helping others looks like helping yourself. It's that whole adage: put your mask on first like they do on the airplane. That whole concept is important to understand that you need to be aware and check yourself of burnout and make sure intentionally how you're spending your time and remember that you and everyone around you can hopefully always improve as people and try to uplift people and make this community better. Leave it better than we found it.

MANDO: Beautiful.

JOHN: Yeah, for sure.

MANDO: 100%. Yeah.

JOHN: And actually that's my post-reflection reflection is also that you brought up the distinction between typical burnout and autistic burnout. That's definitely something I'm going to be reading up on because I had no idea there was a distinction there and it sounds like a very important one.

MANDO: Yeah, yeah. Me neither. But it makes perfect sense. It makes perfect sense that there would be distinct differences there and as folks in the community, this stuff's on us.

RIN: Totally. It's on all of us to just do better, and learn and be better, and research and find what we can to just make this a better place to be at the end of the day and I guess, our takeaway is what are you going to do to make this a better place?

JOHN: All right, that wraps us up for today. Thank you, everyone for listening to the show.

Special Guest: Rin Oliver.

Sponsored By:

Support Greater Than Code