Ayu & Dominic - Hacktoberfest is Coming, Preptember is Here!

Show Notes:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

• Virtual Coffee: virtualcoffee.io
• Podcast Contact: podcast@virtualcoffee.io
• Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw
• Dan: dtott.com, Twitter: @danieltott

Transcript:

Bekah: 00:05

Hello and welcome to season nine, episode one of the Virtual Coffee podcast. We're grateful to be sponsored by Level Up Financial Planning, who understands the importance of finding balance between having an awesome life today and being confident and excited about your future possibilities. If you want to take your financial confidence to the next level, check out levelupfinancialplanning.com and you can get that link in our show notes. I'm Bekah, and this is a podcast that features members of the Virtual Coffee community. We're an intimate group of developers at all stages of our tech journey. And we're here on this podcast, sharing our stories and the things that we have learned. And here with us to share today is my co host.

Dan: 00:51

Yo, what up, Bekah? How's it going?

Bekah: 00:53

Hey, it is very, very good today. I am very excited for this season because we have a specific topic for the entire season.

Dan: 01:02

Yes, we do. It is the season of Hacktoberfest, and so Hacktoberfest is a big deal for Virtual Coffee. Um, it has been Oh, there's air horns. There we go. We need some like spooky air horns. I don't know. I put up a Halloween lights. In my house last night. And now I'm like all in. I'm feeling spooky

Bekah: 01:20

I bought some pumpkins today at the grocery store.

Dan: 01:23

Oh yeah, uh, man, it's decorative gourd season. Alright, um,

Bekah: 01:28

so many amazing decorative gourds in my backyard. I thought they were pumpkins. They are not. They're decorative gourds. So, if anybody needs decorative gourds. And you're in the Ohio, West Virginia, Pennsylvania area?

Dan: 01:40

I'm not,

Bekah: 01:43

You're in Ohio, Dan!

Dan: 01:44

but I'm not in, oh, you mean slash Western Pennsylvania.

Bekah: 01:48

Yeah, we can like meet and I will give you decorative gourds.

Dan: 01:52

Okay, let's do it! Um,

Bekah: 01:56

have many of them. Because it is both spooky season and Hacktoberfest season.

Dan: 02:05

right. So Hacktoberfest is, um, traditionally is, uh, a program run by a company called DigitalOcean, and it's all about open source contributions. It's all about getting people into open source. And, um, we love open source at Virtual Coffee and. Also Hacktoberfest was, uh, what, two years ago, three, three years ago.

Bekah: 02:25

October of 2020.

Dan: 02:27

So three years ago, this'll be our third year, right? And the first year was, uh, really a turning point for Virtual Coffee, um, as a community, as an organization. Um, it's kind of when we banded together and it was our first real initiative as a group. Right. Um, and it was awesome that year. It was awesome last year, and I am very excited to be getting into that, uh, again this year.

Bekah: 02:51

Yeah,

Dan: 02:52

Oh, go ahead. Yeah,

Bekah: 02:53

I was just gonna say, like, when, um, Virtual Coffee was started, it very much was a pandemic thing. Like, hey, we all need community, we all need support. And then when Hacktoberfest started, that was exactly what Dan said. Like, that was the point where we realized that it was beyond that. Like, there were a group of people who... wanted support, who wanted camaraderie, who wanted a community, and this was something that we were going to continue going on with. So for us, like, it's the definitive movement moment of the Virtual Coffee community for

Dan: 03:27

absolutely. And since the timing worked out with our podcast seasons, um, and lined up with this month and next month, we decided this season will be all about open source topics. Right. So a little bit different, um, instead of doing. You know, single interviews with people about their journeys. What we're going to be doing is just talking about open source with people. Um, so with that being said, I guess our first episode is with Ayu and Dominic, both longtime Virtual Coffee members, both big time contributors to the open source Both the open source and the behind the scenes stuff at Virtual Coffee, um, and both very, very great people. So we talked about just generally, um, Preptember. Um, so I guess that's another term that we didn't explain, but Preptember is the, uh, lead into Hacktoberfest, right? And Preptember is all about getting prepared. Um, Bekah, do you want to tell us a little bit about what happens in Preptember?

Bekah: 04:25

Prepare is getting prepared for Hacktoberfest, which is a month long, um, contributions to open source. And so for us, there's a two fold, um, way that we approach this. So it's from the maintainer's viewpoint, like, how do you prepare your repository for open source? How do you onboard the contributors that you need for your project? And from a contributor's standpoint, we look at, like, hey, where are you at in your open source journey? What are your goals? What are your needs? And how can we help you along that journey? And so that might be your very first, um, Contribution to open source and that might be like, hey, I've contributed to open source in a lot of ways, but like, I really want a promotion at my job and I want to figure out how I can get that and utilize open source as, um, one of those bullet points on my resume. And so for us, like, We're here for people at all stages of that journey from maintainer to growth at your contributor status and finding different ways for folks to be able to engage in that and to grow. And like our, our mission at Virtual Coffee is to be in a community that allows room for growth and mentorship at all levels and to create meaningful opportunities for learning leadership and contribution for everyone. And so like, that is exactly what we're looking. For during this Hacktoberfest season and open source, because we believe that the value of open source is to provide these opportunities for lots of different folks. And not only that, but that the tech landscape overall, like there are many different ways that you can influence how the world interacts with open source. And I believe the statistic is like 90 percent of the world interacts with open source software every single day. So like to be able to touch that is incredible.

Dan: 06:19

Yeah, um, absolutely. And so Ayu and Dominic are heading up some of our key Preptemper, um, initiatives. And so we're going to let them talk about that here in a second. And, uh, well, I guess right now.

Bekah: 06:33

And we start every episode of the podcast. Like we start every Virtual Coffee with our Names, where we're from, what we do, and our random question as part of our introduction. And we really, really hope you enjoy both this season and this episode. And today's question is, what is the last type of issue you wrote for an open source repository? I am Bekah. I am the Developer Experience Lead at OpenSauce. I'm from a small town in Ohio. And the last issue I wrote was for a documentation feature. I'm 90 percent sure, but that's also like 90 percent of the issues that I write. So I'm,

Dan: 07:24

Was that on like one of your own repositories or was that on somebody else's?

Bekah: 07:29

uh, it's probably on the OpenSauce docs repository.

Dan: 07:33

Nice.

Ayu: 07:34

Um, Um, Um,

Dan: 07:42

computer stuff and, uh, Cleveland. Yeah. Cleveland, Ohio. And, uh, I was trying to remember what the last issue I wrote, I spent maybe 45 minutes working on an issue for an XJS repo and then. Realized I didn't understand what was happening and I deleted it, but it helped me sort of understand what was going on, you know what I mean? Uh, like, I mean, I was, I was going through and grabbing code examples and like, you know, really in the woods, uh, with the source code and stuff. And, um. Yeah, I mean, like, it was a positive, honestly, like a positive experience, even though it didn't come with anything. I could have just, like, filed an issue and said, this thing isn't working, fix it now, you know, uh, but I, I don't know. I dug in pretty deep and then realized, like, there's, there's some things, there's some things going on that I don't, that I don't know about. So, uh, I hit pause on that one. And, um, yeah, so I don't know, that doesn't super count because I didn't actually submit it, but, um, that's the last one I can remember. So. That's going to be my answer.

Bekah: 08:44

To, to be clear, we didn't say submitted, so you did write it.

Dan: 08:49

Sure. Sure. Yeah. Uh, Dominic, go ahead.

Dominic: 08:53

Yeah, I'm Dominic from the United Kingdom. And I work as a full stack developer at a mainly e commerce focused web development agency. And I also do open source stuff in my spare time. And I think the last issue I opened... Was categorized bugfix, but related to documentation, so you can take what you like from that as to what type it actually was. Um, yeah.

Ayu: 09:27

So, hi, everyone. I'm Ayu and I'm a tech blogger also from a developer base in the Netherlands. And the last time was documentation feature. Yeah,

Dan: 09:41

Nice. Yeah, I was, I was just, while we were talking, realizing we could probably go on GitHub, you could, I think you can go on GitHub and look at like your issues that you've made somehow. So they, how do we do that? Issues. Sorry, this is really exciting for everybody. But,

Dominic: 09:57

Yeah.

Dan: 09:58

if you go to, uh, github slash issues, it like, I think, uh, Oh yeah, create it. Look at that. The default one is like issues created by you. So now I'm looking at all my, I'm just going to see if I can find another one that, you know,

Bekah: 10:11

Oh, it's just github. com?

Dan: 10:13

yeah, yeah. And so that shows

Ayu: 10:15

I think it's author.

Dan: 10:16

uh, the. So the default, if you just, well, for me anyway, if I just went slash issues and it like defaulted to created by me,

Bekah: 10:25

Yeah, that's nice.

Dan: 10:26

and the, the first one I can see that's not a work one that's actually submitted was for this, uh, react code pen embed thing in June. So there you go.

Bekah: 10:39

Nice.

Dan: 10:40

So GitHub slash issues.

Bekah: 10:41

We'll link them in the show notes, so you can check it out yourself. All right. Well, Ayu and Dominic, thanks for being here with us today. Both Ayu and Dominic have previous episodes on our podcast, so you should definitely check them out. Um, but today, since this season of the podcast is themed about open source. We have Dominic and Ayu here who have, um, done a lot of really great stuff for Virtual Coffee and all of the things that we've been doing with open source. So they've worked on the guides and they worked on this month's monthly challenge, which is PrepTember. And so PrepTember is the month where we prepare for Hacktoberfest. And that might seem... silly or counterintuitive or like a lot of time and effort but I think that it's worth having this conversation and talking about like why we're preparing and how we're preparing things and so I'm gonna send it over to Ayu first and maybe you can talk a little bit about how we're preparing contributors and why it's important as a contributor to prepare for Hacktoberfest.

Ayu: 11:42

Yeah. So, um, I think it's very, very important for Hacktoberfest. Especially the beginners. I remember the first time, um, I contributed to an open source. It's some sort of like, what we have now with the Pretember repo. Where I, you know, like only, um, uh, submit my own name and then what I did at that time. But... The process of the contributing and that's, that was, uh, like very, uh, very hard for a beginner, especially, you know, like doing all the GitHub and the, um, the Git itself, uh, like on the version control itself. So, I'm thinking like for this September, um, It would be nice for us to have this kind of repo for, um, our members, especially the beginners, to, you know, like practice open source. So I was like really thrilled when you mentioned, Bekah, that, uh, we would like to have that repo. Uh, so yeah. And then I also talk about it and discuss it as well with Dominic. And yeah, and here we are.

Bekah: 12:59

Awesome. So Dominic, will you take a minute to talk about the maintainer side of Preptember for Virtual Coffee?

Dominic: 13:07

Yes. Um, yeah, I mean I think. Preptember is definitely important, whether you are a contributor or a maintainer, and whether you are a beginner or experienced. Because once you actually get into Hacktoberfest, things can become pretty intense pretty quickly. And I remember before... Preppedember was really a thing that it sort of felt quite full on suddenly and you didn't really think about getting ready for it and I can imagine that for a maintainer that would be even more the case because if you have a vaguely popular repository you're going to get a wall of Issues, pretty fast. I mean, of all the pull requests, I mean, pretty fast. Though maybe this year not quite so much, because I wonder if the lack of t shirt will mean people will actually be less worried about whether they complete the challenge or not. So I definitely think that having this month where we have resources like the Maintainers Checklist, which are always available, but where we're really encouraging maintainers to check their repositories already for contributors and things before the start of the month, and to Get them into a kind of good position to avoid the complicated communications that can happen if you take a project straight into something and people are starting to get involved with that project and you haven't got everything set up properly to set up the guardrails and guidelines for how it should happen. And then the chaos creates an overflow of information that you can't handle, so you can never get on top of it. So if you don't get on top of it before it starts, it will simply get worse as the month goes on. And then at the end of the month, you'll get people getting cross with you because you haven't done anything with their pull requests and they want them approved. Um, and this year we also... We are hoping that maintainers will, having, once they have got their repositories ready, add them to our practice repository. Um, where we're also keeping track of the list of repositories to recommend to contributors in October. So the practice repository is not just for new contributors to learn how to use Open Source, it has a dual purpose. And so maintainers are also very much, we would like them to contribute to that.

Bekah: 15:57

Yeah, I think that's so important. I mean, all of this stuff, um, it takes preparation because getting into open source, especially for the first time, there's a learning curve there, right? Like I was talking about, you have to understand how to use Git. You have to know what a pull request is. And there's a lot of language there that I think that folks who have been doing open source even for a little bit These are things that you need to learn about. Um, and, you know, even now, right before we got on here, I was gonna go add some things to our practice repository. And the practice repository is a really great idea because it helps people familiarize themselves with making pull requests and what it's like to write a commit message and branches and all of that stuff. stuff. And so, uh, I was going through the Virtual Coffee checklist, uh, for some of the repositories that I think would be good. And I'm like, Oh, wait a minute, we're missing these things in this repository. And so actually this was a question that I posted in Slack right before this, because, um, for the repositories, we have our. Code of conduct. We have our contributing guide all in our GitHub community health files, but there's not a clear connection to each of the repositories in the way that I anticipated it would be. So I don't know if I'm missing something. Uh, Whether there's another step that I need to follow through, or that's just like the central place to house these things, but the point is, using this repository has helped me realize like, okay, this might not be super clear for people who are contributing because it doesn't appear in the way that I anticipated it would.

Dominic: 17:38

Yeah, so I think that also highlights an important issue, especially once you get into the maintainership, is that it's not just about the code. It's also that the communication with other people is possibly even more important than the code itself. And that if you can't get the communication right, the code is probably going to be wrong too. And a lot of these things in the repository checklist is to do with creating the right environment to get the communication right. And everything else, I would almost argue, follows from that.

Dan: 18:15

Yeah, I totally agree with that. And, you know, this, and this goes along with the, the concept I think a lot of people are familiar with where, um, like teaching something is the best way to learn. You know, it's like when you are, if you're writing an issue or if you're doing. Anything like that. And you starting to describe something, um, and you put effort into it instead of just saying, this doesn't work, you know, um, and, and describing your steps, doing things like creating a, a reproducible, you know, example repository or something like that. You know, something to point to, um, all of those things are. Good. And, uh, almost essential for like, definitely essential for creating a good issue, but also for helping get it done, things like that, but also, um, help you learn about what is happening and, um, and, uh, also, also, uh, actual, like important document, uh, diagnostic tool for your own thing, right? Uh, so I've come across situations kind of similar to how I was describing before, um, where I start writing an issue and, um, I go to make a, like a reproducible thing that doesn't include all of my. Work, you know, like the, the extra stuff, right? Uh, so there's an issue with some package. So I want to have a repository that like only has that package in it, if possible, you know, or only like the bare necessities. So I can reproduce the issue and, you know, display that it's happening. And I've done that and the issue doesn't happen, you know? And then I'm like, Oh, all right, well, uh, something else is going on here, you know, and sometimes you'll find like, okay, it is still a bug with that package. Sometimes you'll be like, Oh, you'll discover that it's actually a bug with. Some other package. And sometimes the discover is just on your end. Um, but it's, it, it has using that, uh, like using your communication skills, like Dominic was describing, um, have benefit, like many different benefits in many different ways. Um, especially in open source, I think all of coding, but especially open source, um, it's, it's really a useful skill to practice.

Bekah: 20:16

Yeah, so let's take a step back to and talk about the contributors and preparing contributors for Hacktoberfest. And Ayu, what are you, what are some of your favorite tips for folks who are new to open source, maybe they're going to be doing Hacktoberfest for the first time. Um, what do you think are some of the top things that would help them out?

Ayu: 20:37

Yeah. So I think that first of all, um, It's really great to see, uh, that there are not only us, I think there are also like communities that starting with the Preptember and having like the practice repository like ours. So I think it would be, it would be, uh, good, um, you know, like to practice open source, uh, with these, uh, kind of repositories and also start to looking for, um, Uh, how do you say the Hacktoberfest repository or, or any other repositories that, uh, interest the contributors, like start to read the documentation and see if, for example, um, they can follow the, the documentation and stuff. And then. Um, you know, start to also like look around, like how to create a good issue. Like if you find something and then don't be afraid to, you know, like raise an issue and say that, Hey, um, I'm going through the documentation and this part is, you know, like, I think that something missing here, maybe we can fix that and always remember that when you raise issue that, um, you don't need to have the solution. You know, because, like, especially if the issue is a bug, you, you cannot, like, have the solution, like, right away. So, um, if you find an issue or a bug, just raise the issue and don't be afraid of it.

Dan: 22:09

Yeah. I, I, as nodding very vigorously there, but, uh, I totally agree with that. You know, you don't. Writing, finding issues is, is important and, um, incredibly valuable. You, you don't have to. There's no, I don't think there's any con like a social contact, a con social contract that says if you write an issue, then you need to be the one that fixes it, you know, um, finding something broken that there's a good chance that nobody knows about it except for you. Or maybe some people know about it, but they ignored it or whatever, you know, but, um, it. Assuming you have searched through the issues already, um, then, you know, and so you're not like just duplicating another issue. Um, the, I think getting something down is very important. And if you don't have a lot of experience or you don't, you know, maybe you don't know, haven't like gone down the path of creating a reproducible example and stuff like that. I think just saying that in the issue description is fine. You know, like I talked, I mean, I talked about how, like, It is, it is valuable to dig really deep into things, um, if, if possible, but like something is I think better than nothing, you know, uh, squeaky wheels and all that, you know, whatever the saying is,

Dominic: 23:27

yeah. The early bird catches the worm, I think.

Bekah: 23:31

Thank

Dan: 23:31

right. Exactly. Exactly. See? Dominic knows what I'm talking about.

Bekah: 23:37

Um,

Dan: 23:38

Exactly what I was saying.

Bekah: 23:39

okay, so we've given some tips for first time contributors. Now, let's talk first time maintainers, because I think that that's a really challenging thing. I learned a ton. Uh, let's see, it was October of 2020 when I was a first time maintainer for Hacktoberfest. Um, and I think, well, at least two people here contributed to my repository. Um, maybe three. Uh, but I learned a ton through that experience. It wasn't All that I thought it would be. And as I maintain more and more repositories, I learned that this experience changes all of the time, because a lot of it depends on who your community members are and what stage they're at in their journey of open source. So, uh, what tips do we have for first time maintainers to help them anticipate what's going to come in as best as you possibly can?

Dominic: 24:36

Yeah, I mean, I think to start off with it depends on very much on what type of repository you have. Is it an already long standing project that you're trying to get ready for contributors for the first time? Is it a new project? Are you already well known? Do you think there's going to be a ton of people finding it straight away? If you think... You're not going to have trouble finding people to contribute, then you probably want to focus on having a very well organized system for managing contributions before you, um, opted into Hacktoberfest in any way. That might also include making sure your language is very clear, so that if people make unsolicited, um, pull requests, That do not fit with what you've been already asking for. You want to have clear grounds for refusal without it getting difficult. Especially during Hacktoberfest. Awkwardness is super awkward. On the other hand, if you're maybe just starting out with your repository. You're not particularly well known. You actually need to get a group of people around you to start contributing. Then you might want to focus on getting your repository out there. Finding, um, posts where people are asking for, um, caught on in the comments repositories to contribute to. That kind of thing. But if you already think you're going to get a wall of contributors, try and keep your project out of those things.

Bekah: 26:10

Yeah, I think that the

Dan: 26:12

Go ahead, Bekah.

Bekah: 26:13

valuable information, um, I think that, you know, all so much of open source comes down to having clear communication, um, and doing that in the best way possible. And, uh, Nick Taylor, I think was saying earlier, the importance of automating different things. And so, um, where automations can help support new contributors, where you're, uh, Issue templates, issue forms, and PR templates are, those things can be super valuable to help you, um, save time and energy in answering those kinds of requests, uh, and I think, Dominic, what you were saying Nope, my brain, my brain lost it. I, It really like this One thing that you were saying and I was gonna follow up on that, but I don't have it anymore. So go ahead.

Dan: 27:07

Well, I have a follow up. I was, you mentioned, um, having a system to deal with incoming issues and pull requests. Um, can you describe any pieces of system aside from, so I think the, the basics would be having, you know, a read me and a contributors guide. So you can do things like point to. These sorts of things for, for, for, you know, getting rid of spam without feeling guilty and things like that. But, um, I was wondering if either of you really have, have like ideas for how to manage incoming, let's say incoming valid issues and pull requests, right? Like let's assume for a second that they're all good and, and, and, um, they're all, uh, you know, positive contributions, right? Um, how, how do you, like, if you were inundated in Hacktoberfest, how, how What are some systems to, to use to like get through that or techniques or anything? I

Dominic: 28:00

Yeah, I mean,

Ayu: 28:00

a good question. I don't, yeah.

Dominic: 28:03

Yeah, if, assuming they're all good and there's just far greater volume of them than you can hope to process, then I kind of feel like you've already made a bit of a mistake, and that what you should aim to do is to... Only have a manageable number of open issues accepting contributions for Hacktoberfest, so as to make sure that the pull requests you get that you've committed to accepting during Hacktoberfest are not more than you can handle. So if you think you've got capacity to maybe properly review, say, 20 pull requests, make sure you only have 20 issues accepting Hacktoberfest contributions, and make sure that In the contributing guide, or readme, or wherever you put this kind of information, it's very clear that, um, any pull requests that are not on open issues will not be responded to during Hacktoberfest, and that pull requests... Issues that have not been specifically marked for Hacktoberfest may be handled only after October is done. And then you know that you're getting a stream of incoming requests that... You've, um, committed the time to handle.

Dan: 29:23

think that makes a ton of sense. Um, the we've, I mean, we've done that before with Virtual Coffee, right? We've had specific issues, um, or specific labels. I'm sorry for issues. Right. Uh, I've also just like. created new issues halfway through, you know, I mean, like I had a batch of issues that I just didn't create. Um, the, another, another thing that we've done a Virtual Coffee is we reserve some issues just for Virtual Coffee members, right? Uh, so they are Hacktoberfest like valid, right? But, um, we only want our members to work on them. And that was kind of like, I feel like that was kind of cool too. Um, Yeah, I think those are all great ideas, Dominic, and, you know, there's, there's lots of different ways to, um, to do that, um, hopefully people don't end up getting burned. Uh, I, I will say, like, you, you do also have, like, Hector, Professor, at least in the past, the rules have been, you know, you, you can merge pull requests, or you can, um, Add a pull, the label is like Hacktoberfest accepted or something like that. You can add that label to a pull request and, um, it doesn't have to be merged for it to count for the Hacktoberfest rules, you know,

Dominic: 30:37

is true. Equally,

Dan: 30:40

Which is another little stopgap.

Dominic: 30:42

yeah, I would argue though that even so you want to be a little bit careful because if you put Hacktoberfest accepted on a pull request without really looking at it, and it actually turns out to be, um, something you decide later on you wouldn't really have wanted to accept, that potentially puts you in a slightly awkward position. I'm not sure, but I think it could.

Dan: 31:03

That's a good point. I, I think, Oh, go ahead, go ahead.

Dominic: 31:06

personally, I'd be a little bit, I'd feel a bit awkward about putting that label on a pull request just because I didn't have time to look at it.

Dan: 31:17

Uh, that is fair. Um, I think it, I don't know if this happened on last year, Virtual Coffee, or not, but there's sort of a larger pull request and they put a lot of work in it. And they were, it was like, they were assigned the issue. It wasn't like, uh, you know, a random thing. Um, And I, I was like, no, this is, this is good enough. And I don't, I don't know that we ended up merging the pull request, but I communicated that in the thing. Like this is, you know, I think I'm fine with me personally. And this is just a judgment call. I think, uh, rewarding contribution, even if the contribution doesn't get merged, if they're working hard in good faith, you know what I mean?

Dominic: 31:54

Yes, yes, I think, I think that is actually a very good use case for the Hacktoberfest Accepted label, where you can see that there's... Like, you've had enough time to have a look at it. You can see that there's obvious merit in what they're contributing. You can't necessarily make the decisions, right, about whether you're going to be merging it or not. Or maybe you've realised you made a mistake in what you asked for, but they still did valid work. There can be various reasons. Or you just know it needs more work, and it won't necessarily get completed, but they've put in some effort during the month, and so it should be recognised. And I think, yeah, that's very valid. Equally, you could get someone who puts in a piece of work that is complicated and big, but rather obviously doesn't relate to what they were supposed to be doing.

Dan: 32:46

right. Right. Right. So, I mean, it's a judgment call, you know, either way. Um, but yeah, I mean, I, you know, and that like kind of brings up. It's sort of a separate topic, but as a contributor, you know, there you, you need to, like, I think everybody needs to accept the possibility, like, that a pull request that you make won't get merged in, you know, that that's just always the, always a possibility. And it can be for a million different reasons. And That's, I mean, I'm sure some of them aren't good reasons, but most of the time, you know, valid reasons. And, uh, you know, that's, that's just another piece of like, that's another piece of working in open source is that, I mean, you don't have to think of it as a risk, but it's like a part of the process is sometimes work just doesn't, just doesn't work out, you know,

Dominic: 33:32

yeah, and

Dan: 33:33

and it's disappointing and you don't get your name in the contributors like list, but.

Dominic: 33:39

I think it's always the case with... Any type of work really that sometimes things go in a certain direction and for very massive quantities of valid reasons work can't always be used and it's actually quite helpful to go into a situation knowing that that's a possibility and that it's not really wasted work because probably The work had to be done for someone to realise that actually this isn't what we wanted to do. Sometimes you just don't know until it's been done.

Bekah: 34:13

Yeah, I think that what it comes down to is kind of rethinking the Significance of what you're doing, right? Because it can feel like hey, I did this and the work didn't get merged in But did you learn something from that? Have you grown since you started the thing that you did? Because ultimately that's the value, right? That you have learned something and you're able to take that forward. Um, or you're able to share that with other people, because I think that it's even valid to share that experience with other people. It's not, it's not a failure. And I think that we tend to frame it in that way. Like, Oh, it didn't get merged. So I failed, but that's not true. Right. Um, maybe, like maybe you just added a bunch of white space to a repository and the maintainer was like, no, thanks. Um, but what it comes down to is, um, growing from that experience as a contributor, as a maintainer, and taking away that lesson learned and moving forward with it.

Dominic: 35:14

I think also another thing is that when you're working on open source, it's worth remembering that you're working in public and... A lot of people, including like people who may give you opportunities in the future, can see how you approach things and, and that kind of thing. And actually, people who say might employ you in the future are going to... Know that sometimes you're going to be working on stuff that ultimately that work is not going to be used by the company because priorities change, stuff happens, you realize you're not going to do it, and so the way that you conduct yourself when faced with that situation is something also on display when you get into that situation where You. Hmm, the pull request is not going to get merged, and that's valuable as well.

Bekah: 36:09

Yeah, thanks so much. Um, and I, I want to thank both Dominic and Ayu for being here today to talk about this. I think that this is really valuable and useful to folks. So, uh, are there any last words of wisdom you have for folks who will be contributing or maintaining this Hacktoberfest?

Ayu: 36:27

I never maintained a repo before, so I cannot say about maintainers, but for contributors, um, just don't be afraid of open source, um, because, uh, at first it will be intimidating, but there are many people and also communities who can help you with it. And, um, yeah, just have fun.

Dan: 36:53

I love that. I, I have a lot of fun open source. It can be stressful. It can be hard, but like, uh, I think once you get past the first couple of times, and this is, this is what we do at Virtual Coffee for Hack to WordPress is just try to help people kind of get, step into the waters, you know, a bit. Uh, and once you get in there, it's, it can be a lot of fun and it can be very rewarding. Uh, it can be a lot of work sometimes too, and you know, it's all sort of optional, I suppose. But in the end, in the end, I think it's super worth it for a million reasons.

Ayu: 37:24

yeah, and adding to that, I mean, like I've been in open source for a while, but still up until now, I always, but then for lots of things, open source. So, yeah,

Dan: 37:36

You've never once bugged me.

Dominic: 37:41

I think one thing I would add is don't get burnt out while you're doing it, and it's okay if things change and You can't always do the things that you were going to do that you're committed to doing, as long as you communicate hmm, what's going to happen and can make sure that you keep people in the loop about whether or not you're going to be able to do things. Sometimes stuff happens and you can't do what you thought you were going to be able to do, and that's okay. And don't get too stressed out about it. Just communicate.

Bekah: 38:18

Love it. I think that's a great way to end. So thank you both for being here with us today and thank you to everyone who listened. We hope you enjoy your open source contributions and maintenance, I guess, this year.

Dan: 38:32

Thanks everyone.

Ayu: 38:33

thank you.

Dominic: 38:34

Thank you.

Dan: 38:37

Thank you so much for listening to this episode of the Virtual Coffee Podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel, if you have questions or comments, you can hit us up on Twitter @VirtualCoffeeIO or email us at podcast@virtualcoffee.io. You can find the show notes, sign up for the newsletter, buy some VC merch, and check out all of our other resources on our website, virtualcoffee.io. If you're interested in sponsoring virtual Coffee, you can find out more information on our website at virtualcoffee.io/sponsorship. Please subscribe to our podcast and be sure to leave us a review. Thanks for listening and we'll see you next week.

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.