Re: KDE PIM marketing

Jos Poortvliet <[email protected]>
Newsgroups gmane.comp.kde.events
Organization openSUSE
Message-ID <1422109.TDxWodABqP@jostibak>
On Tuesday, February 21, 2012 16:05:25 Carl Symons wrote:
> On Mon, Feb 20, 2012 at 4:47 AM, Stuart Jarvis <[email protected]> wrote:
> > Hey,
> > 
> > On Sun, Feb 19, 2012 at 9:31 PM, Jos Poortvliet <[email protected]> wrote:
> >> As you might have read in the dot story, the KDE PIM team has discussed
> >> marketing at the Osnabrück meeting.
> >> 
> >> A few of the results are relevant for -promo so I promised to mail you
> >> ;-)
> >> 
> >> Please see
> >> http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_10 under the
> >> marketing
> >> header.
> >> 
> >> In short, KDE PIM 4.7 was the first real release of the 'new' KDE PIM
> >> since
> >> the KDE 3 times. It took a long time to get it out, indeed longer than
> >> expected. The stop-gap measures were not exactly great and resulted in
> >> many
> >> complaints. Meanwhile, the marketing team tried to keep the spirit up -
> >> being a tad too positive, perhaps... The result was that the 4.7
> >> release, which would have needed some patience and understanding,
> >> instead resulted in many people giving up on KDE PIM.
> > 
> > Well we communicated what the kdepim peeps told us to communicate, my
> > kde pim was somewhat broken at the time so I couldn't draw any of my
> > own (positive) conclusions ;-)
> 
> Full disclosure...I never stopped using KDE PIM. Worked through what
> it took to get it going. And really like the way it works now.
> 
> In the beginning, I understood that it was not the final product and
> that there might be issues. We also had a culture--similar to
> Slashdot--where people seem to relate to snark as the highest form of
> humor. In my view, this contributed (contributes) to the impression
> that things are badly broken.
> 
> >> That is sad, as in the 6 months after that release, a HUGE number of
> >> issues
> >> has been fixed. The KDE PIM team now actually needs quality bug reports -
> >> but is unfortunately flooded with lots of complaints. What needs to
> >> happen is that we need our KDE Community to start using and testing KDE
> >> PIM again; AND we need help bug triaging.
> >> 
> >> Last but not least, we need to change our communication, make clear that
> >> 4.7 was our FIRST release and the hurt of the huge re-factoring is
> >> behind us: it's upwards from now on.
> 
> We have what we have _now_. Not sure we can do retrospective damage
> control. I just looked for what we've written before. I agree with Stu
> and then some. We didn't generate anything...we edited what we were
> given. But in what I can find, there's not a lot of hype. It's more
> like only part of the story was being told.
> 
> But then people were given the opportunity to "upgrade" to KMail2 and
> it was messy. I found a set of explicit instructions for Kubuntu. I
> followed them exactly and everything worked right (except one thing
> that I had to research about some resource not being available.
> Changed the location of that resource and success).
> 
> I think that it would be a mistake to say that 4.7 was our FIRST
> release. It feels a little like rewriting history. Why don't we just
> say what happened? A decision was made by smart, caring people to move
> from KMail to KMail2, because ____________. It was ambitious and hard,
> but it eventually would have been required. We tried to keep
> everything running okay, but that didn't work for some people. In
> retrospect, there was a lot of learning. We apologize.

It feels like rewriting history, but it IS the truth. That is the problem here 
- the first release of the KDE PIM stack which was properly Akonadi based was 
4.7.0 - and admittedly it had some issues, but (almost) nothing that didn't 
get fixed in the subsequent 6 months. In 4.8 it's quite stable for the 
majority of users, something the KDE PIM team notices as they see an influx of 
new users in their pim user mailing list who are quite happy with it all.

And look at what was fixed for 4.8.1 - I think it might be worth hanging up 
the story on that...

The stuff delivered between 4.0 and 4.4 (with 4.5 and 4.6 being based on 4.4) 
was a rather horribly hybrid which always broke *something* in each release. 
It was a kludge needed to bridge the gap (which turned out to be far longer 
than the team had expected) but NOT what was meant to be the 'new KDE PIM'. I 
really think we lost the majority of our users due to that. Yes, 4.7.0 was not 
perfect, but as a first release, and with most issues fixed in the bugfix 
releases after that, it was not that horrible. You have to release at some 
point...

> Write something similar to words in the sprint story about needing to
> clean house and concentrate on the current system. We understand that
> people might be turned off, but [insert Jos sermon about the nature of
> open source, goodness and light].
> 
> I agree with what Anne has written in another message in this thread.
> The thing that saved me was that explicit Kubuntu page. Good, explicit
> instructions written for everyday users of email, not assuming
> advanced fix-it knowledge. A special topic in forum.kde.org that is
> tracked by KDE PIM experts who can provide quick help.

Yes, communication can improve. Part of the problem there is, again, 
information overload - the devs are flooded with complaints. Which makes 
sense, email is crucial to people's day to day operation. But release early-
release often is crucial to our development process. 

> >> The plan is:
> >> 1. We should stop pushing technical terms like "Akonadi" and "Nepomuk" to
> >> users. Work has already been put in to eradicate those terms from the UI
> >> but we need to do the same in our communication. These terms have not
> >> only gotten a very bad rep but are confusing too. Lets keep it simple:
> >> we have the KDE PIM UI's like Kontact Mail and Kontact Address book and
> >> the KDE PIM backend.
> The terms are unnecessary. However what they do is amazing. The KDE
> PIM people should know what the amazing stuff is, and that's what we
> should talk about.
> 
> Example: Zanshin...alt-F2 "todo: [whatever]" and it shows up in
> Zanshin (a quick, simple, useful todo manager from ervin, et al), even
> though Zanshin isn't open. Oh look, it's also in my Kontact todo list.
> 
> This is just one thing I've found. There must be others.

Yup. Will ask them...

> > Ok. But if we are going to do news about KDE PIM that doesn't use the
> > backend buzzwords then we need some actual new visible features to
> > talk about :-) Will there be some?
> 
> +1
> 
> What should we talk about? Why should people use KDE PIM instead of
> Thunderbird or other app?
> 
> >> 2. We need to communicate that KDE PIM has finally started fresh and is
> >> ready for testing; and needs help bug triaging!
> > 
> > Sounds similar to the story for 4.7 - 'this is the start of something
> > great'. Don't get me wrong, I believe it is, but I don't think making
> > the same points again - particularly if there are still a lot of bugs
> > to be triaged - will necessarily give us the desired results. We need
> > some specifics about how good/bad things are, such as, for those who
> > didn't switch yet, does automatic migration to KMail 2 work now,
> > fairly often?
> 
> I agree with Stu here. "finally started fresh" sounds weak. What's the
> real story?

The stuff below :D

> >> 3. And we need to tell the big story, the how and what of what we did.
> >> For
> >> that, see the graphic here:
> >> http://dl.dropbox.com/u/29347181/KDE%20PIM.svg
> >> http://dl.dropbox.com/u/29347181/KDE%20PIM%20big.png
> >> http://dl.dropbox.com/u/29347181/KDE%20PIM_small.png
> > 
> > Ok, those are fairly cool. We'll probably still need some kind of
> > name/description for the blobs though, even if we don't use 'Akonadi'.
> > Also details on why the right hand side figure is better than the one
> > on the left would be good.
> > 
> >> The plan is:
> >> 1. Change the wiki pages to reflect 1 (done)
> >> 2. Let you guys & girls know (hereby done)
> >> 3. find a good time to do a big 'call for help' for 2 and do it
> >> 4. write articles to address myths around KDE PIM (eg about memory usage,
> >> speed, stability, mail loss etc)
> > 
> > Point 3 needs very careful timing - there might be a chance to get
> > people back, but getting them back and giving them a bad experience
> > will only keep them away longer.
> > 
> > Point 4 would also be useful, particularly if some advantages of the
> > changes can be demonstrated at this point. From my personal
> > experience, they are not apparent yet, but I do believe they will
> > come. People will try the software and they need to experience the
> > good things we write about.
> > 
> > Cheers,
> > Stu
> 
> There are probably myths as you describe, but there were also comments
> and specific complaints that were real and damaging to people's email
> systems. For many people--especially who rely on email--there was a
> breach of trust. We're gonna have to earn that back...Anne has good
> suggestions. I'd add that there should be some intensive testing of
> the migration and the migration instructions.
> 
> I also think that we are missing a bet by not including Kolab stuff. I
> don't know diddly about it, but I hear from small businesses that
> groupware is an important capability. And that's what they do.
> 
> I'm definitely up for doing something. Kontact and its parts are
> useful (essential) to my daily work.
> 
> Carl

Thanks all for the feedback.

I will try to draft an article up based on what's out there, your feedback and 
input from the KDE PIM developers.

Thanks!


_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.
signature.asc (application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEABECAAYFAk9U6gcACgkQ+wgQ1AD35ix/IwCfcW4GBpQUqSCBsu1CZVF0A9qo
PJoAn1fdnbmk2wfAJbeQBIUPKzAxzRgD
=Dueq
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.