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

List:       kde-promo
Subject:    Re: Yet unannounced Plasma TV UI project
From:       "Eike Hein" <hein () kde ! org>
Date:       2020-03-23 15:51:45
Message-ID: e38f7ee9950fff52f6c3f5a0581092fe () kde ! org
[Download RAW message or body]

Hi,

> as the product itself is not ready for release

I would agree.

Just from a cursory look:
* The proposed Plasma Bigscreen website links to a not-KDE company bug tracker for \
issue tracking and not-KDE forums.

* It's not clear to me where this website is hosted and whether it's been aligned \
with KDE's WWW team, who have worked hard in recent months to make our websites more \
consistent. Collaboration would I think be welcome there, especially for a satellite \
project to an existing community brand (Plasma).

* From a product marketing POV, I'm surprised at the proposed announcement text \
calling out "Plasma Nano" as the thing for embedded Plasma development. I'm not aware \
of a conversation where it was established that Plasma needs a sub-brand for embedded \
(brand != code bits; saying you need something called Plasma Nano for embedded makes \
Plasma un-embedded). It invites questions I don't see prep for - Plasma Nano has no \
website or FAQ anywhere.

* Between the website and the announcement, there's a concept of "Bigscreen Apps" \
enabled by a distinct API set from Plasma's APIs (the Mycroft APIs). This also has \
implications and begs questions - is the Plasma API set (we've used terms like \
"mini-apps" for Plasma widgets before) insufficient for this use case? Why? This may \
have pragmatic answers related to integrating two technologies, but those answers \
need to be written out or they dilute messaging around the Plasma brand  

* On the Telemetry/Privacy front it's a similar story of "at the very least, have the \
answers ready". We have other projects that depend on Google APIs (e.g. kio-gdrive), \
but they need less careful communication as they're inherently tied to Google \
products/brands. With something like the Bigscreen case it needs a message how this \
related to the Telemetry policy and what mitigations are there (e.g. an architecture \
not tied to those APIs and allowing for other backends).

This all feels a bit hodge-podge and very rushed. My suggestion would be that instead \
of taking the project to the public under the KDE mantle as very first step, this \
needs a starter period of being introduced to the KDE/Plasma community and for the \
community to decide whether it wants to embrace it (or can embrace it - the \
announcement cites Mycroft as a participant, but the divison of governance is unclear \
to me) and help develop a product narrative around it that appears to \
incomplete-to-missing.


Cheers,
Eike



March 23, 2020 4:18 PM, "Paul Brown" <paul.brown@kde.org> wrote:

> Hello,
> 
> As it turns out, the discussion about the name of the product is premature at 
> this moment, as the product itself is not ready for release, at least not 
> officially as a KDE product, with its dot article and posts through the official 
> KDE social media accounts.
> 
> The product uses proprietary Google technology so, as it stands, it would not 
> pass the FLOSS smell test and can be seen by people outside our orbit as a 
> front-end to Google spyware.
> 
> We already had quite a bit of (unjustified) negative press regarding the 
> telemetry options shipped with 5.18. If we make an official announcement about 
> this product now, it would be further proof for the anti-KDE crowd that we are 
> sliding down the slippery slope of spying on our users.
> 
> My recommendation is this: the developers make it a blog post, the blog post 
> can go through the planet and Promo can echo it, re-tweet it, boost it, or 
> whatever, explaining that this is a project that is WiP. This will still 
> attract the intention of users and companies who are interested in these kind 
> of things.
> 
> I would also recommend that the blog post include the information about the 
> Google back-end explicitly and clearly, explaining how this is a temporary 
> solution, and information about how developers intend to solve this problem 
> down the line.
> 
> When the product manages to remove the Google back-end and uses, for example, 
> Mozilla's voice data, we can confidently make an official announcement via KDE's 
> own outlets and not have to put up with any blowback.
> 
> Cheers
> 
> Paul
> -- 
> Promotion & Communication
> 
> www: http://kde.org
> Mastodon: https://mastodon.technology/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
> LinkedIn: https://www.linkedin.com/company/kde


Best regards,
Eike Hein
-
KDE e.V. vice president, treasurer


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