Organizational Notes Fall 2017

[Jens Reuterberg]

VDG/KDE Design Group
---------------------------------------------

When we work we have three different kinds of tasks: roughly its "speculative", 
"goal oriented" and "maintainership". 

WHAT IS SPECULATIVE WORK?
Speculative work is work done to promote a new design direction, a new concept, 
something that one or more designers thinks should be promoted. It's 
speculative if its not set with a "official VDG stamp" or if the core developers 
in a project see it as the path forward or are involved in it. 
When you want to test something or present new ideas - "Speculative work" is 
what its called. Anyone can do this. 
Speculative work HAVE to be marked as such clearly in ALL mockups and text. 
Either by a banner on the image, covering part of it to ensure its not shared 
onwards without being apparent.

WHAT IS A PROJECT?
A project is work with a clear direction and path to completion. It is supported 
by the developers who's app/other it is or by the VDG in total. A project is 
the main way to practically move forward. Being in charge of a project means 
focusing on it, and being able to say "no" to further work. It means being in 
constant contact with the devs concerning that project and being honest in 
your own time constraints. We all have real lives and no one needs to apologize 
for living one, but we need to clearly tell people when real life is blocking 
work and hunt down a replacement if needed.

WHAT IS MAINTAINERSHIP?
Maintainership is the core work for VDG, it means the daily tasks and core 
work of what we do, ensuring consistency and updates in work. Maintaining 
something means handling the day to day rigmarole, being in charge of checking 
and commenting on bug reports. It means being the core contact for devs and 
users in connection to whatever area. Leaving a maintainership means finding a 
replacement.

What does a Project Lead Designer do?
Needs filling out

WHAT DOES A MAINTAINER DO?
A maintainer ensures that the day to day small choices are settled. The 
Maintainer sticks to the design set down by the VDG, follows the HIG and have 
confidence in his/her own abilities to clearly say "yes" or "no" to choices and 
options. The Maintainer tries to settle conflicts, not start them (that is for 
Speculative work). A "maintainer" can also handle complex tasks like handling 
the bug list, work as an informative source for users or devs. 

CROSSPROJECTS
There are situations where Projects and Maintainerships cross over - Icons is a 
good example of that. On the one hand it involves a lot of Maintainership, 
ensuring that the icon theme is in good order, bugs are filled and handled etc. 
On the other it is flexible and new designs that may be seen as controversial 
may come in - in those cases it may be worth while to write down eventual 
controversies and inform others of it to ensure that there is some sort of 
paper trail and communication about it.

When a project is stable - when the work is more a question of maintaining it 
it should move into a maintainership and a maintainer needs to be set.

WHO ARE THE CURRENT MAINTAINERS
Plasma's Icon theme: Andreas Kainz andreas_k at abwesend.de
Breeze GTK theme: Scionic_Spectre, dirruk1
Breeze Widget theme: (not clear yet)
Bug Wrangling: Graham  pointedstick at zoho.com
HIG Maintainer: Fabian

WHAT ARE THE CURRENT PROJECTS AND MAINTAINERS
Grub to Shutdown v2: Anditosan (droserasprout for SDDM)
Kirigami: Alex L and Colomar colomar at autistici.org and alexl at openmailbox.org
System Settings: Anditosan anditosan1000 at gmail.com
The New Webpresence: Ken vermette at gmail.com
Mycroft Integration: Andrew jamboarder at gmail.com
The new HIG: Fabian

I DON'T HAVE A PROJECT AT ALL OR MAINTAINERSHIP, YOU FORGOT ME, THIS SHOULD BE 
A MAINTAINERSHIP!
I have probably missed something - please help fill it out. I'm forgetful :) 
There are several things which should be maintainerships but with the 
complexity of Plasma (addons etc) we should be careful to avoid having a too 
long list, add the critical bits here. 

WHAT TOOLS DO WE USE?
We use what the devs use for communication. We are not different from the devs 
and need to ensure that we are on the same communication channels as they. That 
means Phabricator and Pholio for us, it means email lists, IRC/Telegram/
Matrix. 
We make certain that tasks are presented openly and honestly. Design is 
complex because anyone with a mouth can cherry pick through the internet to 
find arguments for anything. We need to trust our own abilities, and do that 
with humility and calmness and in the open. 

We use ONLY opensource tools unless there is absolutely no alternative and even 
then we need to be careful and consider not doing it. 

HOW DO WE WORK?
Our work happens in the open. We assume good intentions. Any conflict should be 
resolved and not hunted for. We accept when an agreement have been met. We do 
not rehash old arguments as new to keep a debate going once it has been 
settled. We do not allow personal opinions to cloud our understanding that this 
is a collaborative project and humility is our best quality. We can't always 
get what we want or consider the best, sometimes we simply have to accept that 
cooperation is more worthwhile than our view of perfection in one area. The 
group has value in itself.
We invite others to work with us whenever we can, we accept that being in 
charge means that we have to work harder to gain respect from users - it will 
never be handed over by way of a title.

If we want to suggest a new idea, a new direction, we need to present it to the 
group first, ensure that it follows the HIG and the design goals we have set up 
in terms of style. When the group accepts it, we try to contact the developer 
in charge. If there is none we try to find one to fill the role. 

Autonomy is still relevant though and sometimes it can be refreshing to work on 
your own with a developer - but if the project is directly connected with KDE 
and Plasma we need to keep the group involved to ensure that the design 
doesn't wear off from the HIG or design goals.

TIME, SAYING NO, AND TRUST
We will meet scenarios where there is either too little information, we feel 
countered by the developers or have no time to finish a task. Be clear and tell 
me. I will ensure that what ever is needed from each dev is handed over, and 
that someone else will fill the role or, it will have to be pushed forward into 
the future.

HOW DO WE INVITE NEW PEOPLE?
Just do. Anyone can help out, anyone can understand the work. Just make sure 
they don't join on false premises (that they don't think they will change 
everything themselves - we are not looking for new Steve Jobs here)

WHERE ARE WE GOING DESIGN WISE
This is something we need to consider. We have HIG puttering on but need filling 
out, we have Kirigami and the changes that provides. But we need to look at 
thre graphical and communicative design challenges (what "flavour" we want to 
have) as well as detail work like graphical profile, communicative profile. 

That is one area I would love to deal with in the future. The graphical profile 
(in print etc) as well as working out the "flavour" we are going for.



<3 Jens