00:00:10.080
hi i am so excited to see you all here today because if you're here that means
00:00:15.599
that you want to be an open source contributor and for me this has been one of the greatest joys of my life but i'm
00:00:21.199
also kind of sad to see you here today because you haven't felt comfortable jumping in yet right and i think that
00:00:28.400
there are a lot of big things that prevent people from feeling comfortable stepping into open source a lot of
00:00:34.239
people are confused about where to start there's a whole ocean of repositories and issues out there it can it can be
00:00:39.920
hard to know where to begin it can be hard to understand the differences between open source contribution and
00:00:45.200
your day job and some of the technical differences that occur because of that but i think the number one biggest thing
00:00:51.760
that scares and intimidates people when it comes to open source is the review process it is incredibly vulnerable to
00:00:57.520
put your code out there in public and to have somebody review it critique
00:01:02.800
it and decide whether or not it's acceptable and i think a lot of that comes from the way that we view maintainers as
00:01:08.799
lofty heroes of the internet and what i'd hoped to do today is to break through all of these barriers that you
00:01:15.920
may have been feeling and to answer these questions starting with the number one question i get every single time i
00:01:23.520
work in open source on stream which is why are you doing your job for free or very very cheap
00:01:30.960
so the first thing i want to say to this is that you are not right your work whether you want to
00:01:36.159
acknowledge it or not is a treadmill of issues that you have to complete in order to
00:01:41.840
take care of your needs and your family and to ensure that you have stability
00:01:47.360
that obligation um kind of affects how you feel about it right and open source
00:01:53.920
is an expression of joy it is creating things purely because you like the idea of creating it the difference between a
00:02:00.640
hobby and a job is whether or not you choose to do it and as a contributor you have the choice
00:02:06.320
but most of the time when i provide this answer to these people they don't really agree or understand it so let's talk
00:02:11.599
about the tangible benefits to you as a developer so these first two new skills and experience and learn from experts really
00:02:18.800
comes from having the opportunity to get outside your organization right inside your organization you have access to the
00:02:25.120
projects the stacks and the architectures that they're comfortable with right and you have access to the experts who
00:02:31.599
are within your organization but when you step into open source you expand the possibilities if you've been working
00:02:37.599
with object oriented you have the opportunity to see what a live large-scale functional program looks
00:02:43.280
like if you've been wanting to play with rust isn't it nice to build something larger than a tutorial app you have so
00:02:50.640
many opportunities to meet people that you would never have the opportunity to meet from within your organization and
00:02:56.400
that comes from getting outside of it the other big one is right to repair i don't know about you but if i've ever
00:03:02.720
encountered a bug or an issue with a tool there's this little voice in the back of my head that just screams if you
00:03:20.800
statement of power capability and the things that you can do right
00:03:26.640
one of the examples that i have for this is i constantly see people on twitter who are like at the practical dev please
00:03:32.400
grant me this feature at the practical but dev by the way are the folks behind dev2 and code newbies and the entire
00:03:39.599
platform that they use to run those is open source right it's called 4m and
00:03:45.280
it's a rails repo and you can actually go there and they have an entire feature request process and you can be part of
00:03:51.360
the project that brings the feature you wanted to life instead of being caught in this cycle of
00:03:56.560
begging for people to build things for you on twitter you can be part of the process of creating that and that is
00:04:02.159
incredibly empowering but this last reason is the reason that i got into open source is having a
00:04:08.560
library of examples so i was looking for a new job right and
00:04:14.319
they asked me for a code sample and i looked through my open source like repos and everything's things that aren't um
00:04:21.600
locked behind copyright and that i can actually share and i see nothing but tutorial apps
00:04:27.360
minor things that i've built and played with they didn't reflect my true skills
00:04:32.800
right more so than necessarily passing an interview or wanting an example to show
00:04:39.199
people what i was capable of what hurt the most was knowing that the best code of my career was going to be locked in
00:04:45.040
someone else's private repo inside open source i may not own the code that i've written but at the very
00:04:51.440
least i have access to it i can reference it when i want to build new solutions and my history of
00:04:58.240
accomplishments does not end when i change careers that is the reason that i got started
00:05:04.000
with open source and let's start about let's start talking about how you'll get started in open source most people are
00:05:10.639
going to tell you to find an issue right an issue by the way for those of you in jira land is not necessarily a problem
00:05:16.400
it could be a task a story or another name but they'll tell you to look for something tagged to good first issue
00:05:21.520
there's even sites dedicated to this but i think that this is the wrong approach and here's why dev environment setup is
00:05:28.160
hard learning a new code base is hard and if you are constantly hopping from good
00:05:34.160
first issue to good first issue you are constantly repeating these two steps so
00:05:39.280
instead i think what you should do is you should find a good first repo now what makes a good first repo is going to
00:05:45.440
be different for every single one of you but this is the things that i care about and i hope that
00:05:51.280
it helps you find your own list so the first thing i look for is interest i want a reason to come back is
00:05:57.520
it a tool i use does it have a charitable purpose an interesting tech stack the next thing i do is i look at
00:06:03.280
the closed prs this lets me know how long it takes for review to happen
00:06:08.560
how long um and how in-depth those reviews are this allows me to set my own
00:06:13.759
expectations for the review process and also to make sure that those expectations align with what i'm
00:06:19.759
comfortable with i think that a lot of the frustration we see in open source comes from contributors who have
00:06:25.520
different expectations than maintainers can really keep up with the next thing i look for is a docker in
00:06:32.080
codespaces setup anything that can reduce that dev environment setup and allows me to throw away the environment
00:06:37.759
afterwards is incredibly helpful and then for your first one i strongly recommend stack experience which in this
00:06:44.800
case would be ruby right so you're going to be learning about forked
00:06:49.840
repositories you're going to be learning about how to interact with maintainers and contributors that's a lot of things
00:06:55.199
to pick up at once so make your life a little easier and pick a stack you already know the last and most important one is clear
00:07:02.400
issues so out of all the repositories that i've contributed to the one that i like the most is casa which is an app
00:07:09.680
created by ruby for good and the reason is specifically because of this the
00:07:14.800
issues are clear they're easy to understand and they're easy to work on
00:07:20.400
when i think about a good first issue i think a good first issue is small in scope well-defined and reproducible you
00:07:27.840
want it to be reproducible because you want to know when you're done you want it to be well defined
00:07:32.880
i've seen people pick up issues where there isn't it's a ui change but there isn't a mock-up and this can
00:07:39.599
create lengthy review processes where what the maintainers want and what the contributor has delivered are different
00:07:46.639
the other one is small in scope change the color of a button like it's fine your heroic pr can be your second pr
00:07:54.400
because we're going to stay with this repo for a little while all right i want to continue to dig into this because i
00:08:00.400
think that finding the right first issue can really set you up for success in open source so i want to
00:08:07.360
break these down into a couple of different categories that i see that are really common the first one being the most difficult which is setup changes a
00:08:14.000
lot of times when contributors approach this they think oh well i'm going to adjust the setup and i'm going to give
00:08:20.319
other contributors a way to access this project in the same way that i do right um and here's a little audience
00:08:26.800
participation can i ask you how many of you have heard of maven m-a-v-e-n
00:08:32.959
oh there's a fair few of you nice to see you all here okay so in college i had
00:08:39.120
not heard of maven and it was my first introduction to it and my my friend had this little ruby on rails app and he
00:08:45.360
turns to me and he goes somebody has mavenized my repo and i went they what your repo
00:08:51.920
and he says they mavenized it and i'm like what does that mean and he said i have no idea
00:08:59.279
maven by the way for those of you who did not raise your hands is a set of build tools commonly associated with java right
00:09:05.200
and i think when you are a contributor you're thinking i want to give other
00:09:10.399
people a way to access this repo in the same way that i'm comfortable with but as a maintainer you're thinking this
00:09:16.240
sets an expectation that this repo will be accessible using maven for the rest
00:09:22.640
of the time that it's available like contributors will start using that setup which means it needs to be maintained
00:09:28.399
another thing people commonly forget about is that build tools are some of the hardest to test in dev environment
00:09:34.800
setups as a maintainer you have to completely uninstall your dev environment and recreate it using this
00:09:40.320
setup so that's why while setup changes feel like a good first contribution they're some of the hardest to get
00:09:46.000
merged and they can be very challenging for maintainers um the next one is unrequested refactors if it's requested
00:09:52.320
go free but the way i see it um there's three major things the first of
00:09:57.839
which is that the maintainer could say this is no longer consistent with the rest of the code base and other contributors who are looking at it in
00:10:04.240
one place and moving to another are going to be confused about how these are related the next one is that the
00:10:10.399
maintainer may not like your changes right uh code aesthetics are a very personal choice
00:10:16.560
and that can be a really challenging thing to um get merged and then the last part of
00:10:22.480
this is even if the maintainer likes your changes likes your refactor and thinks that it is a good option what
00:10:29.440
they may say is you've moved a lot of tests changed a lot of code and you've created merge conflicts for other
00:10:35.760
contributors in this repository and our users have no new features and no new capabilities so even if they like it it
00:10:42.560
still may go unmerged the next one that i want to talk about is this challenging but rewarding category i love these and
00:10:49.040
they're such an exciting thing to work on like new features is what we talked about before it's empowering it's
00:10:54.800
exciting but again it sets up this expectation from users of that project
00:11:00.720
that that feature will be extended maintained and the bugs that are introduced with it are going to be picked up by maintainers so when you
00:11:07.360
create new features you need to make a case for why this is valuable not just for you but for other people in that and
00:11:14.320
other people who use that project this next one is different from the rest
00:11:20.079
of them so the first three here you're kind of having a maintainer is an obstacle like they don't want to merge
00:11:25.440
this particular pr but documentation is always welcome it helps contributors it helps maintainers it helps users of the
00:11:32.480
project and in addition to that it's very low risk it's very easy for maintainers to merge it and be and rest
00:11:38.320
assured that there are going to be no issues with the code base but i think what we need to acknowledge here is that
00:11:43.760
documentation is incredibly challenging in and of itself for a new user of that code base right so if we sit here and we
00:11:50.959
say i would like you to write documentation for this method by its very nature that method is undocumented
00:11:56.639
and documentation isn't about here are the parameters that you pass to this method that's facile right what's
00:12:02.880
important is to explain why and how this method is used
00:12:07.920
and if it's undocumented the person who is contributing who is visiting this repository for the first time has to
00:12:14.560
divine from where this method is called and all of the methods it calls and all of the little side effects and things
00:12:20.880
that may be hidden within it how this method is intended to be used however like i said these are incredibly welcome
00:12:28.639
maintainers are willing to partner with you and they're willing to help you with expanding the why and how and building
00:12:34.800
great documentation but we as an industry need to acknowledge that figuring out purely from the code what
00:12:41.120
something's purpose is is difficult and then taking that and writing it in such
00:12:47.040
a way that people who are familiar with the project can read it quickly people
00:12:52.560
that are new to the project have a thorough explanation of what's happening within it and that it's clear enough
00:12:59.040
that folks who um have english as a second language can understand and read what's happening
00:13:05.040
that is an incredibly challenging task and we need to acknowledge that this last category
00:13:13.760
ah thank you this last category are the easier and more welcome ones so with an existing
00:13:19.040
issue you have a buddy right there's a chance the maintainer's already seen it and honestly having another person to
00:13:25.200
back you up on whether this is valuable and another person to work with potentially even to pair program with
00:13:30.639
can make this a lot easier the next category is extending so one of the pr's
00:13:36.240
that i'm most proud of is the comparison validator that's coming out in real seven the idea is that you would be able
00:13:41.680
to say that a start date is before an end date right and when i built this what i was able to
00:13:47.120
do is i was able to look at existing validators and rails and say hey
00:13:52.160
this one uses comparisons this one extracts common language or common information into a module and imports it
00:13:58.959
into two validators i was able to look and say like hey there's test cases there's a test framework that's already
00:14:05.120
built for these and i was able to reuse a lot of what was there i think that extending is one of the great powers of
00:14:11.680
open source because maintainers can build a pattern and then open source contributors can swarm on it and extend
00:14:17.920
it and expand on it the last gold standard are ones that are tagged to good first issue this means
00:14:23.760
the maintainer has looked at it they think it's going to be a small change and honestly these are some of the first to
00:14:29.920
go which is why i want to talk about some of these other categories there's something that i've been implying here that i want to make very
00:14:36.399
explicit maintainers live with the code that you deliver right
00:14:42.000
you drop it off but when it comes to the bug requests when it comes to the extensions when it comes to the user
00:14:47.360
expectations maintainers are really thinking about the long-term future of the code that you've provided
00:14:54.079
and i think that this is something that really helps us understand how maintainers and contributors
00:14:59.920
interact all right but the next thing that i want to talk about is how to understand what
00:15:05.760
maintainer expectations are right maintainers have literally written you a
00:15:10.880
letter in the repository inviting you to contribute and telling you how they want you to contribute and be part of their
00:15:17.839
organization this is included in the contributing.md sometimes for larger repos like forum
00:15:23.440
and rails it's a whole site for smaller ones sometimes it's just a section in the readme but this really
00:15:29.199
is how you know what is acceptable and what's okay inside of that project
00:15:34.399
this is going to include information like style guidelines documentation how to request review and claim an issue
00:15:40.480
and most importantly it's going to have information about your developer setup and your tests and i want to talk about one specific
00:15:46.720
thing about open source so in your daily projects what you probably do is you
00:15:51.759
reach out to it and you're like i would like to be added to this particular project and you provide them with your github
00:15:58.000
username and then maybe they ask you like which projects do you need to be part of what are you working on they add
00:16:03.120
you to a team that is a cumbersome process for open source and also uh
00:16:09.040
maintainers often worry that they'll be responsible for any content that's been uploaded on branches so instead we use
00:16:15.440
forked repositories right so what you do is you have the original repo this is the location where
00:16:21.279
everything is this is where others changes are this is where the maintainers are and then you fork that repo and it creates a copy
00:16:28.639
that is on your account that is where your changes in local dev environment
00:16:33.920
live that's where you're going to push your changes that's where you clone them and then at the end what you do is you
00:16:39.199
point your pr towards the original repo if you do not point your pr towards the original repo as demonstrated at the
00:16:45.199
bottom of the screen what will happen is they will not see it it will exist purely on your account and
00:16:50.959
it will not be reviewed and speaking of prs let's talk about ways to give your peer the best chance
00:16:57.519
for success give it a clear description why do we want this what does it change what are some of the potential impacts
00:17:04.000
what are the resources that you used in figuring this out make it easy make it small in single purpose and also make
00:17:10.559
sure the tests and linting pass i'm going to tell you exactly how i maintain and manage my repos what i do is i look
00:17:17.039
at the list of pr's i start at the bottom i go through all of the green ones and i literally go up from the
00:17:22.079
bottom and then i go through the red ones the bottom ones by the way are some of the oldest ones and i think what's
00:17:27.439
important to remember here is with these small and single purpose ones um i'll often review it based on how long and
00:17:34.320
how many files it is like if it's one to three files i'll probably do it at work and nobody will
00:17:39.679
be advisor right if it's five to ten files we're waiting
00:17:44.960
until the end of the day if it's 30 plus files we're waiting until the heat does in the universe i'm so sorry i really want to review your pr
00:17:52.480
and i haven't closed it but it's 30 plus files and that's a lot to review
00:17:59.360
next one you want to make sure it's easy to test reproduce this ties into the description and then the last one is you
00:18:04.640
want to make sure that you're giving maintainers a quick response these are the people who are going to merge your
00:18:10.240
pr the shorter you can make that feedback cycle the faster this will be merged okay
00:18:16.320
we covered a lot of information there let's take a moment and kind of sit with it
00:18:22.320
our first step is we find a repo then we find an issue then we read the contributing.md fork the repo get clone
00:18:29.039
the fork repo locally set up your dev environment and then reproduce the issue okay so the vast
00:18:34.080
majority of issues in open source are very very bad they're created by volunteers sometimes there's environment
00:18:39.120
issues sometimes it's been closed in a separate pr like you cannot trust these issues make sure you reproduce them
00:18:45.520
next up is code documenting or translate i know you can do this i fully believe
00:18:50.720
in your ability to write code document and translate and i think a lot of people overestimate what is required
00:18:58.160
right like a lot of times the issue will even have like some basic implementation
00:19:03.280
information so i believe in you and i believe in your ability to complete this step last step create a pr and point it to
00:19:10.320
the original repo if you've followed all these you have created a pr
00:19:16.799
round of applause you are amazing that is enough
00:19:22.480
just creating the pr is worth the effort there are a lot of things that are going to happen after this stage there's going
00:19:28.559
to be a lot of back and forth but this was worth it so my first pr right
00:19:34.240
was an image change to a minecraft guide literally it was a one-line change to
00:19:40.960
swap a tool rack with a cow in a jar it had documentation it had comments it had a little description and everything
00:19:47.360
and it went unmerged for four years but what it did is it taught me how to
00:19:52.400
work with forked repos it made me feel confident in my ability to participate in open source so then when i saw that
00:19:58.880
dev2 had vimeo and they had youtube but they didn't have twitch embeds i said
00:20:04.159
well you know what there are some examples there i know how forked repos work i can go in and i can add that
00:20:09.760
dev2 by the way uses liquid tags in order to handle adding
00:20:15.600
embeds and that sort of stuff so i created a pr to embed twitch clips
00:20:21.280
when i started working with jekyll right i saw that they used liquid tags
00:20:27.679
regardless of whether the dev21 was merged i now knew how to create a twitch
00:20:34.080
liquid tag right and i felt confident in my abilities to do so so what i did is i learned how to make a
00:20:40.960
gem in order to wrap that liquid tag which means now at this point i know how
00:20:46.080
to make a gem that story started with a pr that sat unmerged for four years
00:20:52.080
right each step in that journey is worth it even if the immediate results aren't
00:20:59.120
what you wanted building that muscle contributing to open source being part
00:21:04.240
of that community is worth it and there are a lot of reasons your pr might be murder emerge that have nothing
00:21:10.880
to do with you so for example your maintainer may have 20 other pr's to review
00:21:16.720
they may be on vacation they may have a big work project most maintainers have a 40 hour a week job in
00:21:23.679
addition to what they're working on and we all know those 40 hours a week can sometimes turn into 60 to 70. and if
00:21:29.679
that happens your pr may go unmerged and unattended for a while one of the harder ones is they may have
00:21:35.760
found it hard to read or follow your pr and they may be waiting for that reason they may be figuring out how to say no
00:21:41.760
they may have decided despite your case despite your explanation that your future isn't one that they want to merge
00:21:47.120
into the project and that's a hard thing to deal with but it's a possibility on the other hand there may be future
00:21:53.200
work happening there right they may decide that there's additional work that's going to be set up um
00:22:00.799
they don't know for sure like what the expectations are and this may make the re-architecture the merges more
00:22:06.400
difficult right so these are all reasons that your pr might be emerged despite it being
00:22:12.400
beautiful well-written code right next we're going to talk a little bit
00:22:18.080
about maintainers and contributors because i think this is where a lot of the anxiety comes from is this kind of
00:22:24.159
fear of being reviewed in public so you have your contributors and there are a lot of things that you do right
00:22:30.320
creating issues updating documentation creating and reviewing prs once you're familiar with the repository itself
00:22:37.120
but with maintainers as a team they're responsible for a lot more they're merging prs
00:22:42.799
releasing new versions deploying to production and really setting the direction for the project they are
00:22:48.159
focused on the project needs as a contributor you get to explore and focus on your needs and you get to adventure a
00:22:55.200
maintainer has responsibility for the success of that project and making sure that it continues
00:23:02.240
to work for those users so that kind of begs the question like
00:23:07.280
why would you maintain a project right why would you take on that responsibility and i think there's three
00:23:12.320
big reasons i've heard of you want it to exist you want to share what you've built sometimes these people don't accept
00:23:17.679
contributions they're just like i just want to show you what i've built and you can copy it the biggest reason though is
00:23:22.799
you want help building it all of these though boil down to the same thing which is that maintainers
00:23:29.520
care about the project and you when you contribute you are gifting your time and attention
00:23:36.480
to the project that they care about there are a lot of things that get in the way right there are busy work
00:23:42.320
schedules and there are egos and conversations and a lot of other things and whether or not this is for the best
00:23:48.480
to the project but at the end of the day you contribute to the success of the
00:23:54.000
project and maintainers know that they want you there that's why they wrote a letter to you in the contributing.md
00:24:01.200
they want you to be part of the project i think of open source as a community
00:24:06.320
garden right the maintainers are there and they're like oh no that's not a weed that's actually a butterfly host plant
00:24:11.840
here's where the paths are please don't go through those gardens oh my god there's so many of you here and i don't know how to handle it but without you
00:24:18.960
it's not a community garden it's just a garden right like you are what makes an
00:24:24.880
open source project successful and amazing so don't be scared meet a nice repo and
00:24:30.240
build something beautiful and when you do please tell me what you built uh i go by chill or rachel you can find me at
00:24:37.120
chill codes and the places you typically find a developer i stream open source on twitch on sundays and two other days a
00:24:42.799
week as well so that's a really great place to find me i'm a senior full stack engineer at calmly and of course we are
00:24:48.240
hiring also i maintain an app called conf buddies that's built in rails and what
00:24:53.520
it allows you to do is it allows you to befriend other people at a conference and then know when you're attending
00:24:58.880
events together if you're still anxious about the process of open source hi i can be your first maintainer and i
00:25:05.360
promise it'll be a good experience thank you all so much for coming and do you have any questions oh wait sorry
00:25:19.440
okay do you have any questions yes hello yes you in the white cardigan and
00:25:25.679
the very nice black shirt yeah thank you so i've seen on some repos they have a practice of um like requesting to be
00:25:32.159
assigned to an issue yeah at like what stage should i ask to be a song should i go and scope out the
00:25:38.640
problem first or as soon as i see what i'm interested in go ahead and ask for that it really depends on when you're
00:25:43.760
comfortable being responsible for completing that issue personally i could scope it out first i'm like where am i
00:25:48.960
going to make the changes like what's this going to look like do i really want this issue or is it going to be bigger than i think it is and then what i do is
00:25:55.440
they ask to be assigned oftentimes i'll send the message asking to be assigned and then i'll get started on the pull
00:26:00.640
request even though i haven't been assigned yet but yeah that's a great question and what if you realize it's above your head
00:26:06.960
and you've already been assigned is there a way to like back out gracefully absolutely so most maintainers are
00:26:12.640
incredibly understanding of the fact that like you want to step away in fact a lot of maintainers what they do is they actually set up bots to unassign
00:26:19.919
people because you don't want to say like hey this person hasn't touched it for a month like we want to give it to
00:26:25.279
somebody else because you're worried about upsetting that contributor i think people don't realize how often
00:26:30.400
maintainers think about whether or not their contributors feel comfortable in their project because it's entirely
00:26:35.840
written communication um comprom had a great talk at strange loop
00:26:40.960
about like all of the processes and one of the things that she said was she automated
00:26:46.640
the emotional labor by having a process to unassign people so if you realize it's too much like feel free even an
00:26:53.600
hour later like a week later definitely like don't even worry about it like they'll understand
00:27:01.760
yes in the weed maps mask sorry it's the most identifiable thing
00:27:08.400
that's what it was i wasn't sure what this was right thank you uh good talk by the way awesome thank
00:27:13.679
you very very helpful uh i did have a question regarding like picking up
00:27:18.799
an issue uh similarly like in jira they could depend on somebody else or maybe you have to wait and you have to
00:27:24.559
contribute with someone else as well what's the process there what if do you have to
00:27:31.039
kind of find time to work with someone else or you're blocked by somebody else's work at the time or i don't know maybe
00:27:38.000
someone else is relying on you yeah so blockers are significantly less common in open source than they are in
00:27:44.399
our everyday workplaces because people understand that you could step in at any step of the process and
00:27:50.080
like pick up the issue it's far more common for an issue to be broken down into like this needs to be created and
00:27:56.159
then later the second issue will be created because also um maintainers don't know how long it's going to take
00:28:01.200
for someone to pick up the issue so most of the times they don't create the second one until afterwards but if so
00:28:06.320
like normally what happens is after the first one is merged that's when the second one becomes available to pick up
00:28:13.520
does that answer your question
00:28:20.559
uh yes in the front row
00:28:26.240
uh you you said the thing about um having someone uh document how the code
00:28:31.600
works is actually like a really difficult task and that unlocked like a feral anger in
00:28:36.720
me that i forgot i had um because a lot of times you onboard to an engineering team or an engineering
00:28:41.840
team has a new hire and they're like yeah we're just gonna turn you loose and have you write some documentation i'm always like i actually don't think
00:28:47.200
that's a good task um but i didn't really understand why are there other things that you've
00:28:52.799
learned from open source that you feel like have changed how you approach like you know you kind of like paid daytime
00:28:58.480
job oh yeah absolutely so i mentioned before that open source is mostly happening
00:29:03.679
remote uh asynchronously so when i stepped back into the corporate world i was kind of like oh i'm ready for this
00:29:10.799
what i do is i document a lot more and describe what i'm trying to do a lot of
00:29:15.919
times we'll say like oh i need to know how to build this like i'm going to set a 30 minute meeting on someone's calendar
00:29:21.360
but your memory of that 30 minute meeting is less accurate after an hour and i guarantee a month later you're
00:29:27.279
going to completely forget what y'all agreed to and said unless it's written down and that's why having conversations
00:29:33.200
on pull requests communicating what you're looking for allows that conversation to be available years later
00:29:39.679
and my time in open source has kind of trained me to approach things from a remote first perspective and a written
00:29:46.320
first perspective which i think is incredibly helpful
00:29:52.159
thank you oh yes
00:29:58.559
hi there um so i have a question if you are struggling with your local development setup or reproducing
00:30:06.159
the um issue is there like a good way to get unblocked or communicate with the
00:30:12.720
maintainers that would be like more effective absolutely so the the first approach i
00:30:18.080
think is to really comment on the issue and say i was unable to reproduce this and here's why i think the second main
00:30:24.159
way that you can do this is you can look and see if they have a community discord if they have a community slack because a
00:30:30.000
lot of much larger projects have these
00:30:35.120
and i think that that's a good way to approach it but my first instinct would be to comment on the issue this is asynchronous and it's one of the places
00:30:41.279
where things kind of break down because it takes a little bit longer but yeah that would be my first approach because again a lot of these issues are not
00:30:47.440
going to be valid right like you need to take the time to reproduce them and if you comment on it it may just get closed
00:30:54.640
yes thank you that was a great question are there any further questions
00:31:02.640
i want to thank you all so much for coming here if you want to ask me further questions oh goodness gracious
00:31:08.159
i'm so sorry um you can again find me on twitch my twitter dms are open i'm on the discord
00:31:14.480
and feel free to grab me in the halls i like meeting new people and i like talking with you all and also when i
00:31:20.559
said tell me what you built i mean it tell me when you changed the color of a button and i will be so incredibly
00:31:27.760
excited with you thank you all so so much and i appreciate you
00:31:34.960
okay