Na de release van 1.0.0 van de eerste VNG API’s worden de API’s vanaf nu apart doorontwikkeld. Dit heeft al geleid tot een 1.1 versie van de Zaken API standaard, Documenten API standaard en Catalogi API standaard. Voor een volledig overzicht van de releaseplanning zie de milestones van de standaard. Deze milestones bevatten ook de releasenotes
Momenteel wordt er hard gewerkt aan de API standaarden voor Contactmomenten, Klanten en Verzoeken. Van de Contactmomenten API en Verzoeken API is inmiddels een 1.0.0 versie uitgebracht, van de Verzoeken API is een 1.0.0-beta versie beschikbaar.
Het team dat aan de API’s voor Zaakgericht Werken werkt doet dit volgens de agile methodiek. Gemeenten en leveranciers leveren wensen en behoeften in de vorm van user stories rond zaakgericht werken die vervolgens worden vertaald naar wat nodig is in de API’s. De user stories wordenin overleg met de stakeholders toegevoegd aan een milestone en in de betreffende release uitgewerkt.
Het is niet nodig om software of documentatie te schrijven om toch bij te dragen. De ontwikkeling is ook gebaat bij gerapporteerde problemen, suggesties voor wijzigingen en vragen over dingen die (nog) onduidelijk zijn. Om dit te doen kan een issue worden gemaakt. Op de supportpagina’s van GitHub staat uitleg over het maken van issues.
Maak om bij te dragen aan de documentatie of software van de ZGW API’s een zogenaamde Pull Request. Lees alles over hoe git (en GitHub) werkt in deze introductie over git flow](https://guides.github.com/introduction/flow/).
Dit project hanteert het OneFlow branching model. Maak je wijzigingen op een nieuwe ‘feature branch’ met de naam feature/naam-die-bijdrage-beschrijft. Zorg voor heldere beschrijvingen voor iedere commit, zodat degenen die de bijdrage moeten beoordelen een goed beeld hebben van wat de bedoeling is.
Wanneer de bijdrage compleet op de nieuwe feature branch staat kun je een Pull Request maken. Dit is, zoals de naam zegt, een verzoek aan de eigenaren van de repository om de branch met wijzigingen op te halen en in het project te voegen. Verzoek daarbij is om elke Pull Request te voorzien van een duidelijke beschrijving en eventuele issue nummers die met behulp van de Pull Request worden opgelost.
Alle bijdragen worden beoordeeld in een review proces. Je kunt zelf ook specifiek aan een teamlid vragen om een review.
Het kan zijn dat een Pull Request direct kan worden ingevoegd. Vaak is het echter nodig om nog het e.e.a. te verbeteren aan de Pull Request voordat deze in het project kan worden ingevoegd. Feedback op de Pull Request kan komen van de eigenaren van de standaard, van andere belanghebbenden of van geautomatiseerde tests.
Wanneer de gewijzigde documentatie en code door de menselijke review en geautomatiseerde test komt, worden de wijzigingen van de Pull Request in het project gevoegd.
Er worden vier scrum boards gebruikt om de flow naar resultaat in elke sprint te faciliteren.
2. Scrum ZGW Voorbereiding Nieuwe user stories en issues komen hier op de backlog. Wanneer zij worden geprioriteerd komen ze in de flow om ze ‘ready te maken’ zodat ze opgepakt kunnen worden in de volgende sprint.
1. Scrum ZGW Realisatie Huidige Sprint Vanuit de kolom “Ready for Sprint” worden tijdens de maandelijkse sprint planning userstories opgepakt die uitgevoerd gaan worden. Deze komen dan in de eerste kolom van het scrum board gericht op realisatie van de API specificatie.
3. Scrum ZGW Gereed Archief Op dit board is terug te vinden welke user story gereed was in welke sprint.
4. Out of scope Op dit bord komen alle user stories die buiten scope zijn voor ZGW API’s en die functionaliteit beschrijven voor gebruik van de ZGW API’s buiten zaakgericht werken.
Zowel het board Scrum ZGW Voorbereiding als Scrum ZGW Realisatie Sprint x bevat een kolom voor review. Tijdens de voorbereiding worden user stories klaargemaakt om in een volgende sprint uitgevoerd te worden. Daar hoort een review bij: voldoet de user story aan de Definition of Ready? Na de realisatie vindt opnieuw een review plaats, van iedere Pull Request waarmee een wijziging of toevoeging op de standaard wordt gedaan.
Reviews worden vaak aan specifieke personen gevraagd, maar iedereen kan een review uitvoeren. Wanneer de beoordeling binnen je competenties valt, geef de review dan prioriteit boven eventuele andere bijdragen zodat iedereen zo snel mogelijk verder kan.