 So this is the front-end group update for August 8, 2017. My name is Jacob Schatz. I am one of the front-end leads. And this covers both the functional group update for the front-end DC and AC. So accomplishments. We have been doing a lot of UI polish. So in the previous 9.4, we finished 91 or something like 85 UI polish issues. And we're continuing to battle through those. And that just involves cleaning up the user interface and little things like margins here and there, which just makes such a huge difference. So if you see any inconsistencies in the UI of GitLab, then definitely report those. And we will get to them. The group level issue boards is almost finished. Simon is working on that. And that is not in yet, but that will be in 10.0. The confidential issue page redesign is really great. Regis worked on that. And that is going to be in 9.5. We put together web pack code splitting. So there's a lot of stuff that will improve the performance of GitLab tremendously. And Tim's team did a lot of that, including web pack code splitting, where only the code that is needed is included on a given page and removed all the inline JavaScript. So there was a lot of inline JavaScript. And this is something we'll be trying to do for a long time. And now that we have the bandwidth to do it, it's absolutely fantastic. And JavaScript is deferred. So what that means is that all the things that we're slowing down the page from loading on the front end side are fixed. Or a lot of those things are fixed on the most primitive level of loading JavaScript. And so the long and short of it is that this will make GitLab a lot faster. And the repo editor is in under a feature flag as well. So then some fancy gifts here for you. We have the collapsible sidebar and flyout menu, which you can see here, which looks really fantastic. And here's just a quick gift of the repo editor. And that is the start to a really big thing in GitLab. Boom, right? And what that'll allow you to do is edit multiple files at once instead of going to different pages. Some of the concerns were we were doing too much in one month. So the more code that you write, that means the more regressions that you're gonna have just from a line by line situation, the more code that you write, the more regressions you'll have. Also the more characters you'll have on the page. So the solution is, I'll get to the M&Ms in a second, the solution is that we started giving less deliverables in a month. And when you have less work on your plate, then you can have a lot less regressions. And then you can focus on more, you can focus on one thing at a time or less things at a time, which helps people to be able to get a lot less regressions. We started, my wife is a surgeon and in surgery, they do something called M&Ms, which actually stands for morbidity and mortality, which I've mentioned this before. And what that is is surgeons, it's obviously a lot more critical if they make mistakes because people die. And when people die, they always go over that and they have a big meeting and they talk about what happened and so that they try and prevent it from happening again. And I believe that we should take regressions as seriously or very seriously as well. So we started doing something similar to that where we list a bunch of all the regressions that happen and this is not about pointing fingers, but this is about finding out what went wrong. It's a postmortem, but it's a very specific postmortem or a retrospective. It's about finding what went wrong, how we can do better and how each individual can do better and how we can prevent sort of things like this from happening in the future. People aren't dying from regressions, but they die inside. So the thing is that we should be taking all regressions very, very seriously and we should try to not have regressions happen in the first place. And if we can shine a light on how they're happening in the first place, then I think that we can avoid them in the future. I think that that is something that is within our control. So we might as well do it. And also we've been planning, we've been doing this for a while, but we started to really get more in depth. We're planning the next release and we start that planning on the seventh and we're giving each item a total weight so that we can, over time we're figuring out how much one person can handle. There's a link to the 10.0 and you can see on each tab in that Excel spreadsheet or on the Google spreadsheet. Right, every new feature is a bug waiting to happen. I like that. That you can see each tab has a list of all the features, who's working on them, how much weight it is and what the priority in the order that people should do them in. And I think that this is something that we can put into GitLab, more visibility for managers and other people in Philippa and Clement and Tim, we always do this all together and it really helps a lot get a big picture of how the release is going to go. And also to prevent UI regressions and that's like the visual regressions from happening, we started a framework where a server that is currently running on DigitalOcean, basically two times a day, it follows the instructions on how to install GitLab from source, it installs GitLab from source, runs through a bunch of the app and starts taking screenshots. And in a little bit, it will actually gift the screenshots against the previous release and see what has changed and so that we can get, and it does this on multiple browsers, so it'll do this on IE and Firefox and Google Chrome and all that stuff. And so that we're starting to get more visibility into the UI regressions that are happening so that we're at least aware of them. And so you can go to that screenshot archive and you'll see that a really interesting thing is that you'll see a lot of 500 errors because it turns out that often, if you follow the instructions a lot of times, you won't be able to install GitLab from source every time. Sometimes there's just, you know, things that get in your way from that, which is also a good thing for the people who are putting together the GDK so they can put together GDK so that they can see whether or not this... So the QA project, I took a look at the QA project. The QA project is fantastic. Mine is mainly for taking screenshots and running this against browser stack, which hopefully we'll be able to run this against our own sort of browser stack in the future. But this is mainly for taking screenshots and pushing them up. So actually the QA project and this are very similar. When I started it, I think the QA project and this started at similar times and I wound up doing it, you guys wound up doing it all through Ruby and I wound up doing it all through Bash scripts. So I think that we can probably merge the two at some point. So yeah, so, because I did a lot of work into this and I didn't know about the QA project that in the beginning and now I know about it. So I just bashed all the things, that's right. So it's actually really cool. I like it a lot. The one really good thing about it is that it does follow the exact, I'll put the code is up, I'll put the code somewhere and then people who are much better at Bash can review it because I'm sure that it's not, a lot of it's not kosher. But yes, so the thing is that, the main thing is that it follows the install from source instructions like to a T and that's the one thing I really, really wanted to do because a lot of times I find myself trying to install GitLab from source on my own digital ocean because I use GitLab for stuff all the time. And I want people to be able to install it like on the first time, like it should install exactly like the install instructions say. So, and a lot of times it just doesn't. So if anybody who's doing the GDK, if you go to that screenshot archive and you get a 500 it means that the install instructions don't currently work. One of the recent reasons that it didn't work is because of RE2 and I had to install that and Stan helped me out with that. So, you know, I will keep updating that as I can. So, and so we're trying to find solutions to the current problems that we're having. And so those are some of the solutions to those things. We have some big things in the work, in the works the repo editor, which I mentioned before is currently under a feature flag and that is, you know, a work in progress to do much, much cooler things in the future, but you need to start with the repo editor. Next month, we're gonna, this month, intend that we're gonna be commenting on images in diffs, which will be the start of our big idea to help UX designers actually have GitLab be useful to them because GitLab is not always as useful as it could be. Images should be diffed. Images should be revisioned, not just pasted into markdown and then forgotten because images are just like code. They are revisioned over time as well. And so that also winds up helping everyone. It doesn't have to just be UX designers. You can imagine that NASA or somebody else has their blueprints in here and those should be diffed over time and you should be able to comment on a specific pixel point of that thing. So, yes. Yes, Remy, we are currently using, I want to use GitLab in the future instead of a spreadsheet and we can't currently do it. One of the reasons we can't currently do it is because issue boards do not support multiple labels. Is that what it is? They don't support multiple labels. I think that's what it is. And also, I think that we should just make issue boards support all the things that that spreadsheet supports in the way that I'm using it. Not that it should be a spreadsheet, not that it should be Excel. But in the future, also with the UX stuff is that the commentary on images diff, that's the first step to then having an asset library where you can have assets that get revisioned over time. And we talked about this. And like the Wiki has its own repo, the assets should have their own hidden repo. And then assets that don't belong directly to the repo itself can get revisioned over time and commented on. And this will be really, really cool because then as an example, UX can say, here's your design and we comment on it and we can go back to different revisions of it just like we do for regular code. Yeah, so there's the use GitLab for front-end scheduling. Thank you Clement. I had to do this really quickly. There was a quick switch of the schedule. So that's why I put this together really quickly. So that's that. So I didn't get a chance to put all the links in here but all the things do have links. So the UI improvements for a VR framework, we're having big, big performance improvements via Tim's awesome performance tools. He put together SightSpeed and a bunch of other really great things and they're starting to, not starting to, they've made a bunch of really big improvements and GitLab has been a lot faster. We have lazy image loading, which is really fantastic. And it's not just any old lazy image loading. It's lazy image loading as you scroll. So it's very, very cool. A lot of really great math went into that. We're trying to reduce the regressions that happen and we're trying to speed up things with view where we are rewriting the comment section in view which will in time make the commenting because you can't currently comment. You can't have 300 comments on an issue. It just, or on a merge request. It's just, it's impossible to view it. You type one letter every 20 seconds just because there's a lot of event listeners on there. So we need to improve that over time as well. And then we have a proof of concept that we're trying to get in this month which is browser testing in GitLab, like SauceLab. So we have a lot of really cool things in the front end going on. And if anybody has any questions about those things, now is the time to ask those questions. Regarding the screenshots, do you have to go through every screenshot to find the regressions? How are they signaled? That's a great question. The first step is to just get the screenshots to take pictures and we can go through them. I think the next step is to signal when there is a difference between the previous release and the current release which doesn't necessarily mean that there's anything bad. It just means that something changed. And so the key is just to know when something changed. And if we didn't know that it changed that's when the problem exists. So we have to find a way to signal that but we currently don't. The current step is just to take the screenshots in the first place which was kind of a big thing. Yes. Right, yeah, just send all the emails to me. Currently I'm using on my, it's my own server right now just cause I wanted to get the thing running really quick. I'm using image magic as a thing called convert. And I know saying image magic is like, currently we're not using image magic for a lot of things but I happen to be using it on the server to diff things. And the diff actually matters cause you don't necessarily wanna do it. There's a lot of different ways to diff images and currently I'm doing it where one side shows green and another side shows red. And then you can really, really see the individual differences. If you just compare on a pixel level it doesn't do a great job. So I might even different in multiple ways. I've played with it around with a bunch of different. Things like that with different ways to diff. Does anybody else have any other questions? Great, well thank you so much for taking the time to listen to me and have a great rest of your day. Bye.