WEBVTT 1 00:00:00.120 --> 00:00:03.439 Imagine for a second that you were trying to build 2 00:00:03.879 --> 00:00:05.480 a massive skyscraper. 3 00:00:05.559 --> 00:00:07.040 Okay, I'm picturing it, but. 4 00:00:07.040 --> 00:00:09.599 You're not doing it with just a dozen people. You 5 00:00:09.679 --> 00:00:12.640 were building it with literally thousands of workers. 6 00:00:13.000 --> 00:00:16.280 Oh wow, that sounds intense. 7 00:00:16.120 --> 00:00:20.239 Right, and they are all laying bricks, installing plumbing, and 8 00:00:20.399 --> 00:00:23.640 you know, wiring the electricity at the exact same time 9 00:00:23.679 --> 00:00:25.039 on the exact same floor. 10 00:00:25.160 --> 00:00:26.960 That sounds like an absolute nightmare. 11 00:00:27.039 --> 00:00:29.440 It would be total chaos, all right. Without a master plan. 12 00:00:29.600 --> 00:00:32.920 They would be building brick walls right over the doorways. 13 00:00:32.479 --> 00:00:36.439 Yeah, or wiring the plumbing directly into the electrical grid exactly. 14 00:00:36.600 --> 00:00:39.719 The whole thing would just collapse. Yet, in the digital world, 15 00:00:40.159 --> 00:00:43.560 companies like Google and Twitter have thousands of engineers working 16 00:00:43.560 --> 00:00:47.159 on the exact same digital skyscraper every. 17 00:00:46.920 --> 00:00:50.240 Single day, and they somehow don't tear the building down exactly. 18 00:00:50.439 --> 00:00:54.159 And the clipboard keeping that entire structure from collapsing is GitHub. 19 00:00:54.359 --> 00:00:57.000 And you know that is exactly why this matters for you, 20 00:00:57.079 --> 00:00:59.280 the listener, regardless of your technical. 21 00:00:58.960 --> 00:01:01.240 Background, right, even if you do right code. 22 00:01:01.119 --> 00:01:05.640 Exactly, whether you are actively managing a software project, trying 23 00:01:05.640 --> 00:01:09.359 to catch up on modern tech workflows, or just fascinated 24 00:01:09.400 --> 00:01:13.480 by human organization because understanding the philosophy of this platform, 25 00:01:13.599 --> 00:01:15.079 it isn't just about reading code. 26 00:01:15.280 --> 00:01:16.280 It's way bigger than that. 27 00:01:16.400 --> 00:01:20.560 It is an absolute masterclass in asynchronous project management. It 28 00:01:20.680 --> 00:01:24.400 is about how you prevent thousands of incredibly smart people 29 00:01:24.439 --> 00:01:26.599 from constantly stepping on each other's toes. 30 00:01:27.319 --> 00:01:30.640 So today, our mission for this deep dive is to 31 00:01:30.719 --> 00:01:34.599 pull from a foundational text called GitHub Essentials by Achilles 32 00:01:34.640 --> 00:01:37.599 Pepanellas to figure out exactly how that works. 33 00:01:37.760 --> 00:01:40.319 It's a great source for this really breaks down the mechanics. 34 00:01:40.400 --> 00:01:42.519 It really does, because to a lot of people looking 35 00:01:42.519 --> 00:01:45.359 from the outside, GitHub just looks like, I don't know, 36 00:01:45.400 --> 00:01:48.719 a digital filing cabinet, like a cloud drive where developers 37 00:01:48.760 --> 00:01:50.239 just dump text files. 38 00:01:50.000 --> 00:01:51.560 A glorified drop box. 39 00:01:51.319 --> 00:01:54.200 Basically, right, But under the hood it is a highly 40 00:01:54.239 --> 00:01:59.280 sophisticated engine for scaling human collaboration. So, okay, let's impact this. 41 00:01:59.319 --> 00:02:02.159 Before anyone can actually collaborate, they need a shared space to. 42 00:02:02.120 --> 00:02:04.719 Work in, right, Yeah, and that shared space is called 43 00:02:04.719 --> 00:02:08.879 the repository or repo for short. It is the fundamental 44 00:02:08.879 --> 00:02:11.960 building block of the entire GitHub ecosystem. 45 00:02:12.039 --> 00:02:13.639 So how does a repo actually work? 46 00:02:13.879 --> 00:02:17.479 Well, it starts with a very rigid structure. Every single 47 00:02:17.599 --> 00:02:22.680 repository gets a standardized URL scheme. It is always GitHub 48 00:02:22.759 --> 00:02:26.120 dot com, followed by a slash, the username of the owner, 49 00:02:26.680 --> 00:02:29.120 another slash, and then the repository name. 50 00:02:29.199 --> 00:02:31.159 So it's basically a permanent address. 51 00:02:30.840 --> 00:02:34.319 Exactly that name. Space acts as a unique digital address. 52 00:02:34.520 --> 00:02:36.639 You always know exactly who owns what and where it 53 00:02:36.639 --> 00:02:37.039 lives on. 54 00:02:37.000 --> 00:02:39.159 The Internet, and the text points out that when you 55 00:02:39.199 --> 00:02:42.560 are first claiming that digital plot of land. There are 56 00:02:42.719 --> 00:02:44.599 a few optional files you can start with. 57 00:02:44.719 --> 00:02:46.919 Yeah, a few foundational things to get you going, like 58 00:02:46.960 --> 00:02:50.159 the reedeme file, which is basically the welcome matt explaining 59 00:02:50.159 --> 00:02:52.639 what the software actually does. Super important if you want 60 00:02:52.680 --> 00:02:54.240 anyone to actually use your project. 61 00:02:54.360 --> 00:02:56.960 Right, And there's a license file which establishes the legal 62 00:02:57.000 --> 00:03:01.439 ground rules. But then there's this dodly powerful file called 63 00:03:01.759 --> 00:03:03.960 dot get ignore And I wanted to ask you about this. 64 00:03:04.159 --> 00:03:06.199 Ah, Yes, the get ignore file. 65 00:03:06.520 --> 00:03:10.120 Why do we need a file specifically designed to ignore things? 66 00:03:11.159 --> 00:03:13.520 That seems counterintuitive for a storage system. 67 00:03:13.840 --> 00:03:16.199 It does seem weird at first, but it's because of 68 00:03:16.240 --> 00:03:19.520 how version control operates. You see, as you build a 69 00:03:19.560 --> 00:03:23.080 project on your local computer, your operating system and your 70 00:03:23.080 --> 00:03:27.039 code editors generate a massive amount of invisible clutter, like 71 00:03:27.039 --> 00:03:30.680 what kind of clutter like temporary files, system caches, or 72 00:03:30.759 --> 00:03:33.680 even worse, And this happens a lot hidden files containing 73 00:03:33.719 --> 00:03:35.879 your private passwords or apikeys. 74 00:03:35.960 --> 00:03:38.680 Oh wow, Yeah, you definitely do not want to share those. 75 00:03:38.919 --> 00:03:42.960 Exactly. If you upload those, you aren't just cluttering the workspace, 76 00:03:43.120 --> 00:03:47.240 you might be exposing critical security vulnerabilities to the entire public. 77 00:03:47.520 --> 00:03:49.719 So the dot gettignore is kind of like a filter. 78 00:03:49.919 --> 00:03:52.000 It's like a bouncer at the door of your repository. 79 00:03:52.159 --> 00:03:54.240 You program it with a set of rules, and it 80 00:03:54.280 --> 00:03:58.039 physically prevents those specific files from ever leaving your laptop 81 00:03:58.080 --> 00:03:59.879 and entering the shared public space. 82 00:04:00.080 --> 00:04:03.360 Okay, so the bouncer keeps the space clean. But once 83 00:04:03.360 --> 00:04:05.520 the actual code gets uploaded, we have to talk about 84 00:04:05.520 --> 00:04:06.400 how people view it. 85 00:04:06.520 --> 00:04:09.280 Right the interface, because gethub. 86 00:04:08.919 --> 00:04:11.759 Is essentially a visual wrapper for get right, which is 87 00:04:11.800 --> 00:04:15.479 the underlying version control software that actually runs in the terminal. 88 00:04:15.639 --> 00:04:18.839 Yeah, get is the engine, get ub is the dashboard. 89 00:04:18.439 --> 00:04:22.360 And the book emphasizes how much work getthub does to 90 00:04:22.560 --> 00:04:26.240 translate that raw terminal data like in a plain text terminal. 91 00:04:26.279 --> 00:04:27.800 If you want to see the history of a project, 92 00:04:28.040 --> 00:04:30.959 You type get log and you just get this dense, 93 00:04:31.160 --> 00:04:32.519 unreadable wall of text. 94 00:04:32.680 --> 00:04:33.839 It is brutal to look at. 95 00:04:33.920 --> 00:04:36.839 But on GitHub that is translated into a clean visual 96 00:04:36.839 --> 00:04:39.839 commits page. Yeah, but let me push back here for 97 00:04:39.839 --> 00:04:40.199 a second. 98 00:04:40.279 --> 00:04:40.959 Sure, go for it. 99 00:04:41.079 --> 00:04:44.519 As a season developer, do you actually need that visual page? 100 00:04:45.000 --> 00:04:48.160 Is this visual interface just you know, training wheels for 101 00:04:48.199 --> 00:04:49.920 people who are afraid of the command line. 102 00:04:49.959 --> 00:04:52.480 That is a common critique. It's easy to dismiss a 103 00:04:52.560 --> 00:04:56.279 visual interface as training wheels. But what's fascinating here is 104 00:04:56.279 --> 00:04:59.680 that the UI is entirely about managing cognitive load. 105 00:04:59.519 --> 00:05:01.160 At scale cognitive load. 106 00:05:01.399 --> 00:05:04.360 How so, let's look at how git actually saves data. 107 00:05:04.720 --> 00:05:06.920 Every time a developer saves a change, which is called 108 00:05:06.920 --> 00:05:11.000 a commit, get mathematically generates a secure hash algorithm or 109 00:05:11.279 --> 00:05:12.040 SAHA Right. 110 00:05:12.079 --> 00:05:14.560 The SAHA hash, Yeah, it is. 111 00:05:14.519 --> 00:05:20.120 A forty character alphanumeric fingerprint that cryptographically guarantees the integrity 112 00:05:20.160 --> 00:05:22.240 of that exact snapshot of code. 113 00:05:22.600 --> 00:05:25.759 Forty characters. So if you look at the terminal, you 114 00:05:25.839 --> 00:05:29.560 are just staring at strings of random letters and numbers 115 00:05:30.040 --> 00:05:33.959 like seven, three, F nine E two over and over again. 116 00:05:34.160 --> 00:05:37.120 Exactly Reading that in a terminal is exhausting. It's just 117 00:05:37.319 --> 00:05:42.040 visual noise. So GitHub takes that forty character cryptographic hash 118 00:05:42.160 --> 00:05:45.480 and visually strips it down to just the first seven characters. 119 00:05:45.680 --> 00:05:47.279 Oh interesting, just seven. 120 00:05:47.319 --> 00:05:50.879 Yeah, mathematically, seven characters is still enough to uniquely identify 121 00:05:50.959 --> 00:05:53.800 the change without collisions. But it is short enough for 122 00:05:53.879 --> 00:05:57.600 a human brain to easily read, remember, and even reference 123 00:05:57.639 --> 00:05:58.319 in a conversation. 124 00:05:58.519 --> 00:05:59.360 That makes a lot of sense. 125 00:05:59.480 --> 00:06:02.000 Furthermore, when you look at the actual code changes, GitHub 126 00:06:02.079 --> 00:06:05.800 highlights new additions in a bright green block and deletions 127 00:06:05.879 --> 00:06:06.959 in a pinkish red. 128 00:06:06.800 --> 00:06:09.199 Block, so your brain doesn't even have to parse the 129 00:06:09.240 --> 00:06:11.680 syntax of the code to know what happened. You just 130 00:06:11.720 --> 00:06:14.759 see a giant pink block and instantly know, okay, a 131 00:06:14.839 --> 00:06:17.120 massive chunk of code was removed here, right. 132 00:06:17.319 --> 00:06:20.879 And when you are a senior engineer reviewing I don't 133 00:06:20.920 --> 00:06:24.879 know hundreds of lines of code contributed by dozens of 134 00:06:24.920 --> 00:06:27.920 people every single day, that reduction in mental friction. 135 00:06:27.839 --> 00:06:29.600 Is huge to stage a ton of energy. 136 00:06:29.720 --> 00:06:32.639 It is literally the difference between catching a critical bug 137 00:06:32.720 --> 00:06:36.399 and letting it slip through. It democratizes version control. You 138 00:06:36.439 --> 00:06:39.360 don't need to hold the matrix of terminal commands in 139 00:06:39.360 --> 00:06:41.959 your head just to understand the story of how a 140 00:06:42.000 --> 00:06:42.879 file evolved. 141 00:06:43.160 --> 00:06:45.680 That makes perfect sense for the macroview, like looking at 142 00:06:45.680 --> 00:06:48.120 the whole history of the project. But if we zoom in, 143 00:06:48.519 --> 00:06:51.399 the text outlines a completely different set of tools for 144 00:06:51.439 --> 00:06:53.680 when you need to investigate a single specific file. 145 00:06:53.879 --> 00:06:56.000 Yes, the file level tools are fantastic, and. 146 00:06:55.959 --> 00:07:00.160 It highlights three specific buttons, raw, blame, and history. I 147 00:07:00.199 --> 00:07:02.120 want to start with raw because when you view a 148 00:07:02.120 --> 00:07:05.600 file on GitHub, normally it has line numbers, menus, sidebars, 149 00:07:05.800 --> 00:07:08.360 you know, the whole website wrap, hard qui elements. Yeah, right, 150 00:07:08.639 --> 00:07:11.439 But the raw button strips all of that away and 151 00:07:11.639 --> 00:07:14.000 just gives you pure, unformatted text. 152 00:07:14.199 --> 00:07:17.639 Why is that necessary because you need the raw materials 153 00:07:17.759 --> 00:07:21.240 for automation. Think about it. If you are writing an 154 00:07:21.279 --> 00:07:25.000 automated script that needs to download a configuration file from GitHub, 155 00:07:25.439 --> 00:07:29.040 you use command line tools like w get or curl. 156 00:07:29.000 --> 00:07:31.560 And those are just basic download tools basically. 157 00:07:31.639 --> 00:07:35.319 Yeah, these are essentially just little robotic fetch commands that 158 00:07:35.360 --> 00:07:37.360 go out to the Internet and pull files back to 159 00:07:37.399 --> 00:07:40.680 your computer. Okay, if you point curl at the standard 160 00:07:40.680 --> 00:07:44.959 GitHub page, it will dutifully download all the HTML, the 161 00:07:45.079 --> 00:07:49.079 navigation menus, the CSS styling, which is completely useless to 162 00:07:49.120 --> 00:07:51.560 a machine trying to read a config file, you would 163 00:07:51.560 --> 00:07:54.839 just break the script exactly. The raw button provides a 164 00:07:55.079 --> 00:07:58.439 URL that serves only the pure code, allowing machines to 165 00:07:58.480 --> 00:08:01.360 talk to machines without human formatting getting in the way. 166 00:08:01.519 --> 00:08:04.199 Okay, so raw is for the machines. I like that 167 00:08:04.240 --> 00:08:07.680 analogy of getting the pure product wholesale without the packaging. 168 00:08:07.759 --> 00:08:08.759 That's exactly what it is. 169 00:08:08.800 --> 00:08:11.600 But the next button, the blame button, is definitely for humans. 170 00:08:12.120 --> 00:08:15.439 The text explains that this button annotates every single line 171 00:08:15.439 --> 00:08:18.639 of a file, showing exactly who modified it last and 172 00:08:18.680 --> 00:08:20.240 exactly when they did it. 173 00:08:20.240 --> 00:08:21.920 It's like a forensic fingerprint. 174 00:08:22.240 --> 00:08:24.800 Yeah, and it even color codes it by hotness, like 175 00:08:25.040 --> 00:08:28.920 older lines have a brown indicator while newer, freshly written 176 00:08:28.959 --> 00:08:32.919 lines have a yellow indicator. But I gotta say, honestly, 177 00:08:33.919 --> 00:08:36.200 blame sounds incredibly toxic. 178 00:08:36.360 --> 00:08:39.320 The name definitely has a negative connotation, right. 179 00:08:39.799 --> 00:08:42.480 If we are trying to build a collaborative environment, why 180 00:08:42.480 --> 00:08:45.879 would we install a button specifically designed to point fingers 181 00:08:45.879 --> 00:08:46.799 when something breaks. 182 00:08:46.960 --> 00:08:51.600 It definitely sounds punitive, and in a toxic corporate culture, 183 00:08:51.639 --> 00:08:54.120 it probably is used that way. But if we look 184 00:08:54.159 --> 00:08:56.639 at the philosophy of open source, we have to reframe 185 00:08:56.679 --> 00:09:00.799 it entirely. Also, in a healthy ecosystem, the blame button 186 00:09:00.879 --> 00:09:04.600 is about context, not punishment. There is a concept in 187 00:09:04.679 --> 00:09:07.679 systems thinking called Chesterton's fence. Have you heard of it? 188 00:09:07.759 --> 00:09:09.879 Remind me how that goes. It's about not tearing down 189 00:09:09.919 --> 00:09:11.720 a fence until you understand why it was built in 190 00:09:11.759 --> 00:09:12.200 the first place. 191 00:09:12.279 --> 00:09:14.840 Right, precisely because it might be keeping wolves out. 192 00:09:15.000 --> 00:09:15.440 Oh right. 193 00:09:15.559 --> 00:09:18.600 So imagine you are reviewing a file and you see 194 00:09:18.679 --> 00:09:22.480 a block of code that looks completely illogical, It looks inefficient, 195 00:09:22.799 --> 00:09:25.320 and your very first instinct is to just delete it 196 00:09:25.360 --> 00:09:26.320 and write something cleaner. 197 00:09:26.639 --> 00:09:27.840 Sure, clean up the mess. 198 00:09:28.200 --> 00:09:32.399 But before you swing the sledgehammer, you click blame. You 199 00:09:32.440 --> 00:09:34.840 see that this specific line was written three years ago 200 00:09:34.919 --> 00:09:38.000 by a senior engineer. Now you have a name, you 201 00:09:38.000 --> 00:09:40.559 can go to that engineer and ask, hey, why did 202 00:09:40.600 --> 00:09:41.120 you build this. 203 00:09:41.120 --> 00:09:44.039 Fence, and they might actually have a really good reason exactly. 204 00:09:44.480 --> 00:09:48.000 They might reply, oh, that ugly code prevents a catastrophic 205 00:09:48.039 --> 00:09:51.960 memory leak on older Android devices. The blame button gives 206 00:09:51.960 --> 00:09:56.039 you the historical context needed to avoid repeating pass mistakes. 207 00:09:56.240 --> 00:09:57.759 That completely changes the framing. 208 00:09:57.919 --> 00:10:01.840 It's about accountability, accountability and knowledge sharing, and if you 209 00:10:01.879 --> 00:10:04.720 need even more context. You can just click the history button, 210 00:10:04.759 --> 00:10:07.320 which filters the entire project log to show you the 211 00:10:07.399 --> 00:10:10.960 chronological evolution of just that one specific file. 212 00:10:11.080 --> 00:10:13.799 Okay, so we have a shared space, we have visual 213 00:10:13.840 --> 00:10:16.840 tools to reduce cognitive load, we have forensic tools to 214 00:10:16.879 --> 00:10:19.879 understand the context of every single line. But at this 215 00:10:19.960 --> 00:10:22.919 point we are still just a team working in isolation. 216 00:10:22.639 --> 00:10:23.720 Right, a private club. 217 00:10:23.919 --> 00:10:26.159 So the real power of this platform happens when you 218 00:10:26.200 --> 00:10:29.600 open the doors to the public. How does an isolated 219 00:10:29.639 --> 00:10:32.080 project transition into a global collaboration. 220 00:10:32.519 --> 00:10:35.679 It transitions by introducing a social layer to the code. 221 00:10:36.200 --> 00:10:40.200 GitHub essentially operates as a social network for software, and 222 00:10:40.240 --> 00:10:43.879 it manages that interaction with a few key features, primarily watch, 223 00:10:44.080 --> 00:10:45.039 star and fork. 224 00:10:45.240 --> 00:10:48.080 Okay, let's skip over stars, since the text notes that's 225 00:10:48.120 --> 00:10:51.159 basically just a standard or favorite button to show a 226 00:10:51.200 --> 00:10:52.200 project is popular. 227 00:10:52.320 --> 00:10:54.879 Yeah, it's just vanity metrics mostly. 228 00:10:54.879 --> 00:10:57.679 And watch makes sense too. It's your notification settings. The 229 00:10:57.720 --> 00:10:59.960 text notes. You can set it to ignore project entirely, 230 00:11:00.600 --> 00:11:03.960 or only notify you if someone tags your specific username 231 00:11:04.120 --> 00:11:05.679 with an atzymbol, or you can. 232 00:11:05.600 --> 00:11:07.919 Turn on the fire hose and get notified about every 233 00:11:07.960 --> 00:11:10.080 single comment, which is the big brother mode. 234 00:11:10.320 --> 00:11:13.919 Right. But here's where it gets really interesting because the 235 00:11:14.039 --> 00:11:17.919 absolute core of this entire system, the mechanism that makes 236 00:11:18.039 --> 00:11:21.639 massive open source collaboration possible, is the fork button. 237 00:11:21.759 --> 00:11:24.759 Yes, the fork is the engine of open source software. 238 00:11:24.840 --> 00:11:25.919 How does it actually work? 239 00:11:26.159 --> 00:11:27.759 To understand it, we have to go back to the 240 00:11:27.759 --> 00:11:30.840 concept of a name space. Earlier, we established that a 241 00:11:30.879 --> 00:11:34.440 repository lives under the creator's user name their name space. 242 00:11:34.759 --> 00:11:37.519 If I own a project, I control who has permission 243 00:11:37.519 --> 00:11:38.320 to write code. 244 00:11:38.120 --> 00:11:40.480 There because it's your digital property. Right. 245 00:11:40.600 --> 00:11:43.519 So if you want to help me, traditionally you would 246 00:11:43.519 --> 00:11:46.559 have to email me, prove your skills, and ask me 247 00:11:46.600 --> 00:11:50.639 to grant you editing privileges. That is a massive bottleneck. 248 00:11:50.799 --> 00:11:52.600 Yeah, I mean if a thousand people want to help, 249 00:11:52.799 --> 00:11:55.559 I can't spend my day interviewing one thousand strangers. 250 00:11:55.639 --> 00:11:58.200 It would be a full time job just managing permissions. 251 00:11:58.399 --> 00:12:01.080 So how does forking bypass that? Because I was trying 252 00:12:01.120 --> 00:12:02.919 to explain this to a friend the other day, and 253 00:12:02.960 --> 00:12:04.200 I use this soup analogy. 254 00:12:04.399 --> 00:12:05.679 Oh I like soup. Let's hear it. 255 00:12:05.759 --> 00:12:09.360 Okay, imagine a master chef makes an incredible pot of soup. 256 00:12:09.919 --> 00:12:13.519 Forking is like a magic button that instantly clones the 257 00:12:13.639 --> 00:12:17.679 chef's entire pot, but it places the duplicate pot right 258 00:12:17.720 --> 00:12:20.000 in your own home kitchen, your own name space. 259 00:12:20.080 --> 00:12:21.559 Okay, tracking with you. 260 00:12:21.559 --> 00:12:24.519 You now have absolute ownership of that clone. You can 261 00:12:24.559 --> 00:12:26.799 add more salt, you can throw in some carrots, you 262 00:12:26.840 --> 00:12:29.639 can completely ruin the soup, and you will never ever 263 00:12:29.720 --> 00:12:32.120 affect the chef's original master pot. 264 00:12:32.320 --> 00:12:35.720 That is a brilliant analogy. It perfectly captures the first 265 00:12:35.720 --> 00:12:39.240 half of the transaction. By copying the repository into your 266 00:12:39.279 --> 00:12:43.639 own name space, GitHub completely eliminates the need for upfront permission, 267 00:12:43.679 --> 00:12:47.679 no gatekeeping exactly. We call this permissionless innovation. You don't 268 00:12:47.679 --> 00:12:50.039 have to ask the chef if you can experiment with carrots. 269 00:12:50.080 --> 00:12:52.320 You just do it. But you know, cloning the soup 270 00:12:52.399 --> 00:12:56.600 doesn't actually help the chef improve their recipe. 271 00:12:56.080 --> 00:12:57.759 Right, I just have my own weird carrot soup. 272 00:12:57.840 --> 00:13:00.240 Now, the collaboration actually happens in the second half of 273 00:13:00.279 --> 00:13:02.399 the process, which is called a pole request. 274 00:13:02.679 --> 00:13:05.720 So what happens when I finally perfect my recipe with 275 00:13:05.799 --> 00:13:06.879 the carrots and the salt. 276 00:13:07.159 --> 00:13:10.000 You take a spoonful of your new improved soup, You 277 00:13:10.039 --> 00:13:12.039 walk back to the master chef and you hand it 278 00:13:12.039 --> 00:13:14.879 to them. You are formally requesting that the chef pull 279 00:13:14.919 --> 00:13:18.799 your specific changes back into the original master recipe. 280 00:13:18.879 --> 00:13:20.240 Ah a poll request. 281 00:13:20.440 --> 00:13:24.960 Exactly the chef tastes your spoon, If they like the carrots, 282 00:13:25.000 --> 00:13:27.360 they click a button and your coat is instantly merged 283 00:13:27.399 --> 00:13:29.799 into the official project and if they hate it, if 284 00:13:29.840 --> 00:13:32.320 they don't like it, they reject it. But either way, 285 00:13:32.399 --> 00:13:35.519 the master project remains completely safe and the barrier to 286 00:13:35.679 --> 00:13:40.360 entry for new contributors is completely shattered. Anyone anywhere in 287 00:13:40.399 --> 00:13:42.080 the world can pitch an improvement. 288 00:13:42.360 --> 00:13:45.080 But see opening the floodgates like that creates a brand 289 00:13:45.120 --> 00:13:48.440 new problem. We've essentially invited thousands of strangers into our 290 00:13:48.519 --> 00:13:49.639 kitchen to taste the soup. 291 00:13:49.840 --> 00:13:51.320 That's a lot of cooks in the kitchen. 292 00:13:51.480 --> 00:13:54.840 Exactly what happens when five hundred of them start shouting 293 00:13:54.840 --> 00:13:57.480 that it needs more salt, while two hundred are demanding 294 00:13:57.559 --> 00:14:00.399 less salt, and fifty are complaining that this soup is 295 00:14:00.440 --> 00:14:01.440 actually just water. 296 00:14:01.720 --> 00:14:02.720 It's a little chaos. 297 00:14:02.879 --> 00:14:05.919 The whole system would crash Without a way to triage 298 00:14:05.960 --> 00:14:09.080 that feedback. How does GitHub filter that noise? 299 00:14:10.120 --> 00:14:13.799 That brings us to the central nervous system of project communication, 300 00:14:14.080 --> 00:14:16.960 which is the issue tracker. When a user finds a 301 00:14:16.960 --> 00:14:19.639 bug or wants a new feature, they open an issue. 302 00:14:19.679 --> 00:14:21.039 And it is it just for software bugs. 303 00:14:21.120 --> 00:14:23.720 No, not at all. It is incredibly versatile. The book 304 00:14:23.759 --> 00:14:26.799 actually mentions a user who utilizes the issue tracker as 305 00:14:26.840 --> 00:14:29.080 a personal notepad to track home repairs. 306 00:14:29.279 --> 00:14:30.879 That's hilarious, but it makes sense. 307 00:14:30.960 --> 00:14:33.120 It does. It is just a highly structured way to 308 00:14:33.159 --> 00:14:35.240 track tasks and conversations. 309 00:14:35.480 --> 00:14:38.759 And it isn't just plain text either. Issues are formatted 310 00:14:38.879 --> 00:14:42.600 using markdown, which is a lightweight markup language. You can 311 00:14:42.720 --> 00:14:46.080 quickly bold text, create checklists, and even drag and drop 312 00:14:46.120 --> 00:14:49.120 images directly into the browser to show a screenshot of 313 00:14:49.120 --> 00:14:49.960 a broken feature. 314 00:14:50.120 --> 00:14:52.759 It makes the communication so much richer. 315 00:14:53.159 --> 00:14:55.039 But let me stop you there for a second. A 316 00:14:55.080 --> 00:14:57.799 structured conversation is great. But if I am the project 317 00:14:57.799 --> 00:15:00.559 manager and I wake up to find out one hundred 318 00:15:00.639 --> 00:15:05.120 open issues submitted by strangers overnight, a giant list doesn't 319 00:15:05.120 --> 00:15:08.000 solve my problem. It just creates massive anxiety. 320 00:15:08.039 --> 00:15:10.519 Oh absolutely, And if you leave it as a giant, 321 00:15:10.759 --> 00:15:14.799 undifferentiated list, the project will stall. If we connect this 322 00:15:14.879 --> 00:15:18.159 to the bigger picture of agile project management, you have 323 00:15:18.200 --> 00:15:18.919 to find a way. 324 00:15:18.759 --> 00:15:20.799 To cut through the noise, SI do they do it? 325 00:15:20.960 --> 00:15:25.960 GitHub solves this with two specific organizational tools, labels and milestones. 326 00:15:26.080 --> 00:15:27.039 Let's start with labels. 327 00:15:27.120 --> 00:15:30.120 Labels are exactly what they sound like, visual metadata. You 328 00:15:30.159 --> 00:15:32.320 can create a bright red label that says critical bug, 329 00:15:32.519 --> 00:15:35.000 a yellow one for needs testing, or a green one 330 00:15:35.039 --> 00:15:37.000 for good first issue aimed at beginners. 331 00:15:37.039 --> 00:15:39.799 Oh, I see, so you categorize the chaos exactly. 332 00:15:40.000 --> 00:15:42.879 When those one hundred issues come in, the manager quickly 333 00:15:42.879 --> 00:15:46.799 triages them by slapping labels on them. Instantly, that overwhelming 334 00:15:46.840 --> 00:15:49.559 wall of text becomes a queriable database. 335 00:15:49.759 --> 00:15:52.000 So I can just say, only show me the red 336 00:15:52.039 --> 00:15:52.840 critical bugs. 337 00:15:52.960 --> 00:15:56.879 Precisely, you filter the entire tracker, the noise disappears, and 338 00:15:56.919 --> 00:15:58.799 you know exactly what to focus on today. 339 00:15:58.919 --> 00:16:02.519 That makes it totally actionable on a daily basis. But 340 00:16:02.559 --> 00:16:05.960 what about the long term. The text describes milestones as 341 00:16:06.000 --> 00:16:08.159 a special type of label that comes with a due 342 00:16:08.200 --> 00:16:12.039 date and a description. Why separate that from a regular label. 343 00:16:11.799 --> 00:16:15.559 Because milestones are about psychology and momentum. When you are 344 00:16:15.559 --> 00:16:18.840 building a massive skyscraper, you don't just say build the building, 345 00:16:19.039 --> 00:16:21.840 you break it down. You say, our milestone this month 346 00:16:21.960 --> 00:16:23.840 is to finish the plumbing on the first floor. 347 00:16:23.960 --> 00:16:25.639 It gives people a specific target. 348 00:16:25.799 --> 00:16:28.879 Right in software, you might create a milestone called version 349 00:16:28.960 --> 00:16:32.360 one point zero release. You assign fifty specific issues to 350 00:16:32.399 --> 00:16:36.159 that milestone. GitHub then automatically generates a progress bar. 351 00:16:36.279 --> 00:16:38.279 Oh, progress bar is so satisfying. 352 00:16:38.559 --> 00:16:41.840 It really is. As your team fixes bugs and closes 353 00:16:41.879 --> 00:16:45.799 those issues, the bar visually fills up thirty percent, fifty 354 00:16:46.240 --> 00:16:50.279 ninety percent. It visually demonstrates to a distributed team exactly 355 00:16:50.279 --> 00:16:50.960 how close. 356 00:16:50.759 --> 00:16:52.840 They are to the finish line, which is vital for 357 00:16:52.879 --> 00:16:55.759 preventing burnout in massive asynchrodous projects. 358 00:16:55.799 --> 00:16:58.720 Absolutely, you need to see that you are actually making progress. 359 00:16:58.879 --> 00:17:02.240 Okay, so let's review. The code is versioned. Anyone can 360 00:17:02.240 --> 00:17:05.839 submit improvements via pull requests, and the feedback is triaged 361 00:17:05.839 --> 00:17:09.839 into manageable milestones. We have a working system. 362 00:17:09.920 --> 00:17:12.519 It's a well oiled machine, but there's. 363 00:17:12.359 --> 00:17:15.559 A missing piece. If a brand new user stumbles upon 364 00:17:15.599 --> 00:17:18.599 this completed software, they need to know how to actually 365 00:17:18.720 --> 00:17:21.000 use it. They don't know how to eat the soup, right. 366 00:17:21.000 --> 00:17:22.119 They need instructions. 367 00:17:22.319 --> 00:17:24.720 And while a simple reed M file is a good introduction, 368 00:17:25.119 --> 00:17:28.880 complex software requires a real manual. This brings us to 369 00:17:28.960 --> 00:17:32.160 documentation and specifically wikis. 370 00:17:31.880 --> 00:17:34.799 And you know documentation is notoriously the weakest link in 371 00:17:34.839 --> 00:17:35.640 software development. 372 00:17:35.720 --> 00:17:36.359 Why is that. 373 00:17:36.440 --> 00:17:39.319 Because developers hate writing it, and honestly, the moment it 374 00:17:39.400 --> 00:17:42.160 is written, it usually goes out of date. GitHub tries 375 00:17:42.200 --> 00:17:45.319 to solve this by providing a wiki directly alongside every 376 00:17:45.319 --> 00:17:47.200 single repository. 377 00:17:46.640 --> 00:17:48.920 And just like the issues, it is powered by markdown. 378 00:17:49.440 --> 00:17:52.480 The text actually spends some time explaining the exact key 379 00:17:52.480 --> 00:17:55.920 strokes for making internal links with double brackets or transforming 380 00:17:55.960 --> 00:17:58.960 headers into anchor links. It's very thorough, but honestly, the 381 00:17:58.960 --> 00:18:02.039 philosophy behind it is what blew my mind. The author 382 00:18:02.119 --> 00:18:06.240 casually drops this incredible detail. The wiki is not just 383 00:18:06.400 --> 00:18:09.920 a static web page attached to your project under the hood. 384 00:18:10.319 --> 00:18:13.680 The wiki is actually completely separate GIT repository itself. 385 00:18:13.680 --> 00:18:14.759 It's a great plot twist. 386 00:18:14.920 --> 00:18:16.960 I couldn't believe it. Wait, so it's just repositories all 387 00:18:16.960 --> 00:18:17.480 the way down. 388 00:18:17.599 --> 00:18:20.039 It really is, And this is the concept of docs 389 00:18:20.039 --> 00:18:24.000 as code. It is a brilliant architectural choice. By making 390 00:18:24.000 --> 00:18:27.519 the documentation its own GIT repository, it inherits the exact 391 00:18:27.519 --> 00:18:29.759 same superpowers as the software itself. 392 00:18:29.799 --> 00:18:30.599 That is so clever. 393 00:18:30.880 --> 00:18:34.400 Your instruction manual now has a complete version history. You 394 00:18:34.400 --> 00:18:36.720 can use the blame button to see exactly who wrote 395 00:18:36.720 --> 00:18:40.880 a confusing paragraph. People can fork your documentation and submit 396 00:18:40.920 --> 00:18:43.319 pull requests to fixed typos, and. 397 00:18:43.279 --> 00:18:47.240 Most importantly, it has reversibility. The text notes are really 398 00:18:47.240 --> 00:18:51.119 funny quirk the author experienced they accidentally deleted an entire 399 00:18:51.160 --> 00:18:51.880 wiki page. 400 00:18:52.000 --> 00:18:54.279 Oh no panic mode exactly. 401 00:18:54.599 --> 00:18:57.039