 Nid oedd yna'r dros. My name is Malcolm Young, I'm on Twitter all the rest of it as Malcolm Young. I'll work at CAP Jam and I and I want to talk to you about CoGov view. Why it's a good thing to do, how to do it, a few bits and pieces around it, and hopefully it will help you to improve your teams. … coordinates time because I know in the last few years, in my experience, a Codew accidents has been a massive help in improving not just the quality of the code that we are delivering but the skills of theIX … code. I think one of the important things with code view is all about asking questions and I don't claim to know all the answers and I'm not going to attempt to give all the answers in this talk. Ond oed i fi ddim bwysig i chi'n gweithio y cwestiynau ym mhwydd. Yn ymddangos, ydych i'w gweithio, ddim gweithio i'w gweithio i'w wneud i'w bwysig i gweithio? Yn ymddangos, mae'n gweithio i'w fod yn tu'r gweithio i'w gweithio, yna? Fy hwnna, mwy ffwg... Bwysig i chi. So we've had some technical bother which means I'm running on the two laptops so please forgive me if I'm looking like some terrible DJ. So yeah as I was saying it's all about asking questions to this code review business. So if you do have questions as we go along please feel free, shout out. And the first question that I want to ask about code review, pretty basic one, what is it? ..egdshaf o'r tyfn o sydd y clyw yna'r rhaid iawn yn hytyllfa'r ansiyl. Felly yn ystod oes yn hyfrifio'r cyffredin. Fe yna'r enthysgol y maen nhw'n gwertho i fynd i wneud, ac bydd y gallwch gion wedi ffyrdd gan goll ti. Mae chwebwch yn y mach i chi, ac mae'n gweithio'n gwneud. Rylan o bobl y mae'r rhaglen armennill o'r syfrifio. documenting it.So I feel I'll have to go with the tradition on that one. That the difference between good code and bad code is all about how confusing it is in a lot of times. But this idea of a team of people sitting together staring at code together, it's not great. I'm thankful I've never done it, but I imagine it's pretty time-consuming, pretty tedious, pretty inefficient. So is there a better way of doing it? Yes, there is. So these days, I guess, most of you are hopefully familiar with using Git, different branching models. So, when you're working on something, standard process, if you're in Git, would be create branch, commit your changes, and then create a pull request into the main branch. And that pull request allows people to see what those changes are and review them. So you get something like this. And with a quick search of Flickr, the first image of a pull request that came up was on the jubilar. So it feels kind of appropriate for a jubilar talk. So what you'll see with a pull request that you're not familiar with is a red line showing you here's a line being removed, here's a green line with what's new. And so you get members of the team, senior, junior, everyone. Let's have a look. Are we happy with this change? If so, merge it in. In case you're not familiar with Git branching workflows, there's a very good pull tutorial by Atlassian. So yeah, if you're not familiar with it, I'd very much recommend that. And so that's the basics. But before I go further, I want to say thank you to Mr Outfought. So we've got a lot of reasons in the Drupal community to be thankful to him. So I was lucky enough a few years ago he worked with us at CaptureMini. I can see a few familiar faces in the room, and I guess they would also share this view, hopefully. He was a very big influence on our team, and I think on the community as a whole. And in particular, in this area of code view, he was one of the guys that really pushed for that to be a massive part of our workflow. And set a very high standard, making sure I see some nodding down the front of your hair. High standards, pedantic, picky, call it what you like. But there's a lot to be said for having those high standards. And obviously he's no longer with us at CaptureMini. He's become one of the core maintainers of the Drupal projects as a whole. And I think he probably does even more code review now of patches than he used to back then. But yeah, I want to say thanks because I certainly learnt a lot from him. And I think I wouldn't be doing this talk if it wasn't for what he'd helped me learn. So why are we doing this? So you might get some pushback from project managers. You might get clients thinking, ah, you know, we need to get these features out the door on time. We need to rush things through. People breathing down your neck. That perception of is it just a waste of time for developers to sit round talking about code? And I would hope that I would very strongly push back on that. Because everybody makes mistakes. Even Alex, even, it doesn't matter how senior you are, how much experience you've got, you're still going to make mistakes. Sooner or later, you'll press a key before hitting the commit button. You'll find some problem. So it's much better to get those mistakes spotted. So, obviously, most teams will be doing some kind of QA, some kind of testing. But one of the keys, I think, especially when you're in larger teams, is to get really fast feedback loops. So ideally, the fastest feedback loop of all is before you commit anything, you look at the diff of what you're committing. If there is a mistake, hopefully you spot it there. If you do commit and push it up, once you see it in that slightly different context, the red lines and the green lines on the screen that we saw earlier from the pull request, seeing that different context is hopefully going to see that code in a new light. You hopefully will spot potential problems then. And to come back to that point that Project Manager might suggest to you that code reviews a waste of time, it's a false economy. So not reviewing code is going to cause you more problems in the longer term. And anyone that says it's not good value, I would suggest showing them this graph. So this is from a few years ago on a very large project. At the time we were using SVN, and this is from my colleague Tom Feddian's blog from, I don't know how many years ago. But the two graphs we've got here, this top one is the percentage of our custom code that had been reviewed. And this bottom one is, along the same time axis, the number of new defects that were getting raised. So it's pretty clear to me, as you increase the amount of code view that's going on, you decrease the number of new bugs that are getting created. And if you care about quality, and you should, you should be doing code review. And in my opinion, it's almost as important as testing. So spotting and fixing those problems as early as possible, and improving the efficiency of your team. If you can spot that problem before you've wasted the time of let's do a build into the test environment, let's get either our automated tests or manual tests to look at that, you're going to be much more efficient as a team. And hopefully that will end up with happy clients, happy project managers. So yeah, number one reason I would say, prevent bugs. Second reason for doing code review is to improve the maintainability of your code, to stop yourself ending up with this big horrible tangled mess. I guess you may have all seen these projects where it goes on for a little while, someone adds their little bit of code, someone else adds their little bit of code. And before you know, you've ended up with this enormous function that's really a nightmare to maintain. So as you're putting those changes in, code views this opportunity to say, well, could we be doing this a better way? Could we be refactoring this into separate functions to make it more maintainable? And most projects go on for a fair while. And the cost of maintenance is going to outweigh the cost of build. So you're going to come back to that code that you wrote before, or your future colleagues will come back to that code. And if you've taken the time to review it, to make it more maintainable, your future self will thank your present self. And so will your colleagues. We'll see. Reason number two, code maintainability. And the third reason why I think code reduce is important is learning. And somehow my notes have gone crazy, bear with me a sec. Yeah, so learning. I've mentioned it a little bit at the start. So personally, I think I've learned an enormous amount from code views. And that's not just people looking at the code I've written and saying, this is wrong, this is wrong, this is wrong, which they have done and they still do. But it's also about what I've learned from other people's code. You get the chance to see different ways of approaching problems that you might not have thought of. And this, excuse me, this ties into this idea that I mentioned before, that it's not just about you write your code, you create your request, the senior most developer on the team looks at it, passes judgement from on high. Everyone on the team has something to contribute. It doesn't matter if you're junior, if you're new. It's not just about the senior people telling the junior people how it should be done. Everyone might be able to think of better ways of doing things. Everyone might have something to contribute. So yeah, great learning resource. So hopefully you're with me on this idea that it's a good thing to do it. So how do we do it? Most common things that we might use, GitHub, Bitbucket, obviously there's things like GitLab as well more. So these are the big ones that have hosted Git repositories that have built-in reviewing tools in the pull request mechanisms. So I've mentioned the branching model before, and like I say, if you're not sure about that, have a look at that at Lassian talk I mentioned earlier. But basically before code gets merged into your main branch, you're going to get it approved. So I guess most people have probably seen something like this before. Here's the pull request. You look at it and say, yeah, I'm happy for this to go into production. And that is an important step because it's not just about here is one individual who wrote this code. As a team, we're all responsible for the quality of the product that we put out. And when a person says, right, I approve this code, you're putting your name to that as well. You're sharing that responsibility. And you can't later just look at Git blame and say, OK, this guy wrote this line of code. It's this person's fault. We'll take that responsibility as a team for maintaining quality. So as we're doing what is it that we want to be looking for? So some of this stuff is going to be specific to Drupal, some of it not so much. But I think the main things that we want to look for first one, will it work? So is this change that we're making actually doing what the client wants it to do? Are there any edge cases that we might not have thought of? Are there any potential bugs in it? And part of that, obviously, this is going to be specific to your project and your requirements. So there aren't going to be general rules to that. But know what you're trying to achieve, check that the code is actually going to achieve it. And oftentimes, the best way to do that is to check out that branch in your local environment and just test it for yourself. See if there's anything that doesn't work quite as expected. Are there any edge cases that you might not have thought of? I know Lullabot built this tool called tugboat that lets you, every time a pool request gets created, it can spin up a whole test environment that you can get the QA team or the client or yourself to look at it. That's a fairly high tech solution to this. The lower tech solution is, as a developer, check out the code yourself. See what happens. A few other main points to be looking for. So security. Are you making the site vulnerable to any attacks, cross-site scripting, SQL injection? Performance. Are you potentially making the site slower because that's going to cause problems for your clients and for your users? Accessibility. So are you potentially causing problems for some of the users of that site? And I touched on it already. Maintainability. Are you causing problems for your team in the future? So those are the main areas and I want to go through each of them in turn very briefly. Will it work? That depends on your projects. I can't really help on that point. But security. I definitely do not claim to be an expert on this, but there are some general rules of thumb, things that when I'm doing a code review I would always try and watch out for. And first rule I would say is trust no one. Definitely don't trust someone that gets a tattoo like that and wears their phone on their belt as well. So, yeah. In the context of websites, never trust user input. Anytime you're seeing input from the user being handled, as you're in the code review in that pull request, think about, okay, how's this user input getting used? Is there any possibility that an attacker can inject JavaScript into the page or they could potentially write SQL injection attacks? Because if they can, if you're just taking, here is some raw user input from a query string from wherever, an attacker could potentially take over your site, cause you all kinds of problems. So, yeah. Sanitise everything. Now that would be a whole separate talk to go into and I don't have the time to cover that, but there is a lot, and also I'm not enough of an expert on it. Drupal docs about writing secure code, various different sanitisation functions that there are slightly different docs for seven and eight obviously. So, on top of user input, the other thing I would think about in security terms on a code review is, are we changing the types of data that we're getting from users? Is that sensitive data? Is it personal information? If so, how are we storing it? How are we transmitting it? Do we need to encrypt it? Basically, any time you're changing the data structures that you're using, think about that data that's coming from users and what you need to do with it to make sure you keep it safe. Next point on performance, keeping things fast. So, again, enormous subject. I'm not an expert. I think from a code review point of view, one of the top things I would want to look out for is I'll be creating any unnecessary sessions because in Drupal, especially if you're using reverse proxy caches, as soon as you're creating sessions, you're making things less cacheable. You're making the server do more work. So, if you're seeing code from a colleague that's saying, all right, get this data, store it in a session for an anonymous user, is there a better way of doing that that means you don't need to create a session? So, yeah, keep things cacheable as much as possible. Are you writing any inefficient loops? Sorry, this whole two-screen setup is confusing me a lot. So, like I say, performance massive subject, but definitely one to keep an eye out for, keep an eye out on when you're doing code reviews. Next subject. So, I don't know if you guys can see what's going on here. This is down by the south bank. So, here we have some steps, and here we have a realm. So, accessibility. Again, another massive subject, far too big to go into here, but in code review, especially on the front end, there's a few sort of checklists, ground rules that you can bear in mind. So, number one, think about how keyboard users or users of other assistive devices are going to be using your website. Again, you can check out the branch in your local environment, you can test it out. If you're writing CSS, you can always think about any time you're applying a hover state, what about focus state? Or so, are you hiding text appropriately? So, if there's text that we'll show later, think about how is that going to be handled by a screen reader? A general rule, if you're looking at display none, you're going to be keeping it out of screen reader users. So, look at accessible private techniques, hover and focus are mentioned. Pretty useful checklists from the accessibility project to have a look at if you're not familiar with it. Again, it's something that you could really dive deep into. And then the next one, so maintainability. So, looking at how your team is going to work with this code in future. So, you want to make your life easy. You don't want to cause yourself too many problems. So, as you're seeing new code come into the system, think that, are you writing more code than you need to? Is someone doing some crazy custom thing that they don't even need to do? Are they using API as appropriately? Don't be afraid to look at the Drupal docs. See what functions already exist. As well as that, unit test coverage. So, how much of your custom code can be unit tested? If it can't, should it be? There's a possibility you could look at making it, breaking things down into smaller functions so you can test it. And comments. If your code is hard to understand, that's a sign there might be something wrong. So, are there enough comments? Are there too many comments? Sometimes, if you've got too many comments, it just becomes noise. And on the subject of code maintainability, there's something in particular. Larry Garfield talked about it at Drupal on London a few years ago. And that's code smells. So, what is a code smell? So, it's a sign of possible problems. So, Larry did a great talk, I think it was, what's that, six years ago. And that was, I think, the first Drupal event I've been to. Really good talk. I would very much recommend checking that out. But as you're doing code views, think about some of these code smells. So, they're not rules, they're kind of guidelines of here's something that might be causing problems. So, in his talk, Larry mentioned seven common code smells. The first one was and. So, if the description of your function is does this and do that, it's doing too much, break it down into separate functions. Or does your function sometimes do this, sometimes do that. Again, bad sign. So, as you're reviewing code, keep an eye out for these sorts of things. If. So, do you have a lot of conditions in the same function? Are you ending up with excessive complexity? Testability, we touched on them a minute ago. Can your code be tested? If it can't, should it be testable? Documentation. So, again, are there enough comments? Are there too many comments? Tight coupling. So, is this part of your system, does it stand alone? Could you take it out into a class and use it somewhere else? Or is it too dependent on other parts of your system? And the last of Larry's seven smells, impurity. So, does your function have some side effects plus return values? So, all of these would be things to look out for in custom code that you're writing. Obviously, with Drupal, we're in a lucky position that there's a lot of contributed code out there. So, we need to think about, you know, there's a module for that, people say, but is it appropriate to use that module? So, when you're adding custom modules, when you're adding contributed modules to your code base, don't think that just because it's published on the internet means it's perfect. You know, there are bugs in contributed modules. So, as you're adding them, review them. You know, if you spot problems, obviously issues on Drupal. But also, as you're adding those contributed modules, ask yourself if that's the right choice. Similarly, as you're adding custom modules, ask yourself, is that the right choice? So, contributed modules, often they're a bit like Swiss Army knives. They serve a lot of different purposes, but they might not be optimised for your specific purpose. So, that ties in with the performance questions we talked about earlier. You might think, you know, modules like rules, they're massively flexible, but they can also give you performance headaches. They can maybe make life more confusing for your site editors than it needs to be. So, sometimes you just want something very specific to your purpose. So, yeah, if you're creating a custom module, think about should we use a contributed module instead? Or perhaps should we use, should we take our custom module and turn it into a contributed module? Equally, when you've got a contributed module, is it the right choice? Any time you're writing a custom module, think about could you make it more generic? Is it something that you could contribute back to the community? And that's something that we do try and do at Capgeminar. We've got a few examples of things we've built for clients that we've thought, okay, well, yeah, let's make this generic, let's put it back into the community because other people will use it. This slide, I just like the picture really. So, I think one of the big challenges on any project is communication, doing enough communication, doing clear communication, and CodeView is another opportunity for communication. So, yeah, speak your mind, I don't know about the first horseman. So, be open and frank and honest with your colleagues. If you see a problem, speak up. Just because you're a junior or new to the team or unconfident doesn't mean you can't ask questions or spot problems. And if you don't understand what a piece of code is doing, it may well say more about the code than it does about your abilities. So, if it's hard to understand for you now, it's going to be hard to understand for the team maintaining that in the future. So, yeah, everyone on the team has something to say, and you shouldn't be afraid to say it. On the other hand, don't make it personal. So, you're reviewing the code, you're not reviewing the person that wrote the code. Back in the start, I talked about everyone makes mistakes, and that's how we learn. So, writing bad code does not make you a bad person, and being a good person doesn't mean you always write good code. So, CodeView isn't a competition, it's not a chance to score points off the other people on your team, and you are a team, so support each other. Help your colleagues to improve. If you see someone doing something that you think isn't the right way of doing it, don't just say, this is wrong. Explain why you think it's wrong. If you've read an article that helps you to see why that might not be the best way of doing things, share a link to that article. Share ideas. I've talked a lot about mistakes and bad code, but CodeView isn't just about that. It's also an opportunity. If you see here's someone who's written something to solve a problem, and it's a really nice way of solving that problem, point to that example, share that with your team and say, I really like this way of doing it. It's very easy to forget that we're all humans and we need a bit of support from time to time. Get the whole team involved, be supportive, don't just criticise where you see negative things, be positive at where you can. We're all humans, but machines can be better than humans at some things. Where machines are better, use them. For instance, coding standards. Really important. I'm a bit of a pedant on this subject about sticking to Drupal coding standards in Drupal projects, in other projects, sticks to whatever standards are on that project. The important thing is having that standard so everyone's writing code to the same styles. If you're in a pull request, writing comments saying, put a full stop at the end of this comment, have the right amount of white space, that gets pretty tedious. Get the machines to do that for you. The appropriate level of automation is going to vary depending on your team. Cagliam and I were a pretty big team. We've gone to a level where, for instance, when someone creates a pull request, Jenkins is going to run PHP code sniffer against that. If you're introducing new code and standards violations, that pull request isn't going to get merged. It's going to run the unit tests. If the unit tests fail, the pull request isn't going to get merged. We run PHP mess detector. If you're introducing enormous levels of complexity, the code isn't going to get merged. Smaller teams, if you're working on your own, that might feel like overkill, but you can always set up your development environment. Some docs on Drupal.org about how to get PHP sniffer integrated with whatever it is that you use so that, as you're writing the code, it's picking up any places where you're not matching coding standards. You can also set up pre-commit hooks so that, before you even push your changes to the repo, a machine is going to check, are you breaking any coding standards, etc. And, like I say, there's also Jenkins continuous integration, so there's quite a nice template that some of the people have put together. We're using that on a couple of projects to get Jenkins to check the status of the code before you can merge that in. A lot of these points that I've mentioned, it's about spotting bad code, and it can be a bit like needle in a haystack. So, when you are looking for a needle in a haystack, try and keep that haystack small. In the same way, talking about code smells, long functions are a code smell. They're a sign that something might be wrong. Similarly, big pull requests are a sign that they might be something wrong. With git branching is easy. If you've got a big feature, have a feature branch for that, have pull requests going into that branch, review them as they go along, because it's a lot easier to review small changes than large changes. There's a tweet that I quite like from a while ago. If you see 10 lines of code, the people on your team are going to spot 10 problems with that. If you have an enormous pull request, people will read the first file, they'll read the first couple of files, but after a while they'll suffer from attention fatigue. It's pretty difficult to review these large changes, and if you give people too much information, they're going to struggle. There's this cognitive load that people will suffer from if they're trying to review large changes. Also, if you've got a large change, it's much more likely that you will spot problems, and then it'll go around for another loop, and then you'll spot other problems, and then you'll lose track of where you are. It's difficult to spot problems in large changes, and doing code review properly is something that requires concentration, and it's pretty difficult to concentrate for a long time, and that feels like an appropriate place to finish. Thanks very much. Here's some places where I got some images from. Here are a couple of blog posts that I wrote on the subject, and here are the slides for this talk, and that is our engineering team blog. Also, we've got a stall out in the foyer there, so please, if you do have any questions, if you want to have a chat later, come and say hello. Come and talk to us, there's quite a few of us. We have some lovely t-shirts to give away, so yeah, come and say hello, and thank you very much. Yeah, if anyone does have any questions, fire away. Either that or come and say hello. Yeah, okay. So you mentioned that code review is not just for your CEO at this time. What's the process going on, deciding who does the code review? Should it be everyone, should it be a selected team? Yeah, there's that line, I think it's kept back, where any answer to an interesting question starts with, it depends. So, yeah, it depends on the project, and it depends on the area of the project, so certainly with Zipbucket and with GitHub, you can, as you're creating a call request, you can assign reviewers. So you might think, okay, well, here's a CSS change, so let's assign the front end guys to look at that, or you might think here's an area of the code that I know such-and-such a person has worked on. What you might also want to think about is the fact that not all reviews are equal. So I know certainly with GitHub and Zipbucket, you can set it up so that before it gets merged, pool of tests has to have a certain number of approvals. With GitHub, certainly it can be, unless those approvals are from people with right access to the main repo, you know, if you're working on forks, they'd need right access to the main repo. So effectively, there's your senior people who, when they approve it, it's a big green tick, when people without that right access approve it, it's a great tick. So yeah, you do need to make sure that the right people are reviewing it, and you also probably want to make not have an enormous number of reviewers. It depends on the structure of your team and on the structure of your project, I would say. But yeah, I would always want ideally a couple of people to look over code, because if you come from that thought of, well, everyone makes mistakes, you might not spot a problem. So one reviewer may not spot it. So it's definitely worth getting multiple eyes on that. What's much a question that there's a comment wanting I've heard is like, as soon as you start a grant for an issue, you can open a call request on it after the first commit, then anyone assigned his reviews will get notified any time it's a question, then you don't need to take in like 500 lines or 500 files, or once you see something growing, and then along the way say, oh, don't go any further with this, I think we need to read this how we're doing it, because if you wait a week or two or three, it can be too late to change direction that way. Yeah, that ties in with that idea of having the feature branches and having small requests into that. Yeah, we've tried on a couple of occasions doing that, create the pull request first, even when it's, you know that it's not ready to merge. Personally, I'm not a big fan of that. I think I would prefer to have some conversations about the general approach, because you've got this pull request. Yeah, are you going to actually approve it? You know, even if you're even if you're reviewing it as you go along, it's going to grow and grow and grow. At the point where it's really big, you might not remember how much of it you've already reviewed. So effectively, you would need to spend the same amount of time reviewing the whole thing, I would say. That's just more a window of the stuff in progress that's just coming along. I've definitely heard that proposed. Personally, I would prefer, here's this thing that we know is going to be big. Let's have a lot of pull requests into that. And then when we think it's ready, a big pull request from that branch into the main branch, because that way you get that extra level of confidence of, right, well, we know that these changes have all been reviewed. So that final pull request can be a bit more of a just a quick skim down it. Has the international code review changed the way you estimate the question? So has it changed the way we estimate? So I think most developers are guilty of underestimating stuff. It's very easy to think, okay, well, I can write the code for that. That'll be half a day's work. And you don't think about, okay, well, we also need to test it. We also need to write documentation for it. We also need to deploy it to this environment, that environment. We also need to put it into production and so on. So, yeah, definitely code review is something you need to factor into that. I think bigger picture, I definitely believe it doesn't increase the overall amount of time that it takes to build something because you're getting that extra confidence that once it's in the test environment, it's more likely to pass first time. But, yeah, it is definitely something you need to take into account. What do you believe in the institutions like the new configuration management process? Those pull requests are going to be pretty large. There's not really anywhere more than that. Yeah, I think still just review it. You're going to see in those pull requests a lot of green lines, but you still do need to look at them to make sure nothing crazy is going in there. Yeah, so the question was about, on this team they do, is that like with the tug boat type? Yeah, so Jenkins ends up small. So that is another way of doing it. We do it in series rather than in parallel. My personal view on that is if you create the code with the pull request and then get the other developers to review it, it's possible that everything might change. And if everything does change, then the testing will be wasting their time testing this code that hasn't been reviewed. So, yeah, we tend to work with one initial test environment and then a more stable release prep test environment, and we would only get it into the initial test environment after it's passed that code review status. But, yeah, I think that main point for me was the not having the possibility that the testers are going to waste their time on that. Yeah, so in our scenario, client sign off would be after our own internal QA, so it would be devs testing for themselves locally, code review, potentially devs testing other people's code locally, then merge that code into the main development branch, get that into the test environment, get our own QA team on that, and we would only ask the clients to look at it after it's passed our QA, and then, yeah, after that, clients sign off and then production deployment. Yeah, I mean, certainly the projects that I've been involved in a lot of times, the clients don't want to spend that much time directly involved, they just want to see the fruits of the labour. So, yeah, again, kind of with the early point about not wanting to waste our QA team's time, it's that not wanting to waste, even more so, wanting to waste, not wanting to waste a client's time, because they would be even more annoying. Yeah, I haven't, really. What I would say on that front is, if you ever find yourself in, if you're still in features, I suppose it's the same with you, Trudeau, actually, of where the code and the site have got out of out of sync, I would always want to do, right, here's one commit and one pull request to get the feature back in sync with what's in the database, and then a new commit and a new pull request to be, right, well, here's what we're actually changing to try and minimise it, but in terms of trying to reduce the mental load of those large pull requests, nothing I'm aware of, but if anyone has got those ideas, I'd like to hear them. A software as a service idea for someone? Yeah. Then you can use separate commits and then, if you rather than a whole pull request view, then pretty good commits, so if you instruct people to commit their config export, for instance, for Drupalade into a separate commit, you can then separate and just review separately the non-config and review the config as a separate... Yeah, that's a little bit. And yeah, certainly GitHub, there's a query string, I forget what it is, that lets you ignore whitespace divs. I imagine there probably is one on Bitbucket as well, I don't know. You've got several people working on a branch together that then have one pull request, would that have one pull request at the end of everyone's work, or do you have people doing pull requests of their bit into it? Yeah, I would normally recommend doing the individual pull requests into that shared feature branch. So would that be done with private forks or separate branches from... Again, so we've got some projects that use private forks, others that have separate branches, doesn't make an enormous amount of difference, I don't think, in terms of the way you handle that. Yeah, if you're all on branches, you do have that option of everybody pushing into the same branch, you know, you might have the CSS changes and PHP changes, and you might want to put them in the same branch. But I would still prefer, in order to keep the pull requests small and easier to review, I would prefer to have them as separate pull requests then going into a feature branch if you think that that feature might not be ready for the next deployment from your main development branch. Well, thank you very much for listening, and yeah, come and say hello.