Hello openSUSE! one of the items raised on the retrospective* was a large number of open bugs, not just for openSUSE Leap 15.2 but for openSUSE Distribution in general. Tracked as https://progress.opensuse.org/issues/70000 . I already had a discussion with Oliver and Antonis on this topic on the Quality Assurance event that took place last Friday in Schweig. I'd like to share with you the idea of a regular "Bug smashing" meetings. (I'd call those "Bug triaging", those meeting will not get bug fixed but just allow to triage them properly, if I understand correctly) These https://meet.opensuse.org meetings would focus on outstanding bugs and respective "problematic components" (e.g. Other or Base system). We'd focus on one Bugzilla component at a time and would go through the results of pre-agreed queries. It could be multiple short (20 mins) sessions per week E.g. "Base system" Bug smashing etc. I don't mind low attendance but having an option to join and raise particular issue is very important to me. Keep in mind that the openSUSE Release Team is supposed to do this "overseeing" anyway. But I think we can be a bit more transparent about it. The idea is that I'd share screen go through the list of bugs, find an agreement on the next steps, and then the person sharing the screen (typically Release Team member) would write an update to the bug. This would then be followed by sending a notification to the bug owner or finding a new bug owner in case of no response. The public and virtual nature of sessions would enable people to join and raise attention to the bug that might be not getting enough attention. The goal should be on processing bugs in a way that we're able to achieve a decent response time and not cause a potential decrease in quality or close bugs that might potentially lead to a data loss. We're not doing this for the sake of better-looking statistics, but to have a more stable distribution. The pre-requisite for this is an agreed policy about how to tackle bugs properly. So we're helping instead of causing harm. The policy should provide answers to the following questions: What is expected to be tracked in Bugzilla and where to track other requests. E.g. the Documentation component is a bit controversial as it contains various types of requests. Criteria for keeping bugs open or closing them. (aka cleanup that helps). E.g. the definition of CLOSED/Insufficient data, do not close issues that lead to data loss. Agreement about setting the priority on issues, who is expected to do so, and what it means to the bug owner be it SUSE Employee or not. There are two ways how to see priority. How much of an issue is it for Given release (e.g. release can't be shipped with open P1 or P0) and how big of a priority is it to the bug owner. We need to find an agreement. Agreement about ownership of bugs. How does the screening team fit in and so on ... Agreement how to track 'seen' bugs P5 vs Confirmed etc. Agreement on who handles regular processing of bugs for what product(s) and what releases/versions. The last one is important as there seems to be a big difference in overseeing issues for the current release and releases in the maintenance phase. Who should oversee maintenance updates is still an open topic at least for SLE. I'd like to find an agreement with the openSUSE Maintenance team and join forces to be more efficient at pre- agreed bug processing. **Let's use https://etherpad.opensuse.org/p/ReleaseEngineering-bug-smashing-ideas-202008... for a brainstorm and revisit document on next the next Release Engineering meeting* on the Wednesday 19th Aug**. More info and meeting details are in the brainstorm document. [0] https://en.opensuse.org/Portal:15.2/Retrospective Best regards openSUSE Release team