 Hey, everyone. It's Leslie Richardson, host of Visual Studio Toolbox. So 16.9 of Visual Studio is out, but how do you know exactly what you're getting when you hit that Update button? So join me and the rest of the Visual Studio team on March 9th at 9 AM Pacific Standard Time for a live episode of Visual Studio Toolbox, where we'll be talking about all the brand new features and updates that are available in this Visual Studio 16.9. We're going to be covering a lot of different topics from C++ toolings to dotnet refactorings to XAML and so much more. So you don't want to miss this. So tune in on March 9th at 9 AM on LearnTV, Twitch, and YouTube and find out why you should hit that Update button on the VS installer. Ever gotten so frustrated with Visual Studio that you just want to ask the team to add or improve a particular feature? Well, you can with the new and improved Dev Community site. So find out more joining us with the ever so Dev and their Mads Christensen on this episode of Visual Studio Toolbox. Hey, everyone. Welcome to another episode of Visual Studio Toolbox. I'm your host, Leslie Richardson, and today I'm joined by senior program manager who also happens to be on the customer outreach or customer feedback team, and is also an extensions wizard. This is Mads Christensen. Welcome, Mads. Hey, Leslie. Thanks for having me on. Thank you for coming. I love the pipe, by the way. Oh, yeah. Yeah. Very sure. I like homes. Thank you. That was exactly the logo I was going for. Awesome. Channeling it. Good job. So customer outreach and just customer feedback. If you've been a Dev and Visual Studio for a while, chances are you have used VS and have thought, I really wish VS had X feature or why doesn't this feature do this instead of what it currently does, and I really wish I could tell the team about it and that they would get to work, fix it immediately, and that's what we have the Dev community for, right? So can you tell us about that? Absolutely. So yeah, that's exactly right. And as you were saying, it would be cool if Visual Studio had this feature or that feature, or things were a little bit different, more optimized for my personal workflow. Well, then we would love a feature request from you. And the other side of that is, hey, something doesn't work as I thought it was going to work or that you told me that it was going to work. And so we also would like you to send us a bug report, right? So those are kind of the two types of feedback that we are very closely monitoring coming in from Visual Studio. And here shortly I'll show you how you can do that. But, you know, Leslie, I don't know if you know this, but every update to Visual Studio that we do, we actually have a bunch of fixes and feature requests that are implemented in those updates. And I think the next update that's coming out is 16.9, so Visual Studio 2019 Update 9. It's currently in preview. And, you know, right now I'm looking at the number here. Right now it has 511 pieces of feedback that have like bug reports or features request that have been implemented. Wow. 511, and that's, and it's still in preview, it's not done yet. We average over 600 per update. So it's quite a lot of stuff that we actually make it, that makes it in. So please feel free to send us as many feature requests and bug reports as you feel that you need to. Cool, cool. Yeah. But it wasn't mine though, was it? No, I don't know, some of them, I use it too. Like if I find a bug or something like that, I open a feedback ticket, yeah. Sweet, so like where are these tickets going exactly? Like are they just going down a black hole and then a robot looks at them and just decides to judge before ultimately throwing it away in the end or where's it going? Right, right. I'm sure some people think that's what's happening. No, so what happens is that when a feature request is, or a bug report is being reported, we have this website called developer community. So everything is captured there. And so when a new ticket is opened, it's automatically being funneled into the Visual Studio Teams Azure DevOps bug database. And so we have a team that sits there and monitors the incoming ones and makes sure that it goes to the right team within Visual Studio. Like if someone had an issue with typing, let's say in the editor, well, that's going to be routed directly to the editor team in Visual Studio. And if it's something about C-Sharp or C++ or whatever, it goes to those teams, respectively. So that happens to every single ticket that is opened. It gets straight into the team that is responsible for fixing it or implementing it. And they have, every week they do like a triage. And so when we triage, it means we look at the incoming bugs and requests and figure out what to do with them. And so let's take them one at a time, like feature request, let's say a feature request comes in and it lands on, we figure out, it's the editor in Visual Studio. And so the editor team then looks at it and says, well, that's a good idea. So we're going to put it, what's called under review. So under review means that it's under review both from like the community to vote for it. Do other people agree that this is a great feature? At their comments, maybe sometimes comments can actually help clarify exactly what it is that the feature request should do. And sometimes there's some iteration that happens by the community in those comments to kind of narrow in and make it like an even better feature request. And it kind of matures a little bit out there in developer community. And at some point it might fit with sprint planning or it might fit with other work that we're doing in those areas. And then the editor team will then take us, okay, let's plan for this particular one to include that in the next update. And so that is pretty much how it works for any feature request that comes in that's actionable and valid. Now there are also cases where we can't really act on them. And there's a lot of confusion, I think about it. About this, which is if we get something in that we don't fully understand, it might not be clear or it could be ambivalent between like various different things, we will ask for clarification. And so we're gonna send, we kind of send it back. We sent the feature request back because we need more information. And so now the original user that posted that feature request has to like reply back. And I think they got like basically three weeks. And if we don't hear back for after three weeks we kind of close it because it just becomes kind of noise and orphaned a little bit in the system if we can't really do anything about it. And so there's a couple of things like that. Another one would be we might close something that we find is out of scope. So it could be that a feature request is like, hey, can we have Microsoft Word inside Visual Studio? Because in my solution I have a Word document, I wanna edit that directly inside of Visual Studio. We may wanna say, hey, there's actually nothing wrong with this suggestion but we feel like that's out of scope of what sort of Visual Studio is supposed to do, right? And then we close it down. So yeah, so that's how it works for feature request and bug reports is a very similar thing. We look, there it's a little bit different because we look at the severity of the bug. Like, oh, is this something that could impact a lot of people? Is it urgent? Do we really need to do something now while we jeopardizing some very important scenarios that a lot of people have? And then we prioritize them very highly or maybe they get a lower priority. And the ones that get a lower priority or normal priority, they kind of follow that pattern that I just described, right? So they gather feedback, they get under review, see if other community members are gonna vote for them and comment on them and provide more information. The cool thing about bug reports is that it actually allows you to upload trace files. And with Visual Studio, that happens automatically for you. You can simply just say, yes, collect trace files and attach to this bug report. And then that happens in the background. So that's really cool. And also if other people want to comment on an existing bug report, they too can say, hey, I also wanna share my trace logs from Visual Studio. That might help the team figure out exactly what's going on. Instead of just having one dataset, you can have multiple and that should up the chances, right? So it's very rich system for collecting, feedback, organizing it, and then acting on it. And it's getting better and better. And we are rolling out the new one as we speak, right? The title of the show is like, we have a new system now. Yeah, so what is that new system speaking of which? Right, right. So let's just take a look at my screen here. So first of all, it turns out that not everybody that uses Visual Studio knows how to request a feature or provide a bug report. So let me just show that. Oh, see if I can hit the right button. Let me zoom in. Oh, that doesn't work. Okay, so I'm just gonna go up in the help menu in Visual Studio. There's something called send feedback. And right here you can say, report a problem or suggest a feature. See, I always forget that exists. I usually do it directly to the DevCom website. Yep, you can do that too. So this opens just your default browser, right? Whatever that might be. But what's really interesting here is it actually connects you back to Visual Studio. So I didn't have to sign in because I was signed in Visual Studio and so there's actually a connection between the two. Keep it convenient. I keep it convenient. And yeah, so right here you can come in and submit your bug report, right? And let me just go home to the homepage here. So this is again a new homepage. We can see exactly what was fixed and what version. And we can see all the stuff that's the feedback that I've opened myself or that I've interacted with or voted for or commented on that I'm following, as we call it. And you can see all that. You can see I recently had like some things that I was following, three fixes here that went in. So that's kind of nice. And you know, okay, I work at the feedback team. I got probably 1,000 of these. So the average user doesn't have 1,000. I did my hang on it. We're getting just had on average 1,000 feedback tickets. Actually the average user has zero point something, right? Well, but we want, we really want you to come in here and interact more with the system because the more people that come in and look at what's there and vote and comment, the better the feature requests become, the more signal we get, the visual studio team, the more signal we get to understand what is a higher priority, right? So that's actually really, really important. And so one of the goals with the new website here is to drive what we call engagement. And if we scroll down at the bottom here, we can see I'm signed in. So I get to see all my stuff here. But if I wasn't signed in, I would just see this, right? So there's a couple of things that we would like you to be able to find a solution to a problem you might have because someone else might have actually reported it, right? Right. We also really want to hear from you, like what new features would you like in visual studio? And then at the end here, explore existing feature requests, okay? So if we go up here, let's start with that one because that's one I think is like really interesting. So in the menu, I can go up here. It's actually easy, there's kind of just three things that we kind of invite you to do that's the most important, right? Explore feedback or report a problem or request a feature. If I go to explore feedback and I click visual studio, notice here, there's other things that we collect it's not just for visual studio, but for the visual studio toolbox, let's concentrate on the visual studio aspect of it. And in here, I can search, I can filter, I can find here. We've got quite a bit of feedback, right? 130,000. Yeah. But if I just look at feature requests here, I got like almost 11,000. And I can search through it, I can filter, I can sort it and so on. So here's one. If I like a tag, like if I wanted to find all issues pretending to like the editor, can I just search for those? That's coming. That's coming. So we don't have it yet. The idea is that you would be able to come in here at some point and you can say, only show me things that has to do with web development or, you know, or maybe even more granular thing, just JavaScript or just C sharp or just like some sort of subset of visual studio because you don't necessarily care about everything, right? If you're a .NET developer, you might not care at all about any problems in the C++ area of visual studio because you never, you never go there. You never install those components. So it's super important that you're able to be able to filter to your interests. And so that's coming. We don't have it yet. Gotcha. And so here's one. You can see, you can see, just fold them out. You can see, okay, it's green. It was fixed in version 16.4. How many votes it's got? And so I can search by which ones have been completed and which ones haven't. Oh, yeah. You can see which ones are active, which ones were closed. Yeah, absolutely. And so this was a big ask from before where people had a hard time browsing and exploring and figure out what we did. And so now we make that much easier. Although people couldn't figure out, well, when we then fixed something, what version of visual studio was it fixed in? And so this is all very basic stuff when you think about it, right? But something like that, having that very visible up top, it makes total sense. And so the old site, the reason we're doing a new site, some people say, well, why don't you just use GitHub's issue tracker for that? And I create a new GitHub repo and just point people there, for instance. Or bring back user voice for... Yes, there's all such a things, right? No, so the reason we did a new version of the site is the old developer community site that we had was basically something that it was a third party product that we kind of just bought and themed to us. And we've had some issues. We'd like to... It wasn't as flexible as we wanted to. We had some issues getting them to agree about what we thought was a higher priority feature request from our part of you or bug report. And they didn't fix it or they didn't agree that they should do that. And so there were just features we could never really do. And so what we're doing now is that we're replacing the entire front end or keeping the same back end as before. And we do that while we're working on the back end. So we just launched the new front end. We're working on the back end. And at some point, hopefully in a few months, we'll have a brand new back end that will support all these things like we talked about, right? Like being able to filter by the area. Only show things that are relevant to my interests. That's great. Yeah, and a bunch of other things, right? So that's one of them. That's like something we really wanted to do. And hopefully just by having this explore feedback button out here, which we didn't have before, we actually hopefully attract some of you guys viewing this right now to hopefully come check out what was there, see the feature request that exists, vote on some of them that you like and give your comments, right? It's actually super important. And Leslie, you know this, you're your program manager on one of the Visual Studio teams, right? And you know, unless we have like clear amount of votes and comments, it's hard for us to then know what priority to give between, let's say you have 10 different request. Well, which one is the most important, right? Yeah, I'll go through like 20 and it's like they all have one vote. I don't know what one prioritize. Yeah, which kind of brings me to addressing the elephant in the room. I'm sure there's tons of people out there who are very familiar with the Dev community and you know, have posted countless times, numerous feedback tickets or suggestion tickets, that sort of thing. And they never, ever get completed or they just get closed and you leave a bunch of people unhappy when you're on the PM side and you're having to close it even though it's a good idea. So why are there so many tickets that don't get fixed or added to the app? That's a really good question. So there's a couple of reasons and let's take bug reports first, right? Because that's the one thing where it's like, okay, feature request is one thing but if the product doesn't work as advertised then that's problematic and it's the name, right? Yeah. So we get a lot of bug reports. We get hundreds a week. Yeah, 500 some got completed in 16.8 like you can imagine how many didn't get completed. Yeah, right. So when we get as many as that, right? We have over 100,000 in our database. Then we have to prioritize, just there's no way around it. You know this from your own team, your own company, if you're an engineer out there. Like you can't fix everything. If you are fixing everything that means you cannot do anything else, right? You cannot build new features. You can't stabilize other important things or whatever, you can only fix bugs and that's the situation we're probably in, right? So we prioritize and so there's a couple of ways that we prioritize. We look at the impact that we can kind of conclude off the bug report that it has. Like how many users are affected by this? How broadly is this bug, right? And how many people are affected? And then also, is it something that's blocking? Like is there no work around? And of course that takes into account. We take that into account when we prioritize. And then we also look at like something like votes and comments, like if we have a lot of people saying, no, I have this problem, then it, you know, that just is another signal for us to figure out, well, maybe it has more impact than we thought, right? So we see these as signals. There's not one of these things that determines it. It's a combination of probably a handful or two, yeah, like a dozen different things. And the same is true for feature requests, though they are a little bit different in nature, but so then there's the ones that kind of, they don't go through the eye of the needle, right? They're just not, let's say they have no votes, no comments really. We understand them to have like a low impact. It might be that they have a high impact for an individual. Like, and we very much empathize with that, but we have to be a little bit hard when we prioritize because if we get hundreds, we can't do them all as I mentioned, right? Right. And those are left in what's called under consideration. So that's kind of where we let them mature on the marketplace, or sorry, not on the marketplace, on the developer community website, right? We just came from a meeting with some about extensibility. So it's a similar concept, right? But in this case, yeah. So we let them mature on the developer community website for votes, comments, and those sort of things. And they can stay there for quite a while. And so it feels like, oh, well, they're never fixing my problems. And that's really hurtful to me as a customer. Maybe I'm a paying customer. And it's really problematic. And so making sure like there's a few things we can do to make it more likely to have the team prioritize your bug reports. So one is that you have very clear repro steps. Can we easily reproduce the issue? That's actually something that takes a long time. That's one of the things that takes the longest. And so because sometimes we don't really know how to reproduce the step. And so we investigate and that can take an hour for one, just a single bug report, right? So a super specified here, step one, I opened a new project, step two, I opened that C-sharp file, step three, I execute a build and so on and so forth. So the clearer you can make that, the easier it is and the faster we can get to it. And if you need to attach like a demo project, then that is also super helpful. It's not because we don't wanna do it, it's just simply we have to be a little bit hard in our prioritization. I hope it's understandable. Just the sheer volume is just, this was too huge, right? It has millions and millions of users. So that's how that works. Yeah, I get excited, that said, whenever I do see a duplicate ticket, whenever I'm triaging personally, because it's like, okay, great, other people think that this is an issue too. So maybe it makes it easier to prioritize, I find in that way. Right. And anytime anyone includes pictures too, I get excited because pictures are a thousand months. Exactly, as much information you can provide, that makes it easy to either understand or reproduce, that's gonna up the chances of it going somewhere significantly. And again, like if you can get like, if it's not just you that has the issue, but maybe all your colleagues on your team, get them to vote on it too. Maybe comment, help you clarify some of the stuff, like just in the comments on the ticket. And that should be very helpful as well. Awesome. So wrapping things up, what's next for the dev community? I mean, you already talked about the extensive filtering capabilities that are coming up and the backend, is there anything else that you wanna add? Yeah, we're gonna look at like a deeper integration into Visual Studio, that's gonna be one. We don't have it yet, like all thought out, but the idea is instead of just having like links from Visual Studio to the browser that lets you create tickets, we'll have more information. So once something is fixed, you maybe there's a notification or if we request more information from you, like, hey, can you clarify this? There's actually a notification inside Visual Studio and you'll be able to kind of track along, in a sort of more integrated fashion. And then also a way for you to more easily discover new suggestions and feature requests out there to help give us that signal that at the end of the day benefits everyone, right? It sounds like it's sometimes when I talk about this, it sounds like it's all about us, we want you to do something, we want good repro steps, we want good bug reports, we want, you know, this and that. And, you know, and that's true, but we wanted not just for us, we wanted for, because we want people, we wanna solve as many of these tickets as we possibly can, right? And so if we can do something that can up the chances of us fixing your bug report, we would love to do it. And so, yeah, so that's why that sounds like that sometimes. But we really go in for the win-win, absolutely. Sweet, yeah. Like it doesn't give me joy personally to close good ideas. Like I get excited when we do get to put that under a roadmap on the team personally. So like, we're not trying to be heartless. No, it's the best feeling. It's the best feeling when you can put something on the roadmap and everyone can see it. And then, you know, a couple of weeks later, you can mark it as, hey, it's completed, right? Yep, exactly. So, and people can just try out this new version of DevCom like right now, right? Yep. So if you go into Visual Studio, up in the help top menu and then send feedback, you're gonna end up on the new version of developer community. They all want still there. We're kind of redirecting everything at the moment. It's that new. So you can still find the old one if you, I'm not gonna tell you how, but if you could create it, you might be able to, but not for long and then it'll be gone. I think some people are gonna take that as a challenge. Cool. Well, thank you so much for coming on and sharing why triaging and making those tickets and feedback suggestions are so important, Mads. Hey, my pleasure. Sweet. So until next time, happy coding and happy ticketing.