Er zijn geen opmerkingen over het vorige verslag. Jo zal dat op enige punten aanpassen en publiceren. Omdat bijna alle onderliggende stukken Nederlandstalig zijn, is het niet eenvoudig de notulen in het Engels te houden, maar er zal gepoogd worden in elk geval op de website e.e.a. kort te beschrijven.
Naar aanleiding van de vorige vergadering wordt Jean-Luc verzocht zijn stuk enigermate te herschrijven, zodat wat duidelijker is welke taken een releasemanager op zich behoort te nemen. Jo zal het voorstel aan zijn bestuur voorleggen, maar geeft aan dat dit in lijn met de prioriteitstelling is. Bovendien heeft een dergelijke functie twee jaar lang in de begroting gestaan. Deze is er uit gehaald om dat er in die jaren geen consensus over kon worden bereikt.
2. Michiel geeft aan dat om 1.8 te kunnen releasen er vooral nog een groot aantal bugs gefixed behoort te worden. Er wordt afgesproken een bugfixing day te organiseren en dit op de developersmeeting voor te leggen. Daar wordt afgesproken dat deze dag op vrijdag 24 maart in Rotterdam op kantoor van Finalist georganiseerd wordt. Jo zal contact opnemen met het management van de Publieke Omroep om te vragen of het mogelijk is Michiel aansluitend een tweetal dagen vrij te stellen om de release ook daadwerkelijk af te ronden.
Gepoogd wordt om dit moment tevens aan te grijpen om Jira als bugtracker te installeren. Jean-Luc zoekt uit wat hiertoe de condities zijn. Een dump van de database en de contactgevens van Justin zullen naar Nico gestuurd worden (actie Henk).
3. In de tweede vergadering van het technisch comite is uitvoerig gediscussieerd over de vraag hoe te komen tot een architectuur. Het plan bestond om eerst uitgangspunten te formuleren en een soort ‘mission statement’, maar de aanwezigen denken dat de systematiek zoals die door Nadia Poulou van Kennisnet wordt gepresenteerd, waarschijnlijk sneller en makkelijker tot een compleet architectuurplaatje leidt. Deze systematiek laat zich in a nutshell als volgt beschrijven.
Bovendien geldt voor ieder ‘onderwerp’ dat van belang is voor de architectuur dat het op geuniformeerde wijze beschreven behoort te worden (bijvoorbeeld: licentie, platformonafhankelijk, coding standard, documentation standard, etc.).
De leden van het technisch comité maken per omgaande een start met het beschrijven van de principes, conform het sjabloon dat daartoe is opgesteld. Dit geheel leidt tot een set van documenten, die tezamen het architectuurmodel representeren. Afspraak is dat we hier al voor de volgende vergadering een eind mee proberen te komen. Nadia biedt bij deze notulen de presentatie en het daarin opgenomen tijdschema aan.
Deze ‘principes’ worden niet in beton gegoten. Ieder principe heeft een eigenaar. Principes kunnen bediscussieerd worden. Gezocht wordt nog naar een goede systematiek om dit te faciliteren (wiki, sharepoint, anders).
Voor de volgende vergadering zal Jo een communicatieplan opstellen. Als we het schema aanhouden zoals dat door Nadia voor de inhoudelijke bijdragen is opgesteld, dan lijkt het zinvol om bijvoorbeeld in mei de developersmeeting een wat uitgebreider karakter te geven en daarbij ook de gebruikers en dienstverleners uit te nodigen. Er is dan wel een en ander te melden.
Dit is uitvoerig besproken op de developers meeting en de vorige keer in het technisch overleg. In de komende periode moet een aantal kleine en gerichte sessies met belangrijke stakeholders leiden tot meer concrete voorstellen. Belangrijkste doel is om invulling te geven aan een modulaire component gebaseerde ontwikkeling en het bereiken van synergie tussen beide belangrijke ontwikkelingen. En uiteraard om ervoor te zorgen dat beide ontwikkelingen daadwerkelijk geïmplementeerd kunnen worden. In een latere fase zal brede afstemming plaatsvinden.