Raw notes & insights

Goal of research

• Understand usecases of other teams to track history of changes

• Understand if usecases are userfacing or back-end facing

Insights

Current issues with logging;

• Time intensive & too much data to sift through (GN)

• Every change needs to go via email to dev (Felix) (Loket)

Potential usecases to track changes:

• 🟠 Overall there is no/little need to track changes made from ABB-employees to products other than OP

There are however other opportunity areas:

• Release comms/process; Track quality of/changes to other databases & products that affect product-experience. Context; interviewees mentioned release notes & following-up dev/product releases spontaneously when asking what changes they would like to track

  • Vlaamse Codex (GN)

  • Mandaten & leidinggevenden databank (GN)

  • App-universum (lay-out changes need to be updated in manuals) (GN)

  • Updates to formulieren (Asks when certain formulieren went live - Loket)

• Track end user-behavior for

  • support-purposes (but belief that users should self service themselves) (GN & Loket)

  • malicious intent (anonimisering)

• Create feature to visualize & track changes for end-users

  • Reduce support needed (GN)

  • Tracking data quality when end-users are responsible for the data being input in the product (GN & Loket)

• Create platform to report & follow-up changes to other parties (Vlaamse Codex) - instead of tracking changes reactively, create end-to-end proactive platform. (GN)

Concrete potential features to use history of changes;

• GN = anonimisering, verkeersreglementen, Vlaamse codex. --> History of changes is not important for now, but perhaps in a year from now on.

• Loket = Reports to track data quality (did besturen update what they needed to update) --> History of changes might be important for City councils, but this has not been validated with city councils. Additionally; certain "edit" features have been deprioritized in Loket. (I have questions then on need for a revision tool)

• 🟠 History of changes feature: tracking is important for databases & products reporting on data quality, but we need to create a strategy of data ownership (the ones inputting & editing it) and therefore the ones that need to revise changes. Context; Loket was not enthusiastic about a "History of changes" feature for ABB-employees, but they were potentially interested in it for city councils, given they are the ones with expertise in the data and the ones that should input (and thus correct) it. If we want to create a feature of value to multiple user types, we should lay out the ones that would input/edit/revisit the data and what features they need to see where it overlaps (and value is created for several users)

  • For OP, the data is owned by ABB.

  • For GN, as they don't report on data quality as they just provide a "shell product", local governments are responsible for data quality.

  • For Loker, city counsils are data owners. ABB just follows-up & nudges to get the correct data.

• Filters needed. Search on

  • Words

  • Variable parameters

  • Time (hour & second)

• In case of proactively alerting; summary of changes via email

Concerns

• GDRP; can we just show al contributor information?

Proposal next steps

Depending on the effort needed to create a simple list view of who changed something (only usable for OP), create that list OR pause the development of History of changes until below points are completed;

1. More user research

   1. Chat to Katrien (to understand how data quality is measured), Vlaamse Codex (is that possible?) & Aad (unsure with what goal?)

   2. Chat to city councils that input a lot of data to understand need for revision

2. Create strategy & matrix on data ownership

   1. Who is responsible for the data input, editing & revision. Do so per product.

   2. Lay out what features they need

3. Strategy for where revision sits compared to allowing users to edit data Context; revision of edited data happens after data was input AND edited. Is that flow already completely correct? If not, should we focus on that one first?

Raw Notes

Vragen	Notas GN (Pieter & Bart)	Loket
Has there been an instance where you needed to track if someone changed something to your product? Where? What usecase? Who did so?	Wetgeving die toegevoegd wordt aan de Codex. En hoe je die kan opzoeken voor Gelinkt Notuleren. Voor mobiliteit is er een sjabloonl er was een resem van legale verwijzingen die toegevoegd moesten kunnen toegevoegd worden en die zaten niet in de Codex, die werden aan de Codex toegepast worden. Dat werd via mail met de Codex overeengekomen. Verantwoordelijke = cel bij de Vlaamse Overheid. Legale business elementen; Decreet Lokale Besturen --> herinterpretatie. Pieter & Bart kijken naar functioneel technisch, maar business luik moet bij Business van ABB zit . Juridisch legale elementen tracken --> Verkeersreglementen -> MOW die register beheert wil cameras toevoegen. Mandaten & leidinggevenden databank; als daar iets aangepast wordt, en er is een klacht, weten wie dat gedaan heeft. GDPR & privacy wise. --> lokale besturen veranderingen opvolgen. Anonimisering; wie heeft wat geanonimiseerd. Als er teveel of te weinig geanonimiseerd worden. App universum: lay-out aanpassingen tracken --> veranderingen van knoppen om handleidingen aan te passen. Toekomst; structuur van een sjabloon om met een wetgeving om tekst of artikel die inhoudelijk een impact hebben. Reglementen: Visualiseren van parameters die aangemaakt zijn. Belastingstarief vs percentage vs bedrag --> allemaal verschillende parameters. Type ongedierte.	Mailbox van de helpdesk; besturen die vast zitten & kunnen zien of er iets veranderd is. Komma van subsidie bedrag staat fout --> zij passen het aan. Nieuwe formulieren & subsidies; we houden het bij in Jira, wanneer het live komt. (--> kijken in de mailbox). Release notes van formulieren --> aanpassingen aan de formulieren. Meer mensen die het klaar zetten --> wanneer staat het live? Nieuwe wachtwoorden voor collegas die in Loket gaan kijken (op naam). Personen moeten geen wijzigingen doen. Geen wijzigingen gebeurd die moeten doen. Alles die aangepast wordt die in de back-office naar de dossier beheerder. Wat kan aangepast worden; Zaken die naar mandaten databank gaan Wordt altijd nog door iemand inhoudelijk nagekeken. Al 4 jaar zo gewerkt. Lokale besturen beorgen een communicatie naar ABB. ABB stuurt naar databanken.
Do you currently have functionality to do so? How is that working?	Dev kan in de loggings gaan kijken --> niet gebruiksvriendelijk & tijdsrovend. Houden niet bezighouden wie er iets verwijderd. Probleem; heel veel data --> overspoelt door data. Via email & release notes --> kunnen we service desk achter zetten om aanvraag op te volgen? Pro-actief aanvragen van changes.	- Subsidie dossiers; je ziet enkel wie & wanneer er een dossier aangemaakt is en gewijzigd is, niet de effectieve wijzigingen. Zou handig zijn als de wijziging bij gehouden worden? Er is een concept --> doorgestuurd. Als een subsidie formulier is doorgestuurd, is een vraag om een nieuw dossier aan te maken. Gedurende concept fase --> GEEN NOOD Na versturen --> business is er niet op georganiseerd. Besluit gaat naar back office met een termijn van 40 dagen. Zaken aangepast worden --> wat doet dan met de termijn. Vragen openstaan; alarmbellen afgaan. --> Vroeger MANDATEN DATABANK --> je ziet niet wie mandaat bewerkt heeft. Felix kan het opsnorren. --> Besturen kunnen het aanpassen & ABB-medewerkers. In principe moet het bestuur het zelf doen. --> geen usecases van ABB medewerkers die dingen aanpassen. --> Besturen wel die vast zitten --> Politiekers moeten iets aangepast zien. Besturen doen het niet --> ABB doet het. --> Data kwaliteit.
Which changes would you like to keep track of? What are the usecases you can envision for your product?
How important is data quality? How do you measure it currently? Do you need to report on data quality?		Dagelijkse rapporten. Via Sparkle endpoints. Geen structureel process waar de wekelijkse data kwaliteit --> Katrien doet dit Verplichte opsturing van iets, als er 80% Data kwaliteit gaat belangrijker worden Katrien houdt zich bezig met besturen die het moeten doen & GOED doen. Nog geen 100% maar genoeg om Data kwaliteit & gegevens bewerken --> voor mandaten & leiding gevenden heel belangrijk. Bewerken = besturen moeten het doen Usecase = burgemeesters emails sturen & er is eentje vergetenomdat de database niet in orde was.
What granularity is needed in seeing changes made? Should this be on top level (for instance organisation name)? Or on a deeper part of the product (specific page/feature)?
Are there different roles & responsibilities in making changes? Are there usecases where you can envision reviewing changes prior to making them would be useful?		No, iedereen kan alles
Are there usecases where you'd want to be alerted when certain changes are made?
Would you need to see changes in the product or in a back-end?
Prototype showing		Voor Katrien --> data kwaliteit. Als er een communicatie actie was --> Katrien kunnen opvolgen of ze het gedaan hebben. --> er is al een rapport.
Product page: Is there a usecase for seeing the changes on the page (vs in a back-end) would you want to see changes on this page as well?	Besluit, wijzigingen aangebracht --> versie beheer dan zie je nog steeds niet de wijziging. Zien in welke artikelen een wijziging zien. GN schept kader en enigste inhoudelijke sjabloon + Support voor lokale besturen. En dan zijn wijzingen interessant. Geschiedenis verwijderd. Self service voor users --> kunnen we dit creeeren voor gebruikers?	Mandaten & leidinggevenden; goeie usecase. Module sluit er goed bij aan Ook goed om te tonen aan besturen --> wie is de eigenaar van de gegevens & wie mag dat zien. Katrien moet repo OP is gericht op ABB. Loket is lookale besturen. "interessant logboek" Minimaal databank aanpassen; half uur per jaar. Handig voor bestuur ook --> welke collega heeft dit aangepast --> te onderzoeken met besturen. Hebben ze echt nodig? Helpdesk --> stuurt naar Felix. CHECK NUMMERS. 1x/maand.
(export function) Can you tell us more about a use where you would want to analyse the changes outside of the environment?	Aanpassingen door; mag iedereen toegang krijgen tot deze data? Informatie veiligheidsconsulent van toepassing GDPR. Export- Lijst; je kan iets opzoeken. Je heb BI tools nodig --> koppeling. We zoeken een specifieke wijziging. Datum & uur van wijziging. GN usecase = Tekst & documenten (langere teksten). Lange lijst van changes. Filter; - Tijd & uur - Woord - RDFA parameter	No usecase
(watch functionality) What do you think this button does?	Totale aantal aanpassingen = geen waarde voor GN Watch = Gecaptured in nieuwsbrief. Geen informatie die onmiddellijk geweten moet worden. Sjablonen; iemand uit de business zal helpen om die te maken, maar dat zal geen wildgroei zijn. Enkelingen die aanpassingen maken. Rechtstreekse lijn. Leiding gevende & mandaten databank; support-functie. Even veel nood aan veranderingen in deze databank. Kunnen aan de slag met de info van klanten + directe lijn. Bert verkiest GN changes	Hoeveel personen op de pagina geweest zijn. "volg" knop.
Would you want a summary of the changes made to a product entity or feature?	Yes.
Report- functionality
Person who made changes page Is there a usecase where you'd want to get in touch with a person that made changes? (reporting functionality) Should people be able to report faulty data? Who would do so? What is the context? Would you want a summary of who creates changes and where?	Logging van GDPR "We don't care" voor stadsbesturen enkel voor Support is dat belangrijk. Bewaarplicht --> hoe lang wordt dit bewaard? Data kwaliteit zit bij template verantwoordelijke & alle rest zit bij lokaal bestuur. Is anders bij OP. Rapportje voor Dirk --> "amai das een rapportje voor Dirk, ze zitten op mijn vingers te kijken".	Gemeenten activeren & bij de hand houden. De naam moet aangepast worden. "er zijn aanpassingen nodig, kijk naar het rapport die aangepast moet worden". Duidelijke instructies geven
Revision page Is there a need for someone to revize data that changed (like a super editor)?	Nuttig voor lokale besturen --> revisie flow	Wij zijn geen experten in de materie & is dan precies alsof wij lokale besturen niet zouden vertrouwen. HYPOTHESE dat er geen goedkeuringsflow nodig is voor besturen. --> risico dat persoon moet alerted zijn.
Can you rank these features from most to least important? Seeing all changes in a back-end Seeing all changes of 1 person and the ability to contact them Ability to analyze data of who made changes, departments... Ability to export changes & who made them Ability to report changes + review those Ability to be alerted when someone made a change to a page you created/followed	Indien meer community based --> wordt dit een heel ander verhaal. Mogelijks binnen een jaar interessant. (in geval van sjablonen) Heel hard op maat van databanken --> GN is een afnemer & ander type product.	Seeing all the changes Alert krijgen (per bestuur) --> Katrien Export is er al Report & follow-up function
if we allow anyone to build on this super admin, would you do so?
Notes		Contactgegevens samen bundelen --> bespreken van Sofie. We hebben gegevens nodig, wie is master van de gegevens? Mandaten beheer --> aan Sofie

With showing prototype

https://www.figma.com/file/V6uU9cXJf772uhExkwo4K4/HistoryOfChanges?node-id=32%3A1116

Applications for GN

• Register of reglementen (created by ABB)