Verwijs naar de verantwoordingsplicht onder artikel 5 AVG

[floort]

Naast de verschillende normen uit 5(1) AVG die al genoemd zijn moet ook aan 5(2) worden voldaan.

[ruthkoole]

Hi @floort !

Dank voor je pull request en het meedenken!

We waren nog niet helemaal tevreden met deze opzet van de normen, zoals ze nu online staan (het is allemaal nog work in progess). Dus we zijn bezig met een nieuwe opzet hiervan (volgt zsm ook op Github). We nemen deze daar zeker even in mee!

[floort]

Ik zag 3 dagen geleden nog een commit 717934c met wat kosmetisch onderhoud waaruit ik had opgemaakt dat het op hoofdlijnen uitgewerkt was. Is het handig om misschien ergens een overzicht te plaatsen waaruit blijkt waar wel en geen bijdragen gewenst zijn?

[floort]

Zie PR #72. voor een suggestie.

[ruthkoole]

Hoi @floort,

Wat er nu online staat, is een eerste opzet van het algoritmekader. We waren nog niet heel tevreden over de opbouw, dus werken we in de andere branches aan een verbeterde versie van deze opzet. Dat kan je bijvoorbeeld volgen in de branch 'templates': https://github.com/MinBZK/Algoritmekader/tree/templates. Hier werken we aan nieuwe templates voor de verschillende pagina's.

Het is dus niet zo dat bijdragen niet gewenst zijn (juist wel). De inhoud van de normen en maatregelen krijgen met de nieuwe opzet gelijk een update, en daar nemen we deze aanbeveling zeker in mee.

[floort]

Hoi @ruthkoole,

De templates branch is bijzonder lastig te volgen vanwege de enorme hoeveelheid commits zonder heldere omschrijving. Kan ik behalve daar meelezen ook pull requests op die branch voorstellen?

Een ontwikkelstijl waarbij de main branch op slot gaat omdat er in een zij-branch ontwikkeld wordt is mij niet bekend. Is het niet de verantwoordelijkheid van de templates branch om up to date te blijven met main en conflicten op te lossen voor een merge? Dit conflicteert ook met de handleiding in README.md over het bijdragen in deze repo.

Als PR #72 onjuist is, kan er dan een alternatieve uitleg worden gegeven over hoe/wanneer bijdragen wel gepast zijn.

P.S.
Ik bedoel ook niet dat bijdragen niet gewenst zijn, maar ik krijg wel sterk de indruk dat bijdragen voor het normenkader, op dit moment in main even niet gewenst zijn. Meer een nu/zo even niet, maar hoe/wanneer dan wel is nog onduidelijk.

[floort]

Ik heb het even laten bezinken. Git is ervoor gemaakt om onafhankelijke ontwikkelpaden mogelijk en zelfs efficient te maken. Dit project communiceert daar ook impliciet over door aan te raden om bijdragen via pull requests te communiceren. Maar ik merk dat het er nu op neerkomt dat een dergelijke ontwikkelstijl nog niet helemaal in het werkproces van het team zit of zelfs doordacht is en expliciet niet de bedoeling is. Alleen wordt er tegenstrijdig over gecommuniceerd.

De conventie is dat een pull request wordt geaccepteerd, geweigerd of waar relevant voorzien van feedback en verbeteringen tot het wel goed genoeg is.

PR #69 wordt niet voorzien van commentaar, wacht al een maand op een review van @jaspervanderheide, @ruthkoole of @MarjoleinKortemann die uitblijft. Tegelijkertijd wordt de PR voorzien van een stevige stroom ongetwijfeld hele nuttige commits, maar ze worden niet uitgelegd in commit messages en de hele PR veranderd daarmee waarschijnlijk sneller dan dat 'ie te reviewen is. Tegelijkertijd wordt het bijdragen aan main on hold gezet voor een (voor mij) onduidelijke termijn.

Waarom wordt er niet in een branch gewerkt tot er een concreet pak wijzigingen ligt, daarvoor een PR aangemaakt die dan zo efficient mogelijk gereviewd kan worden en al dan niet geaccepteerd worden met eventueel wat kleine aanpassingen? Zo kan er in main en andere branches gewoon door-ontwikkeld worden.

Zeker als buitenstaander is het veel makkelijker te volgen als een PR een redelijk samenhangend en goed omschreven bundeltje aanpassingen is. Als het makkelijker te volgen is is het ook makkelijker om bij te dragen, zeker voor degenen die niet bij alle interne overleggen aanwezig zijn.

Ik probeer bij te dragen op basis van de aanname dat git hier gebruikt wordt zoals het meestal gebruikt wordt. Die aanname blijkt onjuist. Misschien helpt bovenstaande suggestie om het werk zo te structureren dat het wat makkelijker wordt om bij te dragen voor externen. Als de werkwijze niet wordt aangepast verzoek ik om een heldere omschrijving, zoals PR #72, waaruit blijkt wat verwacht kan worden zodat pogingen tot bijdragen niet onnodig voor conflict zorgen.

[ghost]

Hi @floort, Je hebt gelijk met je observatie, we maken nog niet gebruik van Git zoals het hoort. Dit hadden we beter moeten communiceren. Feit is dat het hele projectteam nog geen ervaring heeft met het gebruik van Git, dus er worden dingen uitgeprobeerd en fouten gemaakt. We laten ons op het moment adviseren hoe we het beter (en volgens de conventies) kunnen doen. We verwachten eind van de week een grote inhoudelijke update en willen daarna ook het proces beter inrichten en bijhouden zoals het hoort (maar we zullen vast niet alles gelijk goed doen). Dank voor je feedback en we hopen dat het snel zichtbaar wordt dat we het beter willen doen. We kijken ook z.s.m. inhoudelijk naar dit pull request. @BartdeVisser

[floort]

Helder. Kan PR #72 of een alternatief verwerkt worden zodat het duidelijk is wat nu de stand van zaken is?

[floort]

Ik lees in de nieuwsbrief dat er wordt uitgenodigd om mee te werken in de github omgeving. Ik heb mijn fork weer up to date gemaakt. Ik zie een falende check van een github action waar ik volgens mij helemaal niks aan kan doen. Ik zal een los issue aanmaken voor dat probleem, maar volgens mij kan de PR wel een review krijgen.

[ruthkoole]

Hoi @floort ,

Nogmaals excuus dat het even op zich heeft laten wachten voordat we deze pull-request verwerkt hebben. Zoals gezegd is het werken met Git nieuw voor het team. Daarnaast hebben we in de afgelopen weken (weliswaar ietwat op de achtergrond) gewerkt aan een hele nieuwe versie van het Algoritmekader. Daardoor heeft het Algoritmekader ook een andere structuur gekregen, waardoor jouw suggestie een andere plek moet krijgen.

We gaan werken met releases voor het Algoritmekader. Dat betekent dat we ongeveer eens in de 6 weken een nieuwe release doen. De nieuwe release hebben we vandaag gedaan zie: https://minbzk.github.io/Algoritmekader/ en https://github.com/MinBZK/Algoritmekader/releases/tag/v1.1
In die nieuwe release hebben we jouw (inhoudelijke) suggestie verwerkt, zie https://minbzk.github.io/Algoritmekader/vereisten/beschrijven_en_toewijzen_van_verantwoordelijkheden_bij_verwerking_persoonsgegevens/

Kan jij je zo vinden in de verwerking van jouw suggestie?

Omdat het Algoritmekader een andere structuur van de bestanden heeft gekregen, zullen we je pull-request niet mergen. Hopelijk hebben we de inhoud van jouw suggestie wel voldoende verwerkt.
In afwachting van jouw reactie, wil ik de pull-request daarom sluiten.

[floort]

Bedankt. Hoewel artikel 5(2) wel genoemd wordt is mijn voorstel hiermee significant inhoudelijk afgezwakt. Is de afwijzing van mijn pull request zuiver gebaseerd op de veranderde structuur? In dat geval zal ik een nieuw voorstel indienen.

[floort]

Dit pull request is nu bijgewerkt aan de hand van de nieuwe structuur en kan daarmee op basis van de inhoud een review krijgen.

[floort]

Ik vind het vervelend om om updates te vragen, maar de mededeling over het voornemen om deze PR af te wijzen was onduidelijk. De enige gegeven reden voor het afwijzen is de structuur, die opmerking heb ik verwerkt en het is mij niet duidelijk of er ook een niet-uitgesproken inhoudelijke reden is om de PR niet over te nemen.

Als er nog naar gekeken wordt vind ik het niet erg om de PR periodiek up to date te houden met de main branch. Maar als dat niet het geval is hoor ik dat ook graag zodat ik er geen tijd meer in hoef te stoppen.

[ruthkoole]

Hoi Floor! De werkgroep rondom privacy en gegevensbescherming is aan het kijken naar deze suggestie. Helaas duurt dat wat langer dan dat we voor ogen hadden. Het gaat daardoor niet lukken om deze suggestie te verwerken voor de aankomende release (die is morgen). Er wordt dus wel nog aan gewerkt. Voor nu laat ik de PR dus nog even open staan.

[floort]

Dankjewel @ruthkoole, Dat is fijn om te weten. Ik krijg de indruk dat de PR door miscommunicatie over twee releases doorgeschoven is. ZIjn er zaken die ik beter kan uitleggen of aanpassen die vorige release hebben geleid tot verwarring over de inhoud van mijn voorstel? Er lijkt een vrij fundamenteel verschil van interpretatie te bestaan over art. 5 AVG tussen mijn voorstel en de uitleg die is opgenomen in release 1.1. Omdat de specifieke commit niet beschikbaar is kan ik niet nalezen waarom de auteur van mening is dat artikel 5 AVG zich beperkt tot het toewijzen en beschrijven van verantwoordelijkheden. Is het mogelijk om de overwegingen voor iedereen te documenteren door de inhoudelijke discussie ook hier in de comments te voeren?

[floort]

Bedankt voor de voorstellen @BartdeVisser! Ik heb de meeste punten overgenomen. Maar volgens mij blijven we op een cruciaal punt van mening verschillen: ik wil artikel 5 van de AVG niet afzwakken tot een pricipe om naar te streven. Het is een verplichting zonder uitzonderingen. Ik denk niet dat het verstandig is om te adviseren dat niet voldoen aan artikel 5 een risico is dat je kan nemen, anderzins optioneel is als het te ingewikkeld wordt of dat het voldoende is om vast te stellen of artikel 5 nageleefd kan worden.

[BartdeVisser]

Top, ik denk dat we er inhoudelijk wel zijn. Benieuwd of er feedback vanuit de omgeving komt.

Dat is echt iets wat aan ons ligt. Het raakt zaken als interne werkafspraken en ook de oprechte ambitie om je input voor te leggen aan de werkgroep (waar het spaak is gelopen). Ik hoop dat we vanuit andere PR's inmiddels hebben laten zien dat we er inmiddels beter mee omgaat, maar deze verdient de schoonheidsprijs (vanuit ons) absoluut niet.

Verwerkt