[kdepim-users] open request to KDEPIM devs to address four long-standing regressions

[pkbugs+kdepim at ssl-mail.com]

Alan,

On Monday, October 17, 2011 10:27 PM, "Alan McKinnon"
<alan.mckinnon at gmail.com> wrote:
> I think what Anne was getting at is that there's a trick to getting a
> developer's attention, and she described the general case. Your case if
> specific to you of course so you'll have to adapt your communication to
> fit.
> 
> The thing to concentrate on is not so much the detail, but rather on
> how to avoid have your bug report be perceived as yet more of the dross
> in people's inbox.
> 
> It's a perception thing I guess - get inside a typical dev's head and
> supply the info in the style they expect to receive it.

To be very clear, I have absolutely no issues with Anne's comments. 
They're her comments, and her opinions, and they're welcome to at least
this discussion which I started.  It's problematic only when the
disucssion isn't being had -- which really is the crux of the matter
here.

The conversation needs to be two-way.  It should be frustrating to one
and all that a 'trick to getting a developer's attention' is a
requirement; especially,as I suspect, it's in fact the case.

Users don't read minds, at least mine don't.  Without an engaged,
professional developer IN the conversation, asking for info, providing
guidance and explaining to users in user-speak what they 'expect' (and
need), there's ZERO chance that engaged, professional users are going to
continue to take the time and make the effort to contribute to the
solution either.

The frequent 'I do this for free', 'do it yourslef', and 'show me the
code' mantras are lame.  We *all* do *this* for free -- devs and users
alike.  It's a community.  The strong community, and the robust product,
simply do not exist without BOTH in place and doing their best to make
their contributions.

I've absolutely no investment whatsover in 'my' particular approach to
anything.  If there's a "better way", great. Let's GET there.

My interest in a solution is clearly mercenary.   Point is, there's
clearly a problem -- "stuff" (regression or not doesn't really matter)
is sitting around, and not getting fixed.  And it's costing time, money,
and user adoption.  All of which are resources that could be better
utilized contributing TO the community/product, rather than wasted
finding solutions around it.  From my perspective, that's ALL that
matters.

So, I've started with "just four" frequent issues (I've not yet raised
my personal favorite, the frequent crashing of KDE on plasma-desktop
exit -- I'm waiting to see how many 'duplicates' get added ...).

>From that purely mercenary viewpoint, fixing those four bugs would solve
a costly problem for me, and I strongly suspect for quite a few others.

Otoh, addressing the issue of how we get to these messy places in the
first place, and getting better about the process would be of much
greater benefit to everyone concerned -- users and devs alike.

I know how to fix these issues when it's my organization.  How it's done
here, when STILL we don't know even who the relevant devs are for these
issues ... I really have no magic elixir.

Pat
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users