All right, we're recording And I'll share my screen so I'm I Don't know how you want to do this. I'll edit this first bit out until we work out what I'm doing Yeah, I think so the goal of this is to get an embedded video or we talk about Yeah, the future of create And put it on I think this page actually yeah Um, so so that would be the goal. I think it can it can be just like a quick walkthrough of this page Mm-hmm. Do you want to go into your category visions? Probably makes sense to at least a little bit. Yeah, I don't know if you cover this one two three four five six seven There's ten of them. Yeah, I mean, I think I can probably cover them In some some detail. Yeah, just like what we've been working on and where we're headed next because I think that's sort of like the purpose of this Okay, so let's let's start here Let's spend just a few minutes on this page and then just walk one by one through through the categories and I think as long as you basically kind of describe Just real quickly, you know what it is and then what the big things are and that we've kind of got plump Land already. Yeah, then then we're probably good Yeah, okay, cool. So you can edit at this point. Yeah I don't know how to start this Okay edit at this point. Yeah so This is a quick conversation between myself and Eric on the product vision for the create stage of the DevOps lifecycle at GitLab Yes, firstly the create stage of the DevOps lifecycle Covers code creation Code review But also some other important areas of that process around wikis snippets the web ID that makes it easy to Propose edits and changes code search with elastic search And also new categories coming soon like design management and live coding. So It's very focused on the the git aspects and the source code aspects But there's important supporting roles in facilitating that code creation workflow And that's really what the create stage of the DevOps lifecycle is all about Yeah, so maybe I'll just talk quickly through this page, but feel free to break in with questions to clarify things I guess the create stage of GitLab has been around quite a long time. So there's quite a lot of maturity particularly in the source code management and code review categories I guess that leads into an explanation of categories So at GitLab, we break the stages the DevOps lifecycle down into different categories And I'll quickly talk through those different categories before jumping into I guess like the key items that we've been working on in each So the first category is source code management, which is really the permissions controls policies and Around the git repositories itself So that that includes the repositories interface the branches protected branches All those kind of controls Forking So yeah, that's I guess like the heart of it And then on top of that is the code review category and that builds and works very closely with the source code management category Which is really where the code review process happens? Lots of discussion and a lot of time is spent in this part of the application by software engineers and developers It's really the tool that defends against code quality and Is a source is the place where mentorship happens for junior engineers and Important hard decisions are made once people get into the trenches of building code So doing code review well is very important for team efficiency The workflows and handoffs between the different stakeholders involved in the code review because there's the author and there's typically multiple reviewers Also the controls around approval So there's the the efficiency aspects and the code quality aspects of code review Both the source code management and code review categories I'm mature as I mentioned source code management being the first feature ever built in GitLab Back in 2011 and then code review was or merge requests were first launched in GitLab 2.0 Which I think was around December 20 2011 So they've been viable for quite a long time and are quite mature now To the point of love ability however, there's still I guess important areas of improvement that we want to get to to make specific aspects of those Categories lovable because although they might be lovable at the aggregate There are specific workflows that are not yet lovable and we have more work to do Yeah, I think it's interesting to to continue iterating on a lovable category We should probably put a little bit of thought into once a category that gets lovable Indicate that that's not when development stops. That's not when we stop improving on it we want to continue just to remain relevant we don't want to let competition catch up and and You know, obviously, there's a lot more things and Paul or so we can add to both of those categories Yeah, and I think love ability is kind of a relative term like are we benchmarking ourselves against? source code management tools or all-in-one package tools or are we comparing ourselves to Best-in-class point solutions for code review Thinking about Those kinds of comparisons and also the the different expectations different kinds of users have we might be lovable for a significant majority of users, but There are other classes of users like scientific research Organizations that have slightly different workflows and even large enterprises that are migrating from non-git source code management tools to get We'll have different expectations and workflows Given the structure and shape of their applications and source code assets We think of them as like quite disposable, but a lot of companies develop these code bases that they build on for decades And it's very hard to change and re-architect a big application To match from modern best practice. So we have to consider different kinds of workflows and have flexible primitives The next category is design management, which we are about to launch So design management Is an exciting new category in 2019 for the create stage of the DevOps life cycle And it's really about Providing a place for designers to live inside of GitLab not not replace all their workflows and all their tools But designers already in GitLab collaborating with engineers collaborating with product managers on issues on merge requests Making sure what's built matches the designs And there's a lot of discussion that happens before anything gets built with regards to designs and we've observed particularly at GitLab But also customers as well That the only real way to do that is either by linking to some external tool like in vision and having mock-ups there and doing the design collaboration in a different tool or The images and mock-ups are uploaded into GitLab in the form of images in comments So people are hurriedly typing out markdown tables to fit all the images in nice little tile grids Manually, but then there's no easy way to actually leave comments and have a discussion and track revisions and we think that We can do better than that. We want something better than that at GitLab ourselves And using Git as the back end for storing those designs Building on the capabilities around image discussions we have in merge requests and bringing those into non-code changes into the planning life cycle and that I guess like iterative delivery process Is going to be really exciting Yeah, I think it's neat because it treats designers as first-class citizens inside the application Whereas if you look at all of the various personas that we could actually serve throughout the entire product in the DevOps life cycle Obviously developers are treated as first-class citizens But there's probably very other very few other personas we can hang our hat on right now and say that you you are a first-class citizen that we've solved a bunch of problems for you on and You know even even PMs I wouldn't say necessarily are treated that way yet. So I'm really excited to see this one It's something I'm really looking forward to and I'm excited to obviously get a bunch of feedback on it too. Yeah I'll I can show specific mock-ups when we dive into that the other categories Wikis so wikis are I think well probably well understood by people who've used github They're a first-class feature of github and they've been a first-class feature of GitLab for quite a long time We think they're pretty complete in their capabilities But they're also something where there's more potential Than where we've taken them and where other products have taken them Particularly around Like there's small features like better table of contents generation Like small quality of life improvements But then there's also the potential in the future to really Reconsider the purpose of the wiki and which kind of stakeholders should be involved in it So it's backed by Git repository, but the interface is very spartan and a little bit obtuse So it's mostly used by technical people for documentation of the things that they're building But there's tremendous opportunity to turn it into a much more useful knowledge-based tool for product managers and large parts of organizations where collaboration happens that is of a different nature to issues and planning and execution And for different different kinds of stakeholders there's probably different needs rather than having a plain text markdown input interface having a rich text whizzy wig editor Live collaboration kind of like a google doc Deep across linking throughout git lab those kind of capabilities would be necessary to really Take this from being a simple wiki to something that's a much more powerful knowledge base for a project For all kinds of people and roles The web idea was an exciting category that was introduced in 2018 last year And we've been iterating on it steadily release after release It's one of those features that at first seemed maybe unusual to introduce, but we've found it incredibly useful at git lab For incidental edits Small things that we find that are wrong in code fixing bugs And that's really what we aim for initially, but more and more it's becoming a tool where People can come to make increasingly complicated edits add documentation Update websites all sorts of things where you maybe don't need to be running heavy unit tests and live previews to be confident in your change And we've been working on this year and late last year in improving those capabilities so that you could actually test and verify your work before you commit it and we're hoping to get to a Complete level of maturity quite soon where we have the ability to test and preview changes before committing them Snippets is the is another area of create They're a way of sharing code with their colleagues and friends You can create them in your personal name space. You can create them inside of a project They're quite basic. They don't have versioning. They don't have multiple file support And there's there's really big opportunity for us to Make snippets more like what people expect most people expect snippets to be A little bit more similar to lightweight git repositories Which would be similar to how Github has implemented gists and I think some of our other competitors might have approached this problem Our snippets are more akin to I guess a local snippet manager. You might have in your IDE And so I think there's there's an exciting opportunity for us to Choose maybe a more Interesting direction for them and deeply integrating them into git lab in all sorts of interesting ways um Finally well not finally next up we have There's so many categories Next up we have search which is a very important category where a lot of work is happening at the moment Specifically with regards to elastic search and enabling support on git lab.com elastic search is a really great feature That's available for self-hosted customers But it's not enabled on git lab.com currently. We're beginning to enable it for some groups And incrementally beginning to roll it out But there's a lot of challenges associated with rolling out elastic search for such enormous amounts of data Git lab.com has over 300 terabytes of repository that would need to be indexed for source code search Not to mention terabytes of data in the database as well Which would also need to be indexed for search so There's significant challenges in scaling elastic search to that level As well as the actual process of indexing all that data To make it available for elastic search So we're starting small and incrementally working through those challenges And how we'll bring that to all our customers on git lab.com and make it easier for our Large on premises customers to deploy it because they're also facing struggles using it Yeah, and just one comment on on search Which used to live in the planned stage of the doc's life cycle and was recently moved to create as the primary use case for search At least for most of our users and for most of the git lab team members is is really for code search But of course, there's also other very important elements for searching inside the application Such as through issues and epics and so on and so forth that we'll get improved once this You know kind of comes to fruition Yeah, particularly being able to search across multiple groups and projects and globally dive into things. Um, that's really important for Working effectively in a big organization in your own private instance And it's also very valuable For git lab.com where we hope to have more and more open source projects. We've already got a lot But being able to search and see how other people are using libraries Looking for common problems. It's a very key source of knowledge So really important that we get that right Live coding is something that we're looking at for later in the year. It's a category that we've planned for 2019 fy20 Should probably be using financial years But we're planning for later this year To make it possible to do pair programming the web ID Um could be really interesting for shared note taking as well. So we're looking at different use cases that might not be deep pair programming So it's it's quite interesting and there's also opportunities for hopefully building a shared Foundation where we can use Like that live collaboration feature maybe in wikis and issues For working together more effectively in a synchronous fashion So hopefully we'll be able to build something really useful And then getter is a an open source instant messaging tool that we bought a few years ago And we've been working on I guess fixing some important issues. There's been feedback particularly around threaded messaging emoji reaction There's an active community that does use getter and enjoys it quite a lot And it's important that we continue to maintain support there and retain those customers And we're also working to improve the native integration between getter and get lab Um, particularly by making it easy to create a getter channel for your project Out of the box on get lab and then inside of getter adding deeper integration for Unfilling links to projects and issues and things like that And then finally getterly which is really very closely linked to all the The git parts of source code management and code review Getterly is how we scale git and it's also the team that Is really in the weeds on shaping git itself as well. So we've got Work planned on supporting larger and larger repositories Really pushing the limits of what gets capable of And that includes for enormous monolithic repositories and also projects that are large because of the binary objects They include so the git elite team is really important in making sure git is stable fast and reliable and Providing a stable foundation for people to migrate from tools like perforce say to get lab And they typically have enormous depots Because the structure of perforce is quite different. It makes it easy to accumulate an enormous single repository So we need to have the foundation to support those customers migrating. So that's a Not a super quick but a reasonable overview of all the categories of create Yeah, I think that that's very helpful. I think to probably a lot of people that will be watching us I think it would be really helpful to dive into You know, if possible A vision that that may not necessarily be Defined in terms of what the next, you know tactical steps are but but at least from a year or two out What each of these we desire for them to be Which you've you've gone into a little bit, but then also like diving down into what are we doing What's the next thing we're doing in each one of these categories to keep going? So I think that would be That would be helpful. Well, I'll start from the top and work our way down. So source code management Really a lot of our vision is related to Long term looking at larger and larger repositories and this is tightly coupled with the the git elite roadmap Making sure monolithic repositories work well in the order of 100 gigabytes or larger Eliminating the need for LFS. Those are some really big goals Particularly looking at some of the the key customer success issues related to that Once you start having these larger and larger projects that get split across Multiple projects say multiple repositories and there's coordination problems because although they might be Different repositories, they're generally not well decoupled And so we're looking at that for later this year But there's a I think there's a long roadmap ahead of the first iteration in really supporting These large organizations that have probably partially migrated to git but are still in the process of migrating their most complex and difficult projects be they hardware manufacturers silicon designers or Just long-term vets and runs of the software industry that have enormous complex products that are critical Being able to support those I guess in the shorter term There's some important work that we need to do in terms of forking workflows confidential merge requests for resolving security issues I think those are pretty exciting improvements. We're making a start on resolving confidential issues using private forks in the next release 12.1 or The next release we're about to start developing 12.0 is probably the next release that our viewers will see a release post about And then forking improvements There's some significant gaps between the capabilities of using a native branching model inside a shared project versus using a forking workflow And we need to close those gaps resolve some permissions related issues and that'll dovetail nicely with our work on using private forks to resolve confidential issues And we've got a work that is about to be released in 12.0 for de-duplicated forks and that's going to enable fast forking So teams that use the far use forking will be able to fork projects instantly And system administrators won't have to worry about huge amounts of disk space being gobbled up by duplicated data So that's sort of short term long term where we're going on the source code management front Yeah, I'm really excited for the the kind of de-duplication of forking objects That's a it's a very common workflow in a lot of organizations and so those working improvements should Help drive adoption of some of the git bits of git lab Yeah on code review We've been doing a lot of research recently into the challenges and workflow problems associated with Complicated code review the fact that code view isn't always simple and clean multiple cycles multiple reviewers multiple approvers Managing that process and making it efficient and effective We recently released multiple assignees and we have improvements coming to Improve I guess the way unresolved comments can be navigated But most importantly one of the things we're looking at improving is efficiency By making the merge request diffs more accurate And calculating good merge request diffs is quite challenging because Git natively calculates diffs by looking at the merge base which can often be Quite a few days or weeks old depending on how long live the feature branches And so the contents of the diff may not reflect what Realistically is actually merged and so we're working on improving the accuracy of those diffs Um to improve the efficiency of that review process and we're also looking at improving the efficiency of the review process through improved performance So file by file merge request diffs Is one of the areas we're looking at quite seriously at the moment Trying to reduce the amount of data we load onto the page trying to Increase the focus on the task at hand. There's a lot of data presented everywhere over the merge request page Um And so trimming that down making it focused making it fast making it easy to navigate is critical for making the code review process efficient and then I guess like speaks to longer-term vision, which is really improving the The way the merge request interface handles Very large merge requests. We see it on even Moderately large merge requests every month at git lab work on the release post that there are challenges When you get more than a few hundred lines changed in a single file Or you get 50 commits in a single branch just becomes hard to move around hard to work out what's happening so improving support to support more than a thousand files improving support to Handle very large diffs making rendering fast and also improving The ability to understand what's changed since you've last viewed the merge request So we'd like to be able to track unread diffs files and discussions So that when you come into a merge request, you only have to review what's new And that that was one of the key pieces of feedback that came out of The research into making code review easier and more efficient Unsurprisingly, there's also policy requests and access control related to merge requests. That's a significant thing that we're considering We've did a lot of work over the last six months in improving the capabilities of the approval process with more flexible and capable controls with multiple merge request approval rules and codoners But there's a There's always going to be a long road map ahead to make sure we're supporting the right balance of restrictiveness and permissiveness to Allow teams to be effective. So Um And I guess related to some of these efficiencies for merge requests We're also Exploring and sort of crafting a vision into the future to look at it's more open-ended reviews where Not only are you limited to the Commits that are actually in the feature branch, but considering unchanged files considering Commits that have already merged Um Good code review doesn't mean just focusing on the diff at hand And so we want to make it much more open-ended Really support deep thoughtful code reviews because it's much better to catch problems before they enter the code base then after A big problem's been deployed into a production environment. So I think just really focusing in on these detail and efficiency related challenges on code reviews division Yeah, I think I think coder view is really interesting Based on what you just mentioned This review of a regular review of code for things that might not necessarily have a diff And then like the interplay between code analytics, which lives in the managed stage of the DevOps life cycle and our our users Getting alerts or getting notifications really setting the data at their fingertips to understand where in the code base Um, do I potentially have a problem not in terms of the functionality of the code but in terms of When that code was last touched or is there still anyone in our organization that even understand how that piece of code works? And so dovetailing that data into a coder view process that Might not necessarily have a diff or someone might not even be working on I think is One of those vision items that I'm really excited to bring to life within the within the application Yeah, and I think there's there's also I guess once we work through these more basic foundational Like elements of really Making it deeply lovable There's there's more I think there's an opportunity for us to really accelerate best practices You can be around The git commits being valuable. I think the value of High quality commits high quality commit messages and creating a useful git history is often undervalued partly because It's not the easiest thing to achieve tools could be improved significantly to make achieving like always every single commit in a merge request be green and Every single commit message have value and meaning so when you're digging through the code base using local tooling or In some other tool outside of git lab that you can make sense of what you're looking at and Code often ends up in other places like even if the git lab is the source of truth like Your code might end up mirrored into some other project. Which is hosted somewhere else and relying on links to merge requests that are potentially Confidential or hidden away somewhere else Can mean that people are at a real loss to understand the purpose of certain changes So having that best practice thinking Is really really important So I did mention i'd show you some screenshots of design management We're still focused on the first iteration of design management So it's probably a little early to speak about where we're going to take this Once we get this out the door and iterate because we know there's going to be a lot of feedback it's going to be I know quite a few iterations till we make this This first mvc really great But the starting point is pretty tremendous We're aiming for version designs with point of interest discussions backed by git repository. So that's a pretty good starting point If I can find the designs here The idea being you'll be able to In an issue Something like this there'll be a new tab down here called designs And in there you'll be able to upload a variety of screenshots Upload new versions of them keep track of them and discuss them And the way you'll discuss them is with point of interest comments So you'll actually be able to leave comments on specific issues On the thing so maybe the the title is the wrong text size or You think the copy is not representative the copy that's going to be there or you want to provide some sort of other meta feedback it can It's a lot more flexible than just having a grid of 10 images and having to be like on the third image In this little part here This thing is wrong or have you considered x being able to click on something and leave direct feedback is tremendously valuable Having previously used in vision. It was By far and away one of the best features of all the features they had that was the one the whole team embraced so Looking beyond this first iteration the polish around this this workflow. I think opening up git access providing more automation so Designers can work locally on their different design files and simply push and then all of a sudden the mock-ups get updated those kind of workflows Yeah, they're not that far away Because we've chosen to use a git repository upfront There's all sorts of opportunities for using Pre-commit hooks to do interesting things. There's a possibility of using ci in the future on the git repository even Ci for design to automatically maybe validate usability guidelines looking for contrast problems There's all sorts of opportunities to take this really far Just in this specific area without even getting to design reviews and design systems and trying to capture them So there's um lots of potential but we'll need to listen to customers and hear where they want to go After we get this first iteration working well On the wiki's front In the short term the vision is really just to improve some of the basics We've done some really wonderful jobs making issues easy to edit and there's a consistent editing interface Throughout git lab for all sorts of things But the wiki's have kind of missed out and fallen behind and are a little inconsistent and hard to use So I think it would make a big difference for a lot of regular users just to make it a little bit more consistent a little bit more polished Um and similarly navigation is like the biggest problem most customers face with wiki's as the wiki growers generating navigational Hankers automatically so they don't have to do that manually We'll go a long way Looking longer as I mentioned thinking about confluence google docs notion a whole range of tools that are build up knowledge bases in different ways I think there's a lot of research we need to do into Understanding how we would even approach solving those problems their huge industries and markets of their own That are different in important ways from the wiki's we have today so There's a lot of work to be done to unpick that and work out if that's the right direction But it's something we're exploring James i'm curious to your thoughts on replacing our handbook with a git lab wiki Oh, that's interesting. Um I think it's It's challenging the restrictive format of wiki's in some respects like Having a fully rendered website provides a lot of flexibility for custom content and generation and scripts um It'd be interesting to consider What it would take to do that? Um I mean the the obvious advantage is that the connection between editing and Seeing it is instantaneous. We don't have to edit some source code and then wait for it to be deployed um, I think the challenge is Link validation making sure that things don't break thinking about review process. Um There's an interesting proposal from a little while back that I think sit actually opened a few years ago to potentially make wiki's A sub directory of the main repository and so then you get merge requests for free So if you want a wiki, you just have a slash wiki directory. That's quite interesting. Um, there's a lot of implications in terms of having non-technical users potentially polluting your commit history of your primary repository, which is a little concerning. Um as someone who's Very big on commit hygiene That freaks me out. But um, the idea of having all the power of ci merge requests Ready to roll is pretty great. Um And you could even use code owners to enforce like particular approvals on specific things Like most of the wiki doesn't need any approval to merge but maybe specific areas do Rather than rebuilding all those features into a wiki Maybe just make the wiki a repo Um, there's other ways of maybe taking that approach without making it a sub directory, but that's an interesting approach. I think The other thing that Is striking to me on this page is the competitive landscape section. So You know the the confluence I think that makes sense If I think if you were to go survey a hundred people off the street and say, you know, what's the leading wiki product You'd say it was confluence And so it's interesting that that's under the we should be competing with because I think I think that is like the quintessential wiki product But things like notion in in google docs You could almost make an argument that wikis might not be those things maybe issue descriptions become google docs Maybe snippets becomes like our competition at google docs or or even like the web ide opening a blank file That uh, you can choose what to do with after you're done with it.  You have to have to give it a name That would be an interesting approach as well. And I know that I when I I tweeted out last week Or someone tweeted at kitlab and said how much they love the web ide and I retweeted it and asked them like well What would love to know what else we could do to make it make you love it more and of course like dark mode came up So we should just talk about dark mode, but um, but then our old vp of product yobuh Commented and said well, I'd love the ability to Kind of create a blank file. I'm not sure what exactly i'm going to do with yet And i'm not certain if the web ide is the right place for that or if wiki is the right place or snippets Um Anyway, but it's interesting to think about we've we've got a number of small parameters where I think that makes sense But finding the right kind of user flow and user journey through that process I'm not sure if we've nailed it yet Yeah, and the we the wiki primitive primitive is kind of interesting in that we have kitlab pages And we have the ability to deploy static sites really easily so The difference between wikis and those kind of things is really like technically it's They're quite similar under the hood. They're they're a repository and there's some script that generates the page on demand Well, I guess in the case of pages that generates all the static pages Whereas wikis it just sort of generates them as needed and that Means you just edit it in real time And there's some convenience methods for like I guess an opinionated way of using it so I do wonder if if wikis is even Then Needs to be its own primitive or whether the problems that it Solves a better rolled into something else and we provide like a really good pattern for using projects to achieve What confluence does or something like that? Yeah Yeah, but more to more to investigate there Yeah, and it's a really important tool for a lot of customers the wikis that we have today So it's although I don't think we extensively use it internally at GitLab I know the Gitter team makes pretty heavy use of it but There are the companies that do use it rely on it a lot in their daily jobs And it's it's such a wonderful side effect that you get this version controlled history in plain text That is completely portable and transferable I think the knowledge base is a really Interesting and strong use case for something like a wiki because it you know my back to my first question I'm like Could the handbook be made into a wiki? Well, what is the handbook? It's basically a knowledge base Not in q&a format, but in terms of how we work and our history and whatnot And that seems like a good use case or something like a wiki where you You might not want it to change as easily as a google doc, but you You want it to change faster than say? You know an actual code repository Yeah, it's an interesting thought. I wonder if we should just make forking faster and easier because If you put in a wiki, it's very like it's not inclusive of people who are outside of the project because The wiki is then limited to the people who are part of the project There's no way for them to open a merge request and propose things and we have community members and other people who open merge request to fix typos or Ask questions because we want that to be possible And I imagine for open source projects, you don't want to have the maintainers be the pure Authors of this faq. It'd be great for other people to be able to contribute content Interesting challenges. Yeah. Yeah, sorry. Sorry. We should probably move on. We only have a few minutes left Yes on the web ID so Um Web ID has evolved a lot since we launched it. Um, we added client side evaluation so you can preview JavaScript projects in the web ID and edit them in real time. That's powered by code sandbox We collaborated a lot with ive to make that happen The founder of code sandbox So that was a lot of fun and we've also been working on server side evaluation. That's been quite a challenging project Involving quite a few components and it's where more work will need to come over the following releases once we release the Even the first iteration it's going to be Pretty limited pretty basic But essentially the the short term vision is really making it possible to Got to find the screenshot live preview making it possible to Open a project in the web ID Make an edit run the tests See a live preview and then commit it. So this is a screenshot of client side evaluation But server side evaluation will look pretty much exactly the same. You'll have Your code that you're editing you'll have a live preview And there'll be a web terminal as well. Um, which is not shown in a screenshot and in the web terminal you'll have Your server running whether that's a rails development server or a javascript server with web pack or something like that You'll have that running and then you'll have the preview. You could run tests and run npm test or rspec and actually test everything's working Test it in the browser before you commit. So essentially Replicating the local development environment experience It's pretty rare for engineers to build features and never run Some kind of tests locally before they commit them. I mean maybe they do and just wait for ci to fail but it's nice to be able to Test things manually before you commit them. Um, yeah We can take up to 10 or 15 or 20 minutes sometimes for a pipeline to fail. So it's exactly Yeah, and not having to wait for a whole review app to spin up like gitlab Is great because we have review apps and so you push something and if it's configured You can see a real working version of your application But being able to see it and edit things live and see them change in the browser in real time That's huge. I mean a lot of developers spend a lot of time getting all the tooling set up locally So they've got the browser taking half the window and then as they type they literally see the react or view js components changing in real time in the browser or They change some service like code and recompiles and then the page reloads and you can actually see changes happening in real time That really accelerates the development process and we want to make sure that that kind of workflow is possible in the web IDE I think um looking longer into the future There's there's real opportunity to take the web IDE even further than where it is with more rich capabilities similar to a local development environment Since we started working on the web IDE tools like repel Replet Eclipse Shea Thea there's a whole range of tools that are Quite mature and they've evolved sort of at about the same time that GitLab has each with their own focus and so I think Particularly looking at some of those other open source projects. We might need to consider like Do we take some of those and switch out monaco for a more feature complete open source library to build on? Or do we take our own path? There's there's a lot of questions I guess around How robust and how much of a replacement we want this to be for local development? Do we want the web IDE to become? Sufficient that a large Very conservative organization could say no one's ever allowed to check out code again. You all have to use the web IDE That's a very specific workflow for a very specific kind of customer That we need to consider for the future. Um, and we haven't really decided if that's the case Or there's the other the other kinds of workflows where it would also need to be pretty robust and much more feature complete than it is today Say working on mainframe code There's very few people that are going to want to set up that development environment locally for very specific environments Or occasional contributors to project Companies that practice in a sourcing where they want everyone in the organization to be able to contribute to their different libraries And tools that they're building internally It's important that people can contribute with low barriers to entry having to install all these dev dependencies locally Just to add a couple of lines of code is a big barrier the web IDE solves that To an extent today, it'll be better in a few releases but To really get to where we're imagining Is is a little bit more work. Um, and so We'll probably need to be pushing towards that and then work out what the view is beyond there I think I think that's a really interesting use case and when you think about Commodity hardware being introduced in a lot of organizations a lot of organizations are moving to chromebooks Yeah, and things like this where you know, even for like windows organizations You know, obviously they're embracing the terminal a little bit more than they were just a year ago or even six months ago But those laptops pc's desktops are You know about a third of the cost of an entire organization grabbing a macbook So I think like there's actually this this interesting shift in a lot of organizations that are moving to commoditize hardware The web IDE is a way to standardize all of that and say I don't care what you what you get as long as it's performing enough to like You know has enough memory to run chrome or firefox or whatever You could get into the situation where the web IDE makes a lot of sense to standardize for a dev team Now I think in the current situation And the current, you know experience from the web IDE it is one of my favorite features in the Inification, but I think as a developer I would be pretty Unhappy if if I was forced to essentially use it for all aspects of my day yeah It's a hard problem to solve as a A heavy vim user myself In the background of the screen share is a giant terminal. You can't say it on your screen Like I take all my notes in vim because that's the editor I like So it's they're very personal and also I guess this whole industry is a graveyard of failed companies There are a lot of companies that have tried to do this in the past. It's very difficult to build A high quality editor that works well in the browser The browser is really not designed for this kind of application. Um, so it's it's quite difficult to do it Well, um, and then there's there's all the the server side problems of actually providing quickly reliably A good development environment that has all the tools quickly configured When developers run into a problem on their local machine Many of them are well equipped to fix it and resolve it or have a colleague that can help them If something goes wrong in a cloud based environment All of a sudden you're sort of You're pretty stuck and only the system administrators can probably resolve that So there's there's different risks and challenges associated with it, but it's it's no doubt something that There's there is an ongoing interest from certain kinds of organizations in There wouldn't have been so many companies started in the past trying to solve this problem And there wouldn't be such ongoing sort of feedback about this kind of feature if it wasn't important Drop them down into snippets Yeah, as I mentioned, we've we've got a pretty minimal approach to snippets. Um at the moment and I think the There's there's an obvious path to take in terms of adding version control and multiple file support by making the repositories So I'm pretty sure that's that's the next step that we'll take. Um In terms of making them more useful, but I think the Beyond that, um I think we could do something a lot more interesting than just leaving them as a dumping ground for like random files and code fragments. Um, gilab's got a lot of interesting components built right into it. Um with the web ID ci runners And thinking about some of the capabilities of the web ID What if we could use snippets as a way of bringing like interactive functional code snippets into discussions like In a merge request so being able to run a function in some container and actually test it. Um And building those kind of deeper integrations. Maybe maybe we don't need snippets to do that but Certainly snippets are a place where code fragments are stored and if there are An executable unit where we can do interesting things with maybe There's some interesting applications for integrating them into other parts of gilab Imagining issues where you could have a code pen style situation attached to it where rather than linking to a code pen You just link to a snippet and you have an embedded Embedded working version of your reactor view js component And you can experiment with it and it's linked to your component library So in gilab's case it's linked to pajamas and it's pulling in that and you're interacting with it and then Everyone can sort of see what the mock-up looks like and then it's just someone's job to implement it and write the tests Um, those kind of things that'd be really interesting And much more useful than just a flat text area that said It would be super awesome if I could just push and pull to a snippet So I look forward to that You're on mute I think Yep, I was gonna say I would if I could just do that I would probably use it from a from a day-to-day perspective as of right now. I Rarely interact with snippets yeah Now there's been some interest interesting tools built by other people in the past for other Git based snippets For like hosting all sorts of interesting things using them for unusual purposes It'd be great to see that kind of innovation and like connectivity to gilab snippets as well Um, so I mentioned search In quite a bit of detail So I don't want to go into it too much more. Um in the short term we're working on elastic search for gitlab.com That's a really big project The eta for 11.11 is for the mvc Which was getting it working inside of one group on gitlab.com This vision needs to be updated to reflect that there is a long pathway to getting this enabled for every single project on gitlab.com Um, so we're working on that with a high degree of focus and uh That's that's probably like the main focus for the next Six months or so. Um, yeah, it's a it's a huge technical challenge. Um Working out how we split the elastic search index down. Do we have one elastic search server per group? That works well for large groups But then there's also lots and lots of small groups with only like one tiny project in them So we need some way of sharding and balancing projects between different elastic search nodes Similar to how we have this for giddily. So giddily can shard data across Many nodes to balance the cpu and storage requirements. Um elastic search has similar requirements. Um, so Building all the management tooling around that testing it hardening it getting it to production quality. Um Is is non-trivial. Um, so we'll be working on that for a while to come. Um, but making search work well is critical um Live coding not much to update you there. It's coming um There's we have interesting ideas Well, there are some interesting epics that um, we've created one idea for sort of starting on it rather than doing Simultaneous live editing is maybe broadcasting. So broadcasting the edits from one place to another so you can observe someone else's terminal Web ID session That that might be one way of getting started without having to build all of the things in the first iteration. Um, but there's probably other ways of approaching this. Um One of the particular challenges i've discussed at some length with dower one of our um engineering managers in the create team he He's been working on a new markdown editor with like whizzy wig markdown editing capabilities for issues and merge requests and one of the challenges we've discussed specifically is Whether you're live editing plain text in the case of the web ID you would be live editing plain text But if we wanted the same engine behind live editing markdown rich text fields If they're whizzy wig then you may not use the same data transfer structure behind the scenes um because you're probably not going to be Converting rendered html back to markdown Then transmitted the markdown and re-rendering it and that kind of loop would be error prone. So most of the The live editing markdown interfaces or rich markup actually transmits some intermediate representation Which is more closely representative of the formatted output Um, so there's probably a lot of investigation to work out how to build something that isn't single purpose. Um, I think That will make building an mvc hard if we have a vision to solve both problems simultaneously There's there's probably a couple of video recordings and in discussing the the technicalities this problem that i'm not equipped to discuss but Um, there's a lot of exploration to be done here um Yes, get a um Briefly threaded conversations community rooms. I mentioned those before um, yeah it's The team's been quite small. Um, it's starting to grow. Um, and so we'll be starting to build out the roadmap to factor in the the growing team and uh, yeah, really bring more of git lab into gitter so that um Teams that use both um have a really wonderful experience out of the box really easily. Um, and uh The other big feature that's uh, sort of further down the pipeline is emoji reaction. So just bring that fun into uh Into gitter because it is such a well-loved feature in so many other chat tools Um, that's a good one. Yep And i'll try not to dwell too long on giddily. Um Not because I don't want to but because I would to easily spend a lot of time discussing it. Um One of the the most important and biggest pieces of work that giddily is working on at the moment is high availability Um High availability of git repositories is really difficult. Um At the moment, most of our customers are using nfs to provide redundancy and availability Um of the the storage layer But that is problematic for a performance perspective because nfs adds a lot of latency to the io operations and git expects Like very fast io. Um, it's designed to be run on local storage Either a spinning disc or an ssd and The difference between running git on an ssd versus a spinning disc is very noticeable You get much better performance. So adding 100 milliseconds onto that by making network calls to a A network file system is very detrimental to giddily performance. Um, not shown here is work that we've done over the last few months to mitigate some of those problems for nfs users But the ultimate solution is to provide them with an ha architecture that does not involve nfs so we're currently working on the beta of naive replication. So we're hoping for um eventual consistency with a relatively fast replication delay So Submit it hopefully tens of seconds. Um, but we need to actually put that under production load and see how our approach performs And then once we have that in place and working to a sufficient level of performance We'll then move towards automatic failover. Um, which is probably the next hardest problem and detecting when a repository is unreachable and coordinating the failover from one giddily node to another And failover can be done on a an entire server level or on a repository level. So if a repository for some reason becomes corrupt and unresponsive and We can fail over just that repository. And so that's one way we're going to be able to test this in production Without having to shut down whole shards in a production farm. We'll be able to simulate failures and see how it responds in realistic environments From there, we've got monitoring tools administration All sorts of other things and so we're hoping for the end of the year for that In parallel to that, we are working on native large file support and support for very large repositories And we're doing work in the git project itself to enable those capabilities so just Last week there was a change merged to fix a security issue for filtered clones, which is this sort of one of the key components of partial clones Which is their git approach to native large files and native enormous repositories because you filter or Filter out the stuff that you don't want and you partially clone it so working on that on the git front and then also working on the performance implications of that on the giddily server so Working out which things to send and which things not to send for very large repositories is a very cpu intensive process so doing that on the fly doesn't really scale so That's the challenge that we're looking at along with faster clone performance for all repositories So that's sort of a secondary priority behind uh ha. So big things coming in giddily this year Yeah, absolutely. That's uh, that's fantastic Yeah, that's the end that is the product vision for create. Um, I don't think I can say in a nutshell because that was 40 minutes or so I would say we far surpassed the nutshell You know, yeah, but um, no, that was that was really helpful. Um, you know, thanks for walking through that and for that labor of love No worries. Yeah, it's uh, it's exciting to to see what Create is going to do this year. I think there's Like the balance of taking a few things that we already do pretty well and then just making them ultra lovable Um, it is really neat when contrasted with these things that literally don't exist or they exist as an idea And and taking those and capturing a new market such as design management and some of the live coding stories as well, so Really really exciting stuff Yeah, I think it's a really exciting challenge taking things that are so well used and well understood like code review and finding the things that are really valuable to improve There's always going to be new features that are proposed but understanding like When to iterate and refine versus taking that next big step to really make it that much better Um One one vision item I neglected to mention on source code management and code review because it sort of sits between the two is distributed merge requests It's sort of a little way out in our vision. And um, I'm a little worried that it might slip Out of the at the end of this year as we focus on some of these really important quality of life improvements for code review and source code management But it's distributed merge requests. So being able to Open a merge request from one git lab server to another or even eventually from git lab to git hub Because there are open source projects that live everywhere that are forks of each other Private servers that have forks of open source projects that are hosted on github And if a bug gets fixed locally in a company's private instance, they need a way to get it up and I think there's opportunities like that throughout git lab where things that seem mature well settled well understood we can begin taking those next steps to sort of really raise the bar so that I don't know like we're already lovable But like what does it what's the next version of love all going to look like and can we raise the bar so that? Everyone else has to lift the bar as well. Um, those are really exciting opportunities absolutely Well james, thanks so much for this. Um, it was great to to be a part of it and Excited to get this on the site so that people can have a voiceover of the vision Yeah You too. Have a good afternoon. Okay. Bye. Bye