[kdepim-users] open request to KDEPIM devs to address four long-standing regressions
kevin.krammer at gmx.at
Tue Oct 18 19:07:39 BST 2011
On Tuesday, 2011-10-18, pkbugs+kdepim at ssl-mail.com wrote:
> 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
> 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.
It is an unfortunate situation caused by a number of poisonous people who
willingly harmed community communications for their own short term benefits.
They not only tricked developers into paying attention, they managed to make
the developers pay dearly for it. As a result some developers learned the
lesson to not pay any attention on issues amplified in any way.
> 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.
Exactly! We should all remember to "thank" those people who gamed the system,
harming the rest of us in the process.
> 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.
Agreed, hence the need to distance ourselves from those people who think
developer time is worthless.
> 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.
While I agree that things should be fixed regradless of whether they are a
regression or not, I still need to emphasis the necessity of proper labelling
and the harm done by the lack thereof.
Just consider that by chance a KMail developer had read your list, checked the
first KMail issue and discovered after some time that it was infact not a
regression at all (that's how it looks now, still checking whether I can find
the option to switch favorite folders to icon mode).
In that unfortunate situation the result would be that the second and third
KMail issue, which are in fact regressions, would have now lost their
I hope that the rest of the thread can convince any developer reading it that
some of us actually prefer bugs being fixed over wish items being implemented.
> 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
Absolutely, making it increasingly important to push back against people
harming the community by poisoning the relationships between community
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
-------------- next part --------------
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
More information about the kdepim-users