GitHub GitHub Universe 2020: Developer - DevOps, 10 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How we make VS Code in the open - GitHub Universe 2020

Description

Presented by
Alex Ross, Software Engineer, Microsoft
Benjamin Pasero, Software Engineer, Microsoft

VS Code was launched over five years ago and has become the top-most contributed-to project on GitHub. While developing in the open, our team has learned how to balance community engagement with delivering value and shipping code. In this talk, we'll share engineering best practices our team has adopted on GitHub to collaborate with our users, get feedback, and iterate quickly.

For more from GitHub Universe 2020, visit https://githubuniverse.com

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

Thank you for that. Intro hi, I'm alex my co-presenter here is ben.

B

Hi everyone thanks for having us.

A

uh And we're both software engineers for vs code joining you from zurich.

A

Today we're going to talk to you about how we build vs code in the open, we'll take you through some of the principles we try to stick to to make vs code a successful, open source project and during github universe you can join our discord and you might get some some vs code stickers at aka dot. Ms slash, open source dash discord, we're also going to have an ama on vs code at microsoft reactor if you want to learn more after this session.

A

First, let me introduce you to how the team is set up. We have two physical sites, one in zurich and the other in redmond washington at microsoft's main location.

A

We also have several remote members in the us and, of course, even our physical sites now are more distributed. There are 25 engineers, six pms, two dock writers, one designer one person in marketing, one ux researcher.

A

All of these team members are spread across the vs code associated projects, which include vs code. Our components like the monaco editor our collaborations with electron and xterm.js, and many extensions with that team vs code has been one of the top projects on github by number of contributors since 2016..

A

Because of this, we tend to get a lot of love on twitter, like this very kind. Tweet at code has to be the highest quality, open source project. I've ever seen, whoever does their change and community management deserves a raise.

A

This really is a very nice compliment to the whole team, because it is the entire team that contributes to change logs and community management.

A

This snapshot of our issues, page in our repo, was taken in mid-november, and you can see how engaged folks are with the project.

A

The outlines in red are the work that we do incoming issues, discussions and issues, but in the green you can see that we also get a lot of love lots of people watching starring and forking our repo.

A

In addition to being active on github, we have a getter for accessibility discussion, which our team actively participates in and of course, one way the community gets involved is by creating extensions. For extension, authors, we have a monthly extension author call where they can have a voice too.

A

The team's work doesn't only happen in the vs code. Repository though all of these other repos are run by us and contribute to vs code included. Here are the debug extensions, the monaco editor, the language server protocol, debug adapter protocol, documentation, samples and much more to keep all of these projects running smoothly. We try to follow these open source principles, zero distance, automate, almost everything, monthly, get feedback early and share recurring duties.

A

Now I will hand it over to ben to talk about the first of our principles.

B

Thank you alex so zero distance is the first principle. I want to talk a little bit more in detail about, and what this is really about is that we are trying to engage with our users firsthand we as a development team. So when you are engaging with us us on github issues, for example, you will talk to developers directly, there's no level one support involved.

B

So for that we keep. For example, uh our roadmap in the duration plans and end games plans all public in the guitar issue, tracker, so you're free to see it. There engage even ask questions and we're happy to to comment on them. Besides that we try to be very active on our social channels.

B

We maintain a fairly popular twitter account at code, but also stakeoverflow or hacker news reddit, and even on the chat rooms we maintain um whenever there's a new release. We try to uh watch for feedback and and engage there as well directly. If we see that there are any issues with a new release, but our main source of feedback is github issues uh where I think we count two to three thousand issues per month, which is quite a bit and in this.

A

Talk, we will universal manage these.

B

Issues, so you might find some advice here how to do that. We have a inbox tracker, which is a role that we will explain a little bit later to manage these these issues and as well as some bots uh as you can imagine, we get lots of customer emotions. um I mean, like I'm.

A

Watching universe from popular.

B

Issues and some of the feature requests that we implemented over the years are a result of these upvotes, um for example, tabs multi-root, folders or even customizable. Icons are all coming from there because we didn't have them in the beginning.

B

A

B

Lots of pull requests, so that's another task. We do daily. We look at the incoming pro requests and try to merge them in a timely manner, and you might have already seen that we call out on these pull requests in our thank you section, and I want to emphasize that you can actually have a wiki page on our github repository how to contribute to vs code, and that clearly explains you. How easy it is to do these pull requests. So I encourage you to do that.

B

Let's look into the flow for a feature request how that can actually go uh when you file one. So first thing that will happen is that we receive a feature request, and this is probably most of the issues that we receive and the first task is to assign a someone from the development development team to the um to the issue.

B

This can either be the inbox tracker or the bot based on some machine learning and the content we actually know which developer is most likely to be the assignee and then the first task of the owner is to assign a feature area label, and that is really a way to categorize these issues and later find them easier.

B

And then there is a decision to be made if the issue should move to the backlog or to backlog candidates, and that is an iteration that we are maintaining on github, where we say everything that is on backlog is something that we do accept and eventually commit to. It doesn't really say when we're doing it, but it's a good sign that we're interested in implementing the feature.

B

But if the uh developer moves it to backlog candy, that's then it's a sign that we are not yet sure. If we want to do it, we are waiting for more feedback. And specifically, we want some upvotes here to get community interest in the feature and when we have these 20 upvotes, we accept the issue automatically. The bot moves it to the backlog. But after 60 days the bot will actually close the issue and this whole flow is meant to really filter out.

B

Those feature requests that um really there is lots of interest in and that we should do from the ones which maybe have less interest. So if you are wanting to have a feature in vs code, I recommend you to look at these upvotes and add your vote as well.

B

So in the next slide, I want to quickly look into a special iteration that we are doing every year because we have been doing it just now. It's our housekeeping iteration and the idea here is that once per year we are really trying to get our issue number down by focusing on this for one month and typically our magical number for starting.

B

This is if we have above 5000 issues- and you can see here- we just did that in october and november, we are getting down from 5 000 to around 4 000 issues, and we do that by looking for obsolete issues. Some of them are fixed.

B

Some of them will be marked as obsolete or out of scope, so really trying aggressively to work on them, and one result of this is that, um for example, in this december iteration that we're about to ship, you will see many feature requests fixed that maybe are a bit older, simply because we had time to look at it, and this chart here is done by benjamin lennon shouting out here to his his website, he's not part of the team, but actually a community member.

B

That is was willing to do this website, where you basically can see an overview of our issues each day. So I know last time we did this. I think the website was breaking down from the traffic. I really hope that today, that's not the case, um so give it back to you alex.

A

Thank you ben. Our second principle is to automate as much as we possibly can and use tools wherever possible to keep manual processes low. We have a ci pipeline that runs regularly, so we can catch build and test failures as they happen and on the right. You can see our pull request, ci checks, which help us focus only on prs that we could accept.

A

We do use eslint rules to enforce our code layering structure, so you can't push code that creates a dependency that is while we don't have a unified code style, we do still use custom hygiene checks and git commit hooks to maintain a standard across the code base.

A

Our unit tests can be run against vs code and browser-based vs code, and it runs in the browser using playwright when we're ready to ship. We have a set of automated smoke tests, which replaced original manual smoke tests, and they are just a good sanity check for us.

A

At the top of this page, you can see the header for our internal tools. We use these internal tools to help our monthly help run our monthly end game. These tools, assign and load balance testing so that tests are evenly distributed and no one feels like they're stuck doing a majority of the testing.

A

These tools also help us make sure we don't miss any community members who contribute a pull request when we write the acknowledgement section of our release. Notes below that is our internal builds page. Here we can view, builds for different diff for different qualities. This one is showing it also view builds for stable and for our exploration you can download builds from here. That's what all those icons are, and you can see there are some missing some icons missing in various rows.

A

The build didn't finish there, for whatever reason we can filter by commit filter by release and then on the right. There are those check boxes for releasing a build and for freezing a build. So if we put out a build that has a problem significant enough that we don't want further people to be able to download it, we'll freeze it since issues go directly to us part of reducing manual process is giving users the tools to report more meaningful issues.

A

To help with this, we have a built-in issue reporter envious code that collects some essential info. If we need further information, she asked users to use our cli, which provides troubleshooting options or provide logging or look at the dev tools.

A

We often get issues that can be traced back to specific extensions and aren't caused by vs code itself to assist with finding these extensions. We have a new feature in extension, bisect which works like get bisect and we'll disable extensions in a binary search to help. You find the source of an issue.

A

One part of our automation that you may have had personal experience with on github is our triage bot. Our triage bot uses machine learning to determine who an issue should be assigned to based on which feature area. The issue is about.

A

The bot will suggest duplicate issues and uses github actions to respond to key label changes and comment contents.

A

One example of this is the needs more info flow, which is shown here when we get an issue that isn't actionable in its current state because of missing information like maybe the build number, we can add the needs more info label.

A

This will trigger the bot to add a comment that asks for basic info and if further information isn't provided, then the bot will close the issue for us after 10 days, one of the most hands-off actions that our issues bot does is respond to incoming issues that aren't in english since you're talking directly to us. When you create an issue, and since english is the primary language of the team, we require issues to be in english before we start working on them.

A

When an issue comes in that isn't in english, the bot will respond in the original language and ask for translation at that point. A community member might jump in and provide the translation, then I'll hand it back to you for some more principles.

B

B

So our next principle is involve the community and what we mean by that is that we are really trying to get some of our community members that are very active to help out on our issue tracking, and you can see here, john murray, who is one of these top conut community members that has some special rights here to trigger an action with our bot by confirming an issue.

B

So in this case an issue came in and we maybe didn't have time to look into it yet, and he was already confirming it with some steps how to reproduce, and then the bot adds this label, and that is incredibly useful for us to distill these issues because we know they have been confirmed and we don't have to try to reproduce it.

B

Another example in the next slide is something that joe has been started here from our team. It's the author, verify request author verification requested label which triggers quite a bit of activity, as you can see on the issue, and the idea here is that once an issue is closed and was fixed by a developer, we want the author to verify the issue and we actually have a process that says every end game every end of an iteration.

B

We verify every issue we fixed because we believe that's the only way to really know that an issue has been addressed properly and ideally it's someone else verifying that issue, not the one that closed it. But here with this bot, we can actually trigger an action that asks the user to verify the issue once an insider's build is out and an insider's build is a nightly version of vs code.

B

That always includes the changes from the last day, and this bot is actually smart enough to track once the insiders is released and then ask the user to verify it. Following these steps, and in the end, the user can set this verified label and we have the whole end-to-end experience here without a developer having to work on it at all. Back to you, alex.

A

Thank you. Our next principle is to ship monthly, and that involves shipping, predictably, and with high quality. To do this, we operate on four to five week cycles. During the first week of each iteration. We take the time to reduce debt work on tools and plan. The rest of the iteration team members use their discretion to determine to determine which debt should be worked on or what tools made. This is debt week, and it's one of the reasons that the code base is still in such good condition.

A

After nine years of work, the next couple weeks of the iteration are used to execute that was made during the first week, team members usually have ownership over a whole feature area which prevents one person from getting blocked on another's work and allows for a lot of autonomy over future distances, as we complete features, we demo them during our daily team stand up. During this time, we meet weekly as a team to see how the plan is progressing.

A

In the last week of an iteration, we have endgame during endgame, everyone stops working on features and we all focus on getting ready to ship. Once we've shipped, we watch for new issues and make a recovery release during the following iteration. If needed, recovery releases are small patches to fix important new issues. After a release, an issue meets the bar for recovery.

A

If it's regression, if it's breaking a feature or if we know we will get lots of duplicate reports, if we don't fix it quickly, end game involves all the steps we need to do to make sure we're ready to ship. It's run by the endgame champion and endgame buddy during endgame. Everyone writes tests, plans, everyone tests, everyone fixes and everyone writes documentation. And yes, this means that the devs write the docs there's an edit pass from a doc writer, but the docs were written by us.

A

The endgame champion is supported by tools, but the role is still manual, the first step for any and is use the template to create an issue for the end game plan, which you can see our end game plan from october.

A

Here the endgame champion is responsible and for following the plan, many users love our release, notes and we do work hard to make sure they're worth loving.

A

During endgame, we use our weekly teamwide meeting to read through the release, notes and make sure they're comprehensive, useful and full of gifts, and I will hand it back to ben for our last two principles.

B

Yeah here we go so this one is a very important one to me personally always get feedback early on, and what that really means is that we are maintaining an insider's channel. Besides the stable channel that you probably all heard of the insider channel, is nightly updated with around 50 000 users by now, and what this means is that you can try out the changes from the previous day right on the next day and, more importantly, since the vs code development team, all of us we are using insiders.

B

You can be sure that this version is actually good enough to use every day, because otherwise we couldn't work on vs code itself, so to make sure to give that version a try and give us feedback earlier than the stable channel. That is updated only monthly.

B

We also have extension, shipping, insiders versions, for example the pull request, extension or the js debug extension. You can install them and try them out to benefit from from features, and I should also say you can install insiders and stables side by side and, for example, use setting synchronization to sync your extensions and settings over from both and and use them at the same time, which I find actually quite nice, less known is the exploration channel has around 100 users. We don't really advertise this. It's mainly used for electron updates.

B

Electron is the framework we use to to ship cross-platform and since it is a larger component, we try to still get some feedback, but maybe don't push it to insiders, because they are just too many users there.

B

So, let's look at the last principle that we have, which is share requiring duties. We actually already talked about lots of these duties that we have in the team um and we are trying to share these duties uh across the team so that not everyone, not a single person, has to do them all the time.

B

The inbox tracker is a weekly assignment that we round robin between zurich and redmond and, as you already heard, is supported by bots and github actions, and I should say that all the bots we talked about are actually open source, so feel free to look at those repositories and actually use them for yourself, there's a build champion role. That's the same person as the inbox tracker.

B

That's the person that has to make sure that our insider bills are released every day and are fine, and then we have the end game champion. That runs the end game. It's a monthly assignment, and it's quite a job. I would say, because you have to run the end game show for a week, but you are assisted by the end game buddy in the other time zone, and that is typically the uncamped champion of the last iteration to hand it over yeah. So I think we reached the end of the presentation.

B

I would like to shout out our github url microsoft, slash vs code on github to really exercise this for yourself. Look at our issues. Look at our wiki pages. Our roadmap and engage with us.