Organizational Notes Fall 2017

[Jens Reuterberg]

Addendum on tools:
We stick to opensource tools as much as possible - that being said "use the 
tool you want" - if someone sits on windows and does KDE work - go for it. The 
two reasonings for Open Source is on the one hand ideological (because we do 
open source), but the more relevant is practical. We can't share things that 
uses proprietary formats since others wont be able to work with those file 
formats. 

As long as the file formats work - its up to each person to decide what they 
prefer using, BUT that being said - opensource is to be preferred above all 
others - if say Illustrator can't open something, that is not a problem at all 
for us and not a second will be spent to ensure it can. If Inkscape can't open 
a file - that is a massive problem. 

Use what you want, but know why open source is preferred

On Monday, 23 October 2017 16.09.20 CEST Jens Reuterberg wrote:
> 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