 Okay, so this is a bof. I'm not going to talk the entire time The primary goal out of this Boff at least for me and maybe you have different goals is to come up with a set of things that I need to change in the BTS To come up with a set of things that Maintainers with large amounts of bugs can do both technically and socially and hopefully to Get a couple of you interested in things that you can help me change in the BTS because I'm just a single person And there's no way that I can possibly implement all the things that need to be done there And I'm getting even more busy now than I was before so Without any further ado, let's talk about the problems Just so we all understand what we're dealing with here. The first thing is we have too many bugs Some maintainers don't have a lot of bugs But quite a few of us in this room have a lot of packages which are very popular with users and end up generating a lot of bugs This ends up Causing a problem because there's no way for a single maintainer or even a small group of maintainers to keep up with the influx of bugs And to actually do any development I mean after all we're all in Debian because we like to do development and like to work on interesting problems and Wrangling bugs is not a particularly interesting problem for most of us. I mean it. I know it's not a very interesting problem for me So what happens is when maintainers can't keep up the bugs don't get responded to they don't get altered Nobody knows what's actually the case of the bug Then the reporter feels abandoned. They feel that Debian doesn't care about their bug Then the reporters don't report any more bugs because if Debian hasn't dealt with the single bug that they've sent Well, maybe Debian doesn't care about bugs at all and then consequently the quality of Debian suffers because we're stopped getting the important bugs That actually matter Do we need this thing on? Oh? You can't see me at all with it off It's seeing me is not important Okay Whatever These slides are available on my web page So if you want to get them right now you can go to rzlab.ucr.edu slash Debian slash DC 9 And it's a single PDF that's there if you want to follow along Okay, and so the quality of Debian suffers So these are the sets of packages that currently have the most bugs the first two WMPP and installation reports are kind of non-interesting cases I mean installation reports is probably is entering case. Yeah WMPP itself is not particularly interesting because those bugs are each owned by a small set of individuals who Presumably know who they are and there's a pretty good set of tools already existing that are written by a various number of people to Wrangle those bugs and keep them in reasonably good shape and close the bugs that are outdated However, the rest of the packages that are on this list have a huge number of bugs and there's Unlikely that single maintainers are going to be able to deal with this very effectively This is just a set of bugs currently assigned to these packages by the way I haven't done anything special to figure out whether these are open bugs or closed bugs or tagged in any way So these are just the current number of unarchived bugs assigned to a package So example, I'm an offender here DebBugs. I work on and I have almost 400 bugs that are still assigned to DebBugs So that's slightly problematic So we could see here that there's a lot of packages with bugs on the range from 200 to a thousand bugs against a single package Now that's not really the main issue packages Aren't the whole scope of the problem Maintainers maintain more than one package and so if you're a maintainer You probably some of you are maintaining multiple packages that were on that list And so you now or on teams that are maintaining multiple packages that are on that list If you're a maintainer you can be dealing with upwards of well a single person. Let's say 900 bucks That's a lot of bucks. I mean you probably have no idea what more than Maybe 80 or 90 of them actually are anymore So we need to come up with better ways of dealing with this. It's especially true in the case of teams Teams because there's no obvious single person responsible There needs to be a better way to distribute that workload across the team And that's something that I think I want to talk about a little bit later Just to give you an idea of an example here This is sort of a again a slightly silly maintainer example but packages.qa.debian.org has 1200 and five bugs 710 of those bugs are without a response For example, this bug was submitted on 2001 and still hasn't been responded to This is not to say that packages.debian or the qa team is at fault here. This is somebody else's issue. Yeah So not yet. What you can do is you can easily see which bugs You can sort them by last modified date which will tell you which bugs Have been left alone for the longest time, but it can't tell you which ones haven't been responded to I actually had to do this query using UDD because it wasn't trivial to do in Debugs But it is something that I need to fix so that you can pull out these bugs when you're a maintainer What are the immediate basically the question becomes what are the immediate action items? And I think the immediate action items are bugs that haven't been responded to or Bugs that have a message from the submitter Which hasn't been responded to I think those two things are things that are immediate action items for bugs to Turn to that sort of parlance Okay, yeah granted these are qa packages, so it's it's not really Surprising that there are bugs like this. There's a reason why these Packages are maintained by qa because they weren't properly being maintained before a slightly more useful example The qtkde has 1300 some odd bugs 4 and 26 have no response This bug for example was submitted In 2003 and hasn't been responded to it's just an example of a really old one So there clearly is a case for bugs that have sort of ignored granted This is a wishlist bug and it's not doesn't look like a terribly interesting wishlist bug, but there's still nothing's been done about it Okay, this isn't a playing game The maintainers have lots of packages they do an immense amount of work for Debian But we need to come up with wetter ways to help them cope And ways to help ourselves cope with this a set of bugs so The technical there are a couple different technical solutions and what I'd like to do is break the discussion into two groups One half is technical things that we can do Code that I can write or you can write or other people can write Hopefully code that you can write That will help solve these problems The second aspect which I want to spend the second half of the boff discussing is social aspects How can we get more people involved? How can we keep people involved? How can we make people want to? Modify the bugs anything that has to deal with the way people interact with bugs. That's not a real technical thing so One of the first things that actually was just mentioned Is there needs to be a better way to identify bugs which require an action? Ideally you would be able as a maintainer to look at dead bugs and see in a list from Oldest to newest the set of bugs which required you to do an action and when you had a moment's spare time You would go to item number one and say okay. Yes. This is what this bug is kill it off And so that's something that dead bugs needs to change to do another thing that I'm going to talk about more in the state of the BTS talk is a tool called Local Debugs and what this does is it produces a mirror of bugs that I think interest you It's configurable so you can pick up more bugs if that More bugs are exciting for you, but these are basically a set of Bugs that are RC bugs that you've talked to bugs that you've submitted and bugs in packages that you maintain And so this produces a fully working copy of the BTS with everything except for email handling on your local machine And it has the stuff to our sync to update it So you just run this command it'll update it it runs a little web server And so you can run a normal Debugs on your machine So when you're in an airplane when you're on the train when you are in one of those rare places that don't have Connectivity you can at least queue up emails to deal with your bugs So I think that will help some people And the final thing is I need to fix the documentation for user categorization Which I've been saying that I was going to do for a while, but I really absolutely need to do it I mean it's peering to the top So that it's possible for maintainers to come up with workflow solutions that work for them. Yeah I have some blame for that as well since I did since I Went through the effort of learning how to use user categorization a little while back for mandibia, I think it was and Actually, I find it I find it enormously useful to me once I got it going I have a list of of bugs that I plan to fix in various upstream releases and that sort of thing which works quite well for me in that case But yeah, I think I worked it out by looking through the Deb bug source and figuring out what males it was going to accept So yeah, that's exactly how when I went to to figure it out myself the same problem And it it takes quite a bit of time investments. So that's one of the reasons why I haven't documented So one of the things on my to-do list is to actually fix that or yeah Okay Things that maintainers may find useful One of them is to automate replies for bugs that are likely to be long to upstream So if you see Example is the KDE team which talked to me a couple times Mentioned that they have a lot of bugs which aren't problems in the Debian packaging and it's extremely difficult for them to Handle sending the bug upstream to link up the forwarding and to keep tracking it because they have so many packages And so many different things So one of the things that you can do as a maintainer what I suggested to them is to produce a set of documentation Like a single email couple paragraphs that explains what the problem is ie that there's upstream bugs Where the user can go to shepherd their bug upstream? how they can set up the linking and Basically make the user or try to co-op the user into being the shepherd of their own bugs So that was sort of my philosophy behind that and this basically puts more burden on the reporter So that there are a lot of bug reporters and not so many maintainers generally speaking And so that may help spread out the load. Yeah Sam has a comment. Yeah, your mic is coming So, I mean if this is if you can get someone to do that, that's great But I think one of the key things about Debian is that we are Committed to being the user's interface and that As a Debian user one of the things I like is that I can report a bug Even if it's an upstream bug and I don't have to go register for 40 different bugzilla accounts on 15 different systems And argue with a bunch of upstreams. I have to argue using a consistent single interface With Debian maintainers and so I'd be very careful about You know How far we push that? Right. Yeah, that's that is pretty much succinctly stated my reservations with it as well But it's one of those cases that when the choice is between having the bug totally ignored or at least telling the reporter Some information that they could help. I mean While it's not an optimal choice. I think it was the best of a bad Set. Yeah, I mean the flip side of that is that I reported bug quite a while ago And it sat untouched in the BTS for six months a year and then it was closed I think closed or those reply back to me. This is not stream bug. Please report it upstream and if if yeah, I mean it is but You know people are busy and if I'd got an email back saying look, I'm terribly busy I really don't have time to deal with this at the moment I probably would have gone, you know, I wondered why I bothered to report it to Debian rather than going direct upstream Yeah, there's two Do we have another mic? has there been I'm sure there has but some thought into Doing some automated upstream reporting or if a tag or a Was it attached to a bug by the maintainer That this is an upstream bug it would just Automatically log into the pre set up bugzilla account for the KDE team and file the bug And then interface the replies back That's it's a bit of a problem because there's quite a number of different upstream bug systems, of course, but there are at least a certain set of bugzilla versus Different whatever launchpad or whatever. Yeah Sorry, I'm sure I'm sure somebody else will reply to that. I just wanted to comment on what you said as well the With automated replies the the experience I've Had with them just just from receiving them and seeing people's reactions to them and so on The worst case I think is to get a response that looks like a robot rooted If you get an ultimate if you get something that's actually scripted but that looks like a human wrote it with some attention to how the How the reporter might react and so on it's written as if it were an email to them rather than as if it were an automated response then it goes over a lot better you get these you get these mails that say That basically don't really look like they've read the bug and I think if the if there if there's some if there if you send an automated response that makes it look as if you've read the bug Exhibits some kind of human attention then You can save a lot of you you can get the benefits of saving a lot of effort But without quite so much of the backlash that you tend to get otherwise Yeah, I mean when I had a vision the automated response I'd assume that it would be some sort of system where an upstream looked at the bug Sorry the maintainer looked at the bug and said yeah, press the button and Then it would do that. I mean, yeah in your mail client or whatever. I mean you just have a script that did it with regards to upstream linking Lars actually and I have done a little bit of discussing and we're going to hopefully have some time to discuss later on procedure by which we can Communicate information from different bug tracking systems like bugzilla like dubbugs And this would be specifically of interest as well for distributed bug tracking So that's still in its infancy, but yeah, but that is sort of something that needs to be fleshed out Don Have you looked at SD? Sorry, what have you looked at SD? No, okay. It's a distributed bug tracking system from bestpractical.com the the same folks who brought us SVK Basically it's interesting property is that it has sink and merge algorithms between various bug tracking For example, you can sync a bug from track to bugzilla I think I don't remember which set it it currently supports but basically plugging in a new bug tracking system And moving data between them is is supported by the framework There is not currently a dubbugs plug-in But I would at least look at that technology when you're looking at this problem. Awesome. Thanks Let me since we're already in the stage. This is the discussion phase of the technical part So I mean basically questions that we're hoping to I was hoping to get answered So what are what is missing from the BTS to make this sort of problem easier? Discussion point, what do you spend most of your time doing when dealing with bugs? And what have you guys done that works and what doesn't so? So we can keep discussing in this line. Are there any more comments? I'm not one of the people who actually has huge numbers of bugs on their own packages, but It's possible in the BTS interface to hide the things that are waiting for a reply from from the submitter Yeah, so not currently if you tag them more info then yeah But although if you don't tag them, it's not not possible So yeah, that's actually something that goes back to the action needed list So it is going to be possible to do it in a single mail to tag I mean what is now you can just tag it more more info using a mail to both control and Submit but it is going to be possible to also do any arbitrary control message and any message to submit or bug number at So in that single message you could do it all in one shot But that's not totally complete yet You Well, perhaps this is there already, but the the user tags functionality is Very powerful and quite interesting Although I know quite a few WN users not developers who are have are completely clueless about this functionality Which is kind of funny because it's called user tags, but the Right Exactly well Something that could be quite interesting is on the bug overview page for a package would be like a user tag cloud Or some such that where you could see what other things are being added to the bug perhaps that's there already Some of that information is available, but there's no Right now there's no option to say okay. Yeah, I want to look at the set of bugs as so-and-so looks at them which sort of There's some question about whether we want to really enable that totally but it would at least enable people to get ideas for How they can look at it? Because it'd be quite interesting to know if say my package had a I don't know security user tag added to it or something So while I was working for canonical I spent a lot of my time on The kind of packages that I don't really maintain very much In Debian which have very large numbers of essentially naive users and I found that a Good technique these automated messages that you talked about earlier I found myself doing that basically ad hoc and I'd have little little paragraphs that I Can responses that I paste into these bug reports and nobody actually seemed to mind that very much at all and Occasionally, I'm obviously a very large number of these bug reports are basically noise there's this very little chance that By interacting putting more effort into that report You're actually going to get to a point where it allows you to improve the software, which is after all the point but occasionally I Was able to get you know the right information and disentangle the bug from whatever You know nightmarish context it was in and pin it down and actually improve improve things as a bit as a result And that's something that I would commend To maintain is in general just as an approach and you could you don't need any technical support for this You just need a can email that you can paste in Hey, hey everyone. I'm the summer of code student doing the Web UI for that box. I'm okay. I'm doing hey Well some comments that I'm trying to Test with you in this discussion first thing is One of the motivations for me for doing this break is to try to get more people involved doing triaging because at least in my experience Helping none. It's a real It's a real source of new contributors people starts triaging and then Slowly get more involved and more involved and there's actually a team of people only doing triaging so First thing I would like to ask you all as maintainers is if you will be okay with people that maybe you don't know that will do triaging on your packages like answering to users saying We need more information or that version is too old to be supported Etc. Etc. And another thing as a comment is that The automated responses Have proved to be somewhat useful in none at least for some cases for example When there's crashes most people just click on the back body link a button that says send report and it Blindly sends a report to the back seal most of the time people never replies to that or they never give Further information so usually we reply with We need a better info a better stack price to know what what broke And there's really few people that reply. So most of the crash reports are garbage Because we will never know what happened If I got it right The Sorry, what's your name the guy that we Previous comment. Yeah Okay, if I got it right you are saying the in canonical you got you have this like progressive stock answers So there was no there's no Organizational support that but it was entirely informal I just decided that given that I had hundreds and thousands of these very similar bugs that there wasn't anything I could do to them You know, I couldn't engage with them very much individually because there wouldn't be time. So I wrote a set of stock Paragraphs and I kept them lying around in a text file and after a while I noticed that occasionally Ubuntu is very full of of triages who sort of don't quite know exactly what they're doing and Maybe make the odd mistake, but if you set a good example for them You know, you'd find that they copied your stock answer into some other bug Sometimes this was this was bad, but but on the whole it was an improvement over what many of them were doing beforehand. I Don't know if you could say something about Three others. Yeah, that's actually the second half a week. I was hoping anyway. So so yeah, it's definitely something We need to talk about Okay, well since we're about halfway through. Let's go ahead and switch to the second part So the social aspect that or at least what I was calling the social aspect in the terms of this both is Things that we can do to get more people involved The first thing is slightly better documentation of the BTS and in this terms. I'm thinking more from the casual triage and or casual bug reporter aspect What can we do to make it easier to get started doing things that? The casual triage or who may become a serious triage or started in a way that isn't going to get in the way of maintainers isn't going to cause a problem and It gives them enough information to get started at some level Yeah, sorry the first thing I'd like to suggest there is an implicit social Limitation on people sending out messages that simply say Can you still reproduce this bug in the current release? Right. I think it would be great if the triagers would Be explicit that they are not the maintainer of the package. Yeah, that would be useful as well So, I mean the main thing also as well as in this is enabling them Immediately to figure out where they can do the most good. So what are the packages that are low on manpower? Where a triager may be the only person who looks at that bug for a long period of time? and the other thing is how to recognize the contributions of triagers and wranglers because unlike a package maintainer where you automatically get recognition your names on the package your names on the web page or names everywhere People who work do the sort of work in the bts Sometimes don't get recognized. There's no cliche to it. I mean there is if your Maintaining that package you know exactly who it was who is doing all the work But there's no wider recognition and so that's something that I kept thinking about and I plan to do last year didn't get to it but I want to have a bug start devian org Employee of the month or something where we keep track or try to keep track of who has fixed the most bugs in a month Who has been most helpful for triaging in the month either? Whether it's be a voting or something or whether we Do it via a query or something? Yeah, the people people love getting getting cash for that sort of thing as as long as it doesn't turn into a sort of Do lots of useless things right competition, but it can't but it can be done very well And I'd agree with that The the other thing I'd suggest is something that each maintainer can do. I've had good luck in the past Mostly mostly in Ubuntu, although I think that's only really because they're more of a bug triage community I've had some good luck in the past with As a maintainer looking at people who are doing lots of good bug triage going off talking to them saying that That's great. Could you could you have a look at this because I think that need that needs work? And with a bit with a bit of effort you can turn people into co-maintenors if you try hard enough It's it can take its time people who are doing this kind of thing often aren't Programmers, but in many cases there are people who are looking for a way to contribute to To the project and they just haven't quite figured out how yet if you identify the good ones who are saying oh Yeah, that's that seems to be a bug in path dot itch line 213 and There are this sort of people who you might be able to turn into a co-maintenor over time so I had one Idea to do one of the big trouble with triages is that often they go often do sort of random things that they think are helpful And there's very little explicit documentation anyway that Explains what kind of triaging activity is useful and what isn't and so I'm sure we've all been on the receiving end of the odd incompetent triage And it can be pretty irritating Both as a maintainer and as a submitter But on the other hand they can do a lot of good if you can get the point in the right way So one thing that I thought would be useful is if they were away For a package to publish its kind of triage policy somewhere Probably somewhere in the BTS so that it's nearby the list of the bugs and everything and you could just look at it as a web page And it would say here are some useful things that people do and then while you're at it You know if if somebody's been doing a great job, you put their name up there and say, you know If you have any questions about what would be a good triaging activity the following people really know what's up and and that would be a good way of getting people recognition and maybe Getting the good means out there and killing the bad ones one thing about sorry, this sounds too non-based but over there basically You don't have immediate Bright access because it's back. See that you need permissions but basically everything goes are about You approach the box channel and say I would like to help And someone that is a backmaster and has Access to give you permission to do bright stuff Give you access and follows your activity for let's say one month and if you start breaking stuff or Doing stuff just to fill your status They politely ask you to fix your behavior or you get removed of the bright group so The point here will be that there's a social control over bad triaging if you do bad triaging you get You you get out of the back squat It's So silly but it's not cool to be out of the back squat because it actually is seeing as a cool thing something that really helps That no one wants to do because it's quite boring to only do qa all day filling stock answers and one other thing that might sound a bit questionable is that but norms back sealer has a point system that Depending on how much bugs have you closed commented or reported you get a Specific number for example, you can have one point and after reporting ten bags You can have three points and it gets harder and harder as long as you go on But it's not seen as a competition, but more like Recognition of what you are doing so sort of like the star system on most forums. I'm assuming is the Right uh-huh and something something else about giving recognition to triggers Maybe we can put in packages dot qa devian like close in one of the boxes in the page like people dragging these packages this package Juan Perez and this other guy and link to maybe their Profile page. I have one other suggestion that may be controversial Occasionally you notice, you know You get some mail from from the BTS and you look at it and you say, oh dear or maybe something gruder And and and and then you you think to yourself Well, I wonder how many other bug reports have had this same thing done to them and then you go and You know do a quick search and it turns out that one person has done a very similar thing to a great number of bugs and It would be nice if there were an undo if there were a way to say, you know Maybe one of the bugs admins would have to do it or maybe you'd have to be a DD or something and send a signed message But there were ways say please undo everything that this person did today and then you could send them an email saying I'm terribly Sorry, I had to undo all Your work, but actually we really didn't like it and obviously this would be very discouraging but There are of course, you know, I mean Ubuntu has this this principle that everybody can make a valuable contribution But I'm not entirely sure that I agree with that and I think there are some people You know, there are some people we want to encourage and the vast majority of people want to be encouraged But there's some people who are a bit of a loose cannon and somebody who goes often does a great deal of very similar things without talking To somebody else about it first Is maybe somebody that we would rather have elsewhere Yeah, one of the aspects and one of the reasons why I've always sort of been a little bit careful about Thinking about introducing a web front end is precisely this reason because it sort of puts together a barrier To to contribution that may help enable us to control it But that said we always have this case where anybody can send mail and since now I mean, there's no problem with a web front end generating an email either So that's something that yeah, this ability to recall state may be useful But that said, I mean the number of times that We've had problems for example the number of people who are excluded for control Is fairly small. I think there's only three or four emails that are people who are not allowed to send email to the control interface right now I'm really thinking about here. It's it's it's ignorance and about once every three months I have some of the oldest and most difficult bugs in Debian because well, that's just me really And this means that those bugs Get very little genuine activity because they're very hard and occasionally they do get sort of well triage activity And and obviously I see a disproportionately large proportion of bad triage activity because those bugs are essentially already triaged And the effect of this is that you know, I look at this and then I see that this person Has done a similar thing to several dozen bug reports And it would be nice if I could just undo that and send them a mail explaining why I done in and then you know Maybe they'll learn from it and maybe they won't I Don't think we're at the stage yet where we need to ban people, you know I think if you undo everything they've done they'll they'll probably take the hit unless they're a really would it would it be enough if you could shove The output from the control bot through a script that would generate the contra positive or the inverse of that action Right, but I also need a an ability to search to identify All of the things that that match usually it's the criteria is this person's from address and the last day or so Okay, and if I could generate a List of those bugs You know check up on half a dozen of them to make sure that it wasn't just a fluke and then Yeah, I mean if I could send a You know a scripted email to control that would be fine for me It it might be nice if we so you can extract all of this from the Bug log files and debt bugs, but I think Don and I both know it's a complete pen in the arse to do Yeah, I've actually made it easier, so I'll talk about that too But oh, okay I was I was about to suggest that we keep something that looks a bit like deep good stop look Which just is a complete log of every control action taken regardless of bug And that would both the law fairly easy reversal and also give reasonably convenient way for well at least for admins to check Whether To get a complete list of what everybody had done and maybe to make it easier to expose that in future Yeah, but it says a comment in the back What I think would be really nice if one could undo that is a reassigning box because when you reassign the buck to another package you lose all the version information on in the old Package and if you reassign it back then it's hard to restore that information. Okay. Yeah, so What what I've changed is just since this is coming up in the bug log now Since the most recent upload it tracks What was the original state of the bug and what things it's modified in that control message? So and it's in html comments in the log So if you're looking at a bug that you've recently modified you can actually show the html source It'll actually show you that bit. It's just there And so that'll enable us to roll it back. Also now the control act messages in the reassign Well, there's a they're a little bit too verbose right now But they'll tell you exactly what actions they've done. So it'll say oh, yes I've removed this found version. I've added this found version instead. I've caused it to be reopened So all that is more verbosely repeated It's unfortunately a little bit too verbose and that it tells you what bug in package it is multiple times So I have to fix that it's it was designed not to do that, but it's clearly a bug This is a comment from MRV in on IRC a triage done slash unwanted to tag might help Okay, there are some way of identifying then like bugs that have clearly been handled by the maintainer I think this is sort of the idea of action needed bugs. So if once we got to a state where The action any action required by the maintainer had been done And the maintainer it indicated as such Then there's no point for additional triage So people can I mean focus on other bugs instead and that would sort of clue them in as to that I think that would probably also help with that aspect Comment from me Possibly it would be able To say that we do not want triage by our particular user rather than banning the particular user from doing any Tech Modification of bugs as we've had to do in the past it might be just if he has a particular package or a particular bug that we do not want this user to Modify okay. Yeah, it's currently Would conceivably be possible to code that I mean if people think that's a good idea then we can file wish this bug Instead bugs and I can look at it. So I guess I I'm wondering if if we are either micro-optimizing or if the rest of Debian has a different experience than I have but I am far More worried about trying to convince people to triage my packages than to convince them not to I'll be happy to deal with Triage mistakes, but it would be really great if you know I Could go say to help people please triage my packages. It would be great You know, please find out if these bugs have been fixed upstream. Let me know Please find out if these bugs still reap, you know can be reproduced Please ask for help if you don't from the original submitter if you don't understand the bug report More than trying to figure out how to stop it from happening because that seems to be the status quo, right? Okay, well I think too along with that if we can put in a set of bugs that have an action required and That'll automatically select these bugs and it'll give triage or something that they can look at that They know where to start. They'll know that their Contributions will be useful if they start with those bugs There have been and sometimes I've had a short period of time when I was able to contribute to Debian but not have time to commit to being a package maintainer and so You know, I one of the things one can do is fix some bugs and one of the difficult things actually is finding some bugs But then there's an act a maintainer who's sufficiently active that if you submit a fix It will actually be implemented rather than sitting untouched for months months years on end because that's very discouraging and I mean under STL has done some things for Debian science, which has made it somewhat easier to Pick the subset of packages. I'm particularly interested in and see bugs in that But matching people who've got bugs that require some assistance With people who have some some level of experience in that particular area How how you do it? I don't know but that would enable many more people to contribute If they've got an afternoon or a weekend free and they're not Debian maintainers without having the full commitment of being a Debian maintainer Sorry Okay, that that that actually sounds like tagging. I don't know But it's a really good idea. I will say plus one and about I want to round the idea of the bug squad So basically In norm people is encouraged to screw up because when they do that we basically just say You shouldn't do this because it upsets people But don't worry. You're learning try not to do it again If you have any doubt just ask we will tell you what to do or how to proceed so it's basically a thing of Encouraging people to just try because it's better for us to have people And maybe once in a while screwing up We're getting close to the end here, so let me Flip up the last slide and we can continue discussing until we run out of time But one of the most important things is to take an idea that we've talked about here and run with it So whether that's Producing automated or semi-automated responses to messages based on blurbs Okay, as you're maintaining bugs that stuff that maintainers can do and if you come up with a particularly good set of them Let me know about them and then maybe we'll have a repository somewhere off of bugs So like resources for maintainers. These are responses that Other individuals are using that help The other thing is don't wait for me I'm extra my to-do list is in dead bugs and as you can tell it's drowning in bugs So don't wait for me and don't expect me to solve a particular problem Except passages as to all the dead bugs maintainers. So don't don't wait up for me to to make it work for everything so any more Comments or questions I'll be talking more about the actual current state of the BTS and some new features that may help with this a little bit That have already been implemented in the state of the BTS talk tomorrow at whatever time it is I think it's one o'clock or something There was someone earlier in the talk who suggested some distributed version Tucker bug Tucker based on By the people who did SVK could you provide an a URL? It was Sam who mentioned SD is that correct SD? SD is really hard to Google for Okay, oh with that. Thank you. Feel free again to if you have suggestions file bugs against debugs Or talk to me on RC and devian bugs or pound debugs Doesn't really matter which thanks