 All right, welcome to today's functional group update for Create. My name is Dao Man and I am the engineering manager for the Create back-end team specifically. Create today is a product area, which means that it has back-end developers, front-end developers, UX designers, test automation engineers, product managers, and probably a couple more people I'm forgetting. But this functional group date being held by me will focus specifically on the back-end aspect of that product area and what the back-end Create team has been working on primarily. It is something that I want to start a conversation about because I don't think it's fair that every back-end engineering manager has his own FGU and then front-end has only one FGU for all the flaked areas. But that's something I'll get into outside of this FGU. For today, I would like to talk a little bit about what the Create back-end team has been up to since the last time we spoke on July 24th. We did a couple of things. We managed to release GitLab 11.2, we got started on 11.3, and we also got started on 11.4 just a little bit over a week ago. We went to the summit in Cape Town and we defined some OKRs. I'm not going to read the contents of every slide. I'm just going to go through them relatively quickly. I have the chat open in the second window, so if you have any questions, I suggest you ask them there. Just ahead of the Cape Town Summit, we released GitLab 11.2, and these are some of the more noteworthy contributions by the Create back-end team. The first one there is especially cool because it was a community contribution to the help of a Create back-end team member. If you want to read more about all of these issues, of course, I suggest checking them out, but this has already been in GitLab since August 7th, so chances are you already had a chance to use some of this functionality as well. Just after the 22nd, he went to Cape Town with the whole company, which served as a little bit of a distraction from 11.3, but it was a very welcome distraction. As you can see in the photo here, which is dropped out of a panoramic photo of both of the Create, Manage, and Plan team dinners, we had about 12, 13 people in attendance, and this is not just Create back-end, this is Create across the board. So you've got some front-enders in there, product managers, some partners, and all that. As you can see, we were having great fun in there on the right. I'm in conversation with Nick. Just like I mentioned, the summit took place during the 11.3 development month, but still we managed to push out quite a lot of functionality, and indeed we hit pretty much 100% of the deliverables that we had planned for that month, and two of these were just like 11.2 community contributions that were then finished by people on our team, either by heavily coaching the person who had initially started the merge request or by taking it over once they indicated that they were not interested in taking it any further. And as always, I suggest you check these out if any of these sounds interesting or relevant to you particularly, and if you have any questions about them, that's what you chat us for. So we finalized development with GitLab 11.3 on September 7th, and the next day on September 8th, we started working on GitLab 11.4. These are some of the major efforts we're working on. As always, there's a bunch of performance improvements in bug fixes as well, but the four here at the top are the major features that we are planning to ship in 11.4. Of course, until we finish the month on October 7th, we won't know yet what will actually be going into that release, and that's something that I'll update you on the next time around. Another thing that I did a couple of days ago is that I defined the 2018 Q4 OKRs 40 create team. The first two here are kind of the same across the board for all backend development teams. We want to preserve 100% of the error budget. If that's news to you, I suggest following that link and reading up on what that means exactly. But we're trying to get a little bit better about tracking how many bugs and of what kind of severity are introduced by the company and by each team. Not as a means of punishing people, but as a means of seeing a positive trend over time of us becoming better and more responsible about what we do and don't merge at certain times during the month. We are also planning to add two backend developers to the team by the end of the year, so in Q4, I'm going to be working on hiring two developers, and the team will be helping me in interviewing, of course, but also in sourcing candidates from their local network and LinkedIn and local meetups, that kind of stuff. The third OKR is one that I personally decided to prioritize. Go-Lang, Go-Programming language is becoming increasingly important to recreate product area with projects like Gitly and GitLab Workhorse and GitLab Shell now also being in the process of being rewritten in Go. And we as Create Team have a lot of Ruby and Rails expertise, but not so much Go yet, so we're kind of dependent on people from other teams to help us out there, which is not really sustainable. So for this quarter, I really want every team member to get at least two Go merge requests into some of these Go projects, and Nick, our staff developer, who does already have a lot of Go experience will be helping these team members out with that. And otherwise, before we speak again on November 13th, these are some of the things that are going to happen for Create, and on November 13th, I'll be sure to update you about how these things went. Since there are no messages in the chat, there's one question. If we gradually introduce a feature using Feature Flags, let's see it go south and turn it off before it's a disaster. Do we lose error budgets? I cannot say for sure, because I don't have it seen it written down somewhere, but I would assume no, because if we fix it by just flipping the switch, the impact on production will be minimal. But I should sit on mute it themselves, so he might do something bad. Or it might just be me thinking he had on mute it himself. I was going to make clientele evaluation self-contained. That is a question that if we have any Create from there, and there's on the call, I would ask them to jump in. Like I was saying earlier, this is kind of a Create back-end heavy call because I am the one leading it, and I want to change that. Is there anyone Create front-end in the call who could comment? Respond to Sid's question. In that case, I suggest asking the question in the G Create channel where the whole Create team lives, front-end back-end through XPM everyone. And I'm sure people will have a great response there. Why I am to preserve 100% of the error budget is that anticipating getting to 70%. The thing about the error budget is that we did it for the first time in Q3, and I am kind of hoping to hear back from the infrastructure team on how Create and other teams have done over the month, and also on what we are planning to do in the following months to improve that. Right now, I'm kind of blind there, but I will definitely be working and getting that data. So I think that's where the order is about to come through a close. So I think that's when those conversations will start happening between the different back-end teams and infrastructure. And it looks like Tommy has already asked his question. Sorry, Sid, go ahead. Yeah, so Tommy, you're saying that the real goal isn't to preserve because 100% would be silly, like then we're moving too slow. Right, 100% is the stretch goal. So we would expect normal performance to be 70%. In particular, we've got the qualifier in there about some KRs being new approaches or processes. And really what we're saying is we expect kind of a broad distribution with new goals like the error budget where some teams may hit 100%. Some teams may totally blow the whole budget as we try to figure out what that means and how we're going to measure it and try to dial it in. And it's not that you want people to set the budget at a level where you expect, because now it's not clear how much you should use. Like there is a, like if we set a budget in finance, it's like, this is how much we expect you to spend. Right. The budget in this case is set. The managers aren't setting budgets. We've got, let me grab the handbook link for this real quick, because it's on the engineering handbook page. But it's a fixed budget per team. I think it ends up being like 100 points and different severity issues end up reducing the number of points that you can have. Yeah, I'm aware of how it's set. It's just that now as a team, you have no clue how much, like no mistakes means no deployments basically. Like if you don't build, no mistakes means no new features. So how, how do teams know how to make the trade off? But I think that's a bigger question. So I'll leave it out of this. I agree. That's a good question. That's for the client side evaluation question here. I'm just not clear what, what do you mean? In particular. So right now we ship client side evaluation, except it's only for public projects and only if it's a flag is turned on and it's off by default. Like, and that's because every project that you use client side evaluation from four is shipped to code sandbox. So like they have access to all the code and you might not, you might not be comfortable with that. Even if you're using a, if you have a public project, it might be that your server is behind a firewall and you don't expect public projects to leak onto the internet. So talking about the web ID. Yeah. No, no, no, I understand. I will defer that to Phil because he's the, the engineer more. I don't think he's on the call though. We'll, we'll try to get back to you on the, on G create on that. Is that fair? Yes. That's totally fair. And I think he's making progress and I joined one of the calls. I'm just surprised it doesn't show up in any of the, the road maps or the highlights. I'll double check that. All right. Thanks. Yeah. And so that is in part why I think that we should kind of rethink these back and heavy FG use because there's so much that are fontan team and the create frontenders are doing that deserves, you know, attention in a call like this, but that's something that I will work on with Andre and with James Ramsey as well, product manager to kind of get the balance of content a little bit better. Maybe they should be back in the front end calls, but they should be create calls. Yeah, exactly. That's what I was thinking, but I'm going to create an issue and start a discussion because of course it applies to all of the different, you know, product area based teams that we have currently with their mix of back and front end UX, et cetera. Cool. Cool. Well, in that case, everyone gets 20 minutes back and I'll see most of you in the team call. Have a great day everyone.