[Development] [QtMultimedia] Still is supported, active?

[Prav]

Hello, Everyone.

> Bugs are fixed when they are fixed. You won't get any estimate before the
> developer actually starts fixing the issue. And even then, it may take months
> or more until it actually gets fixed.

Agree but devil is in details. Currently there is a practice to not fill-out necessary fields for the bugs and not to change its status.
I exactly mean
* Not changing from Reported to Opened (or Need Info or Closed) ... like it is with discussed QTBUG-53019 (1/2 year old)
* Not assigning responsible person in Assignee field like it is for ex. with QTBUG-46812 (1 year old)
* Not assigning Fix Version/s ... which can mean there is no plans for the bug.
     No plans can be because of 3 reasons:
        I do not care and going to silently ignore the bug
          OR
        I agree with the bug but have so many bugs to fix already so that this is to far from my 1 month plan (or 3 month plan or 1 year plan ... nobody knows what plan is meant)
          OR
        I except the bug but do not want to bother myself with filling this field about my plans


Having these details like this make such letters from time to time appear in mailing list. This is natural and is predictable result.

So while I agree that angriness is not helpful for mail list ... messages like this are probably the seed to rethink strategy of working with bugs.

This is probably means that we need some easy to use query in bug-tracker system which can show up "unprocessed bugs" ... which is bugs with
  state Reported
OR
  no Assignee
OR
  no Fix version
With sorting from oldest creation date to newest.

All unprocessed bugs make people float in unconditional state like
 floating 1: was the bug accepted or not (state is still Reported)
 floating 2: does anyone (mighty to fix it) knows about it (Assignee filed is empty)
 floating 3: how long approximately to wait for fix ... month, 3 months, year, 10 years (Fix Version blank)

This unconditional state make people do what they do. For example angry letter can be easy the result of "floating 1".
May be my request need more buzz so that it will be processed.

If Yoann Lopes will fill the bugs fields why in the world would Denis Shienkov ever wrote this letter. Never.
Because attitude to the bug will be clear to him.
And Denis can only live with this (like trying to fix himself, or hire someone or stick to Qt 5.5.1 forever or whatever else)

I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable not in sense of not-fixing the bug but
in sense of not filling bug's fields ... Those fields are in the bug-tracker system FOR A REASON and it is
MORE THAN IMPORTANT for reporter to see them filled.


So I am trying to say that there is tendency for qt-devs maintainers to ignore value of described fields for reporters of bugs and
angry letter is predictable result of this tendency.

Instead of trying to shut up the Denis we better discuss current situation with bug-tracker and decide to make some clear for everyone tools
which can show up forgotten bugs (described idea of unprocessed bug query) which makes people write angry.


And I totally agree that "Bugs are fixed when they are fixed". And agree that maintainers need to respect Best Practices of working with bug-tracking ALSO
(which exactly mean filling out ALL these 3 fields ... they ALL are important).


>> Otherwise there is an impression that I talk there to myself or to a blank wall.
You see. He is telling that he feels unheard... he see no reaction ... and he start making buzz in mailing list. Very predictable.
But why this reaction should be exactly in fixing the bug? It can be enough to fill the bug's fields I think.
Maintainers also have limited working-time.



So what I propose IMHO seems to be a good balance for maintainers and bug-reporters.



So I have 3 questions in my mind about this:

Can we discuss this theme (about bug-tracker system) with some practical things which can be improved from ballancing perspectives of view to tracking of bugs?

Can Qt Product Managers arise the importance of Best Practices of working with bugs-tracker for developers?

Can someone create this query inside bug-tracker system and share it with everyone so that unprocessed bugs can be shown?