[kde-community] Differences between proposed vision drafts (or "inclusive" vs "focused")

[Alexander Neundorf]

On Monday, February 08, 2016 22:41:08 Sebastian Kügler wrote:
> On Monday, February 08, 2016 21:42:58 Alexander Neundorf wrote:
> > > I understand that you're saying it doesn't have a place in KDE.
> > 
> > Sebas, you may have missed that I explicitely mentioned eigen in the mail
> > you  replied to ?
> 
> No, I've missed that.  Sorry...
> 
> > I don't understand what's so hard about this: we can say "we consider A, B
> > and  C to be our core efforts.". That does not mean that everything which
> > is outside that "core" must be kept out of KDE. Of course it means that
> > software or efforts that support A, B or C, are very welcome. OTOH
> > projects
> > which don't support the core do not need to be part of KDE, they can as
> > well use github or something else.
> > 
> > I think this can only be avoided by not having some technical direction at
> > all.
> 
> I think that the technical arguments don't make a lot of sense here, at
> least they're not providing the clarity needed:
> 
> - Qt-based, so it should be OK? But why exactly, just because it uses the
> same libraries?
> - "Supports the core", what is the core? Who makes this call? 

that's the 4 items in the draft. It's a draft, a proposal, so they are not set 
in stone.

> Where do you
> draw the technical line? (You gave some examples, but most of them feel
> quite vague to me, and I'd draw the line at different points.

Sure it is vague since the examples were intentionally "interesting" cases.

The draft is called "focused": some things are clearly in the focus (just some 
random examples I could come up with: Scribus, LxQt, libqwt).
Other things are, to me clearly far outside the focus: e.g. the eCos RTOS, 
bash, joomla.
The line between "in focus" and "out of focus"/"not supporting the core" is 
not a sharp line, it's blurry. We can spend weeks on discussing those.
 
> I think one (not the most important) benefit is that drawing the dividing
> line by asking "What is your goal?" makes it a lot easier to identify
> projects, they can self-select ("Do we identify with these goals?"), and
> also be measured internally ("Does this software actually contribute to
> *our* goal?") is easier.

I think e.g. offering applications which provide a consistent look-and-feel, 
following the same e.g. HIG, etc. is a worthwhile goal too.
We achieve this by using a common set of libraries (Qt and our KDE libraries).
We get more done because we gather developers which are familiar with the same 
technologies: again, the libraries, and in big parts also the programming 
language.
So, the technical aspect is important to me.

Alex