Re: [kde-community] Proposal: KDE Manifesto wording revision

2013-11-12 Thread Thomas Pfeiffer
On Tuesday 12 November 2013 23:11:54 Eike Hein wrote:
 On Tuesday 12 November 2013 22:53:18 Thomas Zander wrote:
  All these may actually exclude the stuff that is used to create the
  deliverables. If you use gimp to draw, the gimp file is imporant, but the
  asset and deliverable is typically used for the png you export.
  So I'm assuming we want the source-materials, and in that case those names
  may not be the best.
 
 Yeah, that's exactly the problem I had with deliverables -
 you can play the game that the deliverables of a FOSS project
 *are* source materials, but sadly we just don't live in a
 world where that reads intuitively ...
 
  What about calling them; source materials. Or Product source
  materials?
 
 Hmm, nice idea ... let's briefly check it against a tricky
 case, though:
 
 - With the Oxygen icons, the original source materials are SVG
   source.
 - However, we also store rasterized forms in SVN.
 - Those rasterized forms are often further hand-optimized, i.e.
   you can't recreate trivially them from the SVG source.
 
 Our goal therefore must be to make sure both of these forms are
 in the repo - does source materials apply sufficiently to hand-
 optimized PNGs cut from SVGs, or is there a loophole there?

If the rasterized versions were simply the result of a script running over the 
source SVGs, I wouldn't call them source materials, as they'd be more akin 
to compiled source code.
I would consider hand-optimized PNGs as source material, though, because they 
were modified afterwards.
If for some weird reason a project would compile their code, then go ahead and 
edit the binaries with a HEX editor and put those modified binaries in the 
release tarball, I'd expect them to put those modified binaries in the repo as 
well.
To me, source materials means anything that cannot be produced automatically 
from the other source materials.

I do agree that people might interpret source materials differently, though.
 
 I toyed with variations of source and release materials for a
 while, but that has the problems that it (a) ends up creating
 loopholes for aux assets not put into tarballs in the end and
 (b) can easily start reading on the tarballs themselves, becoming
 confusing.
 
 
 Let's try it out in full for now in order to keep an overview:
 
 All source materials are hosted on infrastructure
 available and writable by all KDE contributor accounts.
 
 
 I think it's an improvement overall - but not sure about Oxygen.

I'd assume that when in doubt whether they should put something in the repo, 
people would just ask.

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] HIG compliance testing via Google Code-in

2013-12-05 Thread Thomas Pfeiffer
On Thursday 05 December 2013 10:16:56 Shantanu Tushar Jha wrote:
 Plasma Media Center would love to have more usability feedback, as usual :)

PMC would surely be interesting to test. The only issue I see is: Which HIGs 
should it be tested against? It's neither really a Desktop nor an Active 
application, and we don't have HIGs for Plasma applications. 
So: Which HIGs would PMC like to comply to?
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] HIG compliance testing via Google Code-in

2013-12-05 Thread Thomas Pfeiffer
On Wednesday 04 December 2013 16:14:26 Jeremy Whiting wrote:
 I wouldn't mind getting usability information about knewstuff (used in
 many applications), kanagram, and/or Jovie.
 
 thanks,
 Jeremy

Sure! Could you handle feedback for all three? ;)
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] HIG compliance testing via Google Code-in

2013-12-06 Thread Thomas Pfeiffer
On Thursday 05 December 2013 14:26:36 Jeremy Whiting wrote:
 On Thu, Dec 5, 2013 at 11:13 AM, Thomas Pfeiffer colo...@autistici.org 
wrote:
  On Wednesday 04 December 2013 16:14:26 Jeremy Whiting wrote:
  I wouldn't mind getting usability information about knewstuff (used in
  many applications), kanagram, and/or Jovie.
  
  thanks,
  Jeremy
  
  Sure! Could you handle feedback for all three? ;)
 
 Yep, I could.

Great! I just added all three tasks. Let's see what they bring. If the results 
are as good as those from the last two HIG compliance tests, you should get 
something useful out of them.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5

2014-01-16 Thread Thomas Pfeiffer
On Thursday 16 January 2014 11:56:08 Sebastian Kügler wrote:
 On Wednesday, January 15, 2014 23:46:29 Adriaan de Groot wrote:
  On Wednesday 15 January 2014 23:13:11 Albert Astals Cid wrote:
   Besides how would you define this KDE Essential Applications group? I
   mean a  tarball? An XML file somewhere? Personally I find distros should
   be smart enough to decide which apps they want to ship by default and
   which not.
  
  It's still nice to have some kind of grouping defined by the KDE release;
  the  reason for that being that it's much easier to say install kdegames
  than install khangman and kgoldrunner and ktiktaktoe and ksnap and ltskat
  and ... and if kdegames -- or kdeessentials -- refers to the same
  name
  across distro's, that's good for migrating users. You really don't want a
  (non-smart) distro saying Oh, we didn't think kmix was essential .
  
  If there's a list of these 38 repositories / tarballs are the essentials
  this  time around then that at least is a strong indication that that's
  what upstream (i.e. us as KDE) wants.
 
 I'm not sure the current categorisation works very well here, for example
 installing kdegraphics gives you a whole bunch of graphics-related tools,
 but probably too many (and then some are missing, such as digikam), and
 workflows might still not be complete. (Underlying assumptions, the user
 wants to accomplish a task, not run an application.)
 
 A brainfart: rather than categorizing applications by their domain, maybe
 providing sets of apps for certain workflows or usecases, a vertical, rather
 than a horizontal integration, if you wish.
 
 For example: a SOHO metapackage would ship Calligra Sheets and Words, Kraft,
 Kontact. A primary educational metapackage would ship edu apps suitable for
 a certain age. A Tablet metapackage would include Plasma Active's UI,
 Krita Sketch, and other touch-suitable apps, and so on. These metapackages
 could even cause configuration changes elsewhere, so installing a hobby
 photographer metapackage would add an Activity for this task in Plasma
 Desktop.
 
 These metapackages can of course overlap (as it's really just a dependency
 definition), but it would it make it easier to create coherent, yet complete
 systems, and be a way to reflect a clearer vision for apps and sets of apps
 towards the actual use-cases.
 
 Just an idea...

Is it just me, or does this idea sound like it's going in a similar direction 
to the Flows Björn and I talked about at Akademy? ;)
Tasks/workflows is really what we should be thinking about, because that's the 
user's perspective, and thus much more likely to be helpful to users than any 
technology-centric perspective.
So, long story short, a big +1 from me!

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Sad news (fwd)

2014-08-27 Thread Thomas Pfeiffer
On Wednesday 27 August 2014 09:00:04 Jens Reuterberg wrote:
 Thats terrible news.
 
 As a community would it be appropriate to write up a short retrospective of
 Mojtaba? Perhaps combined with a photo, some information about him, his work
 and his life and post it on one of the larger KDE blogs?
 
 I don't know how Iranian burial customs work and we should check in with his
 family and friends (Mehrdad perhaps if you could help out) but with their
 allowance it seems as a nice gesture to do towards someone who has been a
 part of our community as well as worked on things that benefit us all
 (beyond our own community).
 
 What do everyone else think?

When community member Claire Lotion passed away in 2012, there was a Dot story 
( https://dot.kde.org/2012/05/20/remembering-claire-lotion ) and the KDE SC 
4.9 release was dedicated to her memory ( 
http://www.kde.org/announcements/4.9/ ). Chakra followed suit and named their 
KDE SC 4.9 release series Chakra Claire.

Maybe dedicating a Calligra release to  Mojtaba would make more sense than a 
KDE SC release because Calligra was his focus, but a dot story would surely be 
due.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Your Akademy take-away?

2014-09-12 Thread Thomas Pfeiffer
On Friday 12 September 2014 14:02:39 Lydia Pintscher wrote:
 Hey folks :)
 
 What are the most important things you took away from this year's Akademy?
 
 Mine are:
 * We are an amazing community that really pulls together when needed.
 Carrying someone up all the way to the castle because they can't walk
 there? Done deal. Big 3 for that. Let's never lose that!

Being the guy who was carried up to the castle, this was of course my most 
memorable experience there, too.

It really exemplified KDE for me:
Originally, I had thought I'd stay at the hostel during the day trip because I 
couldn't even get to the reservoir (where it happened) without walking too 
much (for those who were not at Akademy: I had an infection in my right foot 
so I could barely walk) and Jan Grulich, who had spent two half days taking me 
to the hospital and waiting there with me, was not available to drive me there 
on Wednesday.
When asking on the mailing list whether it was possible to get there without 
much walking, I got two replies from people willing to give me a ride (Martin 
Klapetek and Teo Mrnjavac).
In the end, it was Martin who took me to the reservoir (and also to the tram 
station the next morning).
I was happy that I could take part in the day trip and take the ferry together 
with the group, but I had already accepted that I wouldn't be able to get up 
to the castle (castles are not exactly known for being easy to reach, right?).

When the ferry landed and I said I'd wait there for the group to return from 
the castle, Frederik Gladhorn said something along the lines of No, we won't 
leave you behind, we can get you there!. I couldn't really imagine how, until 
I found myself first on Frederik and Martin's arms, then on Friedrich 
Kossebau's and then Frederik's shoulders.
There are some KDE members which, due to their compact size, might be 
relatively easy to carry. At about 1,85m in height, though, I'm not exactly 
one of them, so it must have looked really funny when a fully grown man sat on 
another's shoulders.

They were not the only ones who helped me when I couldn't really walk, of 
course. A number of other people helped and supported me during the last few 
days, too (Àlex Fiestas also carried my on his arms through the venue on 
Monday, for example). I never had to walk alone if anyone from KDE was around.

This was an example of what KDE means: We always help each other out, and even 
if something seems impossible, together we find ways to make it happen.

Thank you all for showing this in such a vivid way,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Your mission, should you choose to accept it, is.....

2014-09-13 Thread Thomas Pfeiffer
On Thursday 11 September 2014 15:56:01 Arjun Ak wrote:
 How about having something similar to the eudyptula challenge
 (http://eudyptula-challenge.org/) ?

Please don't take this personally, Arjun, but the challenge you linked to 
serves as the ideal example of how we should _not_ do this ;)

Its underlying assumption seems to be if we raise the barrier of entry as 
high as possible, we only get the really good people, so they did what they 
could to frighten people off by
- Allowing email as the only way of communication
- Telling people that HTML mails will be rejected
- Explicitly prohibiting people to ask questions
- Using quite harsh words to describe those limitations

This is the antithesis of welcoming inexperienced, insecure people who would 
like to give back to the community that produced software they love, but don't 
know how.

If there is one thing which the VDG taught us, it's that we should do the 
exact opposite of what the Eudyptula Challenge does: We should lower the 
barrier as far as possible, we should offer people help and advice wherever we 
can, we should ease their minds and help them to overcome their insecurities.
Many new contributors in the VDG forum introduce themselves with I'm not a 
designer, but..., and then they often present brilliant ideas, which are 
sometimes just be scribbled on a piece of paper due to lack of knowledge of 
using graphics software, but can easily be taken up and refined by the 
community to the point where they are clear enough to be implemented.

And people in the forum learn along the way, from each other. They learn how 
to use graphics applications, and some even take a stab at QML in order to 
help their ideas become a reality. 

The VDG showed us is that attracting people willing to help us out and 
motivating them to stick around and grow as they go along is more important 
than securing top talent by raising the barrier. So yes, we need to put 
quite some effort into this, but I'm sure it will pay out in the end.

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


[kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure

2014-09-15 Thread Thomas Pfeiffer
Hi everyone,
this is a topic that has been going around my head for quite some now, and now 
I finally decided to actually try and get the ball rolling on it:

I think we are quite good at eating our own dog food when it comes to 
desktop software: Most KDE contributors use Plasma as our desktop environment, 
many (most?) developers use KDevelop and/or Kate for development, many use 
Kontact for our PIM needs, KTp or Kopte for IM, etc.

Where we don't use many of our own products, though, is on the infrastructure 
side. Which strikes me as quite odd, given that I know of at least two 
projects that have originated within KDE and have become quite successful 
_outside of KDE_ by now, but are not used by us: Kolab and ownCloud.
Both serve needs that are of course present in KDE, too, as in any other 
organization: Communication/coordination and file hosting/sharing.

There has been much talk about making KDE more professional and more 
efficient, and centralized management of communication, coordination of 
appointments and addresses and also hosting and sharing of documents is 
something that most professional organizations (and certainly all of our 
size) do, so it would most probably be helpful for KDE, too.

Imagine we would not have to look up a KDE contributor's email address from an 
email they sent to a mailing list if we want to contact them, but instead just 
go to our central address book and type in their name. Or instead of relying 
on Doodle to coordinate meetings, we could send out invitations via our own 
Kolab system!

Regarding file hosting/sharing, developers might ask themselves Why do we 
need file hosting? We have git for all our assets!, but it's not that easy. 
Git is awesome for hosting code and other plain text assets (like HTML or 
LaTeX source files, for example). What it's not good at is conveniently 
uploading, browsing and downloading working non-plaintext documents, like 
images (which is what visual and interaction designers mostly work with), 
presentations and similar things. I'm not talking about assets which are 
directly used within our software, those should probably still be hosted in 
git to work seamlessly with our deployment process. What I'm talking about are 
e.g. mockups, which are never released with software, but used by designers 
and developers to communicate during the design process. Yes, all that can be 
done with git, too, but
1) Git has quite a steep learning curve for non-developers
2) I've seen SVN being used for hosting binary format documents in a company, 
and it was quite a pain.

A third product which was born within KDE and which could be really useful for 
us is Bodega. We all know that kde-look.org and kde-apps.org are far from 
state of the art at this point. Their websites look really outdated and are 
not very usable, and desktop integration via Get Hot New Stuff has quite a few 
problems, too: For example, often download links in kde-look/kde-apps do not 
point to a file in the format expected by GHNS for that type of asset, making 
it impossible to install it directly via GHNS.

Bodega, on the other hand, was created precisely with our requirements in 
mind: It supports the whole process from creation of an asset to installing it 
on a device running Plasma (and also rating and discussing it, even 
payment/donation to the creator if wanted) very well, and is flexible enough 
to incorporate anything from wallpapers to full desktop applications.

I would not like to discuss the three specific products I mentioned directly 
in this thread, because that could make it confusing quickly. Here I just 
wanted to present the general idea of pushing our use of our own server-side 
products within KDE. If there is general agreement that we should work on 
this, I'd start a new thread for in-depth discussion of each product (and of 
course any others which I haven't thought of yet).

There have been attempts to task the KDE e.V. board with getting the 
aforementioned products established in the KDE infrastructure, but with all 
the crucial strategic things the board has to do, there simply isn't the time 
to do such operative work, so we have to do it ourselves.

So, what do you think?

Best,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure

2014-09-15 Thread Thomas Pfeiffer
On Monday 15 September 2014 15:04:17 Eike Hein wrote:
 On 15.09.2014 14:58, Thomas Pfeiffer wrote:
  Where we don't use many of our own products, though, is on the
  infrastructure side.
 
 That's not actually true, btw:
 
 - identity.kde.org is us
 - ballot (the e.v. voting software) is us
 - commits.kde.org is us
 - our commit hooks are us
 - ditto the anongit mirroring system
 - our forums are heavily customized
 - wikis too
 - ...
 
 We actually do a lot of our own infra.

Ah yes, sorry, that came across wrong: We have developed/adapted many tools 
specifically for our own needs, and of course use those!
What I meant that we have products which we have not developed for our own 
purpose, but many others use them and we could make use of them as well.
Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure

2014-09-15 Thread Thomas Pfeiffer
On Monday 15 September 2014 16:24:55 Aleix Pol wrote:
 Hi Thomas,

Hi Aleix,

 First of all, I'd like to say I mostly agree with you. I would add a bit of
 a twist though, I think we must ensure the services we rely on are free and
 open as possible, they don't need to be our own (or in a tier2 kind of,
 like owncloud or kollab) but we must ensure we keep true to making it
 possible to be able to deliver a KDE development experience based on free
 software.

True. I'd propose the following priorities for software procurement:
1. Viability. It needs to get the job done. A Free but useless software won't 
help us, unless the reasons why it's not useful for us are easy enough for us 
to fix.
2. Feasibility. If it's something we don't have the capacity to host or which 
costs significant amounts of of money to use, it's out
3. Freedom. If there is a proprietary and a free tool that are both viable and 
feasible, of course the free one wins, even if some people like the 
proprietary one more
4. In-house: If there is a KDE product and a third-party one that both satisfy 
requirements 1-3, we should prefer our own so we can identify and fix its 
potential issues.

 To get some perspective, one recent event I'm really happy about is
 Kanboard. We could have all dived into using Trello, but we found a good
 alternative we could use and host and we leveraged on it. Everyone is using
 it now and we're even starting to scratch the small itches we found, so
 we'll end up improving it, most likely.

Yes, I'm very happy about that switch, too!
 
 As for the specific cases you proposed, I concur that they are great but we
 should really see what they can offer:
 - Kollab: This was already discussed recently in this list, it doesn't seem
 feasible to offer a Kollab instance to the membership (let alone the whole
 community) so I don't think we want to depend on it. That said, We might
 want to ensure we have all the tools to use the standards we can rely on,
 then ensure Kollab is capable to interact with them, given it's one of the
 few platforms we could have a say.

Given that Kolab will power the whole of Munich administration soon, I wonder 
why it wouldn't work for the - big, but still tiny compared to that - KDE 
community, but I am not an admin (I really should establish the IANAA and 
IANAD acronyms), so I may totally miss the difference. Would it require 
massive server or bandwidth resources which we don't have?

 - ownCloud: It could be useful. I seldom share actual files, we have an
 owncloud instance in KDE Spain server and we don't use it. Maybe it's that
 it overlaps with etherpad to some extent, or that we haven't learned what
 it can offer.

There could be several reasons for that. For example
- You don't use many non-plaintext documents (I can say that the visual design 
and usability groups use a lot of them!)
- People are so used to working with other tools (like e.g. wstaw for images) 
that they don't switch easily.

I can just tell from my experience in the VDG that having all of our mockups 
spread over a dozen different image and file hosting services and only tied 
together by links spread all over the forum isn't a good situation.
Often when someone asks me for a certain asset, I have to say Sorry, no idea, 
try to find it in the forum. Not what we'd like to have.

 - Bodega: +1, it should happen soon. I'd say there's some rough edges to
 polish on the client side, as we don't really have all the infrastructure
 needed so that it shines, but I'm confident it will happen sooner rather
 than later.

Well, it won't happen by itself ;) If someone is working on this, then yes, it 
will happen sooner or later. If nobody is working on it or will start doing 
so, soon, I don't see it happening.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Give People Access to Great Technology - a possible vision

2014-09-23 Thread Thomas Pfeiffer
On Tuesday 23 September 2014 16:06:36 Stuart Jarvis wrote:
  What’s making this more
  confusing is that the VDG are now discussing branding some apps along
  the lines of ‘Made for…’
 
 I'd be very concerned about this, for any but the most basic components
 deeply entwined in the desktop shell (e..g things like knetworkmanager
 etc). The 'by KDE' tagline used for Plasma surely works much better for
 anything else.

Just to clear things up: Made for Plasma was just one idea of many for the 
name of this, which, because we're all aware of the implications, is unlikely 
to be chosen in the end.
We still have not found a good name yet (the problem with by KDE is that it 
would naturally apply to all KDE applications, but what we're looking for is a 
name we'd only give to applications that fulfill certain criteria on top of 
being made by KDE).
See the forum thread [1] for background and the current discussion.
Input is still very much appreciated, as we're still kind of at a loss for a 
good name.

Best,
Thomas

[1] https://forum.kde.org/viewtopic.php?f=285t=122926
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] FOSDEM Organisation

2014-12-08 Thread Thomas Pfeiffer
On Saturday 06 December 2014 08:36:35 Carl Symons wrote:

 At least some of the FOSDEM organizers believe that it's important. They
 have a social conduct policy. It's published in the front of the program
 brochure. Apparently John doesn't think that it is proper (whatever that
 means):
 
 Social conduct policy
 
The FOSDEM organisers were surprised to hear that
harassment is a common problem at open source conferences
around the world. While we have no evidence of antisocial
behaviour ever having been a problem at FOSDEM, we would
like to remind everyone that harassment of any kind will
not be tolerated.  Please report any concerns to a FOSDEM
staff member (yellow shirts), or contact our coordinator
Wynke on (telephone number)
 from the 2014 conference in plain view
 (https://archive.fosdem.org/2014/assets/booklet-a1fec82960ed17ed7974bc2e9951
 dfc898c83318f8634f7ee046d952ada8ecb7.pdf)

That sounds pretty much exactly what at least I would be looking for in a code 
of conduct, I think it is quite well written and balanced.
However, the important disadvantage of making your CoC available only to 
people who are already _at_ the conference is that people for whom the 
presence of a CoC is a criterion for joining the conference will never know 
there is one.
So if they just put their social conduct policy on their website in addition 
to the brochure, I think it would be fine.
Could you maybe ask your FOSDEM contact if they could do that, Carl?
Thanks,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


Re: [kde-community] Blacklisting of free.fr

2015-10-24 Thread Thomas Pfeiffer
On Sunday 27 September 2015 09:32:32 Ben Cooksley wrote:
> Hi all,
> 
> In 48 hours, i'll be blacklisting the entire of free.fr from KDE email
> infrastructure. This is necessary as it has become apparent that the
> security of @free.fr addresses is quite poor - allowing for
> subscribers accounts to be targeted, hacked, and then used to abuse
> KDE infrastructure.

I still get tons of spam mails in French to both lists I maintain ( kde-
guidelines and kde-usability), as many as before the blacklisting. Is that 
related to this?

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Greetings Everyone

2015-10-04 Thread Thomas Pfeiffer
On Sunday 04 October 2015 18:19:46 Tanzim Rizwan wrote:
> Hello everyone,I just joined in this mailing list to get to know how can I
> contribute this community with code, I know c,c++ and python. But I don't
> know where do I start. Please anybody show me the path.

Hello Tanzim,
first of all: Welcome to KDE!
We're always glad for new people showing up, even more so when they already 
know c++ :)
So, is there any pa project you're interested in? A particular application? 
Plasma? KDE Frameworks?
Many projects have their own mailing lists where people can point you to 
specific tasks they think are good for getting into their code.
Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Final review for the KDE Mission survey

2016-06-12 Thread Thomas Pfeiffer

Hi everyone,
thank you again for the feedback on the KDE Mission survey!
I have tried to implement the feedback to the best of my abilities.
You can find the updated survey (still) here:

http://survey.kde.org/index.php/858172/lang-en

In order to get the survey out the door soon, I'd prefer to just get a final 
review now, unless there are still issues which you find so crucial that they 
absolutely have to be further discussed.


So please have another look over it and point out things like typos, difficult 
to understand or ambiguous wording, problems in the survey logic etc until 
Tuesday, June 14th, 23:59:59
Then, unless there are still any big issues left, I'll start the survey 
Wednesday morning.


Thank you,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Final review for the KDE Mission survey

2016-06-14 Thread Thomas Pfeiffer

On 13.06.2016 22:42, Alexander Neundorf wrote:

A few comments:

I think the questions should be pointing a bit more toward the future path,
i.e. instead  "How useful is it or would it be for KDE's ..."
maybe "How useful is it for KDE's future to..." ?
The way the questions and answers were written, they focus more on what to /do 
now/ in order to /achieve our vision in the future/.
Changing that fundamentally would mean having to rewrite the whole survey, and I 
don't think the added benefit is worth that.


First page, "How useful is it or would it be for KDE's products to..."
---

All good, but:
except one point all offered options are "positive", I doubt there will be a
lot of variation in the answers. I mean, who would object to "support open
standards" or "work well with assistive technologies".
The idea is to get which should be prioritized. If everything gets high scores, 
we'll include everything in the Mission.

The only one which stands out a bit as negative is "integrate well with
popular services, even if they don't share our values".
Maybe those two simply be merged into one point "integrate well with online
services", since on the next page at the bottom there is already the question
which kind of services should take priority.


I have now:
- ...integrate well with existing online services
- ...use new online services created by KDE for areas where no freedom- and 
privacy-respecting services exist


because I still want to know whether KDE contributors would be in favor of 
creating online services.

Second page
---

"offer a desktop workspace with a familiar default user interface"
I don't know what that means, "familiar". Familiar for people used to KDE1..4
? Or familiar for people used to Windows ?
Your original vision/mission draft mentioned a "classic desktop", which Martin 
found offensive, so I tried to word it differently.
Since it doesn't look like I can find a wording which works for everyone, I'll 
just remove this point since we have the question about desktop as supported 
device class anyway.

Third page
---

"How important are the following aspects..:"

How about a point "provide a stable and reliable software" ?

Ok, will add that.

"How much do you agree to the following statements"

Did you intentionally put "adhere to the design guidelines..." and "prefer a
consistent look and feel ... across platforms" that far apart ?
To me they are opposites, and I would expect them directly next to each other.

The same for "cover our users' most common tasks" vs. "treat equally, common
or niche".

The answer options are randomized for each participant to avoid sequence 
effects.
Unfortunately that also separates opposites, but that is okay from a research 
perspective, especially because opposite questions elicit more honest answers if 
they are not immediately recognized as such.

Yes, it looks weird, but it avoids bias so I'd like to keep it that way.

Fifth page, target groups
-

Maybe make the statement a bit stronger, so participants don't feel bad when
not checking some of the boxes:
"...should KDE focus on" -> "...should KDE focus on most"

Or turn this into three levels ?
"How important do you consider these groups of users for the future success of
KDE ?"
Very important - Normal - Not important

I'll do the latter.

And as a last point, I suggest you publish that survey also on kde-core-devel
(and maybe frameworks-devel), so most core-contributors see it too.
(I guess you'll post it anyway also to the eV -list, right ?).


My plan was to send it to
- community
- eV
- devel
- core-devel

And write a Dot article.

I hope to reach most contributors that way.

Thank you for the feedback,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Please participate in our survey for input on KDE's Mission

2016-06-16 Thread Thomas Pfeiffer

Dear fellow KDE contributors,
as already hinted at in the article about KDE's Vision [1], the next step in 
setting our path into the future is defining KDE's Mission statement. Right 
after our Vision was published, a group of people started drafting a Mission 
statement and discussing it on the kde-community mailing list.


While we agreed on most aspects of the Mission, it became obvious that on some 
key issues, we just had quite different individual opinions. Even if an 
individual opinion prevailed in our discussion, we would not know whether that 
opinion was shared by the majority of the KDE community. This is a problem, 
because especially in a volunteer-driven community where a Mission cannot be 
enforced from the top down, it can only have a practical effect if the majority 
of those doing the work agree with it. However it became obvious that not that 
many KDE contributors both had the time and were comfortable with contributing 
to the discussion on the mailing list.


Therefore, in order to still be able to find out what the majority of the 
community considers the right approach towards our Vision, we set up an online 
survey, hoping that this would make it easier for people to voice their opinion 
in an easy, anonymous way. Since we always focus on our users, we are also 
interested in the opinion of interested users, so we opened up the survey for 
everyone.


So, please Participate in our survey:

http://survey.kde.org/index.php/858172/lang-en

It should not take more than 5-10 minutes and providing your input on what KDE 
should do will help us move towards our Vision!


Thank you,
Thomas and the KDE Mission team

[1] https://dot.kde.org/2016/04/05/kde-presents-its-vision-future
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-06-18 Thread Thomas Pfeiffer

On 16.06.2016 13:32, sabayon11 wrote:

Very interesting survey. I found some issues very controversial.

> ...reach as many users as possible, regardless of which operating systems, 
applications or services they currently use


I say no, focus on quality. Be realistic. Don't take to much on your plate.


Be aware that the Mission is not a short-term plan, it is supposed to guide our 
work for years to come.


> ...convince users to switch away from proprietary software and services in 
general


How are you going to convince? Marketing? If quality and useability of KDE 
software is fine they will switch by themeselves. No earlier I guess.


Good quality is of course a necessary requirement for convincing users, but they 
also have to be aware of it.


> ...use new online services created by KDE for areas where no freedom- and 
privacy-respecting services exist

> ...offer our own web-based products / services

Is KDE financialy capable of doing it? Has KDE other necessarry resources to 
accomplish it? Will KDE users sponsor it or pay for it? Will you make it 
commercial service?


WikiToLearn ( http://wikitolearn.org/ ), for example, is a very successful 
web-based KDE product. They have acquired their own sponsors for infrastructure, 
which will probably be a must for any web-based product at some point. So yes, 
it is possible, but probably not with the servers KDE has alone.


> ...aim for a presence on mobile devices (e.g. smartphones and tablets)
> ...aim for a presence on embedded devices (e.g. in-vehicle (entertainment) 
systems, smart TVs, smart home or machine control panels)


Do you really think that KDE can compete with Android or iOS? Or is it a 
wishfull thinking only (dream on).


Nobody said that being a direct competitor for Android or iOS would be our goal.
1. KDE is _not_ the desktop, it is the community which also makes applications. 
We already have a presence on Android devices in the form of KDE Connect, 
KAlgebra and Behaim Globe, and there are several more KDE applications for 
Android in the works. Being present on smartphones does not mean beating Android 
or iOS
2. There is Plasma Mobile. Its goal is not to dominate the mobile market any 
time soon, but that does not mean there are no valid usecases for installing it 
(for example for people or organizations who need better privacy and security 
protection that Android or iOS can offer them)


Aiming for a presence on a platform is not the same as trying to replace 
dominant OSes. Plasma is installed on only a tiny fraction of desktop PCs. Does 
that mean we don't have a presence there?




> ...adopt current and emerging user interface trends (e.g. mobile/desktop 
convergence, conversation-based user interfaces, ...)


Are you capable of doing it in the first place? Do you have resources?

We are capable of doing it. We have Plasma, which already has the capability for 
being used as a convergent desktop, and we have Kirigami, a framework which is 
made for convergent applications. We do not have much technology for 
conversion-based user interfaces, but since we're in the FOSS world, we could 
laverage technologies such as Mycroft.


> ...treat all applications equally, regardless of whether they are for common 
or niche tasks


Quality of Plasma - quickly fixing bugs, providing new features proposed by 
users, basic features of desktop should be a priority. Next utilities. At the 
moment I don't use for example Korganizer because some parts of it are not 
developed and are useless (Kjots, Tasks).


This is a survey, in order to find out what the community wants to focus on, and 
what our users would like us to focus on. We will see what comes out of it.



> Business/ office users

 Is KDE capable of doing it? If yes, in what areas? Be realistic. Is KDE 
office suit capable of replacing MS Office or even LibreOffice? Does it offer 
advanced features like group work? Be realistic.


1. Again: The survey is for helping us decide what to _focus_ on. If we decide 
to focus on business users, then of course we have to invest more of our energy 
into business applications.
2. Why should users not use KDE software in conjunction with LibreOffice? It's 
not like we can only be relevant if people use _exclusively_ our software.


I have the impression that this question reflect that KDE developers have big 
ambitions. But keep in mind that you need to have resources. KDE itself is a 
niche desktop invironment. Focus on basics and if this is fullfilled go further.



See above: The Mission is not our short-term strategy.

I am only an ordinary user. I want the basic features of desktop environment 
to function properly without bugs. At the moment not all features of KDE 4 has 
been implemented.



That is fine, of course, and understandable.
Thank you for your feedback!
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - an alternative draft for discussion

2016-02-06 Thread Thomas Pfeiffer
On Samstag, 6. Februar 2016 16:47:31 CET Ingo Klöcker wrote:
> Yes. I think the vision statement needs to be complemented by a mission
> statement. But I think, before we tackle the mission statement, we should
> nail down the vision.

That exactly was our (the "inclusive vision group") plan. 
And it now looks to me that maybe the actual Vision part of the "focused 
version" isn't all that different form the other one.

It feels to me that we all agree far more on the vision than the mission. We 
all want the same in the end (end-users are in control of their devices and 
software, and can keep their privacy), we just prefer different paths toward 
that goal (the mission).

Am I right or am I missing something?
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] RFC: Distribution outreach program

2016-02-05 Thread Thomas Pfeiffer
Hi Neofytos!

On Dienstag, 2. Februar 2016 23:40:44 CET tetr...@openmailbox.org wrote:

> I would like to propose a middle ground solution hoping it will
> contribute to the discussion. It will imho serve everyone's interests;
> KDE, distributions and users.
> 
> The way I see it, the issue breaks down to 3 core areas as discussed so
> far:
> 
> 1. KDE recommended standards
> Recommendation: Provide a checklist of everything KDE considers
> important (configuration, dependencies, versions etc) as discussed in
> this thread.
> This way everyone can check what KDE proposes as an optimal environment
> for the software it provides to run on.

Yes, I think we won't get around doing that.
 
> 2. Distribution specific implementation
> Recommendation: Provide a place for distributions themselves to share
> their implementation.
> This could be a wiki table of some sort with a checklist and comments
> related to the items outlined in #1. This way distributions have the
> opportunity to explain in short their motives and demonstrate their
> reasoning for not providing something the expected way. This also helps
> users to have a more clear understanding of the goals and methods of
> each distribution that ships KDE software, and at the same time avoid
> any misunderstanding that could occur by people perceiving this as KDE
> pointing the finger to some specific implementation strategy or
> distribution.

That's a very interesting idea! It remains to be seen how many distributions 
would actually make use of this, but if many of them do, this could indeed be 
a very useful collaborative tool from which all sides could benefit!

> 3. Review
> Recommendation: From a distribution's perspective, I would expect
> distributions to be trusted to provide true information, so any
> reviewing should not be needed.
> However, if in the long term this proves to be necessary, it could be
> done in specified or random intervals. A script could be used as
> suggested, a KDE assigned person could handle this, or both. Some text
> of the type 'This page was last reviewed by KDE on X date' could show to
> users that the related information is valid and up to date.
> Badges could be assigned here and some visualization if KDE decides they
> help, as well as some grouping/sorting of the distros in relation to
> their appraisal.

I agree: We could first see if transparency already does the trick, and only 
apply a review process if it turns out that it doesn't.

> And of course, in cases that some information is considered invalid,
> make sure to have open channels of communication with distributions to
> avoid misunderstandings. =)

Absolutely! Communication is key here. I've used the term "Distribution 
outreach program" for my suggestion for a reason. It's not supposed to be a 
"blame distros for messing up program". It's supposed to foster closer 
collaboration between up- and downstream.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - first draft for discussion

2016-02-12 Thread Thomas Pfeiffer
On Freitag, 12. Februar 2016 12:07:27 CET Alexander Dymo wrote:
> On Fri, Feb 12, 2016 at 1:04 AM, Martin Graesslin  
wrote:
> > Why should there be a line?
> 
> I've been managing software development organizations since 2008. I
> attest to the importance of drawing a line. There's so much you can do
> with software. Unless you learn to say "no", you will not make a good
> product.

> By the way, I learned this the hard way in open source world too. Let
> me tell you a story.
> 
> When I was a KDevelop maintainer during 3.x cycle, I welcomed every
> single KDevelop plugin into the core.
> 
> End result? We did not attract new developers this way, but instead
> were forced to maintain a huge collection of barely useful software
> with a small team.
> 
> During 4.x development we clearly defined the core of KDevelop. It was
> to be a great C++ IDE. Any plugin that did not fit into the core was
> separated into its own repository. What remained received as much
> attention as possible.
> 
> End result? A much better product. New contributors. And guess what?
> Some of the plugins that were separated not only survived, but saw
> more development and usage.

See, here is the big difference: I (and I'm pretty certain most of the people 
arguing for an "inclusive" vision here) fully agree that a _product_ vision 
not only has to make clear what the product _should_ be, but also what it 
should _not_ be.

A product vision has to give a clear focus, because there is only so much you 
can do with given resources in a given time, plus more features increase code 
complexity and make maintaining the code more complex.

What we're talking about here, however, is not a product vision. Not at all. 
It is about how a _community_ wants the future to be. It is on a much higher 
level than a product vision.

Maybe what you want is an overarching product vision instead of a community 
vision, after all?




___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Vision, mission and manifesto - what is their definition and purpose?

2016-02-09 Thread Thomas Pfeiffer
Hey everyone,
analyzing the current discussions around the KDE Vision, I have identified one 
problem which could underlie much of the tension:
It's still unclear what we mean by "vision", "mission" and "manifesto". We 
cannot really consult a dictionary or encyclopedia to answer this, because 
there is no clear definition. Heck, even the Wikipedia articles on vision and 
mission contradict each other and are even contradicting in themselves!
That means that every one of us probably has a slightly different definition of 
them. 
The problem now is that we are wasting time and energy debating 
unproductively, not because we want different things, but because we have 
never agreed on a common definition of the three.

That's why I'd suggest that, before discussing the vision any further, we 
should agree on a definition. It doesn't have to be one with which everybody 
wholeheartedly agrees, because it's mostly used for communication.

To start this, here are my proposed definitions: 
--
1. Manifesto: 
Definition: For me, this is what documents the defining _values_ and _identity_ 
of an organization (or rather a movement, because regular organizations rarely 
have manifestos). 

Answered question: What is KDE? What makes a KDE member?

Purpose: To make explicit what a movement has in common, as a guide for 
someone who wants to decide if they want to be part of that movement and to 
remind people of why they are part of it, should they ever gravitate away from 
these values and identity.

2. Vision
Definition: For me, a vision describes the future which an organization or 
movement wants to work towards. It doesn't say _when_ that future has to be 
achieved, nor _how_ . It ideally should not change, unless the community 
collectively sees their goal as wrong.

(Note that this is the definition of a vision for an organization or movement. 
Product visions are very different from that, they can go into much more 
detail).

Answered questions: Why do we do what we're doing? What do we aim for?

Purpose: To guide contributors when they decide what to focus their energy on. 
With every decision they make, they should ask "Does this bring us closer to 
the future we want to work towards?"

3. Mission
Definition: For me, a mission describes _how_ an organization or movement 
intends to achieve their vision. It is on a much more strategic level than the 
vision, and likely to change over time through changing circumstances or trial 
and error.

Answered question: How do we reach our goals?

Purpose: To align efforts, achieve synergies and avoid duplicate effort. It 
guides contributors who are not sure what strategy to follow.
--

Of course the lines are always a bit blurry, but I still find it beneficial for 
the effectiveness of our discussion to take a step back and try to agree on a 
common understanding of the three terms above.

We should set aside differences in our actual preferred visions for this, 
because the purpose here is just to make communication easier by using a 
common definition.

So, please speak up if you
- Disagree with some part of the definitions so strongly that you cannot even 
work with them
- Would like to propose further clarification of the definitions to aid 
communication further

Once we agree on definitions, I will remind anyone who is thinking from a 
different understanding of any of the terms of our common definitions.

Thank you,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Vision, mission and manifesto - what is their definition and purpose?

2016-02-09 Thread Thomas Pfeiffer
On Dienstag, 9. Februar 2016 23:35:38 CET Alexander Neundorf wrote:
> Hi Thomas,
> 
> On Tuesday, February 09, 2016 22:56:32 Thomas Pfeiffer wrote:
> ...
> 
> > That's why I'd suggest that, before discussing the vision any further, we
> > should agree on a definition. It doesn't have to be one with which
> > everybody wholeheartedly agrees, because it's mostly used for
> > communication.
> good idea :-)

Glad we agree here :)

> ...
> 
> > (Note that this is the definition of a vision for an organization or
> > movement. Product visions are very different from that, they can go into
> > much more detail).
> 
> This is maybe an important detail.
> The results of "Evolve KDE" (https://evolve.kde.org/surveyresults.pdf)
> recommend to "Develop a vision, strategy and focus".
> Are we sure we are searching for a vision for the organization (isn't that
> quite close to the manifesto ?) and not for a vision for the products
> created by the organization ?

Good question! Here is a bit of history on this:

In the past, the KDE usability team (namely Björn, Heiko and I) have at least 
twice suggested to create a common vision for KDE's products.
This approach has received mostly negative comments every time, with the 
argument that there is far too much diversity among existing KDE projects to 
define a common product vision which is still useful, and that individual 
product visions would be much more helpful.

We accepted this, and set out to create product visions for the individual 
products instead. Only a few products have created visions so far, but those 
who have, seem to have been quite happy with theirs. I'd even say that there 
is a common feeling now that having a product vision is important for every 
project.

The usability team (and the VDG has a whole) still has the goal to help as 
many projects as possible to create product visions for themselves.
 
However, many within KDE still felt that the community as such should rally 
behind a common goal, to give KDE as a whole some sense of purpose and 
direction.
This is why we set out to create a community vision, after all. 

> Also, what do you think about the relation between vision and mission ?

When I joined the "vision team", my original proposal was to only define a 
mission, because I felt that visions make more sense for products than for 
communities.
However, Lydia convinced me that having a common vision for the future to work 
towards can have more positive effect on a sense of purpose and motivation 
than only defining a strategy, so I agreed to define a vision first and then 
derive the mission from that.

I hope I was able to answer your questions to your satisfaction. If not, feel 
free to follow up ;)

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Distribution outreach program: Where do we go from here?

2016-02-13 Thread Thomas Pfeiffer
Hi everyone,
now with neon having been announced, and some members of some distributions 
fearing that their distribution might become a "second-class citizen" for KDE 
software due to the less direct communication with KDE, I think that it's more 
important than ever to publicly reach out to all distros shipping our 
software.

This thread has seen some skepticism about some parts of my original idea, but 
mostly great suggestions for how to proceed.

I've tried to analyze the brainstorming results and identify what most people 
contributing to the discussion seemed to agree on. 
Here is how I'd suggest to proceed:

- Form a team to organize the Distribution Outreach Program and act as point 
of contact for the distributions

- Define what would be the main communication channel (should we just use 
kde-distro-packagers or do we need a new mailing list, forum or whatever?)

- Publicly announce (on all channels where we might reach distributions) the 
program, including how to reach us

- Collect from our maintainers what a distribution should to provide in order 
to make their software work best on it (where do we reach everyone?) and 
publish that (ideally on our wiki once that is editable again)

This is all I'd do for now. I'd suggest to first see how much simply increasing 
communication and publishing our requirements will take us. We can decide 
whether we want/need badges or scripted testing later.

Does that make sense to you guys?
And most importantly: Who'd be up for joining the program team?

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] RFC: Distribution outreach program

2016-01-30 Thread Thomas Pfeiffer
On Freitag, 29. Januar 2016 21:46:25 CET Luca Beltrame wrote:
> Il Fri, 29 Jan 2016 18:09:23 +0100, Thomas Pfeiffer ha scritto:
> > Maybe the speed of upgrading as such is not the actual point. What I
> > care about is the speed with which bugfixes reach end users. If a
> 
> The only way a distro that doesn't update to major version can cope with
> this is through patching, or to update to the latest state of the branch.
> Patching is problematic, branch updates can cause regressions.
> 
> I'm not saying that this attitude is good or bad: I'm playing devil's
> advocate and think in the perspective of the distros. In openSUSE we had
> permission to submit new major versions as so-called "maintenance updates"
> and IIRC Fedora does the same sometimes (feel free to correct me), but
> most of the distros (save rolling like Arch) don't.

The intention is not to blame any distribution for anything. The goal is to 
give users a way to identify distributions which fulfill the requirements for 
our software to run optimally. 

If for a specific distribution there are principles which are more important 
than meeting these requirements, then that's okay for the distribution and we 
don't blame them, but users should know that they can't expect KDE software to 
work perfectly on that distribution, and they should not blame us for it.
 
> > The same goes for dependencies: If a certain version of a dependency
> > causes bugs with our software, it is the distribution's job to fix that
> 
> However sometimes dependencies don't integrate too well with the distro,
> or need additional time to get worked out. Case in point: the current kdev-
> python beta *requires* Python 3.5 to work. Up until a few weeks ago, Python
> 3.5 could not get into openSUSE Tumbleweed due to some other, unrelated
> issues.
> 
> This means that kdev-python was not packageable until that issue was fixed
> (it is now).

There should be a communication channel for distributions to notify us "Hey, 
we know we currently don't meet the dependency requirements because of this 
and that problem, but we're working on it", so if whoever administers the 
outreach program can cut the distribution some slack.

> Other issues may be distro processes: again I'm speaking about openSUSE as
> I know most of the process, but new packages (so even deps) need to go
> through legal and security review, and that may take time.

That is fine as well: If we know that, we know when we can expect current 
packages to arrive in that distribution. And unless these processes take 
months to complete, it should not be much of a problem (unless it's about a 
critical security vulnerability, but distributions have special processes to 
get those fixed asap anyway, don't they?)

> > Maybe not "special mentions", but when people come from our websites and
> > want to know which distros ship our software, it would be nice for them
> 
> My issue is mainly to prevent "perceived endorsement", which I think should
> be avoided.

Would a "Runs KDE software optimally" kind of badge not be perceived as an 
endorsement?
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] RFC: Distribution outreach program

2016-01-29 Thread Thomas Pfeiffer
On Freitag, 29. Januar 2016 16:44:49 CET Luca Beltrame wrote:
> Il Fri, 29 Jan 2016 17:06:14 +0100, Thomas Pfeiffer ha scritto:
> > I believe that we can improve the situation by intensifying our
> > cooperation with distributions even further. On the other hand, however,
> > distributions also have to do their part in order to make our software
> 
> Some distros already do this (Kubuntu, openSUSE). I've been wearing two
> hats (KDE and openSUSE) for a while exactly for this purpose: keep
> upstream-downstream relationships optimal.

Which is good and I think should be honored!
 
> >  - How fast do they have to deliver our newest major as well as minor
> >  releases - Which version of our dependencies they should ship with each
> 
> If we value just speed, this is kind of problematic by itself:
> - Some distros (Arch) are faster than others in pushing out updates by
> virtue of their model
> - Some distros will *not* be able to update due to policies (Debian)
> - Some distros will update but they won't be "fast" due to internal QA
> processes (e.g. openSUSE with openQA, but possibly others)

Good points!
Maybe the speed of upgrading as such is not the actual point. What I care 
about is the speed with which bugfixes reach end users. If a distribution 
decides to backport all bugfixes from a new major release to theirs and does 
that job well, I'm fine with that.
However we've seen in the past that some distros which won't ship the most 
recent release won't backport bugs fixed in it, either, leaving users with 
sometimes serious bugs for way too long. This is what should be avoided.

The same goes for dependencies: If a certain version of a dependency causes 
bugs with our software, it is the distribution's job to fix that situation, not 
ours. We should not have to work around outdated versions of something further 
down the stack.

> >  - With which options they should compile and package our software -
> 
> Most of them use all or almost all optional features.

These were just illustrative examples. Since I'm not a technical person, some 
of them may be irrelevant, I may have missed others. It should be the 
developers who set the criteria.

> [...]
> 
> > What do you think?
> 
> I would rather keep the badges but not do "special mentions" or something.
> Some distros may be very willing to improve their KDE software experience,
> but not able to do so due to policies.

Maybe not "special mentions", but when people come from our websites and want 
to know which distros ship our software, it would be nice for them to see 
right in that list which distros it works best on. We can also just write 
"Look out for our badge for the best experience" on the page, but that just 
shifts effort from us to the user.

> That said, I hope I don't sound too negative. I think it's a great idea
> and should be definitely pushed forward.

No no, you don't sound negative! I found your comments to be very constructive 
and helpful!

Thanks,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-24 Thread Thomas Pfeiffer
> KDE: control your digital life

and

> KDE - Be in control of your digital life.

are both fantastic taglines, but not really visions. 
They sound like KDE already allows that _today_, it's not talking about a goal 
for the future to aim for.

We should keep one of those as a tagline for KDE, one we can put on marketing 
material of all kinds, but I think it's a bit too short for a vision for the 
future.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-29 Thread Thomas Pfeiffer
On Montag, 22. Februar 2016 23:05:49 CET Alexander Neundorf wrote:
> On Monday, February 15, 2016 18:36:18 Lydia Pintscher wrote:
> > Hi everyone,
> > 
> > A bit less than two weeks ago we sent the first draft for the
> > community vision for KDE. We have gotten a lot of useful feedback and
> > have now put this into a second draft. It reads as follows:
> > "KDE creates technology for a world in which everyone has freedom,
> > privacy and control over their digital life."
> > If there is anything that you disagree with about that vision, please
> > speak up. Otherwise, expressing your agreement is helpful as well!
> > 
> > There seems to be significant agreement on the principles encoded in
> > this vision. Therefore I'd like us to give this a final polish now and
> > if needed go for a third draft (which then should be the last one to
> > not stall this forever). This is a draft for a vision for what kind of
> > world the community aims for, it's not a product vision. As there
> > still seems to be disagreement on the product vision, Thomas will
> > address that in a separate email.
> 
> there's no strong disagreement with your proposal among the supporters of
> the "focused" draft, given that it'll be accompanied by a product
> vision/mission.

I'm happy that we've come to a point where it shows that we all have the same 
goal in mind in the end.

We also all agree that a vision without a mission provides motivation, but 
hardly any guidance, and therefore formulating a mission is absolutely 
necessary.
 
> So, can we try to get that done in one go ?

This is where I see a problem. The whole vision definition process has dragged 
on for quite a while now, which was necessary to get everyone on board, but 
also exhausting.

Defining a mission will take quite a while as well, and if we wait with 
publishing a vision until the mission step is completed, it could be 
frustrating for many who have participated in the vision process and just want 
to see something come out of it already. 

I would therefore suggest to publish the vision once we've agreed on it, but 
in its announcement point out clearly that we now need a mission to lay out 
how we want to work towards that vision, and that this process has already 
started. 
We could even link to a wiki page where the work in progress is documented, 
where you could paste most of what you've already written in your vision draft 
and which is very useful for a mission statement, plus the many points for a 
mission that have come up over the course of the discussions we've head here 
over the past weeks.
That way people could already see where the mission might be headed, and chime 
in if they agree, disagree or have something to add.

The "common product vision" I've mentioned would be another thing that could 
be pursued in parallel to that, but which I see as not directly related to a 
mission for KDE as a community.

Would such a course of action address your concerns?

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-26 Thread Thomas Pfeiffer
On Freitag, 26. Februar 2016 18:58:49 CET Alexander Dymo wrote:
> On Fri, Feb 26, 2016 at 6:01 PM, Jos Poortvliet  wrote:
> > Note that our slogan is: "A safe home for all your data"
> > "Access & share your files, calendars, contacts, mail & more from any
> > device, on your terms"
> I wish we could come up with similarly specific vision for KDE

Only that 
1. The latter part is _not_ part of ownCloud's vision. It's the byline to 
their slogan.
2. ownCloud is _one_ product. A very versatile one, yes, but still a single 
product, not a whole community with dozens of individual products.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-15 Thread Thomas Pfeiffer
On Montag, 15. Februar 2016 21:49:58 CET Alexander Neundorf wrote:
> On Monday, February 15, 2016 18:36:18 Lydia Pintscher wrote:
> > Hi everyone,
> > 
> > A bit less than two weeks ago we sent the first draft for the
> > community vision for KDE. We have gotten a lot of useful feedback and
> > have now put this into a second draft. It reads as follows:
> > "KDE creates technology for a world in which everyone has freedom,
> > privacy and control over their digital life."
> 
> just to make sure: this intentionally uses "technology" and not "software" ?

Yes, this is intentional. Since the vision is supposed to merely outline the 
future we want to live in, not how to get there, we did not want to restrict 
ourselves to software.

If, say, 10 years down the road, hard- and software is so much intertwined 
that we cannot influence the future with software alone anymore, we don't want 
people to say "But our vision says we only do software!".
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-15 Thread Thomas Pfeiffer
On Montag, 15. Februar 2016 21:37:49 CET Laszlo Papp wrote:
> In which case, what if digital life is not the future?

If the world goes completely back to pen and paper, I fear KDE becomes 
obsolete, because I don't think we could adapt to that world.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-16 Thread Thomas Pfeiffer
On Mittwoch, 17. Februar 2016 00:01:39 CET Ingo Klöcker wrote:
> > What I want to say, in my opinion a guiding statement like a vision
> > should emphasize the main strengths, the main direction, and doesn't
> > need to be worded as broad so that it really covers every nuance.
> 
> The vision is not a guiding statement, the mission is. It's the mission
> which details/specifies how we intend to fulfill the vision. IOW, the
> mission statement gives the direction you are seeking for. The mission
> statement would probably state that we will write software with focus on
> UI applications to reach this goal.

Yes, Ingo's interpretation of vision and mission fully matches mine. I'd still 
call a vision a "guiding statement", in the way that the goal itself does 
already provide "guidance". It's not a step-by-step guidance, however, that's 
what the mission is for.

> > On Monday, February 15, 2016 22:27:14 Thomas Pfeiffer wrote:
> > > If, say, 10 years down the road, hard- and software is so much
> > > intertwined that we cannot influence the future with software alone
> > > anymore, we don't want people to say "But our vision says we only
> > > do software!".
> > 
> > Since we are talking about technology, especially a fast evolving
> > technology, I'm sure a vision for a technology project could also be
> > updated. :-)
> 
> Yes, but if we can avoid it (by using a broader vision in the first
> place), then we should avoid it. OTOH, the mission is supposed to be
> updated, e.g. if the world around us changes in a way which makes it
> unwise not to start creating hardware to fulfill our vision.

Yes, that's our intention, at least.
The vision is a long-term goal, so why not make our lives easier by defining it 
in a way that reduces the need for updating it?
The mission will change more often, anyway, because the strategy likely has to 
be adapted to changed circumstances or because we might have found that our 
current path isn't bringing us closer to our goal.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-17 Thread Thomas Pfeiffer
On Dienstag, 16. Februar 2016 21:20:25 CET Valorie Zimmerman wrote:

> I think it could be stated more gracefully. How about:
> 
> KDE aspires to a world where all users of our technology experience
> freedom, privacy and control over their digital lives.

But doesn't that mean we don't care how many users we have, as long as those 
users have freedom, privacy and control? I don't see much ambition in this, to 
be honest. It sounds like "Hey, let's improve the lives of a tiny niche of 
people!" to me.

> Short version:
> 
> KDE: freedom, privacy, control of your digital life

I do like the short version, but I wouldn't change the long version to what 
you suggested, to be honest.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - second draft for discussion

2016-02-17 Thread Thomas Pfeiffer
On Mittwoch, 17. Februar 2016 12:06:06 CET you wrote:
> On Wednesday, 17 February 2016 12:46:26 GMT Thomas Pfeiffer wrote:
> > On Dienstag, 16. Februar 2016 21:20:25 CET Valorie Zimmerman wrote:
> > > I think it could be stated more gracefully. How about:
> > > 
> > > KDE aspires to a world where all users of our technology experience
> > > freedom, privacy and control over their digital lives.
> > 
> > But doesn't that mean we don't care how many users we have, as long as
> > those users have freedom, privacy and control? I don't see much ambition
> > in this, to be honest. It sounds like "Hey, let's improve the lives of a
> > tiny niche of people!" to me.
> 
>   This is, however, an important point, i feel. While i'm sure we'd all like
> to see KDE's software all over the world and so on, is world domination
> (said with my tongue stuck firmly in my cheek) actually something that's a
> part of our vision? For myself, i'm simply not sure, but this does seem to
> be a question that'd need to be considered.

Of course it is. 
I'm sorry if my comment came across as "Valorie's suggestion is wrong", I just 
meant that it doesn't reflect _my_ ambitions (or that of the rest of the team 
who produced that draft).

We don't think that KDE _alone_ can create a world where everyone enjoys 
freedom, privacy and control, that would be unrealistic.
"World domination", no matter how deeply burying our tongue in our cheeks, is 
not our goal, either. 

The problem is: If all we aim for is for our users to have freedom, privacy 
and control, then if our software provides all that, even if it were used only 
by a handful of people, we'd still have reached our goal and there would be 
nothing more for us to do (except keeping it that way). Actually, I think 
fulfilling this vision would be pretty easy. It doesn't take much to provide 
freedom, privacy and control, actually. The difficult part is providing it in a 
way that is _attractive to users_ . 
And to provide motivation for the second part, from my perspective the goal 
should be to reach as many users as possible.

So here's the thing: It might sound a bit counter-intuitive at first, but I 
firmly believe that a vision works best if it is, realistically, pretty much 
unreachable. It has to always be possible to measure _progress towards_ the 
goals in the vision so you can tell if you're on the right track, but if you 
make your goal easily reachable, it loses all its motivational value, and you 
can basically pack up and go home, maybe leave a few people to maintain that 
status.

As was already said in the vision discussions: Matthias Ettrich's original 
vision for KDE has been fulfilled now, and therefore has lost its value. Of 
course an alternative approach can be to create reachable visions, and once 
reached, define a new one.
However, given how much time and energy it's costing us to come up with our 
second vision, I don't know if I want to do that every few years.

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Vision, mission and manifesto - what is their definition and purpose?

2016-02-10 Thread Thomas Pfeiffer
On Mittwoch, 10. Februar 2016 21:42:31 CET Alexander Neundorf wrote:
> > In the past, the KDE usability team (namely Björn, Heiko and I) have at
> > least twice suggested to create a common vision for KDE's products.
> > This approach has received mostly negative comments every time, with the
> > argument that there is far too much diversity among existing KDE projects
> > to define a common product vision which is still useful, and that
> > individual product visions would be much more helpful.
> 
> I can remember having read about that somewhere...
> As you have seen, the argument that KDE is so diverse has been brought here
> too several times, but from what I know there is still very much in common.
> 
> Maybe your KDE product vision effort should be brought into scope again when
> we are talking now here about a vision etc. ? Do you have some pointers ?

I have given up on this effort, to be honest. The community felt that such a 
thing didn't make sense for them the last two times we proposed it, I don't 
see why this would have changed now. I don't want to force anybody.
I won't keep you from suggesting it again, of course, and if it turns out that 
the community now wants that for some reason, I'm happy to throw my experience 
with creating product visions in the ring.
However, you won't see me trying the same thing a third time after it failed 
twice.

> > > Also, what do you think about the relation between vision and mission ?
> > 
> > When I joined the "vision team", my original proposal was to only define a
> > mission, because I felt that visions make more sense for products than for
> > communities.
> > However, Lydia convinced me that having a common vision for the future to
> > work towards can have more positive effect on a sense of purpose and
> > motivation than only defining a strategy, so I agreed to define a vision
> > first and then derive the mission from that.
> 
> That's just Lydias opinion. ;-)

It was originally Lydia's opinion (based on her experience with Wikimedia's 
success), but now that she convinced me and the the other members of the team 
behind "Draft A", it is our common opinion.

> No, seriously, in the last weeks several people contacted me in private
> email and expressed that they are not exactly happy, some even seriously
> frustrated with the strong emphasis on non-technical topics in KDE in the
> last few years, and they would prefer to get some more emphasis on
> technology and products back.
> This (obviously) includes me. Maybe this also includes many of the people
> who said "vision, strategy and focus" in the evolve-survey ?
> 
> Sorry to be blunt: for me, a catchy one-sentence-vision statement *alone*
> won't impress me, everyone has one today. It won't give me a sense of
> purpose or anything. It's just a catchy phrase. Maybe I'm too old for that.

A vision statement alone doesn't do much, either. A mission is needed to turn 
vision into strategy.

> Anyway, I think vision and mission should be defined together, otherwise
> we'll get ugly discussions once we have decided on the vision, and get into
> mission- land.

The discussions cannot be avoided (though I believe they don't have to be 
ugly!), but it seems to me that the two "camps" are much closer in their 
ultimate goal than they are in what they see as the best strategy to achieve 
it.
So what is bad about first declaring what we agree on and then debate on the 
level where we actually disagree?
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - final version

2016-03-14 Thread Thomas Pfeiffer
On Montag, 14. März 2016 22:39:13 CET Alexander Neundorf wrote:
> On Monday, March 14, 2016 14:58:57 Lydia Pintscher wrote:
> ...
> 
> > * collect input for our mission statement. Alexander and others have
> > already collected a lot of that. I have created a page on-wiki for
> > this here: https://community.kde.org/KDE/Mission/Brainstorming
> 
> I added a very short version of the stuff we had there. I hope the format is
> more or less as you intended.

Thank you for adding your notes to get us started with this!
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] KDE Mission - let's do this!

2016-03-30 Thread Thomas Pfeiffer
Hi everyone,
now that we've finally agreed on a vision for KDE [1] and have that out of the 
way, we can fully focus on how we want work towards that vision.
Alex has already set up a Wiki page for brainstorming notes [2], so it would 
be great if everyone who has opinions or ideas about how we can nudge the 
world towards the one we envision could add them to it.
It's really just brainstorming, no ideas are "bad" or anything, everyone and 
everything is welcome!

I'd suggest that we let the brainstorming phase last until Friday and then 
start discussing the ideas collected on that Wiki page.

So now let's focus our brains on the KDE Mission and please fill the wiki page!
Thanks,
Thomas

[1] https://community.kde.org/KDE/Vision
[2] https://community.kde.org/KDE/Mission/Brainstorming
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE e.V. Community Report for 1st Half of 2015

2016-04-08 Thread Thomas Pfeiffer
On Freitag, 8. April 2016 19:31:18 CEST Sandro Andrade wrote:
> On Fri, Apr 8, 2016 at 2:12 PM, Clemens Toennies
> 
>  wrote:
> > On Freitag, 8. April 2016 02:47:12 CEST Sandro Andrade wrote:
> >>> I'm happy to inform you that we have just published the KDE e.V
> >>> Community Report for 1st half of 2015:
> >>> 
> >>> https://ev.kde.org/reports/ev-2015H1/
> > 
> > This looks and reads really awesome!
> > Are there plans to use the design also on the other parts of
> > https://ev.kde.org/ ?
> 
> Hi Clemens,
> 
> We haven't considered expanding it to ev.kde.org. Maybe it's worth
> to coordinate with kde-www team and hear their general plans to
> revamp KDE websites. IIRC, some work were done at CERN sprint
> but I'm unsure if it was content-related only or if it also encompassed
> layout/design issues.

Ken Vermette (from the VDG) is currently spearheading a redesign effort for 
the KDE web presence.
He has worked at CERN on website layout and continues to do so. Might be an 
idea to coordinate with him.

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE e.V. Community Report for 1st Half of 2015

2016-04-08 Thread Thomas Pfeiffer
On Freitag, 8. April 2016 02:47:12 CEST Sandro Andrade wrote:
> Hi there,

Hi Sandro,
 
> I'm happy to inform you that we have just published the KDE e.V
> Community Report for 1st half of 2015:

Thank you for doing this...

> http://ev.kde.org/reports/ev-quarterly-2014_Q4.pdf

...this is the wrong link, though ;)

Here is the correct one:
https://ev.kde.org/reports/ev-2015H1/

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Looking for new doors to open for KDE

2016-04-11 Thread Thomas Pfeiffer
On Montag, 11. April 2016 23:39:57 CEST Agustin Benito (toscalix) wrote:
> Hi all,
> 
> I was unsure if this is the the right list for this since I a not
> subscribed to plasma ML.. If not, apologies.
> 
> The last few months I have been working on a project that could be an
> interesting experiment for KDE. It is called GDP[1] (GENIVI Demo
> Platform).
> 
> GENIVI Alliance[2] is a group of 140 companies that design, spec and
> develop Open Source middleware for automotive. GDP is GENIVI's
> integration and delivery effort to ease the adoption, test and
> development of those Open Source middleware components, specially
> IVI[3] ones. To build the platform, Yocto project is being used. We
> are currently working on porting GDP-ivi9 to QEMU, Renesas Porter and
> RPi2 boards.
> 
> Why this project might be of interest for KDE?
> 
> In the coming days the GDP delivery team will release GDP-ivi9, which
> includes Qt 5.3.2. In May we will start working in the new version,
> which will hopefully bring a newer Qt version..The coming weeks we
> will be collecting requests and discuss them, so this could be the
> perfect time to evaluate Plasma on GDP..
> 
> GDP is being used by many companies as a platform to demo applications
> and other software components for the automotive sector, specially in
> R environments .
> 
> Automotive is a sector that is currently moving from consuming Open
> Source to producing it. This initiative would provide KDE a potential
> new market for applications and it would reinforce KDE project in the
> embedded world, beyond mobile, increasing Qt ecosystem interest in our
> community.
> 
> What do we need?
> 
> My team is in charge of the integration and delivery of GDP. We can
> work with KDE contributors to bring Plasma 5 into GDP. But first KDE
> experts needs to evaluate if it is feasible and make sense.
> 
> How to get GDP?
> 
> Check the Download page[4] for the GDP-ivi9 RC1 for QEMU. If you know
> about YOCTO, you can build GDP from scratch. The new version will be
> available next week with easier to consume images.
> 
> I would love to find a way to promote KDE in a new industry:
> automotive. Drop me an e-mail or answer here if you think you can help
> to evaluate this possibility.

Hi Agustin,
this does indeed sound like a great opportunity for us!
I cannot give any feedback on the technical side, of course, but if there is 
any way I can help with my area of expertise, I'd be glad to!
Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this!

2016-04-11 Thread Thomas Pfeiffer
On Donnerstag, 31. März 2016 23:12:15 CEST Alexander Neundorf wrote:
> > I'd suggest that we let the brainstorming phase last until Friday and then
> > start discussing the ideas collected on that Wiki page.
> 
> two days is quite short (I just saw it right now).
> Let's have a week at least, i.e. April 10th ?

Okay everybody, we've had a little more than a week for collecting 
brainstorming ideas for the mission now on
https://community.kde.org/KDE/Mission/Brainstorming
Unfortunately, only six people have put their ideas on the wiki, but what we 
have there should give us a good start for a discussion, anyway.

From what I see on the wiki, there are three questions we should try to answer 
first:

1. Should the mission focus mostly on our organizational/community strategy, 
our product strategy, or both?

2. Our vision is to have an impact on everybody's lives. Should we keep our 
mission equally broad, or should our mission focus on (a) certain target 
audience(s) as a "door-opener" to reach everybody, and if so, which target 
audience(s) should we focus on?

3. What can our unique contribution to our vision (which is certainly shared 
by others as well) be?

There are the things which who put their ideas on the wiki already seem to 
agree on:
- A well-integrated suite of desktop+applications+frameworks
- Cross-platform, cross-device/convergent
- Providing privacy combined with a great user experience
- Supporting proprietary services as a "necessary evil", but not as the final 
goal

Now I hope that more than the six of us who put ideas on the wiki will join 
this discussion, so that we end up with a mission that all of KDE can identify 
with.

Looking forward to a fruitful, cooperative discussion,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - final version

2016-03-19 Thread Thomas Pfeiffer
On Samstag, 19. März 2016 21:52:09 CET Michael Brade wrote:
> Am 19.03.2016 um 21:30 schrieb Alexander Neundorf:
> > On Tuesday, March 15, 2016 22:53:03 David Jarvie wrote:
> > ...
> > 
> >> This may read a bit better, although it does slightly alter the emphasis:
> >> 
> >> "A world in which everyone has control over their digital life and enjoys
> >> freedom and privacy."
> > 
> > How about one more tweak ?
> > 
> > "A world in which everyone can manage their digital life enjoying freedom
> > and privacy."

One can "manage" something without having full control over it, so I'd like us 
to keep the control part in there.

> Well, that's two tweaks (SCNR ;)
> 
> But I like the idea, so how about really just one tweak: getting rid of
> the double "and":
> 
> 
> "A world in which everyone has control over their digital life, enjoying
> freedom and privacy."

Makes it even better!
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - final version

2016-03-27 Thread Thomas Pfeiffer
On Dienstag, 22. März 2016 17:24:40 CEST Sune Vuorela wrote:
> On 2016-03-15, David Jarvie  wrote:
> >>> > "A world in which everyone enjoys freedom and privacy and has
> >>
> >>control
> >>
> >>> > over their digital life."
> > 

"A world in which everyone has control over their digital life and enjoys
freedom and privacy."

> I've not been able to follow all these discussions (due to busy life). I
> did fear a bit what the outcome could have been from these discussions.
> 
> But. This is amazing.
> 
> Yes. That's exactly why I'm here.

Looks like we've finally found what we've been searching for!

Now let's get this out into the world next week and start working on the 
mission!

Thank you everyone involved, it was a tough nut to crack but the patience and 
effort has paid off!
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-04-01 Thread Thomas Pfeiffer
On Freitag, 1. April 2016 21:54:10 CEST Ben Cooksley wrote:

> Out of curiosity, how are the Appstream files accessed by tools such
> as the various app centers?
> I presume some kind of repository exists?

Nope, actually distributions extract the appstream data from the source code 
of each application and generate their own AppStream database. 
 
> If so, it may be worth pulling the information you need Boudhayan from
> such a repository ( although the indexing process will undoubtedly
> require either source code checkouts or compiled code, in which case
> we'll probably have to use what the CI system has and pick a branch
> group to represent - probably stable-kf5-qt5. More details on this
> would be nice )

We could theoretically just tap into a distribution's AppStream database if 
that makes our lives easier, or just reuse their code to extract the data and 
create the database.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this!

2016-04-28 Thread Thomas Pfeiffer
Hi everyone,
as we've found during the vision creation process that having a concrete draft 
to work from can streamline the discussion, I tried to come up with one.
It goes quite into detail, but I think this is necessary in order to be useful 
as practical guidance.

To fulfill our vision, KDE has taken on the mission to create products which 
 - give users control, freedom and privacy
 - convince them - through excellent user experience - to switch away from 
products which don't give them that
 - reach them where they are

To provide control, freedom and privacy, KDE's products
- allow users to "tinker" with them
- apply open standards to prevent "lock-in"
- integrate well with existing online services sharing the same values, or 
create their own where those do not exist
- never collect or transmit information about users without their explicit 
consent ("opt-in")
- strive to provide usable security and privacy features to protect against 
surveillance and data theft

To create a convincing user experience, KDE's products aim to
- have consistent, easy to use human interfaces
- provide users with _at least_ the features and quality they expect coming 
from non-free products
- be at the forefront of emerging trends like mobile/desktop convergence
- integrate well with other Free products to complete the experience

To reach users where they are, KDE 
- strives to make our products available on major Free but also proprietary 
operating systems and platforms, mostly by applying Qt as a technology that 
allows easy portability
- aims for a presence on all relevant device classes (desktop, mobile, 
embedded)
- continues to offer a "classic desktop" product which makes the switch from 
proprietary operating easy
- offers products that also inter-operate with proprietary software, formats 
and services in order to ease the transition to Free alternatives

---
Now we have concrete points we can discuss and fine-tune.
Looking forward to your reactions,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this!

2016-04-29 Thread Thomas Pfeiffer
On Freitag, 29. April 2016 14:32:33 CEST Olivier Churlaud wrote:

> > As Aleix said, what do you mean exactly with that ?
> > I could interpret it as
> > - sources are available
> > - it is easy to build
> > - it's highly configurable
> > - data is stored in easily accessible formats (text, or documented binary,
> > or binary with low level tools, etc) ?
> 
> I think the 2 first are normal for FOSS. What we should emphasis on is
> more the 3rd and 4th point. 3rd for users to have more power, 4th for
> them to be sure that if one day KDE dies (not soon hopefully :D), their
> data are not lost.I like your draft.

Makes sense. How would you phrase the two points?

> > It does not mention providing libraries explicitely, but focuses only on
> > applications (if I didn't miss it).
> > Is that something which should be added ?
> 
> I like this draft and everything you answered. I think one should
> emphasis on the libraries as well in order to show that our target users
> are not only end-users but developers as well.
> I would really like that someone who uses Qt is able to say "Oh the KDE
> Frameworks are great, let's reuse that instead of rewritting from
> scratch!" Like people use V-PLay or what not based on Qt.

See my reply to Alex' email for that.

> Something else: I'm not sure it should be part of the mission: the way
> to achieve all this? Having common user interface design (work with the
> VDG), same type of configuration windows (use Frameworks libraries),
> having webpresence (up to date websites, documentation online,...).
> I write this last part (webpresence) because I think it's somewhere we
> are not so good at, and being part of the mission could put some
> incentive on it. We really need that to get more users IMOH.

Good points!
This is kind of a "third level", because it describes how we want to achieve a 
good user experience.

I think we definitely should document those things clearly. The question is if 
they should go into a third document (which could be called "Strategy") in 
order to not make the mission too long, or if it should be right there with 
the mission. I'm a bit unsure here, as both alternatives would have benefits 
and drawbacks.

Thank you for the input,.
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this!

2016-04-29 Thread Thomas Pfeiffer
On Donnerstag, 28. April 2016 22:43:02 CEST Alexander Neundorf wrote:

> 
> Does the order of the sections imply priorities ?
> E.g. "tinkering" comes before "presence on all device classes" ?

Not really, I just put them in the order they came to my mind. If you think a 
different order makes more sense, I'm absolutely fine with that.

> > To provide control, freedom and privacy, KDE's products
> > - allow users to "tinker" with them
> 
> As Aleix said, what do you mean exactly with that ?
> I could interpret it as
> - sources are available
> - it is easy to build
> - it's highly configurable
> - data is stored in easily accessible formats (text, or documented binary,
> or binary with low level tools, etc) ?

I had all of them in mind (except "easy to build", but tha's just because I if 
I build software myself, I always use scripts that make it easy to build, 
anyway).
Should we put all of them in separate bullets instead?
 
> > - apply open standards to prevent "lock-in"
> > - integrate well with existing online services sharing the same values, or
> > create their own where those do not exist
> 
> I wouldn't want to restrict us to integrating well with online services
> which share the same values.
> This implies to me that good integration with e.g. Facebook or being able to
> use a kdepim client to connect to an Outlook server is not a top priority
> for us. Both are ...very important for a large set of users. More or less
> everybody is on Facebook, if you need to work with an Outlook server at
> your job it would be great to be able to do that using at least a client
> which gives you freedom and privacy.

From my perspective, integrating well with services that track users to sell 
information on them and/or lock them into a certain ecosystem does not promote 
users' control, freedom or privacy at all.
That's why for me, integrating with those is purely a part of "reaching users 
where they are", not of giving them control, freedom and privacy. See also my 
reply to your other email.

> > - provide users with _at least_ the features and quality they expect
> > coming
> > from non-free products
> 
> Well, we have the advantage that our software is free, so we offer freedom,
> independency and (if we are successful with that) privacy, something
> non-free software just can't do. If our software is also stable and
> reliable then, I can very well live with software which has somewhat less
> features than non- free products.

While I, as a user, have the same perspective as you do, I fear that this is 
not ambitious enough given our goal is to give control, freedom and privacy to 
_everyone_ . If we think that freedom and privacy should be enough to convince 
people, we only reach those who value these highly. All those for whom they 
are nice, but not very important won't sacrifice functionality or quality for 
them.

> > - be at the forefront of emerging trends like mobile/desktop convergence
> 
> Boring engineer speaking:  Nice goal. Not sure how realistic this is.
> We have only a very limited number of full-time developers, so aiming for
> very advanced, complex solutions can quickly require more resources
> (developer time, for new devices also actual money) than we have.

"Be at the forefront" may be a bit marketing-speech, but currently, 
convergence is clearly a goal for us, for Plasma as well as applications.
Kirigami is all about convergence, and there are several convergence-ready 
applications currently in development.

I think it KDE would be in a much better place right now if we had embraced 
emerging trends like cloud, mobile and now convergence earlier. Especially 
young developers want to do things which are hip and cool _now_, not things 
that were hip and cool five years ago.

If we don't even aim to embrace emerging trends due to our limited man-power, 
we create a nice little self-fulfilling prophecy / vicious circle for 
ourselves.

> > - integrate well with other Free products to complete the experience
> > 
> > To reach users where they are, KDE
> > - strives to make our products available on major Free but also
> > proprietary
> > operating systems and platforms, mostly by applying Qt as a technology
> > that
> > allows easy portability
> 
> I'd simply put "Free and propriety" instead of "Free but also proprietary",
> so they both sound like equally first class target platforms.

We obviously have different opinions here. While I agree with you that 
proprietary platforms should get much more attention from us than they do now, 
I'd still like to give Free platforms a higher priority, because according to 
our vision, that's where we want people to end up eventually.
 
> > - aims for a presence on all relevant device classes (desktop, mobile,
> > embedded)
> 
> To me this means e.g. that we'll try to get our applications running on
> Android (good !). Is this how this is intended ?

Android is a platform, "mobile" is a device class. Android is certainly a very 
important 

Re: [kde-community] A new home for Mozilla Thunderbird at KDE?

2016-04-26 Thread Thomas Pfeiffer
On Dienstag, 26. April 2016 16:03:43 CEST Jos van den Oever wrote:
> Hello KDE-ers,
> 
> Mozilla Thunderbird is looking for a new home [1]. They are evaluating a
> number of options. KDE was not in the initial list of options, but I think
> KDE and Thunderbird would be an excellent fit.
> 
> This mail goes to kde-community@kde.org and to a number KDE members that
> work on email. Please respond to kde-community to keep the thread on one
> place.
> 
> I would like to hear what you think about the idea of Mozilla Thunderbird
> joining KDE next to KMail, Kontact, Kube, and Trojita. I think we can all
> benefit from being in one community and infrastructure.
> 
> Best regards,
> Jos
> 
> https://lwn.net/Articles/685060/

I'm all for offering Thunderbird to join KDE!
This is not because I wouldn't believe in our own E-Mail offerings (otherwise 
I wouldn't be part of the Kube team as well as mentor a university project 
within KMail, would I?), but because KDE has never had a problem of being home 
to multiple applications in the same area, and I think they'd be more likely 
to benefit from one another than to "cannibalize" each other.

I also believe that showing a welcoming attitude towards popular projects 
looking for a new home can only benefit us in general.

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-20 Thread Thomas Pfeiffer
On Freitag, 20. Mai 2016 00:14:36 CEST Alexander Neundorf wrote:
> Hi,
> 
> On Wednesday 18 May 2016 23:43:12 Thomas Pfeiffer wrote:
> ...
> 
> > I have created a survey draft at
> > http://survey.kde.org/index.php/858172/lang-en
> > 
> > Now please everybody click through it and give feedback on anything that
> > you think should be changed.
> > 
> > Once it feels like we agree on the survey, I'll publish it on the Dot and
> > on the kde-community and kde-devel mailing lists, hoping to reach most
> > KDE contributors and interested users.
> 
> here are a few comments:
> 
> 
> Section "Support for services"
> --
> - there's a typo "servies"

Thanks, fixed.

> - the first point says "Focus more in [free services]", the third point says
> "Focus on [dominating services]". I would put the "more" also in the third
> point. Or maybe for both use "prioritize support for [Free/dominating]
> services" ?

Good point! I'll go for "prioritize support". It's a bit more difficult 
language, but also more clear on the other hand.

> 
> Section "I consider myself"
> ---
> 
> I consider myself as "formerly very active, now only sporadically active,
> and still cares a lot". Which should I check ?

Hm, so how about
... a regularly active KDE contributor
... a sporadically active KDE contributor
... a formerly active KDE contributor who still cares about KDE

Would that work?

> Section "To promote the development of Free software in general"
> ---
> 
> There's the option "...provide ... libraries which  facilitate the
> development of ... Qt applications".
> Personally I agree with this point, but not necessarily  as "promote ...
> Free software", but as a useful tool for developers, also for proprietary
> applications (... to pull also those developers into KDE).
> Can we make that somehow into a question ?
> Maybe
> "Should KDE libraries target mainly
> * free software developers
> * both free and proprietary software developers" ?
 
The reason why I listed libraries only under that aspect is that I wanted to 
make sure that all aspects of the mission relate to the vision.

Is getting new contributors for our libraries (and by extension to KDE in 
general) the reason why we make them available for proprietary applications as 
well?
In that case, how does that relate to our vision?
 
> Misc
> 
> 
> * I'd like to have a point like "reliable, backwards compatible and stable"
> somewhere. Maybe in "How important are the following aspects" ?

Ok, I can add that to the user experience point.
I'm not sure if "backwards compatible" is clear enough, though. Backwards 
compatible regarding what? Data formats?
And what is the difference between "stable" and "reliable" in this regard? 

> * Should there be a question about the group of users ? Or do we just assume
> all users are equally important ? Like
> - home users
> - business/office users
> - schools/universities/(kindergarten ?)
> - developers
> - FLOSS geeks

A question about our target audience makes sense, yes. I've added one with 
these options:

"Regular" home users
Free software enthusiasts
Business/ office users
Students (at schools or universities)
Children
Developers
System administrators
"Specialists" (e.g. scientists, engineers, artists, ...)
Everyone
 
> * Would it make sense to have two additional levels, like "absolutely must"
> and "not at all, never" ? (I would consider many points very important, but
> a few exceptionally, absolutely must).

Hm. I could change the labels for the extremes to "Not useful at all" and 
"Essential". Not sure if the scale should be extended to 7, though.
 
> * I'm not too happy with the "How should KDE treat Free vs. Proprietary OS"
> section.
> E.g. for Windows and OSX vs. Linux and FreeBSD I would say "equally", which
> translates to "make Windows and OSX first class targets" (while they are
> second class right now).
> OTOH, does Android count as Free or proprietary ?
> And, when asking focus on Android or Plasma Mobile, I would actually say
> getting KDE applications onto Android is more important, since that we
> millions of users can quickly benefit from all the advantages (freedom,
> control, etc.) KDE provides.
> Could the survey ask something like
> "How should KDE treat the following OS
> - Linux
> - FreeBSD
> - Other BSDs, Hurd, etc.
> - Windows
> - OSX
> - Mobile Linux (Mer, Pla

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-23 Thread Thomas Pfeiffer
On Montag, 23. Mai 2016 17:03:11 CEST Martin Graesslin wrote:
> On Wednesday, May 18, 2016 11:43:12 PM CEST Thomas Pfeiffer wrote:
> > I have created a survey draft at
> > http://survey.kde.org/index.php/858172/lang-en
> > 
> > Now please everybody click through it and give feedback on anything that
> > you think should be changed.
> 
> I have a problem with answering
> "...strive to make our products available on all major Free and proprietary
> operating systems and platforms"
> 
> I'm all for making our apps available everywhere so would go very to the
> left, but for Plasma I would go very to the right. And thinking about it:
> not all products make sense everywhere. No matter how much I strive for it,
> KWin won't run on Windows (probably not even with the new Linux support in
> Windows 10).
> 
> So maybe that needs to be more fine grained? Worded differently?

Would replacing "products" with "applications" work? Since you consider KWin a 
systems component and not an application, this sentence should not be of 
concern to KWin, right?
I mean sure, there are still some actual applications which make no sense on 
Windows or Mac, but I assume there are so few of those that we don't have to 
mention them explicitly in our vision.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-18 Thread Thomas Pfeiffer
On Dienstag, 17. Mai 2016 22:06:30 CEST you wrote:
> > Hi Alex,
> > thank you for reminding me of the email I had been wanting to write today:
> > To be honest, I don't think the reach of this mailing list is the problem.
> > I've heard from quite a few people who have been following this
> > discussion,
> > but have not participated in it (for various reasons).
> > Therefore, I changed plans. Instead of trying to get more people to
> > participate in the discussion here, I will do what I'm trained to do: I'll
> > conduct a survey.
> > 
> > I think we've already come quite far with the draft and I don't think we
> > need much more open discussion. We have a quite good draft, but in several
> > points, we have your personal opinion against my personal opinion, and now
> > I think the next step whould be to find out what the majority (especially
> > the "silent majority") thinks.
> > 
> > Tomorrow I will try to identify the points which are still contested (and
> > I'm happy for you or others to contribute to that as well) and put them in
> > a survey (along with those on which we agree, just to make sure the
> > majority agrees with us as well) which I will spread via the Dot, this
> > list, the ev- membership list and maybe kde-devel just to be sure.
> > 
> > This survey will also invite people to join the mailing list discussion,
> > but will primarily aim to just get numbers on those issues where we don't
> > know what the majority thinks.
> > 
> > While I'm confident that we have found a Vision which everybody agrees to,
> > I feel that for some points of the Mission, we'll have to go with a
> > majority vote, because there are competing standpoints which are both
> > valid but cannot really be harmonized. On the other hand, I do not think
> > the standpoints are so far apart that those who prefer the minority
> > position would not be able to identify with the Mission as a whole
> > anymore if we adopted the majority position.
> > 
> > So, unless there are strong arguments against this approach, this is what
> > I
> > will do.
> 
> Sounds good, I'm happy to help.

I have created a survey draft at
http://survey.kde.org/index.php/858172/lang-en

Now please everybody click through it and give feedback on anything that you 
think should be changed.

Once it feels like we agree on the survey, I'll publish it on the Dot and on 
the kde-community and kde-devel mailing lists, hoping to reach most KDE 
contributors and interested users.

Thank you in advance for your feedback,
Thomas

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-22 Thread Thomas Pfeiffer
On Sonntag, 22. Mai 2016 15:38:39 CEST Agustin Benito (toscalix) wrote:

> One of our historical problems, in my opinion, has been our little
> engagement with the "commercial world". Words can help or holding us
> back from turning up side down our current situation.
> 
> Two examples:
> 
> I consider the word  "support" controversial. Support in commercial
> environments has a specific meaning. It is related with paid service.
> I would use a different word.

How about "compatibility with"?
 
> The other word is "product".
> 
> I understand that Open Source projects, and we are no exception, have
> a bigger and better "end to end" conscious. That is good. Still, there
> are several stages of what the commercial world understands as
> "product cycle" we do not cover. The motivation for creating
> "products" is also different, so the expected outcome.
> 
> I would use a different word in the Mission statement.

For me, using the word "product" is very important especially in the Mission 
statement. Yes, we currently do not treat what we make as "products", and I 
think that is a problem.
If there are stages of a product life-cycle we do not cover, than chances are 
that we _should_. Thinking in terms of products would remind us that we should 
think about quality, about bringing our products to market or about handling 
"end of life" properly.

This is one area where I think KDE is not "professional" enough, and it would 
be helpful especially for a better relationship with the "commercial world" if 
we improved that.

> ++ KDE and Qt
> 
> I think we should try to better reflect the aim that KDE has to become
> even more relevant in the Qt ecosystem, and how important it is to us.
> I read two references in the current draft:
> 
> * "strives to make our products available on all major Free and
> proprietary operating systems and platforms, for example by applying
> Qt as a technology that allows easy portability"
> * "provides frameworks and libraries which facilitate the development
> of high-quality Qt applications"
> 
> I would remove both references.
> 
> The first one is irrelevant. In the same way that we mentioned Qt we
> could have mentioned any other technology. In a mission statement
> every word counts. In fact, I think that in general we have too many
> already. It is not easy, I understand.

I had put that in because in the Vision discussion, several participants 
expressed their fear that KDE might be losing its focus on Qt, so I wanted to 
make clear that Qt is still very important to us and we are still very 
important for Qt.
Since the survey is there to find out what the majority of the community 
thinks, though, maybe I should add another question 
"Should a focus on Qt be stated in our Mission?"
Then we find out what the community thinks.
 
> The second one reduces our scope. I thought we agreed on being a host
> for different projects. It seems here that if it is not a Qt based
> app

We do host many different projects and they do not necessarily have to be Qt-
based, but do we want to host non-Qt _libraries_ as well?

> I would write instead a sentence that reflects the position within the
> Qt ecosystem we want to play and how important it is to us.

Suggestions for how to phrase such a question are welcome!

> ++ Free vs Open Source
> 
> I do not like the idea that "Open Source" is the default way for 99%
> of the world to refer to Free Software. Like most of you, I think it
> refers to a wider concept. open does not mean free, right? But,
> specially in commercial environments, that is the current state.
> 
> I propose to use "Open and Free Software", Free and Open Source
> Software" or "Libre Software" instead of "Free Software" .

Ok, makes sense, I'll change "Free Software" to "Free and Open-Source 
Software".

> I think the above changes would help to reduce our gap with the
> commercial world..
> 
> ++ Participation in key forums
> 
> There is something missing to me.
> 
> The Free Qt Foundation has demonstrated to be a key player, we
> participate in other forums How is that reflected in our mission
> for the coming years? Do we want to improve our positioning? How? Is
> it important to us? important enough to be reflected in the Mission
> Statement? Do we participate only to promote Free Software values?

Good point! Any idea how we could phrase that as a question for the survey?
 
> ++ "classic desktop"
> 
> We have suffered the last few years from having two different visions
> within our community on what desktop means/is. Going through the
> process of redefining the strategy should serve to solve these kind of
> fundamental issues.
> 
> When I read the mission, I understand that we have used a "political
> way" to provide satisfaction to both views. In that regard, these two
> points:
> 
> * aims for a presence on all relevant device classes (desktop, mobile,
> embedded) * offers a "classic desktop" product which makes the switch from
> other popular operating 

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-23 Thread Thomas Pfeiffer
On Montag, 23. Mai 2016 07:37:49 CEST Martin Graesslin wrote:
> On Sunday, May 22, 2016 7:29:22 PM CEST Thomas Pfeiffer wrote:
> > > 1.- I believe that mobile/desktop convergence is not an emerging trend
> > > anymore.
> > > 
> > > 2.- We do an innovative and modern desktop. Even if we do a "classical
> > > desktop", we should not state it that way in our mission. The next few
> > > years should be about keeping what is good about the "old concept"
> > > that took us here and evolving it. We are not dealing with cars from
> > > 1920 here. If we have to use quotes in a Mission statement, a document
> > > that should be crystal clear not just to ourselves but the "external
> > > world"...
> > 
> > This is exactly the kind of question why I've set up the survey: I know
> > that some people still care a lot about the "classical desktop" (i.e. a
> > thing that runs on desktop and laptop PCs) whereas for others, desktop
> > and laptop PCs are just one among many device classes and form factors.
> > 
> > Since the Mission should reflect where the majority of the KDE community
> > wants to go, I want to offer people the possibility to clearly state what
> > they care about more. This is why I have both variants in the survey and
> > we
> > can see which gets what score.
> 
> The mission should also not alienate our developer base. If the mission
> states we aim for a classical desktop I would consider that a punch in my
> face. I'm working full time on a desktop, but I don't consider this as a
> "classical" desktop. I consider my work going on a very modern product, not
> something classical.

Good point, "classical" may have been unfortunate wording (interestingly 
enough, the wording did originally come from someone who seems to actually 
care more about Plasma Desktop than other Plasma shells).
Maybe we can just kick that question out of the survey, given that we ask 
about each device class separately anyway.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-24 Thread Thomas Pfeiffer
On Dienstag, 24. Mai 2016 01:01:13 CEST Riccardo Iaconelli wrote:
> Hi,
> 
> On 23 May 2016 at 19:28, Thomas Pfeiffer <thomas.pfeif...@kde.org> wrote:
> > 3. Added another question for the contributors "Which category or
> > categories of projects have you contributed to most recently?",
> > multi-select, with the options
> > [ ] Plasma
> > [ ] Applications
> > [ ] Frameworks
> > [ ] Meta (sysadmin, web)
> > 
> > I have not mentioned promo, vdg or community/support separately because
> > their work is usually related to one of the project categories. Am I
> > missing other functions which contribute to KDE's producs but do not
> > relate to any of the categories above?
> 
> I am not sure how most WikiToLearn guys would reply here: are we meta?
> We have, roughly developers, infrastructure administrators,
> organizers, promo team and content writers. We do a very different job
> than documenters, translators or other generic KDE meta people. Then,
> why Plasma has its own box, isn't it an application?

You are right, I completely forgot WikiToLearn here!
Are there more projects which do not belong in any of these categories, but 
isn't "meta" either?
 
The reason why Plasma is mentioned separately (and WikiToLearn should be, too) 
is that it might be more important what Plasma contributors think about 
desktop matters than what those not contributing to it think. On the other 
hand, regarding issues like which platforms we want _applications_ to run on, 
the voice of someone who only contributes to Plasma or WikiToLearn might not 
be as important as the voice of someone who actually contributes to 
applications.

Of course we want a vision for all of KDE, but our "who does the work, 
decides" mantra should not be falling behind there.

> I would say you should be identified with the skills you apply, which
> better reflect the nature of our community: programmer, designer,
> promoter, syadmin, translator...

The problem here is that the groups for some roles are too small to guarantee 
anonymity.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this! : Feedback on survey draft

2016-05-21 Thread Thomas Pfeiffer
On Samstag, 21. Mai 2016 17:25:06 CEST Marta Rybczynska wrote:
> I get:
> Error
> 
> We are sorry but you don't have permissions to do this.

Ah yes, sorry, I had deactivated it to make changes and then forgot to 
activate it again.
Should work again now!
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] possible foss alternative to telegram/slack

2016-05-20 Thread Thomas Pfeiffer
On Dienstag, 17. Mai 2016 12:33:25 CEST Nicolás Alvarez wrote:
> 2016-05-17 5:55 GMT-03:00 Marco Martin :
> > Hi all,
> > Right now many groups are using Telegram as their primary communication
> > medium due to some limitations in IRC (mainly due to the ease of pasting
> > images inline the channel and the lack of fancy mobile clients for IRC),
> > there may be other valid reasons i'm not aware of
> > today i randomly stumbled upon
> > http://www.mattermost.org/
> > 
> > it seems to tick all the boxes:
> > * open source
> > * we can self host an instance
> > * fancy mobile and desktop apps
> > * inline multimedia attachments into messages
> > * and most important for us old farts: bridge to IRC :p
> > 
> > didn't try it, just stumbled upon it but may be something to be
> > considered?
> 
> There is no sane option for fancy mobile apps. You either compile your
> own apps, get a developer account on app stores ($99 for iOS, $25 for
> Android), get them through the app store review process, and maintain
> them forever; or you use the official Mattermost apps that are already
> in app stores, and pay Mattermost $20/user/year to send push
> notifications through their servers.

Are you sure about this? From what I've read on their website, only encrypted 
push notifications need a subscription, which is not necessary for talking 
about Free Software anyway, if we're being honest.
None of our current Telegram or IRC communication is encrypted, so why would 
we need encryption for Mattermost?
I cannot see anywhere that the Android app only works at all with a 
subscription.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Open Public Consultation: Revision of the European Interoperability Framework

2016-05-11 Thread Thomas Pfeiffer
On Mittwoch, 11. Mai 2016 11:25:00 CEST Jos van den Oever wrote:
> The EU is asking input from its citizens on the next version of the European
> Interoperability Framework.
> 
> KDE has a traditional position in Europe and would benefit from a clear
> direction towards completely open standards (*not* FRAND which make FOSS
> implementations nearly impossible) and strong preference for FOSS.
> 
> I think members of KDE have the right knowledge for filling in this
> consultation. Please take some time to do so.
> 
> http://ec.europa.eu/isa/consultations/

I just saw that one can also participate on behalf of a "private 
organization". Would it make sense to have someone represent KDE officially in 
addition to the individual participations?
Someone representing an organization may have more weight for them than 
individual citizens.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Open Public Consultation: Revision of the European Interoperability Framework

2016-05-11 Thread Thomas Pfeiffer
On Mittwoch, 11. Mai 2016 15:20:29 CEST you wrote:
> On Mittwoch, 11. Mai 2016 11:25:00 CEST Jos van den Oever wrote:
> > The EU is asking input from its citizens on the next version of the
> > European Interoperability Framework.
> > 
> > KDE has a traditional position in Europe and would benefit from a clear
> > direction towards completely open standards (*not* FRAND which make FOSS
> > implementations nearly impossible) and strong preference for FOSS.
> > 
> > I think members of KDE have the right knowledge for filling in this
> > consultation. Please take some time to do so.
> > 
> > http://ec.europa.eu/isa/consultations/
> 
> I just saw that one can also participate on behalf of a "private
> organization". Would it make sense to have someone represent KDE officially
> in addition to the individual participations?
> Someone representing an organization may have more weight for them than
> individual citizens.

Even more: It looks like there are actually different questions depending on 
whether you reply as an individual or on behalf of an organization. Citizens 
only get questions regarding their own communication with public authorities.
Given that, I think it's even more important that someone replies on behalf of 
KDE, so that we can also provide input on the impact which the framework has 
on us as a n organization which produces software.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this!

2016-05-16 Thread Thomas Pfeiffer
On Montag, 16. Mai 2016 22:59:59 CEST you wrote:
> Hi Thomas,
> 
> On Tuesday 10 May 2016 22:48:01 Alexander Neundorf wrote:
> > On Tuesday, May 10, 2016 17:18:39 Thomas Pfeiffer wrote:
> ...
> 
> > > Both positions are perfectly valid, of course. Now the problem is: How
> > > can
> > > we tell what KDE as a whole puts more emphasis on, when nobody but us
> > > voices their opinion?
> > 
> > Maybe post to a few more mailing lists, e.g. kde-devel, plasma-devel, kde-
> > core-devel, kde-frameworks-devel, is there a calligra-dvel ?
> 
> I have the impression this is not going well here.
> How can we get more people to participate ?
> Simply post to k-c-d and k-f-d ?
> Or try with some controversial post ? ;-)

Hi Alex,
thank you for reminding me of the email I had been wanting to write today:
To be honest, I don't think the reach of this mailing list is the problem. 
I've heard from quite a few people who have been following this discussion, 
but have not participated in it (for various reasons).
Therefore, I changed plans. Instead of trying to get more people to 
participate in the discussion here, I will do what I'm trained to do: I'll 
conduct a survey.

I think we've already come quite far with the draft and I don't think we need 
much more open discussion. We have a quite good draft, but in several points, 
we have your personal opinion against my personal opinion, and now I think the 
next step whould be to find out what the majority (especially the "silent 
majority") thinks.

Tomorrow I will try to identify the points which are still contested (and I'm 
happy for you or others to contribute to that as well) and put them in a 
survey (along with those on which we agree, just to make sure the majority 
agrees with us as well) which I will spread via the Dot, this list, the ev-
membership list and maybe kde-devel just to be sure.

This survey will also invite people to join the mailing list discussion, but 
will primarily aim to just get numbers on those issues where we don't know 
what the majority thinks. 

While I'm confident that we have found a Vision which everybody agrees to, I 
feel that for some points of the Mission, we'll have to go with a majority 
vote, because there are competing standpoints which are both valid but cannot 
really be harmonized. On the other hand, I do not think the standpoints are so 
far apart that those who prefer the minority position would not be able to 
identify with the Mission as a whole anymore if we adopted the majority 
position.

So, unless there are strong arguments against this approach, this is what I 
will do.

Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Does KDE attempt to attract experienced contributors?

2016-05-13 Thread Thomas Pfeiffer
On Freitag, 13. Mai 2016 11:06:18 CEST Laszlo Papp wrote:
> On Fri, May 13, 2016 at 11:00 AM, Eike Hein  wrote:
> > On 05/13/2016 06:50 PM, Laszlo Papp wrote:
> >> I do not mean to drag KDE experts away, but it seems that freelancing
> >> platforms have become more and more common. Also, many hobby software
> >> projects have undergone some business path. These generally include lots
> >> of FOSS project opportunities these days in my observation, so yeah, the
> >> question is this really: why would you choose working for free rather
> >> doing something similarly interesting for money and probably also with
> >> other experienced engineers?
> > 
> > The answer to this has been the same from the very start: Because you
> > think free software matters.
> 
> I apologise if I had not expressed myself correctly. I do mean working on
> some free software for money compared to working on KDE free software for
> free. So, free software does matter, yet you can get (potentially
> well-)paid in return elsewhere.

Here is my perspective on this: 
I don't know the actual relative numbers, but many of the commercially 
successful open source software projects that I know of have originally 
started without any money involved. Of course some Free Software projects have 
had financial backing from the start, but many start out as a project people do 
in their free time, and then when they realize they can actually make money 
with them, they do so and turn into actual for-profit companies which pay 
people to work on their software.

Even those, however, often still additionally have volunteer contributors, who 
just like the software (which they get for free) so much that they contribute 
to it for free even when others get paid for doing so (although each 
individual usually spends far less time on it than those who get paid for 
doing so). ownCloud is a great example here.

What I mean is, we should not divide the world into "Software people make for 
free" and "Software people make for money". It's not black and white.

So, if we want to reach people who would like to eventually make a living 
working on Free Software (a group to which I clearly belong, and a goal which 
I have currently reached by being employed by Blue Systems), we should not shy 
away from trying to look for ways we can make money from the software we 
produce.

Maybe by attracting not only experienced developers, but also people talented 
in finding ways to make money off Free Software (of course only in ways which 
are compatible with our Manifesto!) we can make more KDE projects generate 
paid jobs.

Cheers,
Thomas

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Mission - let's do this!

2016-05-10 Thread Thomas Pfeiffer
On Montag, 9. Mai 2016 22:49:15 CEST Alexander Neundorf wrote:

> > Let's finish our mission before we lose interest ;)
> 
> thanks for pushing :-)
> 
> No objections from my side, just a few thoughts, in no specific order:

Glad to hear :)

> * I don't like the term "reach  where they are", to me this always
> kind of implies that the person in question is currently somehow in a wrong
> place (in German: "die Leute da abholen, wo sie sind" :-/ )
> Basically this is the "everyone" from the vision.
> So maybe
> "To be able to make the software available to everyone, KDE"... ?

There are actually slightly different underlying positions concerning 
priorities:
I assume that for both of us, a perfect world would be one where everybody 
used exclusively free software/hardware/services/content. We both know that 
this will probably never happen, so we have to aim for something more 
realistic. And this is where our priorities diverge:
- For me, it's more important to get people away from as much non-Free stuff 
as possible
- For you, it's more important to get our Free stuff to as many people as 
possible

Both positions are perfectly valid, of course. Now the problem is: How can we 
tell what KDE as a whole puts more emphasis on, when nobody but us voices 
their opinion?

> * To me, "classic desktop" does not really fit into "reach users where they
> are"

Ok, so where would you put it? I'm open to any suggestion here.

> * One could argue that to provide control, freedom and privacy for users,
> KDE's products do not only need to have those properties, but the products
> actually need to cover a substantial range of the users needs.
> IOW, e.g. by offering a range of niche nerdy applications, let's say 3D
> printer software and a desktop ruler, we wouldn't do much to achieve our
> vision.
> So, should there be some mention of what we want to "produce" ?
> Something like desktop, office, education, creation, etc. ?

Even "niche nerdy applications" do contribute to our vision, but of course the 
more users, the bigger the impact.

The question is, though: Does the "substantial range of the users needs" 
really need to be covered by KDE software? For example, there is still no 
advanced photo editing software from KDE, because the Krita team decided that 
GIMP has that need covered just fine and Krita should focus on digital painting 
instead. 

I, personally, think that the goal should be that /Free Software/ covers all 
common user needs. Whether that software is made by KDE, GNOME, GNU, TDF, 
Apache, any other organization or an independent project does not matter that 
much to me.

Of course there are some applications which greatly benefit from a very tight 
integration with the desktop environment or other applications, and it makes 
sense to offer these from one source, but that group might not actually be all 
that big.

That said, I have nothing against offering some examples of areas we think we 
should cover, I just won't be the one to provide them.

> * you mention "embedded". I haven't seen any comments here e.g. from KF5- or
> plasma-developers expressing strong interest.

I'd like to keep it in unless someone says they explicitly do not want to 
target embedded. The mission should not just reflect what we're already doing, 
but what we _should_ be doing, after all.

> * "on major [...] OS" -> "on all major [...] OS" ?

Ok.

> * "have consistent [...] interfaces", "available on major [...] OS, e.g. by
> applying Qt" can easily be interpreted that Qt (and our set of libraries) is
> used to achieve portability and consistent user interfaces, which could
> easily be interpreted as e.g. a gtk-application is not part of our
> mission...

As far as portability (especially towards mobile platforms) is concerned, GTK 
is indeed not the toolkit of choice. In the mobile space, Qt (or more 
specifically QtQuick) seems to have pretty clearly won against GTK.

I don't see how mentioning Qt as an example of a toolkit that helps us with 
that effort would exclude GTK applications. If someone would ask us what 
toolkit to use for a new KDE application, we'd still very likely recommend Qt, 
though.

Maybe I'll just spell out "for example" because that makes it harder to miss 
than "e.g.".

> * the two last points of "to create a convincing user experience" are quite
> generic and inconcrete, i.e. they don't add much tangible

They are, but I think they are important as reminders that we should not 
oppose things which are out of our comfort zone.

The last point is mostly to make sure we keep doing what we're doing in that 
regard, the third is remind us not to repeat our mistakes from the past (like 
being wy too late to the mobile party)
 
I think both points are important. Suggestions for how to make them more 
tangible are welcome!

> Alex

Thank you for the input,
Thomas


___
kde-community mailing list
kde-community@kde.org

Re: [kde-community] user stats for Neon

2016-04-15 Thread Thomas Pfeiffer
On Freitag, 15. April 2016 17:46:45 CEST Albert Vaca wrote:
> What's the problem with pinging the Neon servers? Any system already does
> way more than that when checking for updates, not to mention when you
> connect to a website, or even IRC.
> 
> How can this ping be violating any privacy if we don't even need to store
> the IP, just a unique ID? We can even generate the ID ourselves so it can't
> be matched with other sources. I don't see how this can have any impact to
> privacy nor any other use than counting people using Neon.
> 
> I don't understand this extremism and I'm sad to see it in our community,
> specially when other free projects like Firefox have been collecting way
> more complex analytics (opt-out) for a while with a positive impact for
> them.

Firefox uses a pretty obvious opt-out, though. Yes, the box is checked by 
default, but it shows it explicitly to users at the first run, they don't have 
to actively look for it in the settings.

I am all for more analytics (probably more than many others, given that I'm a 
user researcher), we really need that, but users have to be clear about what's 
going on. Firefox provides that. This sort of opt-out would be fine with me, we 
really just have to make it very obvious.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] user stats for Neon

2016-04-20 Thread Thomas Pfeiffer
On Mittwoch, 20. April 2016 15:49:12 CEST Agustin Benito (toscalix) wrote:
> Hi,
> 
> (long mail)
> 
> I went through this same discussions a few years ago in openSUSE. Let
> me outline my personal experience/point of view through that
> experience.
> 
> At some point, openSUSE was in crossroad and those involved in taking
> action, including myself, were not able to agree on the diagnosis of
> the situation. So it was impossible to agree in the next steps.
> 
> In short, my take on that situation was:
> 
> no data -> no common language -> no objective analysis -> no shared
> diagnosis -> no alignment  -> no improvement
> 
> I took the decision to collect and analise data as a key input for
> taking decisions. We worked with UID in combination with existing
> download/page hits numbers to support answers to simple questions
> first and more complex ones over time.
> 
> Leaning from what happened to Canonical in a similar situation a
> couple of years earlier, some requirements were established. The main
> ones I remember were:
> 
> - Transparency about:
> 
> * How we were going to collect the data.
> * What was going to be used for.
> 
> - Publication of the process to collect the data and the mechanism to
> disable it in your computer.
> 
> - Publication of the analysis on regular basis.
> 
> - Protect the raw data so it could not be used for any other purpose.
> We applied measures to ensure that no identification was possible,
> like linking UID to IP and geo info, in the line of what Kevin pointed
> in a previous mail in this thread.
> 
> Despite our efforts to implement a perfect process, trust on those
> handling the information was a requirement for this action to succeed.
> This is always going to be the case, right?
> 
> I had to suffer strong criticism back then, even in public, specially
> from relevant community members. Many did not trust me nor those
> handling the info. Others simply did not understand the need and
> potential impact that this measure would have for the project. Some
> also feared that the project would start becoming "data driven"
> instead of "people driven".
> 
> The impact of the action has been huge. In my opinion, way bigger than
> most think, specially at that time.
> 
> What today is Tumbleweed, Leap would have been different, way
> worse, without the learning process those involved back then in
> openSUSE delivery went through as a consequence of this action. We
> talked less and less about our personal experiences and impressions
> and more and more about the interpretation of the data. A first and
> necessary step towards reaching a common diagnosis.
> 
> Over time, this action stopped being controversial. I think that now
> the outcome of this action is seen within openSUSE as an asset.
> 
> Fedora recently presented at FOSDEM similar analysis to the one done
> by openSUSE. They even extended it and agreed on the potential impact
> in the decision making process that this action will have in the
> future of the project.
> 
> KDE will be criticized too. Even some of our community members will
> claim that our core principles are being violated. But in my opinion,
> those criticisms are unfair, at least until the result of this action
> is evaluated. The risk to screw it up is there, but risk is something
> that can and should be managed.
> 
> No doubt that privacy is a core value in Free Software. I assume it
> and defend it. But understanding how our software is consumed and by
> who, instead of pretending we know what users want and how they use
> KDE, is essential to improve, to increase the value we provide to
> them.
> 
> In summary, to me back then, it was a matter of putting our users and
> the project first, even before my personal values. It was a tough
> decision but I would take it again.
> 
> So my suggestion is:
> 
> * Let's do our best to be transparent about our goals, process and output,
> 
> * Let;s provide a simple way for those who think that collective
> ignorance is an affordable side effect of privacy to not participate
> on the data gathering, They have the right to think that way and we
> should respect it. We should work hard to prove them wrong. We have no
> spurious intentions.
> 
> * Let's make sure we establish a trusted process and rely on trusted
> people for this action. We already has proven in other areas that we
> can trust ourselves when dealing with sensitive topics/info.
> 
> * Let's assume we will be criticized for this. We will need to put
> energy in explaining our intentions and motivations but that will
> never be enough for some, even if we succeed.
> 
> But let's also assume also that:
> 
> * Ignorance is already hurting us. Again, no, we do not know what our
> users want and how they consume our software. This ignorance has deep
> consequences for the project.
> 
> * Even if we share a vision, it will be impossible to align as a
> community if we do not agree where we are. Speak the same language is
> a 

Re: [kde-community] user stats for Neon

2016-04-14 Thread Thomas Pfeiffer
On Donnerstag, 14. April 2016 14:36:21 CEST Jonathan Riddell wrote:
> On Thu, Apr 14, 2016 at 04:18:30PM +0200, Thomas Pfeiffer wrote:
> > Any potentially privacy-sensitive information transfer should be opt-in,
> > not opt-out.
> > I'd assume that the vast majority of users will allow it (given that it's
> > not personally identifiable and they trust their distro), but opt-in puts
> > you on the safe side.
> 
> What's privacy sensitive about it?  It's a machine ID but not linked
> to any other information other than IP address and there's no personal
> information we can link it to.

It's still a unique identifier which can be used to track the machine. We might 
then combine it with others who also only collect the machine ID to create a 
profile.
People can be very sensitive about these topics, especially since we've made 
privacy-aware users our main target audience.

As I said: the vast majority would give us their consent anyway, but it just 
comes across as "nicer" if we ask.

Martin's suggestion with "Make it explicit on the download page that we 
collect these data, and allow users to switch it off in privacy settings if 
they don't like us to do it" works as well, but then users would need to have 
a chance to turn it off /before/ the ID is sent the first time.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Telegram Relay Service

2016-05-09 Thread Thomas Pfeiffer
On Freitag, 6. Mai 2016 17:58:46 CEST Boudhayan Gupta wrote:
> Hi all,
> 
> KDE Sysadmin is excited to announce the availability of a Telegram <->
> IRC relay service. We now have the capability to sync messages both
> ways between an IRC channel and a Telegram group.
> 
> Currently, this service is being used by #kde-soc and #kdevelop. If
> there are any KDE IRC channel that has an equivalent group on Telegram
> and would like to sync messages between the two, please file a
> Sysadmin Ticket on Phabricator with the name of the IRC channel and
> the name of the Telegram group, and we'll set up the sync service for
> your channel.

Stupid question: How does one file a ticket for sysadmin via Phabricator? All 
I've ever used to file sysadmin tickets is https://sysadmin.kde.org/tickets/ 
and https://sysadmin.kde.org/ does not mention Phabricator tickets at all.
Is this process documented somewhere?
Thanks,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Telegram Relay Service

2016-05-09 Thread Thomas Pfeiffer
On Montag, 9. Mai 2016 20:07:02 CEST Bhushan Shah wrote:
> On Mon, May 9, 2016 at 8:03 PM, Thomas Pfeiffer <thomas.pfeif...@kde.org> 
wrote:
> > Stupid question: How does one file a ticket for sysadmin via Phabricator?
> > All I've ever used to file sysadmin tickets is
> > https://sysadmin.kde.org/tickets/ and https://sysadmin.kde.org/ does not
> > mention Phabricator tickets at all. Is this process documented somewhere?
> 
> https://phabricator.kde.org/ -> Click on Plus button at top right ->
> New sysadmin request

Thanks! Is this supposed to replace the old ticketing system or only be used 
for specific things?
In any case, it should be documented on sysadmin.kde.org

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE Sysadmin and GPG Encryption

2016-07-27 Thread Thomas Pfeiffer

On 27.07.2016 00:17, Jeff Mitchell wrote:

I would avoid reading much, if anything at all, into what Boudhayan wrote, 
both from the perspective of the sysadmin team and even Boudhayan himself.


--Jeff


I don't see any "reading into" in any of the replies so far. People have just 
reacted to things that Boudhayan wrote very explicitly in his email.


Pretty bad things could be "read into" that email easily, if one wanted to. I'm 
glad nobody did that, we've had enough drama on this list in recent months.
I don't see why we should avoid reacting to what was explicitly said, though, 
and that's what people did.


___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Results from the Mission Survey

2016-07-29 Thread Thomas Pfeiffer
For those who follow these lists only through archives or digests and therefore 
did not get the attachment, here's the link to the PDF:

https://share.kde.org/index.php/s/JAefwOmCRSB6qp9
and the original ODP:
https://share.kde.org/index.php/s/O3KZRDECua8h9wF
Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Results from the Mission Survey

2016-07-29 Thread Thomas Pfeiffer

On 29.07.2016 08:57, Mirko Boehm - KDE wrote:

Hello Thomas,


On 29 Jul 2016, at 01:04, Thomas Pfeiffer <thomas.pfeif...@kde.org> wrote:

I'm sorry for taking so long with the survey analysis (analysis and 
documentation of survey results always end up taking longer than expected), but 
now finally I've prepared a presentation of the results of the first round of 
analysis of the survey I did for input on KDE's Mission statement.
This is just plain results, no interpretation.
I said "first round" because I'm ready to do perform further analyses if these 
results leave important questions open (if they can be answered from the data, of course).
If you'd like me to dig deeper somewhere, feel free to tell me!

Excellent work, thanks. And there are some interesting insights already. 
Besides minor differences, contributor and user interests are pretty much 
aligned, for example. Or that we are good at retaining long-term contributors.
Yes, I found the alignment between user and contributor attitudes pretty 
striking as well. Pretty much the only area where there are bigger differences 
are priorities for target platfroms, but that might be a bit of a chicken and 
egg problem: Since we're currently mostly targeting Free OSes, our userbase uses 
mostly Free OSes, so that's what they care about.

If anybody would like to get the raw data to do their own analyses, that's of 
course possible as well.

I would definitely be interested in the raw numbers. How can I access them?

Sure, you can find the ODS file here: 
https://share.kde.org/index.php/s/rmC88ki4ZmSdxei
And here is the R workspace and scripts I used for preparing the datasets and 
doing the inferential statistics (though I'm not sure how much others could make 
of it, it's not exactly well documented to be honest): 
https://share.kde.org/index.php/s/V8nX1jxeucr7YG8


Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Results from the Mission Survey

2016-07-30 Thread Thomas Pfeiffer

On 29.07.2016 23:27, Alexander Neundorf wrote:

Yes, probably.

How to interpret other results ?

E.g. "Importance of goals".
Do we consider the difference between 4.5 ("read as many users as possible"
and "convince users to switch away from proprietary") and 5.5 ("do our part to
promote Free...") as significant ?
If so, how does that fit together ? Could it be interpreted as that users of
proprietary OS are not that important to us (3rd option), and we also don't
want to make them switch to free OSs (5th option), while it is important for
us to promote free software (4th option) ?


That is indeed where we have to decide what to make of the results. I would not
recommend to exclude anything from the Mission which scored significantly above
the scale midpoint (which is why I did those tests). We may give those things 
which
scored significantly higher than others greater weight in the wording, but if 
something

is considered as more than averagely important by the community, why should
it not be part of the Mission? Nobody said that only the most important things 
can
be part of a Mission statement.

The aim of this survey was not to identify only the most important goals. The 
aim
was to confirm if the community agrees with us that the goals we identified are
indeed important, and it did so at least for all of the main goals.

About the "make users switch" vs. "promote free software": There are other ways 
to
promote Free Software (like we do with mentoring and advocacy) than directly
convincing users to switch away from proprietary software.

Actually I'm a bit surprised that "reach as many users as possible, regardless
of which OS" got such a relatively low score, because to me this question
translates to "do we want to provide (our part of) freedom to as many people
as possible (even if they still use a proprietary OS kernel underneath) ?"
So it seems we don't want to.


We _do_ want to. If we didn't, it would have scored below the midpoint of the 
scale
on average. What I'd read from these results, though, is that providing 
excellent
software on Free OSes is _more important_ to the community than getting on
as many platforms as possible, which should be reflected in the Mission 
statement.

One thing stands out quite clear: "provide stable and reliable software" got
the highest points.

Yes, it seems that KDE is aware that higher quality standards should be a clear
focus for the future, which makes sense and is something that would certainly
sit well with the public, too.

I'm a bit surprised that "aim for a presence on mobile devices" got a
relatively low score. But that seems to match the (compared to GNU/Linux) low
score for Android.


I'm not _that_ much surprised. Again: The score does not mean that the community
does not want presence on Android, but if it had the same priority to 
contributors as

desktop Linux, we would already be seeing _far_ more Android apps from KDE.

Presence on Android is clearly seen as an above-average priority, so it should
definitely be part of the Mission, but it's also clear that the community still 
sees

desktop (Linux) computers as more important.

The even lower score for "embedded" confirms the impression I have in this
regard from our community.


Yes. This is why I did this survey: I (and certainly some others) do think that 
embedded
is an important area for the future, but it makes little sense to put it in the 
Mission

of the majority of the community does not really care about it a lot.
The Mission is not fixed for eternity, so should that priority ever change for 
the
community, the Mission will reflect that change.

The relatively low result for "use new online services created by KDE" and the
relatively low result for "offer our own web-based services" seem to fit
together.


Indeed. Web services were considered "moderately important" on average by
the participants of the survey, so that certainly does not mean that web 
services are

not welcome in KDE, but they are not considered important enough to shift
resources to them from client software.

I find it noteworthy that we (developers, and even more users) consider the
BSDs and even "Other Free OS" as more important target platforms than Windows.


Indeed. It seems like KDE cares more about a completely Free stack than about
reaching as many users as possible, as already seen in the first question.

The "How much do you agree.." page is a bit complicated.
I guess it means that we want to try to concentrate on "important"
applications (so we cover the common needs of normal users), and that we
should keep the focus on Qt.


Yes, those two seem to be rather clear-cut.

The "focus on GUI" vs. "any useful software"... does that have to be
considered also taking into account the relatively low score for web-based
services ?


Yes, that point is indeed interesting. It does indeed look like having a GUI is 
less important

to us than running on user's systems instead of the cloud.

Alex, going on 

Re: [kde-community] Results from the Mission Survey

2016-08-01 Thread Thomas Pfeiffer

On 01.08.2016 11:20, Martin Steigerwald wrote:

Thank you for doing this.

I am baffled by the extreme coherence between answers of contributors and of
users. Seems like a perfect match.
Indeed, I was equally surprised by that. It is true, though (I've just 
re-checked the data to be 100% sure).
If someone says "KDE has lost touch with their userbase", we can confidently say 
"No, we haven't, look at that
survey we just did!". At least judging from our attitudes. To the extent that 
our actions match our attitudes,

we should be all lined up with what our users want.
Our users should like a Mission Statement derived from these results, then :)

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Cleaning up mailing lists?

2016-08-10 Thread Thomas Pfeiffer

Hi everyone,
recently I went through lists.kde.org and saw that there are lots of lists there 
for some short-term projects in the past, or for projects which have long since 
been abandoned.
Given that it probably doesn't give a good impression if someone subscribes to 
one of those lists only to notice that nothing has happened there for years, 
would it perhaps make sense to clean up our mailing lists, killing those that 
are not used anymore?

Cheers,
Thomas


Re: [kde-community] Randa Meetings fundraising - please spread

2016-07-06 Thread Thomas Pfeiffer

Hi Sandro,

going to the fundraiser website, I noticed that it is out of date:

It still talks about Randa 2016 being in the future. Shouldn't it be updated,

and instead of talking about what we _will_ do there, talk about what _has been 
done_


there, and than changing the message to "If you want us to be able to continue 
doing

such great things, please donate to fund future meetings."

It's not much of a surprise to me that a campaign focused on funding a specific

meeting loses drive after that specific meeting is over. The meeting happened, 
so

obviously we had enough money to do it, now why donate more for it?

If we want the fundraiser to still be engaging, we have to change the message.

Cheers,

Thomas


On 04.07.2016 16:42, Sandro Andrade wrote:

Hi there,

We've reached the last week for Randa Meetings 2016 fundraising [1]
and we're completely behind the goal :( That's mostly because our
audience depletes rapidly after some weeks and we lack some
promotional device (and man-power/energy) to keep pushing it forward.

Now we need to boost its last breath, for example by:

- Writing a nice blog post, everyone is welcome to do that and even
more for those of you who holds a quite popular blog. That's proven to
be quite effective lately.
- Promoting the campaign in regions other than Europe by translating
and spreading.
- If you were in Randa, telling what you achieved and call for donations.
- Doing anything else you feel could help ..

[1] https://www.kde.org/fundraisers/randameetings2016/

Cheers,
--
Sandro
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community


___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] DigitalOcean is now a sponsor!

2016-07-06 Thread Thomas Pfeiffer

On 05.07.2016 21:36, Boudhayan Gupta wrote:

Hi Guys,

I'm excited to announce that DigitalOcean is sponsoring the KDE
Community. Under their open source software sponsoring programme [1],
they've very kindly set us up to use computing resources free of
charge.


Awesome news! Is this sponsorship already "public" from their side
(I don't see KDE on the list you linked to)?
And if it is: Would they like us to keep it low-profile or talk about it?
My first gut reaction would be to head over to G+ and spread the good
news, but of course I'd only do that if they want us to.
Cheers,
Thomas
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: KDE at FOSDEM 2017 wrapup

2017-02-06 Thread Thomas Pfeiffer
On Montag, 6. Februar 2017 18:04:16 CET Lydia Pintscher wrote:
> On Mon, Feb 6, 2017 at 1:16 PM, Jonathan Riddell  wrote:
> > Sadly no women at the party again which was commented on social media,
> > la presidencia stood us up for VLC.
> 
> Important diplomatic mission ;-)  I'll be working on this cloning
> thing until next year.
> 
> Thanks a lot for organizing, Jonathan, Pau and everyone else who helped!

Unfortunately I couldn't be there, so I can only extend my thanks to everyone 
involved.
Great job!


Re: [kde-community] Results from the Mission Survey

2016-08-21 Thread Thomas Pfeiffer

On 21.08.2016 22:17, Alexander Neundorf wrote:

On Monday 01 August 2016 12:05:25 Thomas Pfeiffer wrote:

On 01.08.2016 11:20, Martin Steigerwald wrote:

Thank you for doing this.

I am baffled by the extreme coherence between answers of contributors and
of users. Seems like a perfect match.

Indeed, I was equally surprised by that. It is true, though (I've just
re-checked the data to be 100% sure).
If someone says "KDE has lost touch with their userbase", we can confidently
say "No, we haven't, look at that
survey we just did!". At least judging from our attitudes. To the extent
that our actions match our attitudes,
we should be all lined up with what our users want.
Our users should like a Mission Statement derived from these results, then
:)


just arrived back home. :-)
That's actually a very similar issue to what I have at work: while following
wishes from existing users certainly makes those happier, but is this actually
the right way if you want to reach people who are not yet using this software
? (serious question, not rhetoric)

Alex


Doing what current users want just because they want it is a way which is 
unlikely
to lead to long-term success. However, the community came to similar preferences
as the users without knowing what preferences the users have.

If I were to decide, I'd have set different preferences, but setting a Mission 
which
the community does not agree with is not useful in a volunteer-driven community.
If all most contributors want to focus on desktop Linux, I can say that KDE 
should
focus on mobile all day, without any effect.



Re: [kde-community] Results from the Mission Survey

2016-09-21 Thread Thomas Pfeiffer

On 12.09.2016 18:18, Alexander Neundorf wrote:

Hi,

On Thursday 01 September 2016 16:54:32 Lydia Pintscher wrote:

On Thu, Sep 1, 2016 at 12:14 AM, Ingo Klöcker  wrote:

I don't think so. On
https://akademy.kde.org/
there's no BoF registered for working on the mission.

Thomas and I just added one on Tuesday at 4pm.

how did it go ?
Are there notes or something somewhere ?


Hi Alex,
there are no notes of the BoF, but all the tangible results of it are reflected 
in the updated Mission draft [1].
However, near the end of the BoF, concerns were brought up regarding whether a 
Mission for KDE should say anything about our products, or whether our products 
should only be defined by their individual product visions and a KDE Mission 
should only encompass how we organize and collaborate.
Therefore, we are now trying to find out whether the general direction that the 
draft is going into makes sense.

Input on that is of course welcome!
Cheers,
Thomas

[1] https://community.kde.org/KDE/Mission


Creating a map of KDE contributors?

2016-09-20 Thread Thomas Pfeiffer

Hi everyone,
I recently realized that unless you ask fellow KDE contributors personally where 
they live, you don't really know where over the world (or even in your home 
country) KDE is spread.


I think this is a pity, given that knowing that would allow us to, among other 
things

- show the world how globally wide-spread KDE is
- make it easier to organize local events (like release parties or just local 
meetups)

- determine who could help with local FOSS events where KDE could participate
- pick locations for sprints or conferences depending on minimal overall travel 
effort


Therefore, I would like to create a map of KDE contributors' home towns (the 
towns/cities would be enough, no need to know the precise location). Ideally it 
would be possible for people to decide whether they want their name to show up 
publicly, or whether they just want to show up as an anonymous contributor.


So, two questions:
1. Does that make sense to you?
2. If yes: Does anyone know of a piece of code that allows people to enter their 
city of residence and then show people on a map (ideally as an OSM overlay), or 
could otherwise maybe create it?


Cheers,
Thomas



Re: Creating a map of KDE contributors?

2016-09-20 Thread Thomas Pfeiffer

On 20.09.2016 13:49, Jonathan Riddell wrote:

Gnome already do this
https://wiki.gnome.org/GnomeWorldWide

Nice!
Though a zoomable map would be nicer, because on that map it's a bit difficult 
to distinguish cities in more crowded countries.


Re: Creating a map of KDE contributors?

2016-09-23 Thread Thomas Pfeiffer

On 20.09.2016 14:06, Luigi Toscano wrote:

On Tuesday, 20 September 2016 13:42:35 CEST Thomas Pfeiffer wrote:

Hi everyone,
I recently realized that unless you ask fellow KDE contributors personally
where they live, you don't really know where over the world (or even in
your home country) KDE is spread.

[...]

So, two questions:
1. Does that make sense to you?


We had a "heat-map" of committers in the old commit-digest:
https://commit-digest.kde.org/issues/2014-11-16/
So yes, it makes sense.

Also, for example:
https://www.debian.org/devel/developers.loc


2. If yes: Does anyone know of a piece of code that allows people to enter
their city of residence and then show people on a map (ideally as an OSM
overlay), or could otherwise maybe create it?


If it's not for the fact that sysadmin want to replace identity, a custom
field there with the city and/or coordinates and some script to grab them,
convert into geojson, and it's really easy (read: few lines of code) to setup
a map with leaflet.

http://leafletjs.com/examples/geojson.html


If I read the documentation [1] correctly, Phabricator (which would replace 
Identity) allows custom fields in user profiles, so we could still do that.



[1] https://secure.phabricator.com/book/phabricator/article/custom_fields/



Re: KDE Licensing Policy Updates

2016-09-20 Thread Thomas Pfeiffer

Certainly not. AGPL is like GPL in that sense, with the extra rule
that you must publish the source code even if you're only giving
access over the network and not distributing binaries.

I don't think an AGPL library makes much sense though.


​ALGPL makes sense then :)
​


On the other hand: Is Qt still used much for web services? And if so: Are our 
frameworks of much use for those?


I think this might be more of an edge case. I suppose that if we're doing web 
stuff, it's more likely to be full applications rather than libraries.


Re: KDE Licensing Policy Updates

2016-09-20 Thread Thomas Pfeiffer

On 20.09.2016 19:52, Nicolás Alvarez wrote:

2016-09-20 14:04 GMT-03:00 Jonathan Riddell :

Added:
''Applications which are intended to be run on a server'' can be
licenced under the GNU AGPL 3.0 or later
Rationale: KDE Store code is under AGPL
Question: should this be an option or a requirement for server software?

I agree with this change, but I think it should remain an option.


I would support making it mandatory, actually, or at least recommended, because 
for an end user a web service based on GPL software is no better than one based 
on proprietary software, because they cannot tell what software it is they're 
interacting with. Therefore, the AGPL closes an important hole in FOSS web services.


I don't feel very strongly about this, but to me it would make sense to at least 
recommend AGPL for web software we produce.




Official "Going to Akademy" banner by Ivan Čukić

2016-08-18 Thread Thomas Pfeiffer

Dear community,
as most of you know, each year, there is a banner for people who go to Akademy 
to put into their blog posts (or on their social media profiles or wherever) so 
that the world sees which cool people they can meet there if they're going, 
and/or donate to KDE so those people can meet.
Usually, the VDG (or previously thw Oxygen team) creates those banners. This 
year, however, Ivan Čukić of Plasma fame made a banner which the VDG liked so 
much that we'd like everyone to use it.

You can find the banner on https://community.kde.org/Akademy/2016
Happy word-spreading,
Thomas


We now have an Advisory Board

2016-09-27 Thread Thomas Pfeiffer

Dear KDE,
in case you haven't read the Dot article [1] yet:
KDE now has an Advisory Board, consisting of KDE e.V.'s Patrons as well as 
organizations using our software on a large scale (currently LiMux) and other 
NGOs with visions/missions similar to ours. The list of members is on the 
Advisory Board page [2].


On our side we have a contact person for each organization on the AB in the 
Advisory Board Working Group [3].


We hope the Advisory Board will provide us insights into what the world needs 
from us as well as closer collaboration with our allies in general.


Cheers,
Thomas

[1] https://dot.kde.org/2016/09/26/announcing-kde-advisory-board
[2] https://ev.kde.org/advisoryboard.php
[3] https://ev.kde.org/workinggroups/abwg.php


Re: We now have an Advisory Board

2016-09-27 Thread Thomas Pfeiffer

On 27.09.2016 17:52, victorhck wrote:

in the article:
https://dot.kde.org/2016/09/26/announcing-kde-advisory-board
the LiMux link points to itself.


Thanks, fixed.
I removed the link because I could not find a proper project website for LiMux, 
and just linking to the Munich website feels too generic.


Re: Kubuntu and other KDE distribution's use of KDE infrastructure

2017-01-14 Thread Thomas Pfeiffer
On Donnerstag, 12. Januar 2017 11:18:07 CET Harald Sitter wrote:

> Manifesto says one of our values is "Inclusivity to ensure that all
> people are welcome to join us and participate;". Be inclusive, give
> Kubuntu and Fedora a place on phab to manage their todos. Costs us
> nothing, helps our friends make their product which features our
> products better. If either starts calling themselves a KDE project or
> misrepresents their association with KDE, hit them with the manifesto
> bat.

Let me add to that: Any distribution or spin shipping our software is of 
course welcome to become a KDE project as well (from KDE's side, at least). 
neon was the first to ask for that, but it's not exclusive.


Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

2017-08-15 Thread Thomas Pfeiffer
Hey everyone,
just a quick progress update:

I have now cleaned up  https://notes.kde.org/p/KDE_IM_requirements by removing 
duplicates, removing all discussion / comments (so only plain requirements are 
left) and rewording most requirements to that they have a somewhat common 
wording.

The next step will be to turn this into a Kano survey which will be used to 
prioritize them (will do that tomorrow).

Cheers,
Thomas





Re: Proposal: Have the Community Set Ambitious Goals for Itself

2017-08-14 Thread Thomas Pfeiffer
On Dienstag, 15. August 2017 00:47:15 CEST Lydia Pintscher wrote:
> On Mon, Aug 14, 2017 at 4:48 PM, Mirko Boehm - KDE  wrote:
> > I have seen only agreement and support for the porposal. What would be the
> > required steps to make an official announcement, and encourage people to
> > participate?
> 
> If I get at least two people to agree in this thread that they will
> submit a goal I commit to making the process work according to the
> proposed timeline.

*raises hand* I will.

> Next steps after that would be imho:
> * set up some infrastructure (wiki or phabricator) to collect goal ideas
> * seed with first goal ideas if possible
> * announce and promote via email/blog/social media
> * set up infrastructure to do the voting

Sounds good!


Re: [kde-community] Re: radical proposal: move IRC to Rocket.Chat

2017-08-15 Thread Thomas Pfeiffer

> On 15 Aug 2017, at 11:42, Jonathan Riddell  wrote:
> 
> On Fri, Aug 11, 2017 at 09:49:11PM +0900, Eike Hein wrote:
>> 
>> I've given some more thought to Matrix as a contender and I'm
>> increasingly liking this option among the available contenders.
> 
> We have the possibility of moving to Matrix and allowing individual
> IRC channels to move to real Matrix channels in their own time.
> 
> But alas we've still not heard from the groups who have chosen not to
> use IRC to see if it would interest them. VDG, Promo, anyone?
> 

The VDG has contributed to the Etherpad, so their requirements are covered in 
there.



Re: [kde-community] Re: radical proposal: move IRC to Rocket.Chat

2017-08-15 Thread Thomas Pfeiffer

> On 15 Aug 2017, at 12:09, Jonathan Riddell <j...@jriddell.org> wrote:
> 
> On 15 August 2017 at 10:44, Thomas Pfeiffer <thomas.pfeif...@kde.org> wrote:
>> The VDG has contributed to the Etherpad, so their requirements are covered 
>> in there.
> 
> How to evaluate if Matrix/Riot covers them?  Stuff like "Have a UI
> that someone who is < 20 years old and cares about the looks of a UI
> would use" is hard to evaluate and much of the rest is also about feel
> which is hard to quantify.

That one was my initial copy & paste from the mailing list thread. I admit it’s 
not very good and I’ll have to make it more objective. Other VDG members were 
better at that because they didn’t come from the emotion-laden email thread.

In general the Etherpad has to be cleaned up, the more discussion-y parts have 
to be removed.

I’ll go over it tonight and make sure it’s in a usable shape, but any help with 
that is welcome, so everybody please feel free to edit anything that isn’t an 
objective requirement to turn it into one, and just delete the comments.

Re: radical proposal: move IRC to Rocket.Chat

2017-08-10 Thread Thomas Pfeiffer

> On 10 Aug 2017, at 15:27, Marco Martin  wrote:
> 
> On Wed, Aug 9, 2017 at 7:57 PM, Albert Astals Cid  wrote:
>> You can't expect me to read a 200 messages backlog in 20 channels just in 
>> case
>> something important was said while i was away.
>> 
>> Also one of the reasons of why i hate to use Telegram for anything that
>> "actually matters" is this "always on" feature.
> 
> that's sooo true for me as well :)
> and i guess it's the exact opposite of why so many people prefer
> telegram over irc, but on my end, i *love* that when i'm offline, i'm
> really offline
> 
I get that point. The thing is that people who have grown up with modern IM 
systems have a different mindset. They are used to not missing anything while 
away, they just expect things to be that way.

You always have the option to temporarily mute your IM app’s notifications, 
though, but you can’t set “office hours” and people don’t get a notification 
when they try to ping you while you have it muted.
We could add “Provide easy way to set availability times and communicate 
non-availability to others” to the requirements list, though. Slack has that, 
and it’s really useful especially when you use it for work.



Re: radical proposal: move IRC to Rocket.Chat

2017-08-10 Thread Thomas Pfeiffer
On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli wrote:
> Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell:
> > LibreOffice are having a similar discussion
> > 
> > https://listarchives.libreoffice.org/global/projects/msg02257.html
> > 
> > They want to continue using IRC though which means fragmentation would
> > continue.
> 
> Maybe someone should inform them that there are bridges available to avoid
> that.
> 
> But maybe they'd simply ignore that, multiple times, and go on, as some
> people seem to do in this thread as well *shrug*

Who ignored the possibility of bridges?
Where does Martin Steigerwald's impression come from that people want to make 
this an "either/or decision"?

The only person who seems to want to get rid of IRC is Jonathan, because he 
thinks bridges have a negative impact on the experience of both sides of them.

I never said that. Martin Klapetek never said that.
Yes, we both think that IRC is not suitable as the _only_ chat tool for a 
community in 2017.

Why do people feel something is threatened without people threatening it?

Puzzled,
Thomas


Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)

2017-08-10 Thread Thomas Pfeiffer

> On 10 Aug 2017, at 10:22, Luigi Toscano  wrote:
> 
> Il 10 agosto 2017 10:24:08 EEST, Martin Steigerwald  ha 
> scritto:
>> Martin Klapetek - 09.08.17, 16:12:
 But KDE is not a tech startup. As people correctly wrote, KDE has a
>> very
 long
 history and contributors of all age. I'd rather be that than one of
>> the
 many
 tech startups with a bunch of little to no experience but fancy new
>> chat
 systems, to be honest.  Do we really want and need to cater these
>> mystical
 tweens so much?
>>> 
>>> Yes. Old contributors will slowly fade away for various
>>> reasons, be it life, be it lack of energy, be it other commitments.
>>> Who's going to pick all those projects up after them? I'd like
>>> to think that young enthusiasts with lots of energy and potential,
>>> exactly what those heroes starting the original KDE were.
>>> And I think we should strive to attract younger talent that can
>>> be in it for the long run.
>> 
>> Well, I wonder since reading several posts here about one thing:
>> 
>> To from reading this post and other posts I got the impression that is 
>> absolutely needs to be black or white:
>> 
>> *Either* IRC and nothing else *or* something new and nothing else.
>> 
>> Seriously?
>> 
>> I mean: Seriously?
>> 
>> 
>> There has been almost completely unnoticed posts mentioning bridges. Is
>> none 
>> of this bridges capable to work well enough for KDE community use
>> cases?
> 
> I see it differently; I see people wanting something that also works with IRC 
> (so bridges, starting with the ones that already works) and people that don't 
> want IRC even if it's working in the background without then having to care 
> about it.

Who did ever say that? I certainly didn’t.
Throughout the entire discussion, I have always been 99.99% certain that we 
will end up with something that’s bridged to IRC.
Why would we not? There is not really a downside to it as long as the bridge 
works well, is there?

What I’ve argued strongly against is the standpoint that we should stick with 
the status quo.




Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

2017-08-08 Thread Thomas Pfeiffer
Hi everyone,
now that hopefully most of the emotional arguments in fiery support of one 
protocol or another have been exchanged, I'd suggest we move things towards a 
practical approach and ask ourselves:

What are the requirements that KDE has for an instant messaging / chat system 
for it to be viable as our main channel for real-time communication for the 
foreseeable future?

Here is what I could come up with, feel free to add new requirements or 
challenge the ones I'm listing.

Must-have:

- FOSS clients or at least API available for desktop as well as mobile
These clients must 
 - have a UI that someone who is < 20 years old and cares about the looks of a 
UI would use (or if those don't exist, we need to have people willing and able 
to write them before switching) 
 - run smoothly on computers that can run most other KDE software, without 
eating all of their memory

- FOSS server implementation
(this might look like a nice-to-have for some, but if we'd require everyone in 
KDE to use it, it's not optional)

- Ability to use without having to create a new account just for that.
We could force contributors to sign up for something, but we'd increase the 
barrier of entry if we'd make it mandatory for everyone who's just curious 
about what's happening in KDE.
Identity would suffice, as everyone who does anything with KDE has an Identity 
account anyway.

- Permanent logs across mobile and desktop clients without the need for users 
to set up anything.
That means ZNC does not count unless we implement it in a desktop as well as 
mobile client in a way that is completely friction-free for users

- Easy way to share files
A solution that puts files automatically on share.kde.org and embeds them from 
there works only if we have people willing and able to implement that feature 
into a desktop- as well as mobile client

- Support for a decent set of Emoji (not just the ones you can create using 
ASCII chars).
Using Unicode to display them is probably okay, as long as users can choose 
them from a menu in the client instead of having to paste them from 
KCharSelect.
This, too, might sound like nice-to-have for many, but not having them would 
cut us off from the younger generation. Yes, they use them even in a 
"professional context". Believe me, I'm seeing it in action every day at work.

- User avatars
Again, must-have if we want to reach the younger generation

- Uses a port that is open even on educational networks

- Channel listing
So that every public channel can be easily found


Nice-to-haves:

- Bridge to IRC
For the transitional period or for people who just refuse to change their 
habits

- Full name display
Makes things feel more trustworthy

- Integration with our development tools such as Phabricator

- Web client
Very handy if you are at a device which isn't yours and quickly want to check 
up on things

- Stickers
People love them when they have them, but they survive without them.

---
I'm sure I've forgot many things, but this (already quite long) list should 
give us a good start.

Looking forward to a productive discussion,
Thomas


Re: Collecting requirements for a KDE-wide instant messaging solution

2017-08-09 Thread Thomas Pfeiffer
On Mittwoch, 9. August 2017 02:14:44 CEST Jonathan Frederickson wrote:
> On 08/08/2017 06:19 PM, Thomas Pfeiffer wrote:
> > - Support for a decent set of Emoji (not just the ones you can create
> > using
> > ASCII chars).
> > Using Unicode to display them is probably okay, as long as users can
> > choose
> > them from a menu in the client instead of having to paste them from
> > KCharSelect.
> > This, too, might sound like nice-to-have for many, but not having them
> > would cut us off from the younger generation. Yes, they use them even in
> > a "professional context". Believe me, I'm seeing it in action every day
> > at work.
> I'm not sure custom emoji should be a requirement. That pretty heavily
> limits your options, and even some of the major chat platforms
> (WhatsApp, iMessage, Hangouts) don't support this.

That's why I wrote that Unicode is okay. Unicode now has quite a range of 
emoji and that set is growing steadily, so that's fine. Not optimal because 
they're black and white, but fine. 
Just not only ASCII ones.

Custom emoji are nice, but definitely not a must.



Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

2017-08-09 Thread Thomas Pfeiffer
On Mittwoch, 9. August 2017 09:36:42 CEST Thomas Pfeiffer wrote:
> On Mittwoch, 9. August 2017 01:59:00 CEST Christian Loosli wrote:
> > PS: on the importance of emojis and (animated) stickers: I can see why
> > people want them for friends and family, I love the sticker packs I have
> > on
> > Telegram. But why it is mandatory in a somewhat more professional
> > environment is a bit beyond me, people also still use e-mail despite it
> > neither supporting stickers nor emojis  (Well, unless html mails, but
> > thank
> > god that at least there we agree that it is an abomination)
> 
> It's just that young people do _not_ use email unless absolutely forced to.
> There is a reason why it can take days until someone replies to an email on
> the VDG mailing list, while the various Telegram groups the VDG is in are
> buzzing with activity.
> Or why my coworkers (professional environment, but a gaming company so
> predominantly people younger than me) hardly ever send an email but do
> everything on Slack.
> 
> Emoji certainly are not the only reason for that, but they are an important
> contributor to making communication on Telegram or Slack feel more natural
> than fun than email. Email is not fun at all.

I meant ore natural _and_ fun than email, of course. And here we have another 
thing  feature I sorely miss whenever I have to use one of the old 
communication protocols: The ability to edit my messages.


Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

2017-08-09 Thread Thomas Pfeiffer
On Mittwoch, 9. August 2017 01:59:00 CEST Christian Loosli wrote:

> PS: on the importance of emojis and (animated) stickers: I can see why
> people want them for friends and family, I love the sticker packs I have on
> Telegram. But why it is mandatory in a somewhat more professional
> environment is a bit beyond me, people also still use e-mail despite it
> neither supporting stickers nor emojis  (Well, unless html mails, but thank
> god that at least there we agree that it is an abomination)

It's just that young people do _not_ use email unless absolutely forced to. 
There is a reason why it can take days until someone replies to an email on 
the VDG mailing list, while the various Telegram groups the VDG is in are 
buzzing with activity.
Or why my coworkers (professional environment, but a gaming company so 
predominantly people younger than me) hardly ever send an email but do 
everything on Slack.

Emoji certainly are not the only reason for that, but they are an important 
contributor to making communication on Telegram or Slack feel more natural 
than fun than email. Email is not fun at all.

So unless someone can give me an example of an organization younger than 10 
years, with predominantly people younger than 25, which uses email as their 
main format of text communication, I maintain my statement. 


Re: radical proposal: move IRC to Rocket.Chat

2017-08-09 Thread Thomas Pfeiffer
On Dienstag, 8. August 2017 23:52:40 CEST Christian Loosli wrote:

> > Looking at #kde-devel just now it says:
> > <-- swati_27 (uid130066@gateway/web/irccloud.com/x-abaollxcgicrxgwg)
> > has quit (Quit: Connection closed for inactivity)
> > <-- nowrep (~david@kde/developer/drosca) has quit (Quit: Konversation
> > terminated!)
> > <-- stikonas (~gentoo@wesnoth/translator/stikonas) has quit (Quit:
> > Konversation terminated!)
> > <-- soee_ (~s...@bmi112.neoplus.adsl.tpnet.pl) has quit (Quit:
> > Konversation terminated!)
> > --> soee (~s...@bmi112.neoplus.adsl.tpnet.pl) has joined #kde-devel
> > 
> > Show that to most people and they'll just not want to know what it means
> 
> Good thing every single client coming to mind has a feature to hide these,
> including the official KDE client Konversation.
> 
> http://wiki.xkcd.com/irc/hide_join_part_messages
> 
> I'm rather sure that most other protocols, at least Telegram most certainly
> does, do also show when someone joined or parted a group, mind.
> The part they might hide is the  nick!ident@host part. This is client
> dependent, some do and quite a lot of them can hide it. So I wouldn't really
> recommend switching to a completely different protocol due to "shows
> additional info when someone joins or leaves the group".

The bigger issue seen in what Jonathan pasted isn't that IRC clients show when 
people join or leave a group. The issue is that it shows when people close 
their IRC client. And the problem is not that it shows them, but that this is 
_relevant_ because it means they can't follow the conversation anymore.

That's not the case for modern protocols where people only stop seeing the 
conversation if they actively leave the group (which is whey they do show 
that, but it happens far less often than people quitting their IRC client).

And see my requirements email for my reply to "But we have a ZNC instance". 



Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

2017-08-09 Thread Thomas Pfeiffer

> On 09 Aug 2017, at 09:57, Adriaan de Groot  wrote:
> 
> Can we please keep this thread limited to collecting-requirements, and 
> therefore arguing over which requirements are required or what their weight 
> is? That, rather than re-hashing the discussion elsewhere on which platform 
> with which sub- and superset of features is popular in which location.

You are right, inviting people to challenge my proposals right away wasn’t such 
a good idea in hindsight.

Furthermore, this sub-thread has reminded me again that while email is great 
for having permanently and publicly archived discussions, it is terrible for 
collecting information (any chat protocol would be equally terrible for that, 
of course) because contributions by different people tend to become spread over 
multiple emails.

So to fix this as well as to keep information gathering separate from 
discussion, let’s do the former in a format that makes more sense for it:

https://notes.kde.org/p/KDE_IM_requirements

Once we’ve agreed on a list (if we ever do), it could make sense to move that 
to the Community wiki for searchability and everything, but for brainstorming 
Etherpad usually works better.




  1   2   >