Re: Plasma Next Naming

On Thursday, January 16, 2014 16:36:49 Martin Klapetek wrote:
> On Thu, Jan 16, 2014 at 3:56 PM, Aaron J. Seigo <[email protected]> wrote:
> > > - Version numbers seem confusing an not very expressive, these should
> > 
> > rather
> > 
> > > be a technical detail (for example to group bugzilla entries)
> > 
> > Maybe a silly question: but who finds version numbers confusing?
> 
> The point was I think that 4.11.3 tells you nothing (as in when it was
> released for example), in that regard having the version as month/year
> combination is expressive enough to say for example "this is old version,
> please update".

Ok, so it isn’t a matter of the current numbers being confusing but attempting 
to add more useful information to the version information. I agree that this 
makes sense, particularly the date scheme (though not the animal scheme, which 
is a step towards less information than more)

> >  > * The version number used is Month (as name) + year
> > 
> > Including what gets reported in about UI and command line switches? How
> > will this work with plugin compat checking, or will there be another
> > numerical version?
> 
> I would think so. Like 2013-02 or in better format.

Ok, that’s workable. 

It conflicts with using the animal name as an identifier (I’ve seen this with 
Mac users ...), but personally I do like the date scheme for this better than 
the animal scheme.

Again: how would plugin compat checking work? Currently it is done with a 
simple x.y.z number from the library; I assume that will still remain? If so, 
when plugin incompatibility is reported, it will show reference the version 
#s, but I suppose that’s a minor detail and not a big issue.

> >  > * "Plasma by KDE" (don't use "KDE Plasma", but rather "by KDE”)
> > 
> > What benefit does this aim to bring?
> 
> This was my idea and the idea is to bring more clear separation between KDE
> and Plasma. You would be surprised, but every single article about KDE SC
> in Czech republic still names it "KDE". Imho if we explicitely say "This is
> product Plasma, done by KDE (ie. Plasma by KDE)", this should help the
> redefinition effort.
> 
> Also it's inspired by real-world success rebranding - for example Brise,
> the "nice smell" company, is now Glade and you can see "Glade, by Brise" -
> makes a clear connection to the estabilished brand of Brise and also draws
> a lot more clearer picture - "we renamed this product to Glade, but it's
> still made by us".

Makes sense imo...

> > Will this be the recommendation in login screens as well? (So soon after
> > we finally got most/all using “KDE Plasma” instead of just "KDE")
> 
> I would leave just "Plasma [fish]" here.

I think having this on log in screens would be not so good as it would change 
at each release. This has implications for documentation and translation, as 
well as ensuring all our users understand that the second part of the name 
changes every N months/years but is actually the same thing. That’s probably 
unreasonable to expect from our non-hardcore users.

We don’t currently put versioning info at all in the login chooser; putting an 
actual code-name means having to put extra efforts into promoting a brand that 
changes every N months. From a branding perspective I don’t think this is 
optimal at all, esp as it also competes with the “by KDE” thing which holds 
quite a bit of value: there is little brand value in an ever changing animal 
name with an in-group connection behind it, but there is huge brand value in 
“KDE”.

My input would be to leave it “naked” as just “Plasma” in the log in screen, 
or at most use the ‘by KDE’ tagline.

> >  Should other KDE applications / libraries adopt this naming for
> > 
> > consistency? Why / why not? If not, do we expect our users and downstream
> > to get that sorted out correctly?
> 
> I think this is already mostly the case, no? We have Dolphin, not KDE
> Dolphin...

applications tend not to have any KDE in their naming these days, but rather 
use phrases like "Dolphin is the default file manager for KDE focusing on 
usability” (which actually contains a branding error :) or "Kate is a multi-
document editor part of KDE since release 2.2. Being a KDE application, Kate 
ships with network transparency, as well as integration with the outstanding 
features of KDE" or "Kontact is the integrated Personal Information Manager of 
KDE"

I actually like “by KDE” better than any of those constructs, as long as they 
are part of the KDE community or apps (as per the KDE Manifesto), which is why 
I asked: it is a nice opportunity to harmonize all this with one, single, 
nice-sounding tagline, and wanted to know what the discussion up to now by the 
Plasma team had been in that direction (if any) before I started writing 
volumes ;)

> we do have "KDE Telepathy", but, well, ok...that could use a
> change. Everyone calls it KTp anyway, maybe we'll adopt it for good. *shrug*

There are some notable exceptions. In particular Frameworks. 

We currently call it "KDE Frameworks 5". Should it be Frameworks 5 by KDE? 
That’s a tricky one because “Frameworks” is not a good stand-alone brand: it’s 
a synonym of sorts for “library set” and googles poorly as a result.

So perhaps Frameworks remains an exception (which matches“Qt  Frameworks”), 
while the recommendation to all applications is to adopt “by KDE”?

This would very neatly resolve the “an application written using KDE 
Frameworks by a 3rd party” vs “an application written within the KDE 
community” vagueness we currently grapple with. Thoughts?

(Yes, this is out of scope for Plasma branding, but on the promo list the 
scope widens as we need to ensure branding remains consistent across KDE and 
where there are exceptions that we understand why)

> > There are certainly products that use this naming scheme, such as perfumes
> > and clothing, but it’ll be a bit of a stand-out in the tech space.
> 
> More points for us, then? ;)

Yes, if simply being different has value. :)

> > > * "Please file a bug against Plasma June/2014"
> > > 
> > > * "KDE Releases Plasma Angelfish"
> > 
> > Having both a date/year and a code-name seems counterproductive for
> > communication: do bug reports go against Angelfish or June/2014? (probably
> > neither: a version number, which is a third piece of information, is
> > used).
> > User A says “I’m using Plasma Angelfish” and the other says “I’m 
using
> > June
> > 2014”.
> 
> Seems to work for *Ubuntu. The bugzilla entries could even be "2014-06
> (Anglefish)".

Didn’t someone in this very thread note that this was an issue in their 
broader user community?

> > additional information to be understandable (e.g. knowing that it is
> > alphabetical; a look-up table for how old a given codename is versus
> > another) and doesn’t relate anything beyond sequence.
> 
> Fwiw, I don't think users would ask these questions.

I get questions from people about compatibility fairly regularly, particularly 
between big releases.

> I think it's anyway up
> to distros to provide what's compatible to the users. And distro people are
> imho capable of handling that. Would be nice to have some packagers input
> from packager's perspective.

This does assume a distro driven model; if we ever open up to a broader 3rd 
party application ecosystem approach this will no longer be the case. c.f. 
Steam. It was “for Ubuntu”, but ran just about everywhere. Questions of 
compatibility are not clear in Free software desktopland, and it causes 
questions and confusion.

Within KDE packaging, I have routinely received questions about Plasma Active 
being compatible with Plasma Desktop. There is not always the level of in-
group knowledge we’d hope for from packagers.

Which may indicate we need more clarity.

> >  A name based on animals seems very gimicky imho and a step towards a
> > 
> > rather more informal approach. It may also be perceived as a me-too move
> > in
> > reference to MacOS and Unity.
> 
> I think informal is good direction with this

Interesting .. may I ask: why? Is it just a team feeling (an inner projection 
on to the project) or is there a goal external to the team for this?

> > What particular challenge(s) is the code naming idea trying to address?
> 
> These are stated in the original email.

I read it (obviously), and didn’t see them (hopefully equally obviously since 
I asked). Perhaps I just don’t perceive those issues as challenges that are 
asking to be addressed; so if they were indeed all in the original email let 
me rephrase the question: 

Why do these challenges need addressing such that these branding changes are 
desired?


Thanks for your answers .. I think it is worth considering thoroughly the 
impacts of branding directions across KDE’s assets, and so I hope you forgive 
the volume and detail level of questions.
-- 
Aaron J. Seigo

_______________________________________________
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.