First, I'm going to just take a moment. It's been two and a half years since I've been on the stage. So wow, there's people here. Right, OK, so we're going to talk about Git. Manuel, I already asked you all whether you use Git. Even if you don't use Git, even if you don't work with code, version management can still be useful. Because what is Git? Basically, it's a library. You have everything of the history of a project there. And it can be used for all sorts of document management. So if you manage the documentation of a project with markdown files, that can also go into Git. If you manage something else, again, with file-based documents, it can go into Git. It's version management with a big undo button. And you can undo and go back to it in the history at any point in time. Now, before we really dive in, I just want to make sure that we actually all are on the same page and understand what we're talking about. A lot of people still look at Git or at version management in a kind of old-fashioned way. They look at it as, OK, we have the primary, and then we have replicas. And those replicas talk with the primary, get their information from the primary, and give back to the primary. That is not Git. That is SVN, that is CVS. That is how we used to do things. Git works differently. You have a primary, but then you have a fork. And then there's another fork. And those forks can all talk together. And each of them contain the complete truth. And each of them can go a different direction, and there's still the complete truth. And each of them can be a remote for your fork. So it's not that there is one source of truth, one primary. There might be one canonical base repository from which everything started. But each of these contain the complete truth. So if there's one thing you take away from this talk, forget everything else I'm going to say. Remember this, there is no one truth. Every repo, every fork, even your local copy is the complete truth at that point, at that fork.  So if we're talking different forks, different forks can go in different directions. The original might just add a couple of commits and might have one branch which is still work in progress. But the fork might add onto that. And another fork might go in a completely different direction. And all of that is fine. All of that is a complete truth. These are their own truths. So if you have multiple remotes, you can choose and pick from each remote which bits you like. Am I losing anyone already? Or are you saying like, hang on, now suddenly Gith is starting to make sense. Good, now we're getting somewhere. OK, so when I do a poll, when I grab whatever is in the remote and pull that into my local copy, what am I saying? I'm saying, I accept your truth as my truth. When I push up to a repo, whether it's my own fork upstream as in online, or when I push up to a repo where I have commit access, I'm saying, my truth is now your truth. This is now the truth of that particular fork. So when I send in a pull request, what am I saying? Will you accept my truth as your truth? Correct. So when someone merges my pull request, thank you for asking. I accept your truth as my truth. This is how it works. And you don't always send a pull request to the primary, to the original canonical repo. You might send it to one of the remotes. The primary might be abandoned at some point. And one of the remotes has an active maintainer and becomes the new canonical primary. So this is how it works.  Now when you send in PRs, if you create your PR based on the main branch, which is often called trunk, master, main, sometimes develop, if you create your PR based on that, you can only have one PR open at the same time. If you create separate branches, you can have multiple PRs open. You can have a PR in a separate branch for a documentation change and a PR with a code change in another branch. Why would you use different branches for that then? Why not have those two changes in one PR? So let me first repeat what you were saying. So you can easily merge them and you were saying, smaller PRs are easier to review and merge. Anyone else? Fullback? Okay, the simple answer is, what are the decision points? Every single decision can yield discussion. If you have a PR which has four decision points, then three of them might be fine and might be approved, but then there's still discussion on that fourth point. And because there's discussion on that fourth point, your PR is not getting merged. And those other three changes which were perfectly felled in their own right and should have been merged already are blocked because they're all in the same PR. So if there is a different decision point, use a different PR. And that might mean that some really small changes are in one PR, documentation changes. Then you have some CS changes in another branch and then you have a feature in another branch and a bug fix in yet another branch. That's fine. Branches are your save points. You can have as many as you like. How many of you have ever had a repo with more than 100 open branches? Right, you actually understand that they are your save points.   How do we find a branch which is still working on et cetera? So how do you organize branches? You use prefixes. And this is just some ideas of prefixes you can use. You have to find out the prefixes you use yourself which work for your brain. For my brain, like if there's something I know I need to do but I haven't got time to work on it yet, I might just open a branch without any commits in it yet and just say to do with a little note on what I need to do. It's always a good idea if you create feature branches, if you create a feature or a bug fix to have the issue number of the track ticket or the GitHub issue in the branch name. So you can link it back straight away. You know what the reference is where the original issue was reported. If you're still working on something and it's not ready for commit, you work in progress. Or there might be something where you have a more complex change where you need to change something upstream in another repo which is a dependency for this repo. So you send in a pull request there but you know that you can only send in the pull request to make the change needed in your repo once that other pull request has been merged. So wait for it. I'm waiting for that other PR to be merged. And often I wouldn't annotate what repo and what PR I'm waiting for. PR, once something is a PR you can't make changes anymore as easily as you would if something is only local branch. So prefix of PR is an annotation to give an indication like, hang on, I need to be careful with this branch. I can't make changes without communicating to potential reviewers that I'm still making changes on it. So there's lots of different ways to do it and you have to figure out your own way. I mean, these are just some examples. But figure out your own way. The using prefixes can be a great way to organize your branches and to make it easier to find them back, find the right branch again. Make sense? Is this helpful? Yeah. Yeah? Okay. Now, I'm gonna take a drink because my throat is getting dry. But yeah, how to write history and get your PR accepted? On average, how many of your PRs get accepted? 10%? 20%? 50%? And 90 because they're small. That's a good answer. Mm-hmm. Right. If you look at history of a repo, if you see a history tree like this, what does this tell you? Someone was experimenting, this should never have been committed to the primary branch of that repo. But it is in one of the repos I work on. Not my commits, but still. What about this? Can you still follow what was going on in this repo? Or what about this? Is this better? And what you see here is that each of the commits also have a prefix sort of indicating what's going on. So it identifies what part of the code base that commit was working on. So when you look through the repo, look through the history, it's quite clear to pick out what commits are relevant to what you're currently working on. To get a clean history that requires foresort and discipline. And I'm not talking about deciding everything in advance and making those commits from the start straight away clean. Nobody works like that. Our brains don't work like that. Our brains are messy. We start working on a bug fix and then we notice, oh, hang on, that documentation is wrong. So we fix that documentation. And then we add a new test and they're like, hang on, but that test should have been, there's five tests for the same thing that should have been in a data provider. So you change that test data to data provider and then you add your own test. And hang on, now I have all those different changes. But I was only working on this one bug fix. So how do you work with that? Discipline you need is to make very small commits and commit often. Because that will give you a chance to reorganize those commits later into atomic commits, into logical groupings of code which belong together. You don't normally share that kind of messy branches with anyone. You have that locally and that's fine. Nobody needs to see the mess. Believe me, the branches I have locally you do not want to see. But once you have that mess and you've got the mess, but clearly annotated, okay, I'm doing something small here. I'm doing the documentation change there. I'm changing something to a data provider there. If you have those small commits, then you can reorganize them. You can pull them out to separate branches if they should be in a separate branch in a separate PR. You can reorganize the commits. And the whole fact of creating those small commits and committing often gives you the opportunity to do that. Now, what are the tools of the trade for that? Oh, sorry, I forgot. I haven't slide about atomic commits here. Okay, atomic commits. Anyone knows what those are? Oh, I can tell you something new. That's lovely. Atomic commits are basically a unit which is completely self-contained. If you make a bug fix and that bug fix ought to have a test, then that test is contained within the same commit. Everything that's needed for the commit to be complete is in that one commit. So if you decide, okay, well, I have a PR with three commits, with three different very related changes. And one of those changes is not accepted. You can just pull out that one commit, revert that one commit, and the other two commits can stay the way they are because their each commit is self-contained. It's past the CI, it has the test, it has the documentation, it's complete. Past the CI is important because every commit should be able to be merged. If it doesn't pass CI, your PR should not be even opened.  Okay, CI is continuous integration. Continuous integration is used to do quality checks on your code. So for instance, to run your code sniffers checks, your code style consistency checks, or to run your unit tests, or to run security checks on your code. Those kind of things can be automated and can be automated to run on every PR, on every commit, on every merge. That's continuous integration CI. And I very much recommend you use that, yeah? I'll come back to your question because I know what you're saying and I often do the same, but there's a trick to it. Okay, so past the CI, they focus on those commits, focus on one thing. So each commit has one focus. There is no scope creep and it's so easy to get into the scope creep, but they focus on one thing and they're easy to review. Sometimes I have a PR with seven or eight commits and each of them is very interrelated and it all belongs together, but they each make a separate change. It's like storytelling, a little stepping stone, okay, this step is needed and then because I made that step, now I can make the next step and the next step and the next step. So they are interrelated, they belong together, but they are each separate changes. If you review that as one complete thing, you see one file with only red and green and every single line has been changed. If you review each commit individually, it's so much easier than that. Having those atomic commits saying, okay, this test belongs with this change, this test belongs with this change, this test belongs with that change, then it makes it easy to review. The reviewer knows exactly what you've done, can verify each commit individually and then say, okay, I now know the whole is complete and is correct and can merge it. Does this make sense? Yeah? Are you going to change it and scale the review in the comment or just all the changes in the... That the question is whether you would review as a reviewer individual commits or the complete thing with a complex refactor. Well, that really depends. On the one hand, it depends on how well the reviewer knows the code base. If they are intimately aware of where the code base, they understand really well what the refactor is you're going to do. They might just look at the complete thing. At the same time, if the refactor is extremely complex, that storytelling with those individual commits can make it easier. Like if I move some code from location one to location two, as a reviewer, I would want to know that there were no changes when I moved it. I moved it without changes. That's a separate commit. And then the changes I make are in the commit after. That way you can make sure that you know exactly what was changed. And that becomes a lot harder if you look at everything as a whole. And it depends. It really depends on how well you're familiar with the code base and what the changes are. If you're interested, I can show you some PRs at some point where I explicitly say to the reviewer, review per commit, because I know that's going to help them. And some others where I don't say that and it's up to them to decide what they do. Correct? Yes. Right, so what have we learned today? Atomic commits is storytelling. You take the reviewer through your thinking process. They're step by step. They are individual, self-contained changes. And if one of those steps is wrong, you can just pull out that step and all the other steps can still stay in place because you're using atomic commits, yeah? So tools of the trade. First off, amend.  As that is the last commit I made, I can just amend that commit. I can say, okay, I'm just going to rewrite some code. Just add that to that commit. I might even rewrite the commit message and say, okay, fixed. Make sure it's past the CI now. So you, amending a commit can be either amending it with file changes or amending it with the commit message change, but both can happen and you can still do that. That's fine. If you've pulled the PR and you've run CI online and all it throws up is a code style error, please amend the commit and do not create a separate commit saying fixed CI. That fixed CI commit has no value. It doesn't add anything to the history of the project. It's just saying, I forgot something.  Yeah, that's a meant interactive rebase. How many of you use rebasing? Can I invite everyone who did not put up their hands to learn rebasing? Pay very close attention to this part. It's gonna make your working bit get so much easier and so much more powerful. Remember that I said that branch is for your save points. Yes. Yes, create a duplicate branch. Just create a branch before you do the interactive commit. Then you have a backup and you can always go back to your backup. There's nothing wrong with that.  Yeah, save points. Good. Right, so what is rebasing? A plain rebase is okay, we have a branch which is branch off at some point. The primary branch in the repo has moved on. Now I'm ready to pull it but I wanna make sure it doesn't conflict with any changes which have been made in the meantime. So I'm just gonna move this commit. I'm just gonna cut it off from where it was originally attached and I'm just gonna move it to the top of the primary branch again. That's a plain rebase and you don't need to do this just with one commit. If your branch has five commits, you can just rebase it on top of the latest commit of the master branch and those five commits will be on top of it. That's normal rebase. Now interactive rebase is where it gets really interesting. Say we have those commits here, four commits and one of the commits is because I made some local CS changes, I'm fixing something up. Another is like, okay, for the storyteller, for the reviewing, it's actually gonna make more sense if that commit would be before the other commit so we can just reorganize them. We can change the order of commit or we can group commits together and just merge them into one commit. How do you do that?   You can choose to edit. Then the rebase stops at that point. You can edit the files and you can edit the commit message.  You can drop a commit. You can say, okay, that wasn't something I was trying but it's not actually relevant anymore. I'm just gonna drop that, not relevant. Or you can fix up and that's squashing those two commits together. But hang on, there's also squash. I'll get back to that. The difference between squash and fix up in a minute. And you can say pick. Pick means I want that commit but you can still pick that commit and then move it in a different place in the order of things. So what does that look like? Okay, so I'm adding a feature here. I started with a failing test. Like you said, then I'm working on the feature then I add some more tests. I add helper methods. Maybe the helper method should have been before the feature. I work some more on the feature, some more on the helper method, et cetera, et cetera. You can see what I've been doing here.  It's messy. Now we're gonna create order from that mess. So I'm gonna do an interactive rebase. I get this screen in which I can edit what I wanna do. You can see by default everything is set at pick. Now I'm gonna change that. And I'm gonna change it like this. So the F means those two, I've moved things around. You can see that the helper is at the top now, the first commit. I've moved all the commits which are related to the helper method next to that. And I'm just gonna fix up that commit. I'm gonna pick that failing test. I'm gonna squash the feature into it. And then I'm gonna fix up everything else with that. What I end up with if I then save this and run it is this. Two atomic commits. So yes, very often when I start working on something to answer your original question which you asked earlier, I often create a failing commit first, a failing test. Locally, I will create that failing test because that failing test proves that the bug exists and it's very helpful to make sure that the test is actually failing. If I would commit everything in one go straight away, I cannot verify that my test actually tests the bug fix because I can't verify that it's failing because it's together with the fix. So locally, I would have that failing test separately but then by the time I send it into a PR, I merge them together because they belong together as an atomic commit. At the same time as a reviewer, if it's a complex bug fix, I may go in, check out that commit, just undo the feature change, the bug fix and run that test locally to verify that that test is failing before the bug fix goes in. Does that help? Does that answer your original question? Good, what I just showed you, is does this look like magic to you? Does this look helpful? Helpful? Good. If you want, I can do a live demo in the question bit but yeah, let's first see if we can get through the slides. Now, the difference between squash and fixup. Squash basically says I wanna merge the file changes so the changes in the files of multiple commits, I wanna squash them together and I want to edit the commit message. I can get the commit messages of all those different commits and I can combine them and I can rewrite them so the commit message encapsules all the information. Fixup also means I wanna combine all the changes except I wanna keep the original commit message of the first commit which I'm using. So if I have a commit where all the commit messages is add to that helper, that is not a useful commit message. That's just a note to myself that that commit belongs with the helper function so I don't need to keep that commit message, I can just fix it up.  So when you wanna join the commit message together you use squash, if you wanna throw away the commit message except for the first one you use fixup and I know you might think like hang on but I'm gonna make so many mistakes. Again, use those save points, use temporary branches, experiment, go and play with this. When I first started with it, I made so many mistakes but once I realized how it worked and actually understood and saw the changes starting to work the way I wanted to, it became my power tool. I live in interactive rebase. How are we doing for time? 10 minutes left, okay. Right. I've already mentioned all this so let's move on. The next bit which is actually really interesting if we're talking about interactive rebase, if we're talking about the squashing and fixup and editing that commit message but whether you're amending a commit or whether you're doing an interactive rebase, we also talk about commit match. So let's, let's pause there a little. What's a good commit message? I already give some hints here but why are these things important? Someone. For your future self. For your future self. Absolutely. Well, what other reason? Absolutely.  Which may have been me.  Now I understand what the reason was behind this change and maybe I should not change it but do it in a different way that fix which I want to make. It cannot be too long. And this is really important. I see a lot of people who have very short commit messages and then have a really long description in the PR. Please do not ever do that. And there's a very simple reason for it. What if you move from GitHub to Bitbucket? You lose all that information which was in the PR. You do not lose your commit messages because that remote which used to be GitHub now has a fork and it lives on Bitbucket and all the commit message are still there. All the commit information is still there but your PR information is no longer available. So keep that information in commit message. Make those commit messages useful. So what does it look like? Often I often use a prefix to just indicate what part of the code base I'm working on, short description, long description. In that description, describe why you're making the change, what you're trying to fix, what the alternatives were which you considered and why you decided that this was the right way to fix it. This will help your reviewer but it will again also help your future self. And also something which I know few people use, give credit where credit is due. If someone helped you with that commit, if you created the commit with PR programming, if someone inspired that commit and you looked at their code for an example on how to do it in your code base, give them credit, co-altered buy. And if you look for commits with co-altered buy in GitHub, you will see that it actually shows both avatars. Both people get credit for that commit. Credit where credit is due. We are working on open source. Why claim something out of your own if it's not? Leaves your ego out at the door basically. Okay, now how do we work with this? How do we create those small commits? Because again, brains are messy. So we've been working and okay, we've made all those things but now how do I make those small commits because I didn't do that while I was working on things? Well, you can cherry pick. And you can cherry pick individual commits, you can cherry pick files, you can even cherry pick lines. You can cherry pick them when committing. So you can say, okay, I'm just gonna stage a few lines and one file and the rest of my changes, I'm not gonna stage yet. I'm just gonna commit this first and then I'm gonna stage another part of what I fixed and make a separate commit again. You can also pick things from other commits or even from other branches. Cherry picking is useful, but once you've changed things and now you have a PR open and there's a conflict, what do you do? Do you do a rebase and force push? Or hang on, say a CI fails and the PR is open. You've already basically asked someone, look at my code, review my code. To force push or not to force push, it depends on, in large part, on the conventions in your project, but basically if it's a non-collaborative branch, you've not pulled it yet, force push it will. Feel free to force push, nobody's looked at it, you're fine. If you've pulled the branch, you've rebased it but not made any changes other than maybe fix a conflict, force push it will. But do leave a comment in the PR rebased without changes so the reviewer knows you've not made any changes. Depending on the conventions in your project, if it's been pulled and you fix a typo or CS fix, maybe it depends. Sometimes the reviewer might prefer to see a separate commit so they know what's been changed and then they can squash them together or merge. I would recommend squashing them together and merge then. If it's a non, if it's a collaborative branch, you're working together and someone else might pull in changes, you might pull in changes, you might push changes, someone else might push changes, please do not use force push because you might overwrite someone else's change and you really don't wanna do that. If you've pulled something and the review has already started, do not use force push because you will confuse the reviewer. They will not know what you've changed. They can't see the difference if you've made a change in the original commit and then they don't know whether you've fixed up what you needed fixing or made a completely different change and they need to do the review completely all over again which is wasting their time so let's not do that. Yeah? Okay. I'm very briefly gonna go into when things go wrong and then skipping a lot of the rest because I also have when things go really wrong and when things go really, really wrong. If you really wanna know, ask me in the questions. I'm just gonna do this bit and then we're gonna go and have some questions. Okay, when things go wrong, reset and refer to the rescue. What is reset? Reset is basically, okay, I'm just gonna go back. I'm just gonna remove that one commit. You can do a soft reset. That means I'm gonna remove the commit but I'm gonna keep all the fault changes and that allows you to commit them again in a different way or you can do a hard reset and then that commit is gone and your fault changes are gone and you can start with a clean slate. That's reset. That's something you only do locally. You do not do that on a public branch. On a public branch, if something has gone wrong, you referred and what I referred is, is saying, okay, we've had a commit. Now I'm gonna basically do the complete opposite of the commit and refer to those changes and that doesn't have to be the top commit at the top of the branch. That can be an earlier commit as long as there's no conflicts. You can still refer to it but if you refer to it, it adds an extra commit which undoes those changes which communicates to other people. Again, okay, we've stopped that change. We're not gonna do that and other people can build on to it again. Make sense? Any questions on that? No? Then I'm just gonna skip over some slides to work the end. Whoop. Can I, yep, let's see if I can quickly find that part where I wanna go to. Right, this bit. Now a lot of people are very hardcore and say, oh, you need to learn to get on the command line.  No, you do not. You need to know the terminology and I've used the terminology here. Rebase, revert, reset, amend. That same terminology is used on the command line as well as in GUIs. But if a GUI works better for your brain, please use one. When I started using a GUI, my productivity went up by 300%. I've never looked back. I've never since that moment ever, ever, ever used Git on the command line. So use the tooling which works for you. Start experimenting with some GUIs because especially like how those branches work together, cherry picking from other branches, those things are so much easier when you have a good GUI. Find one which works with your brain, with your visualization and then Git in comfort. Right, questions. Questions about the atomic damage. Yes. How you describe that is pretty much the same thing that's called stacked branches which is used by a lot of companies. Because that's a branch on top of a branch, a top of a branch, and you're reviewing each branch individually, which is basically how you describe how these should be reviewed when they are atomic. No. Okay. Stacked branches are often branches which depend on each other. If you would pull those individually, they would conflict. So if you pulled them individually and one would get merged, and the other one is still open, they would create a merge conflict. That's why you stack them. Atomic commits, you can have a PR with just one atomic commit. A PR doesn't have to have multiple commits. A PR with one atomic commit can be just a soluble or a PR with multiple atomic commits. If you have stacked branches, those stacked branches would still use atomic commits. But the stack has to do with preventing merge conflict between your open PRs, while atomic commits don't necessarily have to do with that. Does that make sense? Yeah, it does. So basically it's all about ranking and order. Generally, yeah. You're looking at varying jobs, and the other one didn't start in the same door and don't want backing. Absolutely. So with stacks, more than anything, you want to prefer to prevent merge conflicts. You know that if the next change depends on this change and this change needs to be merged, otherwise this change can't be made. That's why you use stacking. More questions. Or is everyone just desperate for lunch? That's fine as well. Please, hang on, there's a mark behind you. Was there a reason GitHub desktop wasn't included in the software comparisons? Not particularly. To me, it's never... I mean, I tried it when it first came out. It was not feature complete, and it really didn't work. It wasn't that user-friendly. So of the tools I listed, those are the ones which have a better reputation than GitHub desktop itself. That doesn't mean that GitHub desktop might not have evolved to a point that it should have been included. I did not re-evaluate it. Okay. Tower, I think that was on the slide, wasn't it? Oh, sorry. Sorry, yes, could have definitely been on the slide, but I only had eight slots. Right. Right. Is an ongoing discussion in the team will change log entries to be part of the commit for the feature or to be separated? Oh, yeah, that's a process flow thing. Generally speaking, it really depends on how large the team is which works together. If you work on your own on a repo, yep, please add your change log entries with your commits. That's fine because that again makes them more atomic. At the same time, if you have a large team working on a project and there's 10 open PRs, and each of them adds a change log entry, believe me, that change log entry is gonna conflict because everyone's gonna add their change log entry at the end of the existing change log, and now we have 10 different change log entries which are all on the same line. So it depends on the project, it depends on how many contributors there are, what the discipline is. Sometimes one of the tricks I see used is have a template for a pull request where you ask people to add a change log entry, and then the committer which merges the PR adds the change log entry to the change log as the next commit, or squashes it into that commit at the point of merging because at that point you won't create a conflict but if they are already in the PRs, they will very easily conflict. So in big projects I work on where there's lots of changes in a release, I normally just milestone everything. There's a little tool in GitHub you can enable to force every PR to have a milestone and you cannot merge without milestone. And because of that I can just select a milestone, it will show me the whole list of every single PR which was merged for that milestone and just go through them, spend half a day going through them and just listing the change log then. It depends on the project. I can't give you advice, but yeah, there are some considerations there. Having them always in the commits is asking for merge conflicts. Okay, more questions. So you are very active on GitHub. So the question to you is, I am. You are very active on GitHub. Yeah. You have a lot of rebels. So the question to you, do you merge and commit? No, merge and score or just merge? Again, it depends on the convention of the projects. In a lot of projects I merge because it also shows that there was a PR and what was happened. There's also one project where we actually have forbidden to merge with forbidden squash. We only allow rebase merge because that was the convention in the project before I became part of it. And it depends really on what you agree upon with the team of people who have commit rights. Like in WordPress core, basically it's all rebase mergers, but then it's SVN. So, yeah. Yeah, because when Adobe commits us, you show them separated and easy and understandable and so on. But if it's just a breakdown within the branch while working on PR? That should not be a PR. Now, seriously, that should be a work in progress branch. Maybe a work in progress branch you've shared. You might have shared it as a draft PR, but it should not be an open PR if it's a breakdown. Okay. More questions. I'm starting to get a feeling that the questions come from the usual suspects. Just a small one. What about the instance and the workers, for example? Do we need to thank kids and next users? It will be 6.1. My future will be merged. So, I use the next version. Or should I use the 6.x or something like that to leave it to the committer to use the version which is this patch? You're talking about track where the little drop down which version it should be committed to or? No, no, no, the code. The AdSins. Oh, the Sins tag in the dog blocks. Okay, generally new features only go into majors, so then you already have your answer. For anything that is not necessarily a new feature but a bug fix, use your own judgment. Look at the track ticket also where it's milestoneed in track and the committer might just adjust it depending on what the actual reality is gonna be. And patches sometimes stay open for years, so there might be patches still out there with the Sins 4.8 and it hasn't been committed yet. And I do feel sorry when that happens, but it happens. So don't let yourself be bound too much by that. Just use your discretion and judgment where you think it belongs. Submit the patch and then the committer can make that final adjustment. That's okay. I'll be around, you can ask me questions later. Thank you for all the questions. This is what I'm considering with all the questions. Thank you very much. A warm round of applause.


Hello, people of the internet, my name is Johnny and welcome back to Poppy Playtime Chapter 2. And I think the game is running smoothly now. They did release a patch, but I also don't think that they fixed the settings bug. No, they did not, so I just, the game is in my favor and running smoothly now. Though I do think it looks a bit blurry, fuzzy in the actual video, I'm sorry. I don't know why they released the game, not being able to change the settings, but we're just gonna have to go with it. And now we found ourselves, where did the brawn cutout go? It used to be right here, but now it's gone and that has me a bit, a bit worried.  Oh, I've been looking for you for so long.  I think the one I was looking at over here is Owen the Oven. Great, then there's the barrel of huggies, the retail shipment. Okay, so that doesn't have a name. But yeah, it's a whole bunch of rejected toys, sir poops a lot. And resigning in this area is also brawn the dinosaur. Hey buddy, and we need to find a way to get you either up there or off of this so we can go up there. I don't know, but let's play the tape and let's see what it holds. There's poops a lot. So quiet. You may listen very carefully. I guess my words must have really inspired the tape action. Because the next day, I got demoted down to the freaking island of Mithridai. So this guy, this employee, had an idea. I think they didn't like it and so we got demoted to working down here in the freaking island of Misfit toys. All right, let's turn on the power. I said let's turn on the power. We can charge up our hand, though I don't immediately know where. Hello, where to send my electric energy. No, I was told to keep pressing these buttons repeatedly because apparently they get creepier as you keep pressing them. But that just seemed pretty friendly. Oh, I can move this actually. Where? Actually, can I move this? Doesn't seem like I can. Oh, I can.  Can I pick this up? How do I activate? Oh, the electricity. There we go. Do I have to move this so it doesn't drop it into that bucket again? What the heck? Oh, it's another collectible. I will take it. So now is there a way that I can bring this all the way to that brawn and move him? I think so. Yes, I can. All right, let me do that. So we ought to loop this all the way around. I will say I am loving this chapter so far. This is so much better than chapter one. And it gets me really excited for more poppy playtime. I've heard the chapter gets really good going forward. So I'm happy to hear it stays consistent in quality. All right, let's move this a bit more. And that should do it. So now, where'd it go here? Pick them up. Yes. And let's move it out of the way. Now I go up. Yes. See you, brawn. I kind of wish we had an encounter with you, but it is what it is. All right, so I can't go that way. So let's make a detour going left and left again. And another puzzle. Okay, I need to open that gate. No, I need to turn that on. Okay, so that's going to list that. What does this do? I don't know. All right, well, let's try doing this. And that'll take me up here. And can I squeeze? No. And I loop it around up here. Oh, I'm a genius. What does this do? And that brings me up. All right. Yeah, I'm kind of a puzzle master is what they call me. Whoa, hey. Does this open? No, I just keep on walking. All right. You didn't scare me this time game and wow, this is getting quite laggy. Move chair. And now we are... Oh, we're back here. Oh, okay. But first, I did see that there is yes. A little choo choo trophy that I did want to loop back and get. So I'm happy it dropped me off here. All right, next mini game. What do you have to say? You did fantastic. Who gave you permission to be this smart? Mommy is super proud of you. Thanks, mom. But I'm sure she's already told you that herself. Yes. Our next game is Wack-O-Wuggy. Head downstairs. Wack-O-Wuggy. All right. Here we go. Wack-O-Wuggy. I believe we saw this in the trailer. Yes, we definitely did. Oh, how cute. Hello. Oh, wow. I don't like the look of this. Playtime Co. Wack-O-Wuggy. Welcome to Wack-O-Wuggy. Fitness Gram-Pacer Test. This advanced test is designed to assess the extent of your reactionary abilities. Okay. A dual-palm grab pack will be provided to you for this test. Around you are 18 sizable holes. 18? An adorable, huggy-wuggy toy could appear out of any one of these holes. My God. If one comes out, hit it with your grab pack. Okay. That's all. Okay, cool. Good luck. They actually doesn't seem like that bad of a minigame, though I don't know. Because the last minigame, the memory one, was... The toys in this game used to have strings attached to them to the children. You got rid of the strings. Okay, well, here we go. Ooh, it is quite dark, actually. Okay, so they do have audio cues. Oh, wow. Okay, I can't see these guys at all, actually. Like, they are so dark. Oh, my God. This is actually kind of creepy. What the heck?  So they do kind of stay in place for a while. Whee. Hey, yeah. Hello. Yeah, dude, I cannot see these guys at all. Like, it is so difficult. Hey, see you. Do they all have pause-champ audio cues? It's hard to tell. Is that one up there? Oh, go away. Go away. I see you. Go away. I said go away. I see your hand. Good God, dude, what the heck? You can't see it. Whee, hey. Hey. Hey. Are they speeding up? They must be. I hit you, hit you. Oh, okay, okay. You, get rid of. They don't even know at this point. Oh, my God. This is getting crazy. I can't see you at all. Oh, my God. Oh, my God. Oh, my God. Oh, my God. All right, this is actually getting impossible at this point. Okay, I'm done. Thank God. Thank you. Here, mommy has another hint for you. Ooh. Is it the key to the... That's a fanathe noise. That was, that had to be a fanathe noise. That sounded exactly like a fanathe noise. That has to be. All right, so what do I have now? I have a train code, one of three. Okay. So I'm missing a few or just a few. Oh, wow, I'm missing so many actually. And red, yellow, red, blue. All right. Only one left. Yeah, I don't want that. I changed my mind. Oh, you want me to go this way? Sorry. Where are you leading me now? So there's one more game left. Is that true or no? Cause I feel like that's not true. You have broken these stairs. Oh, okay. It's this section from the trailer. Or you can just climb the railing. Hey, huggy, wuggy figure. And now I grab onto it. Here we go. Hello, candy. Okay. Okay, I will. More candy. Okay. Oh, here you go. More candy. My tummy's full. Oh my God. Can I keep feeding him? Oh, no, no. I said, no more. Oh, no, no. Stop. Oh my God. Oh, no, no. Okay, okay. So I killed candy the cat. That's good to know. Guys, no more Fnac four. It's canceled. Oh, oh, this is the choo-choo place. I really hope I get chased by the choo-choo. Oh, it's you. Are you friendly? Can you help me please? Pull that lever. Pull that lever. Yay. Oh, no, a little bit more force. There you go. Hey. Are you, you're nice. Okay. Thank you. Where'd you go? I want to thank you. And maybe we can be friends. Where do I put this? Oh, Barry. Hello, Barry. Oh, oh. What? Oh, a little hole. All right. So apparently you can transfer power from this thing to that thing. So watch this. So we activate this. We bring the power back and we activate this. I didn't know you could transfer it. I thought you had to keep it at the receivers. And now we pull this. And that's creepy. Hello, Barry. Wow. Okay. So you really got to be fast with this. Oh, no, you can just do this, actually. That opens this. And I'm assuming I will need to activate this. Go, go, go. Ooh, a blue tape. How wonderful. Let's have a look. Is that Jacksepticeye? No, he's Marcus. All right. Why do they always make him play the super exaggerated Irish man? First in a bendy, now in poppy. Oh, that's the, um, the caterpillar. But I wasn't human. Who have you told about this? Besides me, obviously. Just you, sir. Obviously. I'll have security skim the cameras and take a look. What? There's a massive, pretty monster. Skimming ain't gonna get rid of it. You're out of line, Marcus. We make toys, not monsters. Now come on, get out of my sight. Sure. Actually, I grabbed me a coffee, William. Actually, never mind. Get out of my sight. That's cool. Jacksepticeye Easter egg. Always loved that. Love, Sean. Love, Sean. Again, I just find it funny how he's always playing a super exaggerated Irish person. Again, once in bendy. I can't remember the character's name, but now in poppy, it's funny. Anyways, let's open this. And now, wow. Okay, so we really gotta go quick. So let's get Barry.  And let's stop you. We can bring you right about there. Is that just your sound effect, continuously playing? Or is that someone in the walls? Boom. Let's run. Open that. No. What? What? Oh wait, I never did that one. All right, you really gotta go quick. Ah, come on. There we go, there we go, there we go. Come on, Barry. Oh, you're going automatically. Good job, Barry.  Why'd you stop moving? Okay. Okay, let's bring you down. Do I? I'll go first, Barry. I'll go. I'll make sure it's clear. Unless you wanna go. Oh, okay, you wanna go. Oh, because you had to break the... No, Barry, no! Oh no! Man, I'm sorry, Barry.  Oh, I'm back here. Only one more to do. I guess we can check it out in this video. Is that Bron up there? Bron! Bron, buddy. So sad. We'll check out what the next one is. Thank you. Seems like you're ready for the final game. Statues! Follow mommy down the stairs one last time. Statues. I hope you had a fun day at the game station. What's statues? See you next time. What's statues? Wait, what's statues? Wait, I don't know what statues is. Oh, right here? Oh, it's what the... Yeah, it is the caterpillar. Oh. Why does it want me to move it? Yeah, okay, I gotta yank it. Here! Come on, don't open. I don't like that I have to open it myself, but... I guess we do what we do. I hear someone. Hello? Another puzzle I see. What's up? Do you want to play with PJ? Why do you sound like that? Caterpillar or bug? I'm crawling on all four hundredths. I'm hungry for some delicious bones. Do you have some bones for PJ? I have like a lot. Oh. Oh. You don't sound too good, PJ. All right, let's figure this out. I can climb up here. And... Ooh, I can sneak around. Okay. Okay, I get it. I get it, I get it. Ooh, but I have to deal with the other hand because this one needs the electricity. Okay. And then... Boom, boom. And then... Power, power. Grapple up. Diplomo. Diplomo. It didn't work. Okay. No shot. Wait, did that... Wait, but what did that do, though? Apparently I did it. Even though I don't think that's how you're supposed to do it. What did that... Oh, did that open the gate? Oh, it opened the gate. Okay. Oh, I don't like this. Statues, okay. Oh, how wonderful. Okay. Why? Right, okay. So, red light green light. Yup, red light green light. Oh, what the... Wonderful. Oh, hey, whoa! Can I move? Jesus! Dude, look at the... Freak as that thing. Hey! My God, you're terrifying. Sorry, I'm not listening to you. Hi.  Hmm. Oh. That's kind of... Mean. Oh, my God. Oh, my God. Dude, it's a giant... Oh, my God. Oh, my God. Can't see at all where I'm going. I'm assuming... I moved a little bit. Hey, buddy, can I get up here? Can I get up here? Awesome. Can I swing? That was a laggy jump scare. What do I do there? I got a swing, but I can't... Move when the lights are on. But anyways, I think that's going to do it for... Today's episode. I'm not sure how many more episodes we have left. I think at the start...  I'm not playing. I'm doing an outro. I think in the next episode, we're going to do this minigame. Oh, yeah, here he comes. Hey, buddy. We're going to finish your minigame, then we'll do whatever's left. And there might be one episode left. There might be two. I'm not entirely sure. But good God, you are creepy. He's not even coming after me. Well, you have fun. And I hope you guys had fun watching this video. So thank you so much for watching. And I'll see you all on the flip side. Goodbye. Whoa, his head spun. That was cool. Goodbye. What? Oh, my God. There he just goes.


Hello, this is Timorkai Yantar, FreeSync 7, Capital Planning Committee Chair, speaking on Article 56. Taking a listen from Hamlet, we're keeping this short and sweet. I have five minutes, I'm going to cover five points. One, two, three, four, five. First, thank you. The Capital Plan is a group effort. Many thanks to our partners throughout the town. But mostly, this was months of hard work by the Capital Planning Committee. I have listed our members for you here, and I want to call out the work of two persons. Our treasurer, Phyllis Marshall, congratulations on issuing $77 million worth of bonds at 1.77 percent interest. And Kate Leary, who is my co-author and editor on the Report to Town Meeting. I couldn't have done it without you. Okay, second, the content of the report. We lead off with an explanation of what you're voting on and that vote itself. This is the capital budget for fiscal year 2022. It's shown on pages one through six. It lists what capital items we'll be buying in that year and what we'll pay in debt service. More detail on those in a minute. The report also talks about the full five-year plan with detail by department. It covers both fiscal 22, which is what you're voting on, and projections for the out years. And in the appendix, we have several tables covering all the capital plan items. Third, our fiscal 22 acquisitions, which total $8.5 million. They're paid for with a combination of cash from general tax, other funds, and bonds. And they're listed in sections two, four, and five of Article 56. We discuss it in the report, but here are the highlights. About two-thirds of the capital budget is going to public works, mainly water and sewer maintenance and rehabilitation, also roadway and sidewalk repairs and improvements, as well as vehicle replacements. Another 14% goes to schools, including information technology for education. That's some covers academic IT, vehicle replacements, and engineering study, in which we are assessing the scope, timing, and cost of school facility repairs. The remainder of the budget, about $1.6 million, splits roughly equally four ways. Town buildings, recreation, police and fire, and all other departments. The portion that we financed through bonds in section five is relatively small at $790,000. But I mentioned these because they obligate future town meetings to pay their debt service, so they specifically require a two-thirds vote by this town meeting, which is a good segue to fourth debt service. For Pistol 22, it's $15.8 million. This is in Article 56, Section 3, and is mostly paid by cash from general tax. It covers principal and interest on all the bonds that the town has issued in the past. With a few exceptions, our debt is non-exempt. It fits in the capital plan approved by town meeting. Exempt debt is outside of the capital plan, authorized by town-wide debt exclusion referenda. These are usually big-ticket items. The clearest example is Arlington High School. We have to pay interest on both exempt and non-exempt debt, and here's where we pay it. Apart from debt exclusions, though, the town keeps within the capital plan. That's my fifth point, its size. In Pistol 22, it's $8.6 million. You see it in this table here, which is also in your reports. The 5% rule limits the capital budget to, you guessed it, 5% of the town budget. We target that level in both Pistol 22 and in the out years. This rule constrains the town to live within its means. To make room for some new high-priority items, something else has to give. And so, in conclusion, I hope you've had the chance to read the full report. The committee and I are available to take questions. Please vote yes on 56, and please stay safe.


It's an absolute pleasure whenever I talk about this love brand of ours to an audience as exciting as this. So good evening, 90 years, 90 years is a really long time, really long time. It's about time that we see three generations. It's about time that really calls out an entire period of evolution, right? And whenever we deep dive into how have we transformed this humble little brick into this timeless legacy, there are many, many things that come to mind. And if I have to really decode the journey of this brand to you and bring to life how these 90 years really happened, I thought of various formats in my head on what would be the best way of actually bringing the story to you. And then I decided that the best way to do this would be actually to do what we do best at the Lego group, that is tell the children a story. And so here I am to tell you the story, the story of this brand and the people behind it from time to time. What I have also tried to do here is to basically break the story into a few chapters, you know, from my side. And each chapter essentially is actually going to be a little bit of a peek into a decade of sorts, the challenges, the opportunities, the times that were and how the brand really adopted, evolved, faced those adversities and came out as the timeless brand that it is today, right? So to go back 90 years or maybe even before that, where did all of this begin? And if I have to really go back to where it all started, it has to go back to 1916. And in 1916, this is the story of a young 24-year-old boy, a little 24-year-old Danish boy called Oleker Christensen, right? He was living in this town called Belun. It is the house of the brick, a very, very small town in Denmark. And this all started with him buying a little factory, a little factory for about 10,000 Danish Kronje. What did the factory do, you think? Well, it built everything, doors, windows, cabinets, shelves, chests, coffins. And that's what happened for quite a while, till about 1929. And then 1929 struck and the world around Ole started changing. What did happen? Well, 1929 is the time when the world started reshaping because the New York stock market had crashed. It had to actually send the whole world into a dramatic economic collapse after that. And thousands and thousands of companies were shutting down. Inflation was skyrocketing and Ole obviously realized that his entire customer base had started dwindling because people were obviously sticking to basic essentials. And where was the place for all of this? So with a heavy heart, he had to let a lot of his employees go. And when he did let the last employee of his go forever, he actually found an article in one of the Danish magazines. What did the article say? Well, the article actually talked about something very interesting. It said that there is good manufacturing sense or rather good sense in manufacturing utility items. Utility items like stepladders, iron boards, things like that because possibly people were moving from hiring people to doing these jobs themselves. The last item in that list of products that was mentioned was the item that was to change Ole's life forever. It said toys. Very reluctantly so, Ole decided to allocate a little space in his factory to building toys as well. And that's the chapter one of the story, the wooden duck. So this is the mid-1930s that we are talking about. Ole was producing furniture yet and all the other utility items. He was also producing toys, right? Now this is also the time when there was a little tussle between his head and heart. And the child that Ole was in his heart, he decided to give his heart a listen. And what did that mean? It meant that he said that let's focus on producing only one thing, that is toys. A huge punt, one would say, but an exceptionally fateful one because one day this company started by building wooden toys. The wooden duck was the first toy that the factory produced, was going to become the largest toy brand in the world. So this was also the first break in the evolution of Ole Kirk Christensen or the Lego brand, necessity was the mother of invention, right? We move ahead and that takes me to chapter two. Now you know the factory could not be called the Billund Woodworking Factory as it was called earlier. It had to have a fancy name because it was producing only toys. So what do you do when a young guy actually wants a young company to have a different fancy name? Again Ole did this in his very typical style. He actually opened a contest to his employees. And he said, think of a fancy interesting name that denotes what we do. There's a precious prize to it. And the prize to it was something really precious. It was Ole's favorite homemade wine. Who do you think won the contest? It was Ole himself. He actually put together two Danish words, like got as you see them here. And he actually combined that to give the brand its iconic name Lego. It essentially translates in English as play well. And that is the name that we have lived with for years. It was only very recently that we discovered that the name in Latin also has a meaning. Incidentally, the name means I assemble. Such are the interesting stories with the brand. We move on and we see that, you know, we have settled in the 1930s and we are entering the 1940s. Ole's sons have joined the business and are showing active interest. And this chapter three, which is very close to my heart, is a chapter that I will narrate to you in the words of Gottfried Christensen, his third son. So basically Gottfried comes back from office one evening and he says, Dad, it's a great day. Why? It's a great day because we've made a lot of money today. How? We've made a lot of money because we've cut down on some costs. Okay, go on, says the father. He says, you know, today I had an order from the Danish cooperatives for two boxes of ducks. I actually gave them those two boxes today up the station. And how did you save money in this entire process? Well, you know, we typically give our ducks three coats of clear varnish. I decided to give them only two this time. They looked good enough. And I have packed them and given them off. After all, they are for the Danish cooperatives. They wouldn't notice.  He said, Gottfried, don't you know this is wrong? You will go back to the station right now, open up those boxes, give those ducks a third coat of varnish, pack them back, go back to the station and deliver them where they have to be delivered. You will not go to bed until this is done and you have no help allocated to doing this. There was no arguing with that anymore and Gottfried had to complete this task at night. That night was the biggest lesson that Gottfried actually learned about what quality means. The next morning when he got up, he actually took a slab of wood. And these were the letters that were printed or rather carved out on that wood and hung on the factory. If you go to any Lego office today, you will find this slab hanging around. These words translate to the core sense of the brand, which means only the best is good enough. And that is the spirit of our brand. When it comes to children, only the best is good enough. That is the next brick in the evolution of the brand as well. That is the obsession with quality that we have and we completely live by it as employees there. Moving on, with an unwavering focus on quality, where could you go? Only up. Even in the middle of what we now know was the Great Depression, this company was growing. Growing and how? And then what can go wrong? Well, in one of the unluckiest incidents in the world that could happen, this factory was hit by a fire. And everything, everything that Ole had was erased and wiped out and destroyed. The most precious thing that actually got destroyed that evening was Ole's spirit to continue this business. And he decided or rather almost decided to abandon this business forever. It was only, I think, a sense of responsibility towards his sons and the 26 employees who were left behind in Billon that kept him going. He got a lot of offers from other companies in Denmark but he decided to stay back in Billon and with a little help from these employees and the family, he decided to rebuild the factory again. What came out was a factory which was obviously more modern than the warehouse that they had. And what did that mean? That meant that they could actually go into mass production. They could also actually use new age materials now, move on from wood to something different, notably plastic. And this, you will see, becomes a very important chapter as we go ahead in the history of the brand. Now not only the destruction of the factory but also this is the time when they were faced with the World War II. Good quality wood had become rare and so what do you do? Ole decided to take yet another punt and he invested hugely into a very expensive then injection for a plastic molding machine. He brought it and installed it into his factory much to the displeasure of his children. Godfrey was once found coating to a newspaper saying you can make very cute little nice things in plastic but then wood is always stronger. So the sons also decided to persuade the father and said plastic is not good enough, we should move out. And these are the famous four words that Ole used to his sons at that point in time to say can't you see, you know, if we were to actually build in plastic, we will be able to move out of Billon and Denmark to the rest of the world. And the globe is where we will be able to make the children happy and bring smiles to their faces. I must say now he was definitely a visionary, not only because, you know, he gave us the brick that we see today but also because decades later another factory actually took fire and that's the time when the sons decided to absolutely abandon the wood business and go back to where their father had shown faith and that is plastic. This is also another brick which actually shows resilience and innovation at times that were changing rapidly. Now, you know the business is doing well, the sons have joined in, they are taking their part, they are moving across the world and this is the time when the sons had started going out to the globe and gathering feedback. They were very keen to listen to customers and kids to understand what is doing well and how could they do better. At one point in time, Godfreyd met one of the retailers who simply said, toys are not that great these days and Godfreyd said, what's wrong? Toys are just great, we are doing very well. He said, yeah, they're doing well, but there is no system. There is no system. These are the words that then kept haunting Godfreyd throughout the night and he said, what do these words essentially mean? The next morning when he got up, it all made sense to him. He said, yes, there is no system and what does that mean actually? He said, you know, kids, imagine and create, but what are we giving them as toy makers? We are giving them ready-made toys. Yes, I love a car and so there is a car for you. Yes, I love a dollhouse and so there is a dollhouse for you and what if I want a horse tomorrow and what if I want a rocket day after? So he said, there has to be a system. Yes, these bricks could be placed together but there was no mechanism to lift it and he thought and he thought and thank God he thought because what he came up with at that point in time is the classic interlocking mechanism, tube mechanism in the bricks that we see today. They click and fit together. Now, you know, a lot of you ask us, is the box that you sell equal to one build? Can I really buy this box for my child? It's so expensive and then he just builds it once and I just display it and it's over.  We allow the children to imagine and create whatever it is that they actually imagine in their heads. So they could actually decide to build a rocket today and a plane tomorrow and a car day after and their worlds could also merge together in the same system, that is the system in play. Okay, so that brings me to chapter seven. All is going well. There are bricks and bricks and bricks that are selling, sets are all doing well and then we have been listening to customers and we have been listening to retailers but what about the core consumers, the children? The company had learned its own lessons in saying that we need to listen, we need to see feedback and we need to grow with that. What better way than observe our kids playing and understand their play patterns? This is the time when Lego as a group opened its doors, you know, opens its offices to children. Even today, all the children are invited to our offices to play with the bricks. They were given hordes and hordes of bricks and they are allowed to play. What do we discover? We discover that children are very happy playing with our bricks. But then the manager said that there is a gap, a clear gap between what the child wants and what we have an offer. And what's that gap? You know, we have subtly and slowly moved into the age of self-expression here and the child himself or herself wants to be a part of the play. He wants to be in the castle. He wants to be riding that horse. He wants to be flying that rocket but we don't have a figure to represent the child in there. Very simple problem one thinks and yes, we also thought that there was a simple solution to offer. So that is the birth of the mini figure, a four brick simple figure with movable hands and legs but that changed the fate for us because it was the child who was a part of the play now. He or she could himself or herself see them as part of the play. This mini figure, as mini as it looks to be, changed the fate of the brand once again. We grew about six times our size in the next decade, only owing to this mini figure. And then you say, you know, we have the bricks, we have the sets, children are building, they are in, everything is going just right. What can possibly now go wrong? Times have changed once again and the kids have gone back to screens or rather gone first time to screens and video games and there are fleets and fleets of consultants for the first time at the Lego office, advising them on the fact that the box of bricks is very humble. It's not good enough to keep the children besotted because children are now into Tamagoche's and Nintendo's and whatever. That's the time, there was a knee jerk reaction for the first time by the senior management at the Lego group and they decided to give the consultants a listen. If there are any consultants in the audience, it's no offense intended here. But this is the time when they actually decided to give the consultants a listen and they said, okay, let's make our sets flashier. There was jewelry, there was motors, there were lights, everything that was added to the Lego sets. It was actually no longer the vision that Christensen had started with. It had really become a product that was trying desperately to stay relevant in times that had seemingly changed overnight, right? Sales were plummeting. And this time, in my head, there was no factory fire, but the brand had gone up in smoke. The brand was almost at the verge of filing for bankruptcy. And this is the time when they opened their doors to a new CEO, a 36-year-old man called Yon V Nootstrop, who we very fondly call as JVK in our office. 36-year-old guy who's come in from a consulting background and for the first time outside the Christensen family decides to take over. His strategy and what he has achieved out of that strategy has become one of the biggest lessons in the turnaround of corporate history. It is actually put together in a book called Break by Break. And that book has some of the most essential lessons that are given in business academics today. What was his strategy, you would think? The strategy was simple, go back to basics. And what did that mean? So he simply came back and he said, let's cut the number of pieces that we are developing right now to half. Let's sell off all the Legoland parks, drastic as it may seem, right now, only to focus on what we do best with the audience that we work best with, that is children. He got the design team absolutely focused on understanding what children do, play and how, and said innovate, but innovate profitably. This is the first time when the group invested in homegrown IPs. And that is the birth of Bionicles, which may be new to some of you, but that was also the birth of something new that is collaborations. We actually opened our doors to collaborating with what was trending at that point in time. And that gave birth to one of the things which was our collaboration with Star Wars, riding onto the pop culture. The homegrown IPs and this collaboration itself snapped Lego brand out of bankruptcy and how, is a story to tell. So now things have started looking better. And then wisened and humbled by the lessons that we have learned, we decide not to ignore any of the demographics that matter to us. And one of the demographics that mattered to us and had been royally ignored were the adults. You know, we had a lot of motivated fans who were continuing to build us. They were passionate about building, but we were always focused on the kids. And by this time, from a time perspective, we had also entered the age of community building. So this is the time when the Lego group decided to actually create a platform and bring in all the adult fans together. That platform of the adult fans allowed them to vote for ideas and submit their ideas. Some of those ideas were then picked up by our designers and are some of our best selling products. We fondly call this community the A-Falls, the adult fans of Lego. This is hugely growing across the globe even today, including India. I don't know if some of you sitting in the audience are A-Falls, but this is for all of you who enjoy building that this is the time when the group actually opened its arms to the adult fans as well, riding on to innovation with a different audience altogether. And then, we said, while we stay true to our core of children and role play and storytelling, the way storytelling is happening has got upgraded. Children are now a part of a content revolution. What can we do? And that's the time in 2014 that we decided that time was ripe for us to invest in content. The first time that the Lego group went out and made a movie, the Lego Movie. The budget for this movie was very, very minuscule, but the movie was one of the biggest grossers at the box office that year in 2014. Not only did it change the way the Lego group looked at content, but that was the year where Brand Finance reported that Lego had actually toppled Ferrari to become the most powerful brand in the world. And since then, we've never looked back on content. So chapter 11, figuratively and otherwise, meant the end of that part. And that brings me to the final chapter, chapter 12, which is the chapter that we are living and breathing today. It's a chapter that I lovingly say, a chapter of promise. A promise of keeping children playing with things with an environment that they are growing in. We talk of sustainability today. We talk of energy conservation. We talk of diversity and inclusion. And what does that mean? As I stand here representing my brand today, there are tons and tons of people who are actually working towards getting us sustainable materials to build. You know, replacing the plastic that you see today. We are changing our packaging from plastic to paper. From an inclusion perspective, the minifig that we just saw is no longer the minifigs that you have only seen. You see not only all colors of skin and hair to make it more inclusive, but you also see all sorts of disabilities presented by those minifigs because we want to give each child an equal opportunity to play and adults as well, of course. So that is actually the end of what I wanted to say. And at the end, I just want to conclude by saying that we are not 90 years old. We are obviously 90 years young, and we hope that we can keep all of you young with many, many years of play that we have in us. Thank you.