Organizational Notes Fall 2017

[Jens Reuterberg]

(Andy sent directly to me by mistake, quoating him here) 
"As part of this effort to maintain Breeze, can you tell me what you
would be doing exactly? I am not familiar with how Breeze is
maintained. I might be able to help as well."

--------------------------------------

Firstly make the small edit Nate suggested for the colour theme (even if that 
is slightly off scope for this role still worth while though)

Aside from that I would love to look into spacing in general for the widget 
theme. 

Aside from that - slightly panic. :)

Hugo



On Monday, 6 November 2017 15.10.00 CET Jens Reuterberg wrote:
> I have currently taken over Breeze Maintainership until the time Andrew Lake
> finds more time from work (CC'ed Hugo since he deserves forewarning)
> 
> Added for information
> 
> On Tuesday, 24 October 2017 09.38.44 CET Jens Reuterberg wrote:
> > 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