 Go ahead and get started. So you guys are in teaching GitHub for Poets. I am Aaron Suggs. I go by K Theory on social media. I'm the lead operations engineer at Kickstarter and I'm a terrible dancer. This is me dancing horribly in a grizzly bear. It's called the Grizzcoat. It was a Kickstarter reward. Yeah, I'm always a little nervous starting out these talks, but I feel like once you guys have seen me dancing poorly in a grizzly bear suit, there's nowhere to go but up. So I work at Kickstarter. Kickstarter's mission is to help creative projects come to life. We are a Ruby on Rails application. You guys probably know how it works. If you have an idea for a comic book or a film or a gadget or a software project, you post your idea with a pitch video. Your friends and family and strangers on the internet pledge money to it. That's sort of the ultimate way of saying I want this thing to exist in the world. And if you get enough money to complete the project, then we collect that money, pay it out to you, and you can go on and build the thing you want to do. In my role as the operations engineer, it's my job and passion to make tools and processes that help the engineering team and the whole Kickstarter organization do awesome work. And to that end, one of the programs that we do is called GitHub for Poets. So super quick outline of what I'm gonna cover in this talk. I'm gonna talk about what GitHub for Poets is, why it's awesome and useful and beneficial for our organization and for your organizations too, and how you can implement it yourself. Yeah, so jumping right into what GitHub for Poets is. So it's a really quick class. It takes about an hour that goes over how to make a copy change to our website. It's using the GitHub flow and browser, so we're gonna be finding a file that we wanna change, changing it, committing it, making a pull request. It's open to all staff. Everybody in the organization, not just developers or designers or people that you'd expect to be committing code and working with a Rails app. And it's also an introduction for everybody in the company into the tools and processes that the engineering team uses. Really trying to be accessible and clear and transparent throughout the organization of what we're working on. The name GitHub for Poets, by the way, is a reference to a lot of liberal arts schools, my college at least, had this physics for poets class. The idea being it's sort of an elective class geared towards people who weren't going to become physics majors but want to have, just part of enriching their lives, they should know something about electromagnetism and relativity and things like that. And so this is the idea that people, there are lots of people in our organizations that aren't expected to be doing Rails development or working with GitHub on a day-to-day basis, but knowing something about it can really improve their workflow. So that's where the name comes from. I wanted to dig in a little more into what each of these three bullet points entails. So doing a live demo of a copy change. So the GitHub flow and browser, for those who aren't familiar with it, is a way of just finding files to edit and editing them and committing it all inside Chrome or Safari or something like that. The great thing about this is there's nothing to download or install. You don't have to tell people to open up the terminal, you don't have to get clone anything. You're just searching in your GitHub repository, a lot like you'd search Google or something like that, something else. So the learning curve on getting started, both in terms of technical know-how and the commands you actually have to run is very, very low. Like you don't have to run any commands, you just go to a website. And this flow of finding a file to change, changing it and committing it and then making a pull request, I see that as sort of the fundamental development loop. Like that is the cycle that all engineers and designers and anybody building a product. That is the cycle that you're doing over and over again. And to show that and make that accessible for people who aren't familiar with it, it's a really powerful tool. This has really helped like our community service team or our integrity team who would be trying to find confusing parts on the site. Maybe we had a poorly written validation or something like that. They would use this to improve copy changes. Also, because we're just changing copy like the text in views or emails or something like that, you don't really need to know Ruby programming at all. We don't need to get into really at all like how Ruby works, how Rails works. This is the kind of thing that you can cover in an hour and come away feeling like you have a better understanding. So like I said, it's open to all staff. What that means at Kickstarter is we have about 110 employees. One third of them work on the product either as engineers or designers or product managers. But that means most of the employees at Kickstarter are doing things like HR and maybe like doing recruiting or managing our job postings or things like that, doing some legal stuff like if we ever upgrade our privacy policy or terms of use or something like that. Those are code changes that are really just text changes that people who have gone through our GitHub for Poets class can do. A lot of the community support team is also making these kinds of changes in a much more straightforward way than before we had done this class. It's sort of grown to become, GitHub for Poets has sort of grown to become part of the onboarding process for new employees. I think of it as analogous to how a lot of companies have customer support rotations where every new employee spends a day answering support emails because that is a great way to get to know what your customers are seeing when they're interacting with the product. Similarly, if you wanna know how engineering and how a product development team works, showing them this cycle of how the sausage gets made is really eye-opening and often startlingly easy for a lot of people who aren't familiar with it. They sort of assume that you're doing really complicated, genius hacker type stuff because that's how it's portrayed in Hollywood. But if you just show them it's like, you're doing this really simple thing. I'm just changing some text and some files. It can really improve their understanding of how engineering works. And right, so it's an intro to the tools and processes we have. This has to, this is involved with how you run tests before deploying to production or something like that. So we'll talk about how we have a continuous integration environment, how we test things like you have to, if you sign up with a username and password and you submit those username and passwords, you'll be logged into the website. And similarly, we'll have testing things that shouldn't happen. You can't have two users sign up with the same email address or something like that. We explain just as much git as you really need to in order to do that development loop, which is really just two things, like commits and branches. If you understand a commit as like a single change with a message describing why you did that change to a file, that's a commit. And a branch is just like a list of all these changes being made throughout history. And any branch can represent all the work you've been doing and these branches are safe places for you to do your work without affecting anybody else's work. Rails, we explain, is a collection of tools for building dynamic websites. We don't really have to go into the nitty gritty of how active record works or something like that. We just need to show them the directory layout. Most of the copy lives in app views or app mailers views or maybe in config and some YAML files. And this is a great way we've made the engineering process transparent and inclusive for everybody in the Kickstarter organization. So because people, poets are going through this process and they're doing this loop, we end up in this place where everyone in our organization can commit code. And a lot of people, when they hear this, they sort of have this reaction. I'm the guy in the middle, who thinks it's pretty great. So what happens when you let everybody in your organization commit code? It actually works out pretty well. And I'm gonna go now into the middle section of why it's pretty awesome to do GitHub for poets. So the biggest reason is it makes our process more lightweight for making easy changes. It used to be the case that our community support team would notice that a validation message is confusing and generating a lot of support tickets. Or they'd notice that there's a typo on the website or something like that. And people were actually writing in to correct this typo because most of the copy was written by engineers at the time. They would tell this to their VP of community support. VP of community support would have a weekly meeting with the VP of engineering who would then say, okay, yeah, these are all things that we need an engineer to fix. And then file these really simple changes into our ticketing system so that an engineer can go and fix the typo or clarify the error message or something like that. So the process was really, somebody noticing something that they weren't empowered to fix telling their VP, VP tells another VP and then that VP like trickles down to the people who actually fix the problem. And that is just crazy. That is way too much process to fix something that anybody that should be really easy to fix. So GitHub for poets now just means that the person who notices the typo who notices that a validation is written in a confusing way. They can edit that file themselves, put up the pull request and an engineer will get pinged and they'll know to merge and deploy it pretty shortly there afterwards. Everybody else is informed but no longer part of that critical path. They can see what happened but you don't have to wait on your boss to tell you that it's okay to do something. Another really great reason to do GitHub for poets is that it lets you avoid building a CMS. So as you're making these minimal viable product features and things like that and you're just throwing stuff out there and trying to see if it works and you don't know if you're gonna be committed to this long term, there's often this sort of awkward phase of a product, of a feature where it might need to become a CMS at one point where you're gonna be changing it so much that you want other people to just be able to fix it themselves but you don't know if you're actually gonna change it that much. In our case it's like, we have a lot of editorial features where people, like staff could highlight different films or comic books or something like that and we have these flexible pages but we're not sure exactly how they're gonna wanna change them or what the rate of change is gonna be and having GitHub for poets lets us say, well, you just go in and edit this view just like we use Hamel and Hamel's really easy to learn and so you're just like copying these chunks around and if the test passed that means there's not a syntax error and we'll check it on staging on its way out to production and it's just a low risk change that saves a lot of engineering effort in storing all this stuff in the database or something like that when we don't really know what the full life cycle of that feature is going to be. Thinking of this another way, version control is a content management system and you're just letting everybody use that thing instead of building your own bespoke content management system. All right, so those are very practical reasons why you would build this, right? This is like you saving yourself work, you increasing the productivity of the engineering team. The real, the really awesome benefits I think are the more cultural value. The cultural reasons for doing this, right? And I'll say we kind of stumbled into some of these, like initially GitHub for Poets was just going to be, it was Ruby on Rails for Poets because we wanted to teach, some people really wanted to learn Ruby on Rails and we said we have a Ruby on Rails app, like we'll just show you how it works and we'll be helpful and then people, A, it was like way too much material to cover in a couple hours, like boot camps are 12 weeks long or so and you're just like getting started with one of those and so it was ridiculously over ambitious to be like, oh yeah, we'll just spend a couple hours talking about Ruby on Rails and you guys will get it. But what we found was like as we started talking about how Git works, it was sort of this mind blowing experience being like, you guys have so much transparency and context about every change that anybody has ever done and we ended up just talking about how GitHub works the whole time. So our values here that we're sort of realizing is we wanted to improve the transparency with how, like the engineering process. You know, sometimes there are features that are about to go out and at the 11th hour we notice of security liability or a performance gotcha or something like that and it'll be in the pull request where we're like, whoa, I think this is not gonna really work that well, like we gotta refactor it or something like that and for everybody on the marketing team to know that that's why this feature is delayed and like because we're building this extra stuff into it, it's great to just have them be part of that workflow. So that's the transparency and the inclusivity part of it. There's also a lot of consensus that is sort of baked into the pull request cycle that we use, which was pretty surprising for how a lot of people, for how a lot of other departments make decisions. So what we're kind of realizing here is that version control is a communication tool really in the same league of like your chat or email clients that you guys give access, everybody in your organization should have access to your chat room. Everybody in your organization has an email address. People can email each other that your version control for your product is this rich history of why you built everything and how it was built. And thinking of it that way, it's like of course everybody should be able to see that context. It's so useful to know that the product was built this way because of these very good reasons that were hashed out in this engineering, like in this discussion amongst engineers on a pull request and why that's not a simple change, like what you think might be a simple change is not actually a simple change. It's really kind of amazing to think that as we work, we're building up this story of how we built things through our GitHub commit, or through our Git commit history almost as like this byproduct. And that idea that I'll be able to go look back in time and have something trigger my memory of why I did it that way, that's really powerful. And it was almost like a fish in water kind of moment for me, realizing like I'm thinking of the David Foster Wallace anecdote about two fish swimming past each other and one fish says to the other like, oh he says, how's the water today? And the other fish says, what's water? And it's getting at that thing that's like so ubiquitous to the way you work, you don't always realize it's there. And so engineers using version control, we are used to this idea of having this rich context around how we built things that when other people see that for say, community support or a marketing team, it's sort of a mind blowing experience for them to know that they have those sorts of tools for their own documentation or something like that. So yeah, version control is really increasing the transparency that not just the engineering team had or like other teams had with the way the engineering team works, but it turned out that other people wanted this for themselves. So they started making their own repositories for documentation or for like policy documents of how they would handle troublesome cases or something like that. So those decisions now have this like commit history and a pull request and this rich context of the discussion around why a particular thing is the way it is. So I should say too, this is called GitHub for Poets, but it's really pretty applicable to any version control system. The one thing I particularly like about the way GitHub does pull requests is they're sort of getting your, getting this idea of consensus as a sort of a political tool for decision making or like a tool for governing what code is good enough to get in master and to be deployed to production and things like that. You do it by asking in a pull request. And so even beyond a commit history, pull requests are even adding this even richer context about what the discussion is around this, not just what the developer says in their pull request, but it's like really this dialogue between several different parties. Maybe it's the product manager who's urging like the getting something out quickly because there's an important deadline to meet or something like that. Another security engineer talking about security trade-offs, somebody asking about performance. All this conversation is happening in the pull request. Now also because everybody else is, everybody in that organization is on GitHub, we also have a marketing person in there who can be like tweaking marketing copy up to the last minute as they figure out how they want to position this new feature. Another really cool thing, the other really great thing about pull requests is that there's this shared responsibility that's implicit in them. That if things break, because as a result of you merging your pull request in and deploying it, it's not entirely your fault at all. In fact, we have a pretty blameless culture too and so it's not your fault at all, but in any organization that uses pull requests, you put it out there and you ask people to help you make it better. And it really sets this expectation that you're not, like nobody's doing perfect work, but we at least expect you to ask how you can make it better. And I just see that as like a really mature, a mature attitude and a mature way for teams to work. And once other teams saw the way engineering did that, they wanted to do it themselves. So those are some of the cultural reasons why you should do GitHub for poets. The last reason is a really self, it's kind of a personal reason for you and in your career development, this is a great way to increase your impact in your organization. And so as you level up and progress in your career, you'll find that one of the things your boss expects of you is to have ever greater impact. Like you should be able to manage yourself really well, then you should be able to improve the way your team works and then you should start improving things throughout the organization and ever greater concentric circles of impact. And GitHub for poets is really like a few hours of your time teaching the class, getting everybody into your GitHub organization, answering their questions about how it works, merging and deploying their pull requests when they're ready to go. And it can have a radical change on other department's workflows because it's so much easier for them to make changes on the site. Like that is now a tool in their toolkit of things they can do. And it creates this better attitude around working with this asking for consensus and expecting transparency in this rich context in how decisions were made. So the final reason to do GitHub for poets is because your boss will like you for doing it and you will make your organization better. All right. So how to do GitHub for poets. This is sort of a whirlwind tour, maybe even like a mini session of what GitHub for poets is like at Kickstarter. So the things I explain upfront are how branches and commits work because it's really confusing to use GitHub.com at all without understanding what a branch or a commit is. We explain the sort of bog standard Rails file layout. Really the important places are app views and app mailer views and your config file if you have a lot of copy in YAML files. A nice analogy here which I'm cribbing from my friend Emily Reese who co-taught the class with me is think of like in college for each semester, you would have a folder of like all the classes you took and in each folder you'd have like a term paper one, term paper two, so on and so forth. And so it's just like this big hierarchy of folders with a bunch of files in them and like really that's all our code bases are at the end of the day. And for somebody who's not used to programming, like that can be a radically simplifying view of how our code works. Another really important thing is this idea of always be learning. A lot of people are reluctant to start contributing because they feel like they don't know enough to do that and they wanna be like an expert at all the things before they make their first copy change. And you have to disabuse them of that notion that they're ever gonna feel like they're an expert at all the things. And that engineers never feel like that either. This always be learning concept is pretty important so it gets its own slide. One of the, I found one of the most useful things to do in these GitHub Proposals classes is to demystify the development process. We've sort of, our engineering team has sometimes been glorified as like these really elite smart hackers who have this sort of like communal mind meld with computers and can just make it do amazing things. But actually we're trying to do the most simple things. Like we are generating Rails scaffolding and it is just not rocket science. We are Googling for a gem that does most of the work that we wanna do and we're not doing something really clever. So really lowering the barrier to entry, like lowering the amount of knowledge that you need to have to get started. I like to talk too about how this dovetails with the programming pattern, I like the philosophy of dry, don't repeat yourself, dry. In a macro level, this means that if you were writing code to do something that you've already written before, like that's not dry. And you would just reuse the code that you've already written. And so as a kind of corollary to that, it means that you're always writing code to do something that you've never done before. If you were writing code to do something that you've already done before, you would just use that old code. So it's really, you should really just get comfortable with the idea of you're always going to be working at the edge of your comfort level. And also that it's really okay to ask for help. It's okay to ask an engineer how to do this thing or what this files for to show you how Git history works or something like that. Engineers ask for help all the time from Google and Stack Overflow. Yeah, so that's what I go into when doing a GitHub for Poets session. I also just wanted to do a really quick live demo here of what it involves. So if anybody else wants to follow along too, I'm gonna go to github.com slash ktheory slash Rails demo. And we're gonna see how well my networking works. Let me hop over to your display. There we go. I know the contrast might not be great, but yeah. So we're looking at a very bog standard Rails application. In this case, I just did Rails new and then I generated a user model scaffolding. So as the whimsical copy edit that we're going to do, I'm gonna go to the user listing and we're gonna increase the SEO of that page. So to find out, I know that there's a user listing somewhere, I don't remember where it is. So I'm just gonna search for it. Sure enough, there it is. App views users index.html.erb. I'm gonna click into one of these line numbers that I wanna edit. And so sure enough, this looks like HTML. There's a little bit of magic down here that I'm not gonna worry about because I'm not trying to change that part. So in order to edit this, I need to go from the particular tree back to a branch. So I'm gonna hop on the master branch and then I'm going to edit this file. And so I wanna be sure that people know as we're listing users, I wanna add a subheader to here that I don't know, expresses what I like about monoliths. So let's say monoliths are, okay, now audience participation time. Monoliths are what? Help me out. Majestic integrated systems. All right. And you guys are all encouraged to make your own pull requests right now too. So now I'm gonna commit this and I'm gonna commit it to a new branch. I'm gonna describe what I'm changing. Oh, see, I already typed this out. So I'm changing the user listing and the reason I'm doing this is I'm adding some SEO around monoliths. And then it's always nice to show the emoji. All right, and then we come up with, we try to encourage reasonable branch names too, but honestly, it doesn't really matter. There are so many branches. You should just let it go and they're never gonna be neat and tidy. Just embrace the chaos. So we could leave this or we could call it something like RailsConf monolith SEO. And now I'm gonna propose this file change. There we go. We can preview this. We should say what feedback we would like in this pull request. Pull request, please check if monoliths are actually majestic and or integrated. And we can at mention DHH for that, I guess. I don't know. And then we create the pull request and then we're pretty much done. So in our process, where it goes from here is we have a support engineer, it's sort of a weekly rotating basis of that's the person who is trying to stay on top of whatever bugs come up and basically absorb interruptions from other engineers. And so they'd get app mentioned in one of these pull requests that just give it a quick spot check. We have the continuous integration set up so we get the nice green check mark. And if all looks good, they just deploy it and it's out on production within a couple minutes. All right, thanks. It's good to see some participation on this pull request. Yeah, all right. I'll hop back to the slides. Yeah, okay, so that's more or less what we cover. There are a couple common concerns that people have when they think about giving everybody access to their GitHub repo. Most common I hear is they'll break the site. Honestly, the poets themselves are incredibly concerned about this. In fact, I'd say they're even more concerned than engineers and people on the product team about breaking the site. So as a result of that, the people who've gone through the GitHub for a poet process tend to be very cautious and they will ask for help a lot. Even though they're making what are from an engineering perspective, very trivial changes. Just fixing typos, moving some words around is not gonna have a significant impact on your site. The worst thing that we've had happen to is like there's, because we use Hamel, like indentation has gotten screwed up and then we discover that because a test fails. You should be testing your views, pro tip. So yeah, these are really low risk changes and they're changes that can have a really awesome impact because believe it or not, the copy that's on your site is actually a huge part of your product. Some small copy changes can have a really impressive effect on how usable your product is and how well it converts. So yeah, we have not found it to be the case that giving more people access to our code repository has decreased code quality or it hasn't been a liability for the website. In fact, it's been the opposite. So other people are worried about security, that our code is so special and it's so dangerous for everybody else to be in there. I also think this is kind of crap. So first of all, we have to remember that there's a communication medium, right? Version control is a communication tool. This is just like chatter email and there's always a possibility with every communication tool that if that information got out, it could be damaging or just like embarrassing. So that's true, but it's a trade off that you always accept because chat and email are so helpful to increase your productivity so much that it's worth the risk that if somebody had a bad password, like all that information won't get leaked. And so there's some really easy stuff you can do to improve your security too. Like we have everybody use one password so that they have strong unique passwords for every website they use. You can require two-factor authentication for lots of important stuff. Also, another reason I think this is kind of a bad excuse to not do this is that your code is not a trade secret. Your code is not that special. Most Rails apps that I've seen are just mostly Rails scaffolding with some small customizations and a bunch of gems that you're requiring. Like that is the majority of the cleverness that goes into most Rails applications. We are not trying to make clever genius apps. We are trying to build simple things quickly. If our code was ever leaked to the public or something like that, we like to think that another Rails engineer would look at it and think, yeah, oh yeah, that's how I do it too. Like it's the obvious thing to do. We're not trying to be clever, we're just trying to make it easy and obvious. And so as a result, it's really not that much of a security liability. Also, so a few pro tips here. These are some things you should also have in place just to make sure that all your bases are covered in terms of security and site reliability and stuff like this. I'm sort of putting on my ops hat and be like, we have to say these things. So you should, like, poets should know that when they're working in a Git branch, it's really their own space to do whatever they want to experiment as much as they want without affecting anybody else's work on any other feature. So anything they do in their Git branch is not gonna break things for production or break things for other developers. You have lots of tests and continuous integration to catch lots of obvious features that if something managed to slip through all this, your process of checking it on a staging environment or a production environment and it passed all your tests and things like that, it's really a breakdown in the engineering process. And I think of it as kind of my problem to have a better process that would make sure we would catch these things before they get out. If they get out and there's still a bug, it's probably gonna be a really minor bug. And yeah, another safety check is that we have deploy, whoever's doing the deploy scans exactly what commits they're deploying and just like sanity checks that these are what they expect to be deploying. So if a poet like forgot to create a branch and committed directly on master, that goes into our chat room and everybody would see it immediately and we'd be like, hey, did you mean to do this? Is it a really important change that needs to get out right away? Or if not, we'll just revert it and we can say, okay, let's go and do this through the pull request flow. Another thing that we've gotten a lot of questions about is what it means when you get a thumbs up in a pull request. It means something positive, obviously, but does it mean like you can merge this and it's ready to deploy? Or does it mean like I like the idea that you're doing this? Does it mean that I like this particular feature but I'm not sure about the, like it doesn't mean you like the implementation or do you like just the direction that the feature is going? This is actually a surprisingly rich emoji. So, yeah, talking about like this often just means, like it can really depend on the context whether this means like actually good to deploy or just like congrats on making a pull request. All right, so I wanted to show you guys who some of the poets are at Kickstarter. These are a bunch of our employees who have gone through GitHub for Poets and have then gone on to make several commits and pull requests. In particular, oh yeah, so there, I did a little grepping through our Git history and realized that of the 70s or so people who have gone through GitHub for Poets class, 29 of them have gone on to like actually make a pull request that we then merge into master and have a total of 1100 commits, which I am, I think is super amazing. Like that is 1100 times a developer didn't get interrupted to do a trivial copy change. That's a lot of time saved and that is a lot of people who have an improved workflow. That's a lot of people who were able to fix a solution by making a change to the website instead of say making a support macro to reply to a customer support ticket. So actually there's a whole anecdote behind that. There was a confusing part of our video uploader where at a support meeting, they were saying like oh, all these creators are writing and confused that they're not seeing a video preview when they're expecting to because it takes a while to transcode and maybe we're getting enough of these tickets, maybe I should just write a macro so we can like reply to them more quickly. And then they realized like wait, we can just edit the HTML around the video uploader and just like put a message being like we're gonna show you a preview on the next page, don't expect to see your preview here and then you don't even get the support ticket in the first place. It's just like a big win for contextual help. And longer term there was like we wanted to, engineering wise, we wanted to show the preview but it was just a complicated front end stuff and like asynchronous. It was, we wanted to build it better, we weren't gonna get to it soon and just adding one div tag of inline help was a big win that drastically cut support tickets. I wanted to call out third from the right is Carol and she has alone made 312 of these commits. She's on the copywriting team now because she's so awesome at editing and making our copy really pop. There's an interesting scenario where a copywriter started recently and her first project was to get familiar with all the tone and the copy on the site. She looked for any place where we weren't using a serial comma, which is this grammatical pattern where if you have a list of three or more things you have to have a comma for the final item. She felt very strongly about adding those because it clarifies what you're talking about. But so she goes through and makes all these pull requests like each one fixing a serial comma and this was like her first week on the job and she'd never used Rails and never used GitHub before. It was pretty great. Yeah, okay, so final thing is like, here's a slide, I don't know how well this shows up because it's on a light background. But yeah, this is an example of our colleague Emma making a pull request and just, I really thought she was doing a great job with the emoji here. Lots of people chiming in right after she makes the pull request, it's a good feeling when other engineers are congratulating you on a job well done for making your first pull request. Because I have, because I'm up here, I get to sort of talk about a weird abstract law or thing that I would like to happen and that is that coding becomes more like writing and what I mean by that is writing is a tool that we spend thousands of hours learning how to read and make written language. Like it's not something that comes naturally to humans at all, it's something we work very hard at and it's worth doing all that because it's so useful to use written language. It's such a powerful way to communicate ideas and starting a few generations ago using computers and software is gonna be just as important. This is something that people spend thousands of hours learning how to use software, learning how to use computers, but it's something that is worth investing that time because you use it all the time and it's so helpful. And so I see GitHub for poets in a small way helping us along that path of making our engineering, like the software development process a bit more accessible and giving people another tool in their toolbox as they're trying to solve problems to try to solve it by editing our code base. So the final couple slides here are examples from the Kickstarter homepage that things that have been made by poets. So this is an actual screenshot of the Kickstarter.com homepage at one point. We have these big like hero graphics where we're calling out things that we wanna highlight on the site. So this one was about films. In our GitHub for poets class, we play around with editing these hero graphics in a pretty fun and whimsical way. So behind the camera here is our co-worker Liz. So here's what the poets came up with. Another actual hero graphic that we had on the homepage was highlighting video games. At the bottom there it says 87,000 Kickstarter backers helped produce the video game Broken Age. But when Catherine got ahold of this, it turned into a dogecoin scheme where 87,000 dogecoins sent to Catherine and the call to action button says send more dogecoins. And our final one, highlighting library projects, but the way GitHub for poets actually ends up often is people everywhere creating chaos. So that's the end of my talk. I'm K theory on social media. If you guys wanna hit me up there, I also have time for some questions. I actually, maybe I don't, but come up and ask me questions. And just in case there was some people here who were really wanting some poetry, I'll leave you with some bad git poetry. All right, thank you.