Domain bevat alle inhoud, specifieke yaml (bijv. beslag.yaml) bevat alleen HAL componenten.

Dus inhoudelijke componenten verplaatsen van hypotheek.yaml, beslag.yaml, enz. naar Domain.yaml

BRP-Historie-Bevragen --> Eerst een o.9 release aanmaken met hudige stand van de master. Check hier ook eerst op verwijzingen naar de master van de BRP-bevragen repo en pas daar eerst deze verwijzing aan voordat er een 0.9 wordt aangemaakt. Dan releasenotes nog aanscherpen n.a.v. opmerkingen in Pull Request. Indien afgerond --> release v1.0.0 aanmaken. --> check ook adellijke titel impact van BRP_bevragen 1.3.0.

• BAG bevragen
• BRK bevragen
• BRK historie
• BRK event sourcing
• BRP bevragen
• BRP historie
• BRP reisdocumenten
• BRP bewoning
• BRP tabellen
• BRP update API
• HR bevragen
• WOZ bevragen
• BGT bevragen
• Web-Security

Op https://vng-realisatie.github.io/Haal-Centraal-BRP-Bevragen-RvIG/ wordt het Haal Centraal logo niet gevonden

Ik heb zojuist even rondgesnuffeld op de “Open Personen” website van maykin media, maar zijn zijn bij de implementatie van de BRP-API behoorlijk afgeweken van onze API_specificatie.

Zie https://github.com/maykinmedia/open-personen/blob/master/src/openapi.yaml
Het kan best zijn dat als je een consumer volgens onze API bouwt dat die dan niet breekt als je Open Personen bevraagt, maar zo diep ben ik er nog niet ingedoken.

Als we echter op 1 of andere manier deze implementatie als referentie-implementatie in willen zetten zou die analyse wel gedaan moeten worden.

Het is niet duidelijk wat 'live' nu precies betekent. Ik denk dat wel duidelijk is dat het een status is maar wat houdt dat dan in.
Daarnaast wordt binnen de productpagina's bij de specificaties soms nog een andere status getoond ('IO') die n.m.m. in tegenspraak is met de status 'live' (voorbeeld).

BRP-API/Haal-Centraal-BRP-bevragen#528

hier is opnieuw gevraagd wat de status hiervan is. Nu wel oppakken? Of antwoorden dat (en waarom) we het later (of niet) doen?

BRP-Update-API --> Robert maakt versie v1.0.0. Johan stuurt mail aan Lia voor testondersteuning door ProcessFive.

Lint workflows voor alle repo's in orde te maken.

na het mergen van pull requests faalt generatie-sdks:

 ! [rejected]        master -> master (fetch first)
415
error: failed to push some refs to 'https://github.com/VNG-Realisatie/Haal-Centraal-BRP-Bevragen-RvIG'
416
hint: Updates were rejected because the remote contains work that you do
417
hint: not have locally. This is usually caused by another repository pushing
418
hint: to the same ref. You may want to first integrate the remote changes
419
hint: (e.g., 'git pull ...') before pushing again.
420
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
421
Error: Process completed with exit code 1.

Ha Melvin, zou jij de lijstjes met user stories kunnen filteren?
Alles wat in productie is (laatste productieversie + labels voorgaande versies).
De user stories die horen bij de versie in ontwikkeling moeten worden gefilterd op dat versielabel.

Zodra IO in productie gaat worden de user user stories van deze versie aan de user stories productieversie toegevoegd.

https://vng-realisatie.github.io/Haal-Centraal/ -> Onder het kopje “Producten” staan links naar API beschrijvingen van de BAG, BRK, BRP, HR, WOZ en BGT. Per beschrijving kan onder het kopje “Bronnen” een link naar de Stelselcatalogus worden toegevoegd.:

https://vng-realisatie.github.io/Haal-Centraal-BAG-bevragen/ -> https://www.stelselcatalogus.nl/registraties/BAG/
https://vng-realisatie.github.io/Haal-Centraal-BRK-bevragen/ -> https://www.stelselcatalogus.nl/registraties/BRK/
https://vng-realisatie.github.io/Haal-Centraal-BRP-bevragen/ -> https://www.stelselcatalogus.nl/registraties/BRP
https://vng-realisatie.github.io/Haal-Centraal-HR-bevragen/ -> https://www.stelselcatalogus.nl/registraties/HR/
https://vng-realisatie.github.io/Haal-Centraal-WOZ-bevragen/ -> https://www.stelselcatalogus.nl/registraties/WOZ/
https://vng-realisatie.github.io/Haal-Centraal-BGT-bevragen/ -> https://www.stelselcatalogus.nl/registraties/BGT

Kadaster-personen bevragen --> Afsplitsen endpoints van BRK-bevragen. Is hier nog steeds behoefte om de specs hiervan in een aparte API te gieten ? Zo ja, doen we dit op zo'n manier dat er geen impact is voor de consumers (lijkt me wel…). --> Bespreken we volgende week als Melvin er weer bij is. Daarna op de lijst om met Kadaster te bespreken.

Om wijzigingen op het theme zichtbaar te maken in de van dat theme gebruikmakende repo's moeten die eerst opnieuw gebuild worden. Dat kan door daar eerst een commit op uit te voeren. Er zijn nu 15 repo's die we op GitHub Pages publiceren dus dat is best een karweitje dat verder niets oplevert.

Misschien kan dit ook met een script geregeld worden. N.m.m. moet dat script dan het build proces op alle repo's opstarten.

• De benaming van labels voor versies is niet gestandaardiseerd. Verschillende repo's gebruiken verschillende benamingen. Ik zou dat graag gelijkgetrokken zien aangezien het dat makkelijker maakt lijsten met user stories te genereren zonder user stories te vergeten. Wellicht kunnen we dit meenemen bij het aanmaken van respositories.
  Syntax voor versie labels 'v[x].[x]'
• Haal-Centraal-BAG-bevragen: Er zijn geen issues gelabeld als user story voor versie 1.1.
• Haal-Centraal-BGT-bevragen: Er bestaan nog geen labels voor versies en ook niet voor 'user story'.
• Haal-Centraal-BRK-event-sourcing: Er bestaan nog geen labels voor versies.
• Haal-Centraal-BRK-historie-bevragen: Er bestaan nog geen labels voor versies en ook niet voor 'user story'.
• Haal-Centraal-BRP-bevragen: Er zijn geen issues gelabeld als user story voor de versies 1.0.
• Haal-Centraal-BRP-bewoning: Nog niet aan alle issues met het label 'v1.0' is het label 'User story' gekoppeld.
• Haal-Centraal-BRP-historie-bevragen: Aan niet alle issues is al een versienummer en user story label gehangen.
• Haal-Centraal-BRP-tabellen-bevragen: Er bestaan nog geen labels voor versies en ook niet voor 'user story'.
• Haal-Centraal-BRP-Update-API: Nog niet aan alle issues is een versie label en user story gekoppeld.
• Haal-Centraal-HR-bevragen: Er bestaan nog geen labels voor versies.
• Haal-Centraal-Kadasterpersonen-bevragen: Er bestaan nog geen labels voor versies en ook niet voor 'user story'.
• Haal-Centraal-Reisdocumenten-bevragen: Er bestaan nog geen labels voor versies en ook niet voor 'user story'.
• Haal-Centraal-Web-Security: Er bestaan nog geen labels voor versies en ook niet voor 'user story'.
• Haal-Centraal-WOZ-bevragen: Er bestaan nog geen labels voor versies.

Moet identiek zijn aan de index

• BAG bevragen
• BRK bevragen
• BRK historie
• BRK event sourcing
• BRP bevragen
• BRP historie
• BRP Reisdocumenten
• BRP Bewoning
• BRP tabellen
• BRP update
• HR bevragen
• WOZ bevragen
• BGT bevragen

Bugs die opgelost zijn, issues en userstories die geïmplementeerd zijn. etc

• BRP-Bevragen
• BRK-Bevragen
• BAG-Bevragen
• BRP-Bewoning

Check of het allemaal begrijpelijk is.

Zie VNG-Realisatie/Haal-Centraal-BRK-bevragen#779

ZSM afronden

Alle userstories in alle Haal Centraal repositories die een versielabel hebben van een al gereleasde versie moeten worden gesloten.

zoals kadasterpersonen

Het is mij niet duidelijk wat wordt bedoelt met het 3e item van de genummerde lijst onder 'Bijdragen' in 'Hoe kun je bijdragen?'.

Wellicht dit item iets anders formuleren.

BRP-Reisdocumenten-Bevragen --> Pull request #6 mergen ? --> Melvin, Kay en Frank nog niet approved. Cathy ook reviewen ? Indien gemerged --> Versie 1.0.0 maken. Johan doet check op wijzigingen en stelt releasenotes op. Van huidige stand master een 0.9 aanmaken. Bij breacking change of twijfel terugkoppelen en nog geen 1.0.0 aanmaken

BRP-Bevragen -- > Pull request #760 mergen ? Cathy heeft nog niet approved. -- Indien OK --- Release 1.2.0 maken.
Mergen en release aanmaken. Johan (check ook versienr in de OAS.)

Ook goede documentatie voor beheer en onderhoud hiervan maken. --> Robert en Johan doen dit samen met hulp van Melvin.

Melvin heeft al uitleg opgeleverd, maar dat is (voor mij in ieder geval) nog niet voldoende om zelf het beheer te kunnen doen.
Deze kennis en zelfstandigheid is nodig bij de (toekomstige?) beheerders van de repositories.

Verschillen-analyse uitvoeren op StUF WOZ versus de WOZ-API. (Versie Frank of versie Johan ?)
Wat zit er wel in onze API dat nu niet in StUF-WOZ zit. Voornamelijk afgeleide gegevens die een economische activiteit impliceren. (BV afgeleide WOZ-waarden en filtering i.g.v. meerdere beschikkingen.

De repo Haal-Centraal-Web-Security is nog helemaal leeg, inclusief de readme en docs/index.
En er zijn nog geen user stories toegevoegd.

@CathyDingemanse Kunnen we dat nu vullen, of moet voorlopig de link uit het top-menu worden gehaald?

Bag bevragen: kortere intro

BRP bevragen:
licentie wijzigen in 2020
kortere tekst: is nog niet live!
direct aan de slag wijzigen in: direct experimenteren?

GOALS canvas bewoning naar bewoning rep verplaatsen

elke action geeft een waarschuwing:

Ubuntu-latest workflows will use Ubuntu-20.04 soon. For more details, see actions/runner-images#1816

BRP-Bevragen --> Gestripte versie voor RvIG waar alle wettelijke belemmeringen worden uitgehaald (bv. aanschrijfwijze ) . Cathy zoekt op welke afspraken daarover gemaakt zijn en zet dat in een issue. Discussie over hoe we dit gaan doen in termen van branch, fork en/of release voeren we volgende week als Melvin er weer bij is.

Discussie m.b.t. nieuwe majorversie n.a.v. beperken parameter-lengte afronden. Frank stelt oplossing voor aan Mark (geen foutmelding bij >255 maar gewoon een leeg resultaat teruggeven. ) Issue #364 gaat hierover --> naar de backlog met label “volgende major” en "breaking".

zoals kadasterpersonen, totdat een opsplitsing beslissing is genomen en doorgevoerd.

Op de pagina "Hoe kan je bijdragen" staan de bovenstaande links, maar die werken nog niet naar behoren.

Het zou beter zijn de subresources ouders, partners en kinderen als groepen (objecten) in de ingeschrevenpersonen resource op te nemen. Eigenlijk zijn dit geen subresources, het zijn eigenschappen van de persoon

Er is een repo BRK Historie Bevragen, maar de readme is nog leeg. Specificaties zijn er alleen in drie branches, maar onduidelijk is wat in welke branch staat met welke "status"

@MelvLee weet jij wat in welke branch staat? M.a.w. kunnen we de side-na links voor Swagger en Redoc laten verwijzen naar de specs in develop, of toont die dan maar een deel van wat er gemaakt is?

De pagina waarop de planning moet worden getoond geeft een foutmelding.
De link naar 'https://eu-rm.roadmunk.com/publish/4ac89376551785bace5e22f09c8247f307e1c061' loopt blijkbaar dood.

Status is nu in ontwikkeling. Wel is er binnen ons team enige discussie over dit onderwerp. Ik nodig Arnoud uit om hier een toelichting op te geven in ons team.

Zie GOALS Canvas in develop branche:
https://github.com/VNG-Realisatie/Haal-Centraal-BRP-bevragen/blob/develop/docs/goals-canvas.md

zodat zowel RvIG als deelnemers aan de pilot weten welke gegevens in de RvIG API niet geleverd worden, en hoe dat met de proxy API geleverd wordt

BRP-Bewoning --> Eerst een 0.9 van de huidige versie maken -- check #760.
Noot: Alle verwijzing naar BRP -- laten verwijzen naar 0.9 versie van BRP in huidige master van Bewoning. Dan checken op resolven. Dan 0.9 bewoning aanmaken. Daarna alle issues verwerken die v1.0.0 gelabeled zijn. Na verwerking alle issues --> final check en dan release v1.0.0 aanmaken.