Installatievergadering
Documentation and research focussing on the user journey during the inaugural meeting
| REVIEWER | DATE | APPROVAL |
|---|---|---|
Bart Stichelmans | 14/02/24 | Comments added in red |
Pieter Van Maldegem | ||
Tim Vereecken | 20/02/2024 | Comments/questions added |
Karel Kremer | 20/02/24 | Comments added as comments |
Arne Bertrand | ||
Jurgen Robyns | 28/02/2024 | Comments added in purple |
Elena Poelman | 27/02/2024 | No comments |
Niels Vandekeybus |
Installatievergadering = inaugural meeting = A meeting where both outgoing and newly elected members of a municipality or council gather to formally accept their roles and responsibilities, exchange positions, and begin the new term.
Problem
We don't have a way for users to hold an inaugural meeting in GN, nor do we have a good way to send correct (annotated) data from the inaugural meeting decisions, containing mandate data, to the Mandate database.
Solution
Both of these problems are reliant on each other.
We want to use GN to help users take minutes during the inaugural meeting, in which we want to annotate (among other things) the mandate data, which will get sent to the Mandate database after publication.
This will help municipalities ensure there will be less to no errors in the data, as well as helping them avoid double work/double data input.
Lokaal Mandatenbeheer vs. Vlaamse MandatenDatabank
When talking about the Mandatendatabank, we need to understand there is a difference between the Local Mandate Management (LMB) and the Flemish Mandate Database (MDB).
MDB is a database with all the mandate data, where GN gets their mandate data from for e.g. the attendees lists for all kinds of decisions and meetings. At the end of the inaugural meetings, this is where the correct data needs to end up for municipalities to be compliant with the law.
The "verkiezingsuitslag.csv" is something ABB delivers to LMB in a certain format, via an endpoint or a service. For the verkiezingsuitslag.csv there will be granted person uri's, so we definately need the rijksregisternummer, otherwise we cannot compare with the previous election periods to match the same people with the right person uri.
Verkiezingsuitslag
After the elections, the election results are produced (.csv). This .csv forms the basis for the list of elected officials, which in fact contains more limited data than the election results (only the elected officials). The election results may be updated at regular intervals. The main reasons are if there has to be re-election or if there has been a recount or change in the distribution of seats ex officio by the council.
With the latter, the election disputes council can actively start looking at making a seat change (seats from list X to list Y). In previous elections, this was never applied. The reason could be incompatibilities, but also errors that crept into the PV: e.g. 30 instead of 300 votes listed.
For a recount, there is always a ruling by the council, with the help of ABB. These incompatibilities or no agreement do not apply to the installation meeting. Recounts originate from complaints. If there are effective elements indicating that an error has occurred, the council may decide to proceed with a recount.
The final results come in a PV from the municipal headquarters. This is usually the day of the election or the day after for municipalities that still vote manually. This PV states who has been elected and how many votes there are. The installation meeting is postponed until the council rules. The last day to file objections is at the end of November. You have 30-35 days after the election to file objections and then the council has 30-35 days to rule. Those against whom objections have been filed will not install. This is postponed until the result is final. Only then can the installation take place within the 15 days. want to express exactly.
Definitieve verkiezingsuitslag
Before the installation meeting, you always have a PV from the municipal headquarters or a ruling from the election contests board or council of state, which will serve as the basis for determining the list of elected officials. That PV is promulgated again by the council. This ruling of the council reflects the new election results. The PV of the municipal headquarters is published by Vlaanderen Kiest (www.vlaanderenkiest.be) .
This is a simple table with the full election results. You don't need to load the base table per se, just copy the necessary fields/columns in the form you need. Creating a proper CSV based on that is absolutely basic anyway. That table is sufficiently clear and our election people can provide interpretation if needed. Besides, that format is always (every 6 years) different. Is done manually based on an sql query. You have to understand that for something that happens once every 6 years and software used only 2 times, not everything is automated.
In the end, the table will contain everything the 2018 table contained, only the order of fields might be different. We can always send you the 2018 one if you don't have it. The method of calculating results differs a bit from 2018: oa influence list vote.
Also remember that the election result is subject to change in the months after the election. First by the Election Disputes Board and later by a possible re-election as a result of an annulment by the State Council. The former usually involves minor changes by recount, the latter is a totally new result for the constituency in question.
We want to be able to indicate at the installation meeting those present from previous and current period (electoral list) as present at the beginning of the meeting.
It is sufficient at the installation meeting to note attendees and absentees. No distinction is made visually between mandataries, elected, non-elected in annotating the session.
User Journey
We organised a Theme day on 13/02/2024 to brainstorm user journeys and how the data, development, vendors, etc would impact each other, to better help us decide which option is a better suited solution.
Step 1: Publishing the meeting agenda
The meeting agenda needs to be published 10 days before the meeting.
Needs
A way to create an inaugural meeting from the GN-app or it's vendor alternative
This meeting is a template created by dev and differs from other meetings because:
There are set agenda points.
User cannot edit APs
User cannot reorder APs
User cannot add other APs
We know whether a municipality will need a Police zone - if it does, there will be an extra AP for this in the correct place between the other APs.
Step 2 onwards
After the agenda is published, things can go 2 ways depending on who (LMB or GN) creates the URIs.
This means:
At meeting level:
We need a way to sync/re-sync data in the inaugural meeting whenever there are changes to the LMB draft
A way to allow first data sync + any consecutive re-syncs
Warn users which decisions/fields will be affected by the re-sync
Both the inaugural meeting and the Council of Social Welfare will use draft data from LMB, so any re-sync will (possibly) affect both of these - this also needs to be made visually clear
Questions
Do we allow users to edit/prepare/fill in the decisions (so basically enter the editor) if there hasn't been a first data sync? Yes or No: we need a warning "please fill out first the LMB data" to get the most out of our IV template builder. You can sync your data at any time by pushing the "" icon. Alternatively you fill it out manually, but than you will not have an automatic sync with your LMB afterwards. - or alike message/
What do we do if a municipality has their own alternative to LMB? We cannot expect them to be ready to sync with GN by the deadline - dataformat definition / guideline is needed - otherwise they will do manual updates to start with (as it always has been)
At decision level:
Decision templates (created by dev) more robust and users will have less control over how they write their decisions
More "blocks" of correctly annotated text which will have to be filled in/updated with data from the draft-LMB-database
Users can still update/add some free text which won't be annotated. This text will not disappear with every re-sync.
Questions
To correctly design and work out which wizards, plugins, variables we are missing and need to build for every decision, we need the final version of the decisions. The initial set of templates was handed over to our colleagues from LOW. They will have all templates ready by the end of March 24.
What do users expect from ABB regarding the inauguration meeting notes? Meeting to be organised with Mechelen, Oostkamp, Gent, ...
Vendor integration?
Here, we don't use a draft-database from LMB like in option 1. Instead, we load the electionlist/election data that LMB has (In fact ABB has this list, and should deliver it somehow to LMB, Question is if we use the LMB for further input, or use our own list directly into GN) into GN and send everything (all relevant, up-to-date mandate data) back to LMB after the inaugural meeting.
This means that
The user gets more freedom editing the templates
We don't need to sync data from LMB, so less impact on the meeting UI
Users won't be forced to have two separate application open.
BUT
The user has to manually input a lot of the information in the decisions, creating more work for the user.
Because we give the user more freedom, we also give them more room for errors and data discrepancies.
The local Government isn't able to add extra local data to the mandate/person based on e.g. their information form (with e.g. private email, phone number, emergency contact,...) before the inauguration, or they should be - how? - an upfront election list upload.
At meeting level
No special changes required compared to option 1
At decision level
the data from different decisions have impact on each other - e.g. if a person's position is marked as terminated, they cannot take oath in the next decision.
Questions
Will we use loose plugins and let the user edit everything - or will we work with wizards (e.g. pop-ups where users select or fill in data) for some of the decisions?
We still need the final versions of the decisions to design and build the correct variables/plugins, etc
How do we deal with discrepancies in the data? to be resolved manually based on reporting?
Vendor integration?
Perhaps we should talk about a graded integration option, e.g.
I use my vendor application meeting notes and I use my own CRM system. I fill out the MDB manually
I use my vendor application meeting notes and I use my own CRM system. I fill out the MDB based on my annotated meeting notes.
...
Below the integration choices per software to define the context per local government
| Integration Choice Municipal | meeting notes | Contacts/LMB | MDB |
|---|---|---|---|
| own vendor, based on word templates | own vendor | manually |
own vendor, building on a proper solution | own vendor / LMB endpoint or LDES or service | machine-based: based on LMB or based on publication (harvesting) | |
own vendor but using the templates and plugins offered via the editor | LMB Flanders hosted | ||
own vendor, but using the GN IV app. and don't integrate with vendor meeting tool, do integrate with vendor publication environment (how?) | |||
5. | GN IV app user, and GN publication environment user. | ||
6. | Using 2 solutions before "Merger" and copy the result into another / or one MDB organisation (Merged municipal) |
Last updated
