Workspace sprint, workplan/methodology

[Aaron J. Seigo]

On Wednesday, May 16, 2012 21:27:47 Aleix Pol wrote:
> Regarding the document, I think it's a great thing to have. I'm a bit
> afraid that we're focusing a bit too much on how do applications
> integrate to Plasma instead of how does Plasma integrate applications.

how so?

> Furthermore, I see things like "on-screen keyboard" in this document.
> 
>From my point of view, this sprint should be about how to iterate KDE
> 
> on the desktop systems (with this mouse and keyboard we've all grown
> to love), 

OSK is needed for a11y, for kiosk usage, etc. the OSK was actually started for 
the desktop and we have just re-used it for Active. the OSK is actually more 
suited to the desktop than mobile, in fact. and if there are people interested 
in working on these things, i don't think there is much to be gained by 
stopping them.

> others are already taken care of by the Active project which
> is doing great but on the desktop we have some void. If I

you have hit on a pet peeve of mine, one that i feel is ultimately destructive 
to our community here: drawing artificial (fake) divisions between those 
working on components that are used in one device type or another.

and yes, they are fake and it leads to mistakes. you managed to get it wrong 
for the on screen keyboard above, and in doing so discouraged someone from 
contributing in a way they found exciting and interesting. do you see why this 
is not good?

much of the effort put into Active has benefited Desktop. and vice versa: it has 
been our plan for a long time to do exactly what we're doing with Active: 
extend the reach of Plasma Workspaces to other device types, and that was made 
possible by the work we did on the desktop.

they are symbiotic. as is netbook. as is media center. as wil be other targets 
in the future. the view that these are all different things is a primitive and 
archaic viewpoint of how to create primary user interfaces ("shells", 
"workspaces", whatever you wish to call them).

treating them as completely separate things, as in the above statement of 
"active is taken care of, desktop isn't" will eventually turn them into two 
separate projects because people will start thinking of them that way. then we 
lose the symbiosis, we lose people working on components that benefit all 
workspaces, we divide the Big Fire into a bunch of Little Fires which will 
eventually go out. that is a way to kill all workspace projects in the long 
run. we do not have the resources to run each shell as a wholey separate 
project, but we do have the resources to run them together.

most frustratingly, i have spent much of my coding time until very recently 
almost exclusively on desktop components (the shell, plasmoids we use only 
there, etc) and yet still received feedback about our lack of commitment to 
the desktop. some who have been making such observations have been doing so 
from the outside without an accurate picture. 

this situation is NOT cool. it WILL erode our community. and that is one of 
the only types of behaviour that is not acceptable here.

the reality is that sometimes we'll spend more time and effort working on 
components used in one device workspace or another. this will ebb and flow over 
time. have patience with this process. celebrate people's efforts and 
interests. support the sharing of code between workspaces. search for ways to 
harmonize the different shells and components they share.

that there are people who want to put more effort into the desktop components 
is great! i am very supportive of this, opening the doors to our working 
processes, sharing our vision, open to seeing where that needs evolving, etc. 
in the process of doing this.

i only ask that those getting involved show the same level of interest and 
respect. that means learning how plasma has and is working and engage with 
positivity rather that stop energy. thank you.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120517/a91f267d/attachment.sig>