LiMux student "kick-off"

Hi everybody,

since the LiMux students are already working on various LO
EasyHacks, I really want to get the long-term projects started.

We're using currently using the #libreoffice-lhm channel for
communication. I hope the respective groups get organized themself.

And I hope I have all involved persons in the CC.

So - just as a reminder from the LOConf14 hack night:

> * KDE5 - OpenGL / VCL rendering backend (Moggi / Tor)
>       + solve the BitmapEx problem ...
>       + CloudOn / KDE5 / Android ?
>       + DTardon ?
>               + Stefan Weiberg
>               + Michael Juamannn
>       ** Tor - help with infrastructure / setup etc.

LHM: Jan-Marek Glogowski

I just started to refresh my 10+ year old OpenGL knowledge.

> * VCL: main-loop / timeout foo [ menTor ;-]
>       + Making our main-loop have an 'idle' concept
>         with priorities vs. mix & match timers.
>               + Tobias Madl
>               + Jennifer Liebel

LHM: Florian Haftmann

> * Import performance - XFastParser vs. old-style parsers.
>       + ooxml foo [!] ... - semi-mechanical ?
>       * Auto-correction first:
>               + Daniel Sikeler

LHM: Ignaz forster

AFAIK Miklos was Michaels suggestion for the mentoring - can't remember.

Last week at LiMux we sat together and wrote down aprocedure to handle
the mentoring from our POV. We already have a non-digital kanban board
(anybody used to https://trello.com/?).

>  Sketch of a model for cooperation and coordination
>  --------------------------------------------------
>
>  ### Framework
>
>  * Two-week iterations (»sprints«)
>  * At the transition from one iteration to another, there is a common status meeting via Google 
> Hangout. This covers:
>      * A status report concerning the passed iteration.
>      * General remarks concerning the state of the whole progress, including refinement proposals.
>      * A planning of the next iteration with envisaged aims and effort estimation as far as 
> appropriate.
>  * The iterations cover the following issues
>      * Three major topics (»stories«):
>          * OpenGL backend
>          * Priority scheduling
>          * FastParser promotion
>      * Vast minor topics (»small tasks«):
>          * easy hacks and most annyoing bugs from LibreOffice
>          * various LHM-specific issues
>  * Issues are selected via status meetings. A reasonable proportion of issues (e.g. 70 % stories, 
> 30 % small tasks) is taken into account.
>  * A task lifecycle could look like as follows
>      * stories
>          * iterative breakdown in smaller issues
>          * overall status estimation (»_ % done«)
>      * small tasks
>          * qualification
>          * development
>          * test (four-eye-principle)
>          * internal documentation (for LHM reporting)
>  * Visualisation is done using a taskboard (Kanban like)
>      * no equipment for digital taskbaord available, but we can take a photo for each status 
> meeting
>      * suitable color code, e.g.
>          * story = green card
>          * story task = bright yellow card
>          * small task = pink card
>      * Administrative tasks can also be represented (e.g. dark yellow card)
>          * e.g. pre-qualification of LHM-specific issues
>      * Structure of task board resembles task lifecycle

>  ### Common Todos
>
>  * Refinement of sketch
>  * Agree upon sketch
>  * Find suitable weekday for status report 

Probably we should simply add a Wiki page for easier coordination?

Comments please

Jan-Marek