Choosing Krita's most annoying bugs and most sought after features

[Sven Langkamp]

On Thu, Aug 16, 2012 at 6:38 PM, JL VT <pentalis at gmail.com> wrote:

> I have a proposal:
> --Let's ask our users for their most hated bugs, or most wanted features,
> in Krita.
> --If they are grouped in something large, which could be turned into a
> project instead of a set of bug fixes, then let's give shape to that
> project.
> --Let's propose it.
> --People vote on it.
> --I will do it.
>
> Let me elaborate a bit further. I want to find an efficient way to
> prioritize what to work on, for an extended period of time.
> Slangkamp has his own vision for bug priority:
> <slangkamp> Pentalis: priority should be data loss->crash->regressions
> ->often report things->normal bugs->minor bugs
> <slangkamp> at least that's how I see it
>
> My own POV answer:
> <Pentalis> well, it depends, we all hate crashes, but a crash that happens
> once a week is less annoying than a feature that doesn't work properly and
> you use it every 5 minutes
>

"Happens once per week" is a very uncertain measurement. It really depends
on the workflow and the system that the user is running. If you look at the
reported crashes most appear very regularly (just not on my system).

If a crash is valid, then it should have high priority. After all crashes
are pratically data loss.

I want to resurrect my blog on Krita, update it weekly, and make buzz about
> new exciting features or new equally exciting bugfixes. What makes a bugfix
> exciting?, when it kills bugs you really hate; same with features, they're
> exciting when you really wanted them.
>
> So I need YOU, dear Krita user, to help us find these most sought after
> features and most hated bugs. Give us your own list of horrors and dreamed
> features, explain those you think merit explaining (specially new
> features), and give us your insight on what more efficient way we can use
> to determine which improvements rank as the most needed for our application.
>
> I'll be giving a face-lift to my blog on the meanwhile.
>

We don't really need that. First of all users don't really vote much. Only
a very small fraction actually uses that feature, so it's never
representative. Beside that the usual user has a very narrow view, so they
vote for their bugs but barely any other bugs. Just going by the amout of
duplicates would be a much easier measurement without the need for votes.

Finally we already know the winner: Grayscale selection. Apart from any
votes in Bugzilla, that feature has been requested a lot in the forum or on
irc. Before that is solved, there is almost no need to ask users to do more
votes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120817/13f44acf/attachment.html>