[RFC] Moving Wishlist Items to Brainstorm

Oliver Henshaw oliver.henshaw at gmail.com
Mon May 27 15:20:10 UTC 2013


On 25 May 2013 07:58, Martin Graesslin <mgraesslin at kde.org> wrote:
> Hi all,
>
> based on yesterdays discussion with Aaron about the bugtracker I want to
> provide a few suggestions on how we can start to clean up the bugtracker and
> get it into a workable state again.
>
> My first suggestion is to move from now on all "wishes" to
> brainstorm.forum.kde.org. Bugzilla is quite unsuited for feature requests as
> we don't have any way to figure out whether the feature is just a one users
> dream concert or a valid need. Brainstorm allows to filter out the bad
> requests. The only indication we have is the voting feature and that is well
> not very useful.
>
> For KWin I use the following template when we get a new feature request:
>> Thank you for your feature suggestion. Unfortunately bugzilla is not the
>> best place to discuss feature requests. We hardly have any users here, so we
>> don't get an evaluation whether the feature is needed.
>>
>> We therefore recommend to use http://brainstorm.forum.kde.org to suggest
>> this idea. Users are able to up/down-vote the feature request and by that we
>> get an idea whether it's something our users wish to see and whether it is
>> worth to invest time into it.
>>
>> If the feature request is supported on brainstorm it will automatically be
>> recreated here in the bug tracker. Given that I'm marking this feature
>> request as WONTFIX for now. This has nothing to do with whether we think
>> this is a good or bad feature request.
>>
>> I'm very sorry that our software does not allow to send users to brainstorm
>> in the first place.
>
> This is something easily doable from now on.
>
> Now the more difficult topic as it involves the existing database: closing all
> existing wishlist items. In my opinion if we agree on using brainstorm the
> logical consequence is to close also all existing feature requests. That's
> again something I did for KWin just with a difference. For KWin we were able to
> look at each feature request and give a reason on why the feature request
> doesn't make sense.
>
> I had a look at whether Plasma devs use the wishlist reports. So here are some
> stats:
> * 1137 open reports
> * 123 reports were not touched over the last four years
> * 385 reports were not touched over the last three years
> * 591 reports were not touched over the last two years
> * 22 reports got fixed over the last year
> * 6 reports got fixed by a commit over the last year
>
> Given that I think we can safely assume that having those wishlist items is
> not useful. The question I cannot answer is whether to automatically close all
> reports or just those not touched for n years? This is something the Plasma
> devs have to tell me whether they think there is anything useful in the still
> open reports.
>
> Things to agree on:
> 1. Send users to brainstorm when creating a wishlist item from now on
> 2. Close existing wishlist items
> 2a) how many items to close
>
> If we agree on 2 I will prepare a message, but will need a native speaker to
> cross-read it. And we need sysadmins to do the closing otherwise they will be
> unhappy because we kill the mail server ;-)
>
> Cheers
> Martin

I'd be quite content for the "widget-battery" and "screensaver
overlay" components to continue to receive wishlist reports. In some
cases they're appropriate to the plasma component, in others they
should be moved to a related non-plasma product.

Also there aren't a huge number of them to deal with. That said, I'm
aware that the triaging of widget-battery bugs is not as good as it
should be (and that powerdevil bugs need more effort from me to
complete the stalled process of bringing them under control). And that
all screensaver-related components need a serious effort to clean up
outdated bugs and concentrate down on the components that are still
relevant.

Powerdevil/battery-monitor triaging was discussed at the Solid sprint
earlier this year. And I have some idea of how to approach the
screenlocker effort. I plan to start on this (and post my screenlocker
cleanup proposal) once the various 4.11 related freezes have finished
flying by.


More information about the Plasma-devel mailing list