Rename Coffice?

[Inge Wallin]

On Thursday, March 28, 2013 18:10:35 Sebastian Sauer wrote:
> On 03/28/2013 05:47 AM, Jaroslaw Staniek wrote:
> > Sebastian, I only referred the marketing/PR side of things; both Inge
> > and part of me offer you support in that area.
> > The desire I tried to express is: avoiding confusion among users or
> > 3rdparties, plus wannabe journalists, by not multiplying extra
> > *official public* flavors of Calligra in their minds unless it can be
> > easily explained in a short sentence to a Joe user.
> 
> I see what you mean but I am not sure how to do better in the future.
> Maybe a bold intro sentence that explicit says "This is experimental"
> and probably most important :"This is not an official Calligra release".
> Yes, makes sense, agreed :)

I think we need to distinguish two things:
 - What the user sees / experiences and who created this.
 - What the package consists of.

In this particular case COffice is a creation by you. It builds on the Calligra 
Office Engine(not yet tm :) ) but what the user actually sees is created by you.

In any LInux distribution the packager would be behind the package and if it's 
an official part of the distribution, then it's the distribution name that is 
behind it. This is part of the quality assurance; if the program is not mature 
enough it simply won't be a part of the official distribution but will be hidden 
in some repo for "contributed code" or so.

In this case, you are both the developer and the packager. What you have done 
is remarkable - in a very short time you have created something that works on 
Android and solved many and tricky problems on the way.  But that's not what 
the user sees; s/he sees a limited package that can only show one file format 
and with a very limited UI. There could even be crashes - I don't know.

I think that in a case like this it's very important that we stamp alpha (or 
beta) on it and say things like "built on the calligra engine" rather than 
"calligra for android" - until it's ready!

But we all agree on that, so I'm just preaching for the choire and repeating 
what you already wrote. The actual point here is that we don't have any 
policies on how to handle this. 

Normally KDE only releases source code and never does any packaging. However 
for Android and other similar platforms we either have to outsource the 
packaging to individuals or companies (like KO ;) ) - or start a new trend in 
the KDE community by packaging and releasing binaries ourselves.

I'd like to have a short discussion about this here and then take it to the 
wider community and e.V board so that KDE can create some new policies. What 
does a package need to be able to put a "KDE" stamp on it, or in this case 
"official Calligra software"?

> > This is important,
> > and was also quickly pointed out in the first comment on your blog
> > entry
> > [http://blogs.kde.org/2013/03/24/coffice-calligra-android-available-now].
> Yep. Well, its all "work in progress" and that includes names, getting
> the patches proper upstream / into master, etc. I think its a different
> balance act of at the one time making clear "its a start, a preview, its
> going to change" and still make clear "yes, this is Calligra *code* done
> by the Calligra community". The later was important for me cause of
> exactly that assumption that some may write "New Office suite" and leave
> out all the background that 99.9% of the work that was needed are not
> done by me but by Calligra. Yes, it was important for me to outline that
> direct in the headline. Always not so easy to proper balance such things
> and you can be sure some news-pages will get it wrong, like to get it
> wrong, will spin there own stuff, always, cause it may sound better,
> brings more clicks. What I think is/was very important here is to make
> the message positive on any level. News love negative messages and imho
> its better to be to positive then negative on any level.
> 
> In concrete I personally prefer to be wrong citated with "its an
> official Calligra release" then with a "its a Calligra fork". I really
> tried hard to prevent the last case. Not only with Calligra but also
> with that fake-library, with the qmake/cmake case, with the Qt-only
> case, with Linux Desktop/Android case, etc. pp. In that blog I tried to
> explain why while making sure a) its not set in stones and b) its going
> to change and c) this is NOT negative and cause things are done
> different does NOT mean how its done before is bad or so.
> 
> Actually that's one of the reasons why I got that code into our
> repository weeks before. Personally this days I like github more but
> okay. Its also why I talked about that in IRC, why I announced the
> milestone2 here 1-2 weeks ago, why I gave earlier packages for testing
> to the community, why I real-time chatted in IRC, showed of the blog
> before, etc. pp. I just think it was very important to name Calligra
> (and for that matter KDE), to make clear that yes, this is Calligra code
> and its coming out of the Calligra community.
> 
> For the last sentence, the "its coming out of the Calligra community":
> Let's be realistic. NO project in Calligra or in KDE is done by all of
> the community. If somebody (and most things in KDE/Calligra are done by
> only one dev) comes up with something and if it fits basic rules (like
> FLOSS) then its from (or coming out of) the community. More so if it
> utilizes 99.9% of the code written by that community :) Anyhow, the imho
> REALLY important and interesting aspect here is more how its driven
> future. That's what we worked out or are still working out. Looks
> promising so far :)
> 
> On that matter:
> * Calligra Mini then.
> * I mailed sysadmins. In future we may use an own KDE Google Play
> account. Still some things to work out. Its in progress.

Great! Calligra Mini is a good name.  But I'd be uncomfortable to release 
Calligra Mini under that name until it's quite a bit better than now. On the 
other hand the release early, release often mantra also is good.  So how shall 
we handle this? Release Calligra Mini alpha1, alpha2, beta1 and so on? Or use 
COffice as the development code name and then release Calligra Mini when it's 
ready?

> > I am totally OK with codenames, by design internal, either using urban
> > dictionary, coding prefixes (COffice) or anything else :) But I would
> > pick some parity here too since in case of FOSS also developer's blogs
> > are part of the public messages. Journalists keep using them to
> > sometimes say much more than the original authors actually mean. See
> > Phoronix in the Aaron/Mir case as an example.
> 
> Well, really irrelevant imho. The one thing was positive and
> constructive ... but let's close *that* specific topic/example.
> 
> > Codenames, if they even exist, are not the same as the publicly
> > communicated names that shaping the public recognition. A good
> > improvement is the proposal of Calligra Mini sub-brand.
> > 
> > Regarding the part that you do not plan (and I am not surprised given
> > how complex it is): the look. I hope that ultimately, Calligra on
> > Android shall be compliant with how 'native' apps look on the OS. This
> > also most likely applies to any other platform that offers anything
> > like own UX guidelines.
> 
> I think there are more important things for me to do atm and that's what
> I focus on. Its not that I not like to do that but it has no high
> priority for me atm. If anybody else likes: please do!
> 
> For a starting:
> * What we may need is a night-/inverse-mode of textlayout to proper use
> a dark color scheme.
> * There is a "SystemPalette" QML-item. Would make sense to experiment
> with it and fix Qt4 Necessitas where needed. *Note* that it may needed
> to build Qt5 Necessitas and do same/similar patch for Qt5 too. Rule is
> first Qt5 patch, then backport to Qt4. May also needed to get in contact
> with Necessitas-dev and look what's current Qt4 state, if backporting
> components/work from Qt5 to Qt4 is possible.
> * Alternatively hacking direct in Java/JNI to fetch color-schemes, etc.
> and offer to QML. May the quick & dirty way for Qt4 being.
> * Or alternatively port Calligra to Qt5.
> 
> > So your early (and hopefully often) releasing should be highly
> > respected. I only mean that the effort should be have an
> > 'Experimental' label attached in very visible place (Google calls it
> > beta) so it is much safer for us.
> 
> Yep, fair enough & agreed. Thanks :)
> 
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel