 My name is Pam and I'm going to give you a quick overview of the bug smash initiative, which is what I've been mostly focusing my contribution on for the last several months. Bug Smash initiative is quite simply a community initiative aimed at fixing known bugs in Drupal core, which I know sounds quite broad, but there is a method to the madness. And the sort of fundamental premise that we're all working off is that there are a lot of bugs in Drupal core. And I think basically what happened was Lee Roland, who's a core committer just sort of got frustrated, I think with the number of like really serious bugs things that drive people crazy and and the slow case of getting those addressed that he just basically said, I think we need to really focus our energy just on getting rid of some of the more annoying bugs. And that was really where it started. Lee sort of came up with a vision for it. We started having meetings and then that's how the ball got rolling. So right now this is just like an overview of where Drupal core is right now, which is 7474 opens and then we have a look at reports 1092 of those are major or critical. As you can see, there are thousands of bugs that either needs work or needs review, which means that there is a patch, at least one patch against those issues and could be, you know, assisted with patch reviews manual testing, because there are 23 are TBC bugs, which hopefully means that they're about to be fixed and then there are just over 15,000 bugs that we have closed. So that's just a quick overview of where we are currently in the state of Drupal core. And then just quickly, I'll talk about how we've been working and how we've been kind of seeing the bug issue q So basically the bulk of it is just triage and triage probably sounds really either boring or maybe it sounds intimidating or I'm not really sure but basically the whole key to this initiative is triage. So the first thing that we've been doing is just going through old bugs and either adding steps to reproduce if there weren't stuff there to begin with or updating them based on changes to core or just kind of make to make them work in size. And when I first started doing this was digging up issues from five years ago, and rewriting the steps to test to test them just kind of thought what is the point of this, you know, is this really going to matter and I was blown away because just the simple step of updating the issue summary to clearly explain what the bug was was enough to get people writing patches. So I think for me it was amazing to see that there are people out there who are looking for ways to contribute, but maybe they just didn't know where and a lot of times the bugs that get reported. It's not entirely clear what these are meant and so you have to kind of step through it and look around and try to kind of figure out what they meant and then once you can put it in terms of easy to reproduce and easy to understand then these things are getting worked on. A couple of the other things we've been doing is just recategorizing. So sometimes someone will log a bug and say, you know, this doesn't work, but actually it works the way it's meant to work. So they're either asking for a new feature or just, you know, it's more of a task, you know, more of a to do rather than an actual bug. Another thing we do is update issue priority so by there tends to be a bit of abuse of the critical and major statuses and so by just kind of keeping that clean and I think it helps the community focus and, you know, if critical and major if we know that those are being applied properly it's easier to prioritize this I think. And then the probably the biggest thing we've been able to do is just to close folder outdated issues, either where there was a duplicate and issues been fixed in the meantime, or, you know, it's a bug against like trigger module which was removed in Drupal 8 so we can just kind of either close that as obsolete moving to the simple test issues from core to the simple test queue, just to clear them out and that actually I think it helps a lot because I think if we can get to a point where all of the bugs in the queue are like legitimate bugs, I think it'll just become easier to work through them. And then just a couple of other things you've tried to do some group triage sessions by Google Meet where a couple of people jump on a meet and just kind of talk through a bunch of issues and, you know, what do you think about this and triage them very quickly and that worked really well but it's been a bit tricky to find to find good times for that where everyone's time zones one. And then the last thing to note is that if you do find a bug that either you can't reproduce or works as designed or it's a duplicate and you close it. In the traditional issue system, you don't get any credit for that. So what we do is we have a meta issue each fortnight where you can post the bugs that you close, and then we will give anyone who did that to at least one bug in the fortnight will get a core contribution credit. So a couple of the other things we do are just briefly we set we set targets so we might pick an issue or a series of issues that we want to focus on for the fortnight and we all kind of pile on and and throw our resources at that either through reviews or ready tests or whatever it is. We do a lot of patch reviews and we also have a system that we call review swap where you can come in and posted an issue that you want to get reviewed and then you basically offer to review someone else's in return. Writing test is also a big thing that's needed because a bug fix can't be committed if it doesn't have an automated test. So that's big one. And then we also do a lot of mentoring, you know, bringing in trying to encourage new contributors. There's quite a low bar for entry because there's such a range of things that needs doing. So we found we have a lot of people just pop in and ask a question. I don't, you know, I don't know how to get set up to run the Drupal test spot on my local environment or, you know, what's the process for marketing and issue RTB these kinds of questions that process questions that tend to prevent people from contributing. We have a very captive audience to answer those questions. So this is what we've done since we started on the 30th of May, we've closed 612 bugs and we fixed 125 of those. So the fixed means a fixed got contributed to core for that issue. The other ones were outdated. Can't reproduce all these other things. And then these are, these are a couple of other stats. This is just overall the number of bugs since from April to October. The difference is quite big there you can see. And then these are just some stats about the average age, which are a little bit less impressive because six months passed between those two deadlines. So those numbers didn't go down as much as we would have liked. And I'll just talk quickly about why I contribute to this initiative and, and hopefully these reasons resonate for you as well. So the first big thing is that a lot of the core meetings happen either really late in our night or first thing in our morning just totally unfriendly times and because this initiative was started by Lee and has a number of Australian contributors we do our we do our meetings and and we tend to have our most active times during the Australian daytime. So it's a really good way for people in this time zone to get involved. Another thing that I think is pretty cool is just the ability to collaborate with core committers and subsystem maintainers, kind of on a daily basis so if you post a question about views. We've got land views of use subsystem maintainer and they're answering those questions leaves in there all the time. We've got we've just got a really active and helpful community of the experts to answer your questions and kind of guide you if you need it. You can also selfishly earn karma to fix bugs that you might care about so if you jump in and help out on a couple of bugs that aren't really things that bother you very much but it's something you have expertise in by contributing to that you'll you'll basically earn karma and make it more likely that you'll get help with a bug that you do care about. Another thing that's cool about it is that there is a lot of stuff you can do to help it's not just writing patches so it's not just all about code and it's not all super technical. There's a lot of different ways that you can contribute. It also just feels good I think to help. Obviously, you know, my livelihood is based on Drupal and I, I think it's really great that it's run by a community and I feel really lucky to be able to give back in a very small way. I also have learned so so much. This is another sort of selfish thing but triaging issues is an incredible way to learn about Drupal. There are so many things that people either trying to do or systems that I don't normally touch in my job like translation, for example, I never use multilingual functionality in my job but I've done so much trying to reproduce multilingual bugs that I could I could pretty well set up a multilingual site from scratch just on that basis alone so I strongly encourage you, like I said a couple of selfish reasons you'll learn so much. It's also just a super supportive community and I've really enjoyed just meeting new people and talking to people through the initiative. So how you can help there are a couple of ways but I think the first way and the way that everybody can can and probably will is by filing good bug reports. So one thing that I've kind of really taken on board is before you create a bug in Drupal Core be really really sure that it's a thing that's broken and it's not something that either you know it just doesn't work the way you think it should or you know you did it wrong. There is so much energy that goes into triaging these bugs and if you just kind of throw it up without a thought and say well they'll want to know about this bug. There is no they it's us and so just be really sure that it's a bug. Check for duplicates you know obviously sometimes can be hard but at least do a cursory search to make sure that it's not a duplicate. Please please please please please please include steps to reproduce even if you think it's something so obvious they couldn't possibly need the step by step. Please include steps to reproduce starting from install Drupal. This is so so so so so important I cannot emphasize it enough. For one thing it means that anyone who comes along that might not know the first thing about it like I said with the multi-lingual and anything about multi-lingual. If someone put some steps to test I can verify that it is an issue and then we can easily verify that the issue is fixed. The other thing it makes sure is that it's not a contrived bug it's not coming from a contrived module. If you if you reproduce it in vanilla Drupal we know it's really a bug. Also just be sure you issue summary template which is linked in the description when you're creating a new issue. And lastly just some just be nice. I've seen a lot of kind of shocking attitude and language in some of these issues and I can tell you that if you're not if you're not being nice you're much less likely to be to get help so just just be nice. So these are the ways you can join us just jump into the bug smash chat in Drupal Slack you can direct message me. Anytime we have fortnightly meetings at 2pm Sydney time on Slack and then that is a link to our initiative page where you can learn more about our initiative what we've been doing how to get involved all those kinds of things. So that's it.