Plasma Bug Workflow BOF

[Myriam Schweingruber]

Hi Thijs,

On Fri, Jun 22, 2012 at 10:22 AM, Thijs Heus
<thijs22nospam at googlemail.com> wrote:
> Hi Martin,
>
...
> My personal opinion, which counts for nothing: BKO can only work with less
> than 50 bugs or so per component. So be rigurous. BKO can only work as a
> developers tool if the developers want to use it, if they can have
> developers discussions within the report (like KWin does, or telepathy). The
> difference is that Plasma got almost 1400 bug reports in the past half year
> more than 10% of all of KDE, not even counting the bugs that ended up being
> redirected to nepomuk, kwin, solid, etc. Currently there are ~800 bugs open,
> my guess would be about 500 real bugs in a current version. That makes a bug
> overturn time of only 2 or 3 months.
> These are impressive numbers, and they show that Plasma is doing OK in
> beating the bugs, even though plasma may not yet be doing OK in beating BKO.
> So should we really keep minor bugs that will never be fixed unless as
> colleteral damage open? Crashes of over a year old, without any duplicate
> since? I am not saying that these are no bugs, just that they are not
> helpful reports (anymore), and thus pollute the database. For a highly
> visible project like plasma, the amount of eyeballs is so high that an
> accidentally closed bug will be reported again. Currently, this is working
> against us, but we could make it work a bit more in our favor if we want
> to.

I agree with most of your points here, but what we really should avoid
is closing reports without any comments, that should never happen, and
sadly it did in the past and that is something that only causes anger
from the bug reporters

As for the current bugs it is crucial that all incoming reports are
triaged ASAP. We can hold a bugsprint to tackle the remaining
duplicates and close old ones, but what counts are the bugs that are
reported now. If we continue to ignore those the b.k.o situation will
not improve.

I have in mind an initiative similar to what Ubuntu does with their
"Five a day": https://wiki.ubuntu.com/5-A-Day

While we all would like to have the complete triaging process taken
away from the developers we currently are quite far from that and even
if it is not something a dev. likes to do I think with a common effort
it should be doable. What saddens me is that I hear from plasma
developers that they don't have time and are not willing to ever
actually triage bugs, and that is exactly the attitude that lead us to
the situation with close to 2000 (not 1400, the figure was much, much
worse) open and untriaged reports. And I don't even talk about the
wishes which is a completely different matter.

What needs to be understood is that all code can have bugs, that is
only natural and nobody will deny that. But that also means that we
should thrive to make the code better, and IMHO to some extend a
developer should feel responsible for the code s/he commits and also
take care of the bugs that are found.

While I understand that nobody likes pressure it should also be
understood the perception from the other side: developers not even
looking at bugs in their own code are perceived as arrogant and
uncooperative. With the current situation the politics of putting the
head in the ground or just walking away with the "I don't have time"
wave is not going to help, so efforts need to be done on all sides.

Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)