--===============0435922996==
Content-Type: multipart/signed;
  boundary="nextPart2562720.Xo22kezii3";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2562720.Xo22kezii3
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 th=
at
> > 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 a=
nd=20
no explanation was given at all.  I've been around the community long enoug=
h=20
to know, logically, that it's not really 'don't care', but it still felt li=
ke=20
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=20
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 t=
hat=20
a kde 3 feature they used being no longer available, or being only availabl=
e=20
by some other method, that's a bug not a wish.  They will report it as a bu=
g. =20
If it's not viable, for any reason, then it has to be closed with WONTFIX o=
r=20
whatever, but a short reason should be given.  If it's a genuine missing=20
feature that will probably appear at a later date, then it has to be re-tag=
ged=20
as a wish.  Again it would probably help if a short note, such as 'working =
on=20
it', or 'to be addressed' where it's not possible to guess time-scale, were=
=20
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=20
strategies, and frankly we are short on those at the moment.

> So, would "WONTIMPLEMENT" help?=20

Not really.  We could sub-divide them by the kind of reason, but that just=
=20
makes extra work.  Probably we have to keep WONTFIX, but ensure that we alw=
ays=20
give a reason.  If the reporter argues, the developer should read it - if i=
t=20
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 kd=
e3-
missing-features are being reported as bugs.  If they were clearly separate=
d=20
out, then bug-squashing and feature-developing are more clearly divided as=
=20
well.  I would have thought that getting this more accurate would be a help=
 to=20
developers, rather than a hindrance.  The only snag I see is man-power, but=
 a=20
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 e=
ach=20
other as they used to be, and when you throw in the anonymity of the net, y=
ou=20
can say anything without ever being really held to account.  You can simply=
=20
cease to exist and start again as a new persona when the going gets too hot=
=2E =20
This is not going to change, so again, we have to develop strategies for=20
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 ne=
ver=20
doing anything that isn't entirely for yourself.  We do tend to do things f=
or=20
others when life is treating us better, not when we're feeling scourged, so=
=20
again, we come back to long-term strategies for preserving a good environme=
nt.

> > > (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 f=
or
> > > 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=20
stop people voicing their annoyances, though, so we have to live with that.=
 =20
All we can do is make sure that we make the best use of bugzilla, then we c=
an=20
simply point complainers to that.  At the moment, for many reasons, some of=
=20
which I've mentioned, I don't think bugzilla is doing the best it could for=
=20
either users or developers.

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

--nextPart2562720.Xo22kezii3
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEABECAAYFAkp5GYoACgkQbMErw/n0TZqZ0ACfc2V55C+BwDzaF1PR1qIDp60B
e8IAn12OW3/GL0p+VsjfLKHGaJ80fa1N
=ba6m
-----END PGP SIGNATURE-----

--nextPart2562720.Xo22kezii3--

--===============0435922996==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0435922996==--