Teaching GitHub for Poets
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 30 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30709 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201530 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
Online helpAlgebraische K-TheorieCodeOperator (mathematics)Degree (graph theory)HypermediaComputer animationLecture/Conference
00:48
Self-organizationProcess (computing)Cartesian coordinate systemProjective planeOperator (mathematics)FamilyComputer programmingInternetworkingSoftwareVideo gameQuicksortVideoconferencingComputer animation
01:43
AreaComputer fontSelf-organizationGodProduct (business)MathematicsStaff (military)Cycle (graph theory)Task (computing)Message passingCodeSpektrum <Mathematik>Online helpBranch (computer science)EmailSoftware testingComputer fileSocial classTheory of relativityComputer programmingWebsiteElectronic mailing listSyntaxbaumService (economics)Row (database)Directory serviceBasis <Mathematik>Continuous integrationSoftware developerView (database)Confidence intervalWaveProcess (computing)Open sourceAddress spacePhysicalismPoint (geometry)Inclusion mapInformation privacyTerm (mathematics)Data managementLoop (music)MereologyRadical (chemistry)Web browserGoogolCurveHacker (term)DataflowQuicksortType theoryRotationFundamental theorem of algebraDemosceneINTEGRALWave packetIntegrated development environmentOrder (biology)BuildingPasswordValidity (statistics)Mobile appConfiguration spaceDemo (music)Graphical user interfaceInstallation artComputer animation
09:49
Physical systemCommitment schemeSelf-organizationCodeSheaf (mathematics)Process (computing)InformationPoint (geometry)Web pageMathematicsCASE <Informatik>QuicksortContent management systemContext awarenessRuby on RailsValidity (statistics)WebsiteUniform boundedness principlePhase transitionWeightProduct (business)Lattice (order)Execution unitCanadian Mathematical SocietySound effectInformation securityBit rateBuildingMereologyView (database)Software testingCycle (graph theory)Error messageMultiplication signVotingComputer fileDecision theoryTelecommunicationWordDatabaseClient (computing)Video gameNormal (geometry)Maxima and minimaData managementStaff (military)Right angleAddress spaceTerm (mathematics)EmailRevision controlBootingBoss CorporationOnline chatMessage passingInclusion mapLevel (video gaming)Content (media)Online helpDifferent (Kate Ryan album)Meeting/InterviewComputer animation
16:43
Product (business)MathematicsFlow separationRevision controlConcentricDifferent (Kate Ryan album)Expected valueSocial classCapability Maturity ModelCodeWater vaporSelf-organizationContext awarenessPosition operatorEuler anglesResultantDependent and independent variablesForcing (mathematics)Rule of inferenceData managementArithmetic progressionBoss CorporationQuicksortSemiconductor memoryMultiplication signRepository (publishing)Information securityCASE <Informatik>Software developerWebsiteMoment (mathematics)Decision theoryData conversionSoftware development kitRadical (chemistry)Online helpCommitment schemeSurfacePolarization (waves)Figurate numberBuildingComputer animation
23:12
HypermediaOnline helpQuicksortTerm (mathematics)Computer fileHierarchyBuffer overflowCodeMultiplication signAlgebraische K-TheorieBranch (computer science)Software developerDemo (music)Coma BerenicesNeuroinformatikProcess (computing)Social classHacker (term)Slide ruleMilitary baseSoftwareBitExpert systemMathematicsVapor barrierMacro (computer science)View (database)AnalogyComputer programmingWritingConfiguration spacePattern languageLevel (video gaming)Contrast (vision)Standard deviationMobile appStack (abstract data type)Electronic visual displaySoftware design patternComputer animation
27:38
Electronic mailing listSubject indexingMultiplication signBranch (computer science)Line (geometry)NumberQuicksortComputer fileEndliche ModelltheorieSoftware bugBitFeedbackINTEGRALInterrupt <Informatik>MereologyGreen's functionPhysical systemMathematicsContrast (vision)Cartesian coordinate systemStandard deviationNetwork topologyDependent and independent variablesCASE <Informatik>Order (biology)Product (business)Continuous integrationShared memorySlide ruleWeb pageProcess (computing)Basis <Mathematik>EmailRight angleMobile appChaos (cosmogony)View (database)Computer animation
31:47
PasswordCodeMathematicsWebsiteOrder (biology)Continuous integrationMereologyQuicksortIntegrated development environmentProduct (business)AuthenticationSpacetimeBranch (computer science)Revision controlArithmetic meanHypermediaCASE <Informatik>ImplementationControl flowRepository (publishing)Direction (geometry)TelecommunicationSound effectContext awarenessSoftware developerSoftware testingProcess (computing)Right angleCartesian coordinate systemLevel (video gaming)EmailInformationResultantInformation securityPort scannerOnline helpMilitary basePoint (geometry)Online chatChainTerm (mathematics)Software repositoryView (database)Perspective (visual)ThumbnailDataflowWordOperator (mathematics)Software bugComputer animation
38:23
Macro (computer science)Right angleOptical disc driveProjective planeCopula (linguistics)WeightWebsiteTotal S.A.Text editorVideoconferencingSocial classMessage passingPattern languageCodeWeb pageMultiplication signMathematicsSoftware developerFiber bundleElectronic mailing listMereologyTerm (mathematics)Process (computing)Division (mathematics)Online helpBitSoftware testingLattice (order)Slide ruleComputer animationMeeting/Interview
41:36
Process (computing)Slide ruleRight angleElectric generatorNeuroinformatikAbstractionQuicksortSoftwareSoftware developerCodeFormal languageBitMultiplication signHome pagePhysical lawComputer animation
43:39
Library (computing)Coma BerenicesWeb pageNumbering schemeProjective planeHome pageGreatest elementChaos (cosmogony)System callGroup actionFile viewerPoint (geometry)Video gameWebsiteOnline helpSocial classAlgebraische K-TheorieComputer animationLecture/Conference
44:59
Multiplication signCASE <Informatik>Logic gateAlgebraische K-TheorieHypermediaComputer animation
Transcript: English(auto-generated)
00:00
Go ahead and get started. So, you guys are teaching GitHub for Poets. I am Aaron Suggs.
00:21
I go by Ktheory 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. And yeah, I'm always a little nervous starting
00:41
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
01:01
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, like, 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
01:20
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, a super
01:44
quick outline of what I'm going to cover in this talk. I'm going to 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.
02:03
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 going to be finding a file that we want
02:24
to 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
02:41
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.
03:01
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
03:23
that 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.
03:41
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
04:00
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 git clone anything. You're just searching in your GitHub repository, a lot like you'd search Google or something like this, something
04:21
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 a file to change, changing it and committing it and then making a pull request. I see
04:45
that as sort of the fundamental development loop. 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
05:04
familiar with it, it's a really powerful tool. This has really helped our CS team, 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.
05:22
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
05:44
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
06:05
employees at Kickstarter are doing things like HR and maybe like, you know, 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
06:23
that are really just text changes that people who have gone through our GitHub for Poets work 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.
06:43
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
07:01
with the product. Similarly, if you want to know how engineering and how a product development team works, showing them this cycle of how code like how the sausage gets made is really eye-opening and often startlingly easy for a lot of people who aren't familiar
07:22
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.
07:44
Right, so it's an intro to the tools and processes we have. 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 if
08:06
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 like 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
08:26
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
08:42
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
09:04
websites. We don't really have to go into the nitty gritty of how ActiveRecord 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.
09:21
And this is a great way we've made the engineering process transparent and inclusive for everybody in the Kickstarter organization. So because poets are going through this process and they're doing this loop, we end up in this place where everyone in our organization
09:42
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.
10:01
So what happens when you let everybody in your organization commit code? It actually works out pretty well. I'm going to 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
10:20
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
10:42
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 needed an engineer to fix, and then file these really simple changes into our ticketing system so that
11:03
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 trickles down to the people who actually fixed the problem. And that is just crazy. That is way too much process
11:24
to fix something 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,
11:41
put up the pull request, and an engineer will get pinged and they'll know to merge and deploy it pretty shortly thereafterwards. 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.
12:04
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 like throwing stuff out there and like trying to see if it works and you don't know if you're going to be committed to this long term, there's often
12:24
this sort of awkward phase of a feature where it might need to become a CMS at one point where you're going to 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 going to change it that much. In our case, it's like we have a lot of editorial features where people like
12:45
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 going to want to change them or what the rate of change is going to be. And having GitHub for Poets lets us say, well, you just go in and like edit this view. Just like we use Hamel and
13:02
like Hamel's really easy to learn. And so you're just like copying these chunks around and if the test pass 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
13:22
or something like that when we don't really know what the full lifecycle of that feature is going to be. Thinking of this another way, like 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.
13:44
Alright, 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 really awesome benefits I think are the more
14:01
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.
14:24
And then people, A, it was like way too much material to cover in a couple of hours. Like boot camps are 12 weeks long or so and you know you're just like getting started with one of those. And so it was ridiculously overambitious to be like, oh yeah, we'll just spend a couple of hours
14:41
talking about Ruby on Rails and you guys will get it. But what we found was 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
15:04
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 you know security liability or a performance gotcha or something like that and it'll be in the pull request
15:22
where we're like whoa I think this is not going to really work that well like we got to 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
15:40
transparency and the inclusivity part of it. There's also a lot of consensus that is sort of baked into the to the pull request cycle that 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
16:05
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
16:23
version control for your 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
16:42
know that you know 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
17:06
this story of how we built things through our GitHub commit or through our 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 you know have something
17:21
trigger my memory of why I did it that way that's really powerful and it was almost like a fish in water like a fish in water kind of moment for me realizing like I'm thinking of the the David Foster Wallace anecdote about two fish swimming past each other and one fish says to the other like oh he says
17:42
how's the water today and the other fish says what's water and it's it's getting at the 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 this idea of having this rich context around how we built things
18:02
that when other people see that for say community support or a marketing team there it's sort of a mind-blowing experience for them to know that they can you they have those sorts of tools for their own documentation or something like that. So yeah version control is really
18:21
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
18:43
would how they would handle troublesome cases or something like that so these those decisions now have this like commit history and a pull request and this rich context of the discussion around how why a particular thing is the way it is. So I should say too this is called GitHub for Poets but
19:06
it's really pretty applicable to any version control system. The one thing I particularly like about the the way GitHub does pull requests is they're sort of getting this idea of consensus as a sort of a political
19:26
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
19:41
history pull requests are even adding this even richer context about you know 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
20:00
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
20:21
marketing copy up to the last minute as they figure out how they 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
20:40
responsibility that's implicit in them that if things break because like as a result of you merging your pull request in and deploying it it's not entirely your fault at all in fact you know we have a pretty blameless culture too and so it's not your fault at all but in any organization that uses
21:02
pull requests you put it out there and you ask people to try like 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
21:27
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
21:44
really so 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
22:02
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 and an ever greater concentric circles of impact and github for poets is really like a few
22:21
hours of your time teaching the class getting everybody into your github organization answering their questions about how it works you know merging and deploying their pull requests when they're ready to go and it can have a radical change on other departments workflows because it's so much easier
22:42
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 and expecting transparency in this rich context in how decisions were made so the final reason to do github for
23:05
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
23:23
like a 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 explained the sort of bog
23:41
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 who
24:05
think of like in college when you when you would have 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
24:21
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
24:43
contributing because they feel like they don't know enough to to do that and they want to 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
25:05
pretty important so it gets its own slide one of the I found one of the most useful things to do in these GitHub approach classes is to demystify the development process we we've sort of our engineering team
25:22
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 rail scaffolding and it is just not rocket science we
25:44
are googling for a gem that does most of the work that we want to 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 to about how this dovetails with the with the
26:03
programming pattern 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 that's not dry and you would just
26:22
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 your you're always going to be
26:43
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 get history works or something like that engineers ask for help all the time from Google and Stack Overflow yeah
27:04
so that's what I go into for 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 K
27:22
theory 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
27:46
great but um yeah so we're looking at a very bog-standard rails application in this case I just did like 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
28:04
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
28:21
index dot HTML dot ERB I'm gonna click into one of these line numbers that I want to 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
28:42
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 want to be sure that people know as we're listing users I want to add a sub header to here that I don't know expresses what I like about monoliths so let's say monoliths are okay now
29:07
audience participation time monoliths are what help me out majestic integrated
29:21
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 I already typed this out so I'm changing the user listing and the
29:41
reason I'm doing this is I'm adding some SEO around monoliths and then it's always nice to show the emoji alright and then we come up what 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
30:02
gonna be neat and tidy just embrace the chaos so we could leave this or or we could call it something like rails comp monolith SEO and now I'm gonna propose this file change there we go we can preview this we should say what we
30:26
would like what feedback we would like in this pull request please check if monoliths are actually majestic and or integrated and we can add mention
30:48
DHH for that I guess I don't know and then we create the full request and then we're pretty much done so so
31:02
in our process where it goes from here is we have a support engineer every 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 they'd get at mentioned in one of these pull
31:21
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
31:43
all right I'll hop back to the to the slides yeah okay so that's more or less what we cover the there are a couple common concerns that people have when they think about giving everybody access to their github repo most common I
32:04
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 have gone through the through
32:23
proposed process tend to be very cautious and they will ask for help a lot even though they are making what are from an engineering perspective very trivial changes just fixing typos change it moving some words around is not going to have a significant impact on on your site the worst thing
32:42
that we've had happened 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
33:01
because believe it or not like 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 and 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
33:23
to access to our code repository has decreased code quality or it hasn't been a liability for the website in fact has been has been the opposite so other people are worried about security that that our code is so special and
33:42
it's so dangerous for everybody else to be in there I also think this is kind of crap so first of all let's say 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
34:00
communication tool that if that information got out it could be damaging or just like embarrassing so that's true but it's a it's a trade-off that you always accept because chat and email are so helpful to so increase your productivity so much that it's worth the risk that if somebody had a bad
34:23
password like all that information will get leaked and so there's some like really easy stuff you can do to improve your security to like we have everybody use one password so that they have like strong unique passwords for every website they use you can require two-factor authentication for lots of
34:41
important stuff also another reason I think there's kind of a bad reason 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 scaffolding with some small customizations and a bunch of gems that
35:01
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 was ever leaked to the public or something like that we'd like to think that another
35:22
rails engineer would look at it and think yeah oh yeah that that's how I do it too like it's it's the obvious thing to do that's we're not trying to be clever we're just trying to make it easy and obvious and so as a result like it's really not that much of a security liability also so a few pro
35:44
tips here these are some things you should also have in place just to make sure that that your all your bases are covered in terms of security and site reliability and stuff like this I'm sort of putting on my like ops hat and be like we have to say these things so you should like poets should know
36:01
that they're working in their own 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 did anything they do in their git branch is not gonna break things for on production or break things for other developers you
36:22
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
36:40
engineering process and I think of it it's 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 it's 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
37:02
deploying and just like sanity checks that these are what they expect to be deploying so if you 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
37:22
it and we can say okay let's go and do this through the 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
37:42
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 implement like it does it 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
38:10
really depend on the context whether this means like actually good to deploy or just like congrats I'm making a pull request all right so I wanted to show
38:22
you guys who some of the poets are at Kickstarter these are a bunch of our employees who are who have gone through GitHub for poets and have then gone on to make several commits and pull requests in particular oh yeah so so there I did a little grepping through our git history and realized that of
38:44
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 a 1,100 commits which I am I think is super
39:00
amazing like that is 1,100 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
39:25
macro to reply to a customer support ticket this so actually that 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 where when
39:43
they're expecting to because it takes a while to transcode and maybe I 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
40:01
being like we're gonna show your 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
40:21
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 support 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
40:46
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 to get familiar with it with all the the tone and the
41:02
copy on the site she looked for any place where we didn't weren't using a which is grammatical pattern where if you have a list of two or more things like three or more things you have to like 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 it makes all these pull requests like
41:23
each one fixing a serial comma and this was like our first week on the job and she'd never used rails and never used github before it was great yeah okay so final thing is like here's a slide I don't know how well this
41:41
shows up because it's on a light background but yeah this is an example of some 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 really good it's a good feeling when other engineers are congratulating you on a job well done for making your
42:04
first pull request because I have this 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
42:21
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 it's worth doing all that because it's so useful to use written language it's such a powerful
42:43
way to communicate ideas and in you know starting a few generations ago using computers and software is going to 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
43:03
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 giving 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
43:23
to solve problems to try to solve it by editing our code base so the the final couple slides here are examples of the kicks from the Kickstarter home page that things that have been made by poets so this is an actual
43:42
screenshot of the kickstarter.com home page at one point we have these big like hero graphics where we're calling out things things that we want to 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
44:01
whimsical way so behind the camera here is is our coworker Liz so here's what the Poets came up with another actual hero graphic that we had on the page on the home page was highlighting video games at the bottom there it
44:23
says 87,000 Kickstarter backers helped produce the video game Broken Age but when Catherine got a hold of this it turned into a doge dogecoin scheme where 87,000 dogecoins sent to Catherine and the call-to-action
44:41
button says send more dogecoins and our final one highlighting library projects but the way get help for poets actually ends up often is people everywhere creating chaos so that's the end of my talk I I'm K theory on social
45:04
media if you guys want to hit me up there I also have time for some questions 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