Meeting Notes: Plasma 2 Coordination

Thu Oct 31 16:50:32 UTC 2013

Plasma Meeting Thursday, 31-10-2013

Present: d_ed, mck182_, terietor, sebas, bshash, notmart, aseigo, teo, 
agateau, erin, ivan, unormal, bcooksley, vhanda, afiestas

Agenda:
	* enumerating the functional blocks in Plasma Workspaces at a coarse level 
(e.g. “power management”, “desktop shell”, “window manager”..) matching up 
with maintainers
	* summary of functional and design goals from last Tokamak
	* rough outline of time based goals (technical preview, etc)
	* tabling a project management framework that ties the above three things 
together
	* possibilities for Tokamak.next()

Introduction (aseigo)

My hope is that after this meeting we will have the start to some more 
concrete project management for the Plasma2 effort. Talking with sebas on 
monday, we noted that the effort has turned a very important corner: we're no 
longer just porting libraries to a shaky Frameworks 5 foundation. Now a lot of 
the emphasis has turned to porting things in kde-workspace and restoring 
functionality to key components
which is awesome; you all deserve a huge "you rock" for getting things to this 
point. :) What lies ahead, however, requires more than a TODO list that people 
pick away at; well, at least it does if we want to end up with something that 
is consistent and wonderful as a finished product. In the last ~18 months 
people like afiestas have talked more and more about wanting the various 
components to work well together and for there to be a higher level of 
"seamlessness", and i think that's a very useful goal. to get there we need to 
be organized and collaborative given some of the recent work done, such as 
mck182_'s good efforts to get splash screen stuff back to good, it's apparent 
at least to me that we aren't doing a great job of that. :)

The Functional Blocks Of Plasma Workspaces

Plumbing / underlying infrastructure

	* appmenu
	* kactivitymanager
	* kcheckpass
	* kcminit
	* kded
	* kglobalacceld 'Reference Lists' section.
	* knotify4
	* ktimezoned
	* ktouchpadenabler
	* kuiserver
	* kwalletd
	* kwrited
	* metadata
	* online accounts
	* shell switching control
	* statusnotifierwatcher

Session management

	* fast user switch
	* ksmserver
	* ksplash
	* lock screen
	* login / display manager
	* log out UI
	* startkde

Hardware experience

	* bluetooth
	* disk management: automount and freespacenotifier
	* input devices (e.g. keyboard layouts)
	* kscreen
	* libsolid
	* network manager
	* powermanagement
	* soliduiserver

Desktop UI

	* activity manager
	* add ons / application delivery
	* desktop containments
	* firstrun experience (set up accounts, choose shell style ..? oem like)
	* kdesu
	* khelpcenter
	* kinfocenter
	* klipper
	* knetattach
	* krunner
	* ksysguard and process list
	* libtaskmanager
	* notifications and status notifiers
	* panels
	* screen savers
	* share*like*connect
	* styles (oxygen, air for widgets and qml)
	* system settings
	* unified plasma shell
	* wallpapers
	* widget explorer
	* window manager (kwin)

Summary from Tokamak 6 (at least the relevant bits)

Notes: http://community.kde.org/Plasma/Tokamak6

Look 'n Feel system

Info: http://community.kde.org/Plasma/lookAndFeelPackage

Many things are managed by different processes, or even completely different 
projects (like login manager). But the user doesn't care about that, so the 
idea is to give it a grand unified look, even if they keep being different 
things internally. So, the potential places identified, in order of startup 
are:
	* Login screen
	* Splash
	* Some Kwin effect, such as Alt+Tab
	* Lock screen
	* Fast user switching
	* Logout screen

These are all just defaults. We will need a user tweakage UI for Look 'n Feel 
component settings and such things.

Desktop UX Elegance and Consistency

We discussed ways to bring some visual and behavior consistency to these 
different things, e.g. all modal parts really ought to look and work exactly 
the same way so they feel continuous. So some things in the workspace ui are a 
modal, interrupting thing like the login screen, the splash, the lockscreen, 
the user switching the logout dialog. Other things are non-modal like activity 
switching; some are semi-modal like Alt+Tab (semi-modal -> strictly speaking 
they are modal, but they are features to aid the user through transitions and 
so it doesn't actually block workflow). This part of plasma2 is our 
opportunity to rethink how some of the core UX components are presented

Improved the session management process

During Tokamak6 in March, we put the options for the startup procedure on the 
table, and realized that we have 4 unsatisfying solutions: startkde, 
startactive, systemk, and systemd scripts.

Goals for the Startup:
	* fast startup (as few processes as possible, minimal set of actions, 
highest performance options)
	* respect dependencies between components (component B requires A, so start 
component A before B)
	* seamless (no resolution changes visible, no shifting wallpapers)
	* declarative (easy to extend/improve, not tied to a single system)

Time Based Goals

~Quarterly milestone releases with public communication (blogs and 
announcements) and tarballs

Mid-December 2013
	* "Proof of Life" technology demonstration release
	* Dogfoodable
	* Basic functionality in place, then we can tackle UI and new concepts from 
there
	* Hardware experience

EOM March 2014
	* Technology demonstration release 2
	* Wayland session
	* Look 'n Feel package support implemented in all affected components
	* Session management and startup++, kded4 / ksmserver / etc

EOM June 2014:
	* The UX as we imagine it (yes, vague, we have a lot of definitional work 
to do there)

EPIC GOALS:
* Look 'n Feel system
* Desktop UX Elegance and Consistency
* Improve the session management process

Project Management Framework

	* We identify the main component domains for plasma 2 (e.g. "hardware 
experience") and ensure there is at least one coordinator for each (e.g. 
afiestas for "hardware experience")
	* We've actually already identified the main components when we did that 
big listing. the lists are the sub-components, the headings are the main 
components
	* That coordinator (or 2) ensures that all of the sub-components in the 
domain they coordinate has an acknowledge maintainer for the plasma2 
development effort
	* If there is a maintainer missing, we need to mark that down as well
	* For each domain component (e.g. "screen savers" in "desktop UI"), the 
maintainer needs to develop two stories:
		1) the porting story -> what needs to be done to make it awesome on 
Qt5/FW5
		2) the goals story -> how does work that is being done (or needs to be 
done) meet each of the 3 epic goals we have
	This will let us all know where we are individually heading and provide 
input without having to have giant meetings like this one constantly :)
	* The coordinator for each domain will work with the people working on that 
code to develop and document a time based plan that matches the milestone 
goals
	This will let us know when we should be able to expect things, identify 
when things need more people working on them (because they aren't meeting 
their goals)
	* Some time goals won't be known right away, and that's ok; those 
components can be marked with "time unknown" or "defered, waiting on <whatever 
is blocking>"
	* 2 people will co-maintain a project management position that oversees the 
entire documentation process, prodding people where necessary, working with 
coordinators to complete their areas, and then making sure that there is a 
global consistency to the planning

	* sebas and aseigo take on overall coordination
	* research into tools to replace wiki-based lists
	* PW2Todo becomes the todo list that feeds from the PM we document together

Next Tokamak

	* Preliminary plan: January, in Barcelona (before 15th)
	* sebas to start planning, email to list next week

Finis.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9