[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE4: missing features from KDE3
From:       Anne Wilson <cannewilson () googlemail ! com>
Date:       2009-08-05 5:32:58
Message-ID: 200908050632.58891.cannewilson () googlemail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 04 August 2009 21:21:56 Andreas Pakulat wrote:
> On 04.08.09 20:23:46, Anne Wilson wrote:
> > On Tuesday 04 August 2009 19:00:09 Aaron J. Seigo wrote:
> > > On Tuesday 04 August 2009, Anne Wilson wrote:
> > > > WONTFIX is a major annoyance.
> > >
> > > it's also part of reality. not every thing can be or should be
> > > implemented.
> >
> > I never said it would.  Like it or not, WONTFIX gives the impression that
> > you don't care.
>
> Well, if a wish is closed as wontfix, without an explanation why, thats
> clearly not acceptable. However, if closing something as wontfix and
> providing a suitable explanation, I can't see how anyone can think the
> developer doesn't care.
>
Agreed, but of all the bugs I've reported I've only had one close WONTFIX and 
no explanation was given at all.  I've been around the community long enough 
to know, logically, that it's not really 'don't care', but it still felt like 
it.  I would have accepted any explanation without question.

> > That should never be.
>
> Assuming you mean the "developer doesn't care" part, then yes I fully
> agree.
>
Actually, I meant that the user should never be left with that belief, but the 
effect is the same.

> > There must be a better way of tagging
> > things.  In many cases we probably need a tag that conveys the meaning
> > that it would break other things.  Something on the lines of
> > SystemBreaker.  In other cases just changing the tag to Wish should be
> > sufficient.
>
> Well, we're talking about feature requests, which are already tagged as
> wish. So closing it as wish won't really help here I think.
>
Actually, I was thinking of certain very annoying users who take the view that 
a kde 3 feature they used being no longer available, or being only available 
by some other method, that's a bug not a wish.  They will report it as a bug.  
If it's not viable, for any reason, then it has to be closed with WONTFIX or 
whatever, but a short reason should be given.  If it's a genuine missing 
feature that will probably appear at a later date, then it has to be re-tagged 
as a wish.  Again it would probably help if a short note, such as 'working on 
it', or 'to be addressed' where it's not possible to guess time-scale, were 
appended.

> > Sorry, but that's life.  If explanation has been given they should be
> > ignored.
>
> Yeah, thats the theory. Unfortunately reality sometimes looks a bit
> different :(
>
I do know :-)  I'm often on the receiving end, but we need survival 
strategies, and frankly we are short on those at the moment.

> So, would "WONTIMPLEMENT" help? 

Not really.  We could sub-divide them by the kind of reason, but that just 
makes extra work.  Probably we have to keep WONTFIX, but ensure that we always 
give a reason.  If the reporter argues, the developer should read it - if it 
makes a valid point, answer, otherwise ignore it.  His job has been done.

> As Aaron already said, bugzilla isn't
> quite the right tool to do feature requests anyway. The fact that a
> feature request is nothing but an ordinary bugreport with the lowest
> severity possible already indicates that.
>
It doesn't have to be, though, does it?  At the moment so many wishes or kde3-
missing-features are being reported as bugs.  If they were clearly separated 
out, then bug-squashing and feature-developing are more clearly divided as 
well.  I would have thought that getting this more accurate would be a help to 
developers, rather than a hindrance.  The only snag I see is man-power, but a 
determined effort at a pre-agreed time to deal with backlog could help.

> I think this is also a social problem, people are getting used to be
> able to shout, rant and moan on the net without ever being held
> responsible for the possible damage they do with that.
>
I totally agree.  In general terms people no longer are as considerate of each 
other as they used to be, and when you throw in the anonymity of the net, you 
can say anything without ever being really held to account.  You can simply 
cease to exist and start again as a new persona when the going gets too hot.  
This is not going to change, so again, we have to develop strategies for 
coping.

> There's a difference between seeing some feature as "actually useful"
> and the motivation to work on it because one wants to actually use it.
> For example, I totally understand why the above mentioned feature is
> useful, but I don't have the slightest motivation to work on it myself,
> because the only thing I use the menu for sending the machine into
> suspend.
>
This I can understand.  However, I'm sure that you don't go through life never 
doing anything that isn't entirely for yourself.  We do tend to do things for 
others when life is treating us better, not when we're feeling scourged, so 
again, we come back to long-term strategies for preserving a good environment.

> > > (answer:
> > > completely destroyed for 4.3 by the rudeness of the only response i
> > > received back from saying "yes, this needs to be done. won't be the for
> > > 4.3 though.")
> >
> > One comment?  Come on!  We all get rude comments from time to time.
>
> Well, some of us get them on a more regular basis, especially projects
> that are exposed to such a _huge_ user base as plasma. I'm personally
> thankful that KDevelop is not exposed to such a large amount of users.
>
Understood.

> > > > Unkind and unrealistic.  Without bug/wish reports how do you know
> > > > what features people value?
> > >
> > > i'm just fine with reports. i don't like it being scattered in N
> > > different places (wiki lists, blog entries, etc )
> >
> > It's called Free Speech.  You (and I) don't have to agree.
>
> The problem is, if its scattered around N places, the chances are good
> that no developer ever see's it (or see's it and then forgets where he
> saw it) and afterwards the users start complaining about developers not
> caring about their needs. And they rightfully point at a random blog
> post where they've formulated they needs.
>
> Face it, if people want a feature implemented in "my application"
> (speaking as a KDE developer) there is exactly 1 channel to make sure I
> see that request and am able to remember it in 6 months when it reaches
> the top of my todo list: bugs.kde.org.
>
I have no problem with that, and I often tell people so.  You're not going to 
stop people voicing their annoyances, though, so we have to live with that.  
All we can do is make sure that we make the best use of bugzilla, then we can 
simply point complainers to that.  At the moment, for many reasons, some of 
which I've mentioned, I don't think bugzilla is doing the best it could for 
either users or developers.

Anne
-- 
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature?  Add it to UserBase

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]