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

[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] Looking for new doors to open for KDE

[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 e.V. Community Report for 1st Half of 2015

[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

[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] Our new project metadata system

[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

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

[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] finding a clear vision for KDE - final version

[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] finding a clear vision for KDE - final version

[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

[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

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

[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

[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

[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

[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] finding a clear vision for KDE - second draft for discussion

[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

[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

[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

[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

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

[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] finding a clear vision for KDE - first draft for discussion

[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

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

[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

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

[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?

[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

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

[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

[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] RFC: Distribution outreach program

[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

[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] Blacklisting of free.fr

[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

[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

Re: [kde-community] FOSDEM Organisation

[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] Give People Access to Great Technology - a possible vision

[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

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

[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

[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

[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] Your mission, should you choose to accept it, is.....

[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

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

[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] Sad news (fwd)

[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] KDE Essential Applications - was - Re: Applications in KDE Generation 5

[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] HIG compliance testing via Google Code-in

[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] HIG compliance testing via Google Code-in

[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

[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] Proposal: KDE Manifesto wording revision

[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