Issues with the issue tracking system
mgraesslin at kde.org
Mon Nov 4 08:05:30 GMT 2019
Am 2019-11-04 02:11, schrieb Philippe Cloutier:
> Dear community,
> I am facing 2 issues with the ITS which I cannot solve myself
> Over the last months, I requested the "severity" (importance) of
> several tickets to be adjusted:
> No adjustment was done yet. Please either:
> 1. Solve https://bugs.kde.org/show_bug.cgi?id=272388
> 2. Allow more developers to modify the field
> 3. Or perform the requested changes
I just looked through some of the bug reports and I think there is a
general misunderstanding about bugs. Let me first introduce myself: I
used to be KWin maintainer and managed all incoming bug reports for
KWin. KWin is one of the products in bugs.kde.org getting most new
reports - about 600 reports just last year.
While it would be awesome to fix all issues, that is just impossible. We
are a community of mostly volunteer developers and don't have the time
to fix all issues, especially not in a timely manner. Some bug reports
while seeming a minor issue on first glance are a big issue and require
years of planning and work. In my development it happened quite
regularly that after years the code base had moved in a way to resolve
10+ year open bug reports.
What I did not like at all when managing the bugs, was:
* adding comments "still not fixed in 5.12.3" as that adds useless
noise. If it's fixed we mark it as fixed, otherwise it's not fixed.
That's the state of the bug.
* users changing severity.
The severity is a field important to developers. We decide how important
an issue is. Of course the issue is important to the affected users,
otherwise they would not have reported the issue. We are quite aware
that an issue is important, is affecting users and is problematic to
workflows. Changing the severity doesn't indicate this. Every user
thinks his issue is critical. If users are allowed to change the
severity it would end in every bug report being critical. It becomes a
nagging feature which is working against the community.
In KWin I used the severity field to decide what gets fixed. E.g.
critical in KWin has the meaning "system freeze". A critical bug has
highest importance. It's the issue which has to be resolved before any
other work. It's the issue which once fixed results in an emergency
release. I hope you understand that if a user reported a bug as critical
I immediately changed back the severity to "normal" - which is what it
is in most cases.
Overall my suggestion is to not nag in bug reports. At least in my
involvement nagging and demanding in bug reports always had the opposite
effect. If I have n bugs to fix and time to fix m bugs and n is
significantly larger than m, I chose the subset m which gives me in
volunteer working most pleasure.
As bad as it sounds: the best way to get bugs fixed is to get involved.
More information about the kde-community