If you are interested in working with Plasma bugs, request an account upgrade from aseigo in #plasma. Your account can be upgraded to allow closing bugs, marking duplicates, etc.
The goal is to help the plasma developpers sort through the bug reports and figure out which need attention and which need to be closed (and closing them with some indication as to why)
One of the trickiest things is to identify duplicates. It gets easier once you get familiarized with the bug database, but in the meantime you can use bugzilla search capabilities.
For crashers, see below for how to look at a backtrace.
For non crashers, just try and repeat the steps.
For problems with individual plasmoids you can often use plasmoidviewer to run just the one plasmoid in a variety of ways (as if it were in a panel or on the desktop, with a different svg theme, etc) so that you don't have to mess too much with your plasma-desktop.
There are two methods to go with for choosing your bugs: random sample or "triage a component"
We will be ignoring wishlist items for now, as this is just about defects, not missing or requested features You can also do the "triage recent reports" where you start from the bottom of the plasma bugs list (most recent reports) and work your way up, but when we do things in groups, it's often better to either do a component or a random sampling, so make sure nobody else is working on those bugs.
Crashes are usually the highest priority and a lot of duplicates can be found there. As a rule of thumb, the more duplicates you find, the more likely you're dealing with an "real" bug, or one we can do something about (if only one person ever reported that crash, it's may not be an actionable bug report...)
For crasher bugs, you will need to look at the backtrace that needs to be provided with the bug. https://bugs.kde.org/show_bug.cgi?id=271182 is a reasonable backtrace. The section that starts with [KCrash Handler] is the one indicating where the crash happens, most often in thread 1 (as in the example).
Lines like this: #6 __libc_free (mem=0xffffffff) at malloc.c:3709 are the trace through the application. So this was the last thing that was executed before the crash. In a good backtrace, most lines will have a file name and line number like this: painting/qpaintengine_x11.cpp:256. When those line numbers are missing, the backtrace is a lot less useful and it means that the reporter does not have the debug package installed (if you need to reproduce the crash, you will need at least the debug package installed: kdelibs,kde-workspace and kdeplasma-addons, check with your distribution the exact packages).
The backtrace is read from top to bottom, until we reach kde code, noticeable because things start being called k<something> and/or plasma_<something>. In that particular case, the interesting line is #20 QPMCache::flushDetachedPixmaps (this=0x1fc0270, nt=<value optimized out>) at image/qpixmapcache.cpp:250.
To look for duplicates, at the top of the page there is a "Search Existing Reports".. open that in a new tab in your web browser then take "flushDetachedPixmaps" and paste that into the "A Comment:" field, select "plasma" from the products listing (hit 'p' from the menu list to go faster) and submit the form. It should return the following bug: https://bugs.kde.org/show_bug.cgi?id=252816. In this bug you can see that even though they had different ways to reproduce .. they look very, very similar. Bugs.kde.org will also put "This bug may be a duplicate of or related to" and "Possible duplicates by query:" links at the bottom, often saving one from manually searching. If you see such similar backtraces, check with a developer and we can confirm if its a duplicate. Eventually you'll get a feel for it. If the backtraces are essentially identical you can just mark it as a duplicate.
We have a goal that we're reaching for! to drop from #2 to #3 in this list: https://bugs.kde.org/weekly-bug-summary.cgi