FP Absent chairman/secretary

Status

Analysis

  • Full analysis in subpage.

Context

Exact product & product area we're talking about:

Within GN, when creating a "zitting", appointing people that are at the meeting.

Under agenda points we can edit who is absent:

Current state
  • When creating a new meeting, currently in GN one should appoint

    • 1 chairman (voorzitter)

    • 1 secretary (secretaris)

    when creating a new meeting (zitting) - see screenshot above. (Unclear what will be shown on publication)

  • When editing an agendapoint. One can

    • Remove chairman & secretary

    • And select a new one from the list that is pulled up from the Leidinggevenden (mandaten) Database

  • To select these roles, the list is loaded & pulled up from the Mandaten database (other Product we do not have ownership of)

  • For some or several agenda points, the chairman and/or secretary might have an interest in it and someone else should take on that role.

  • It is important that they are NOT listed as such for those agenda points, as the approved and signed meeting minute notes are legally binding, therefor it should be possible to appoint another chairman & secretary possibly not present in the mandatendatabase (as such)

  • Database

    • For short absences; ambtenaren taking on a role for only a couple of weeks (because an official mandate is absence for X weeks), are currently NOT added to the database. Unclear why.

  • Product;

    • You can appoint a chairman/secretary per agenda point (not the same as the ones for the meeting)

    • In publication this is already fixed as well

Existing documentation
  • JIRA-Tickets:

  • Other FP's:

    • (Other product area FP's)

Requirements

💰 Value streams

We want to avoid free text fields in order to generate a legally correct basis to indicate the presence of a secretary or a chairman. This is in line with our vision of Open Data.

🦭 Problems to solve for

  • Substitute secretary might not be in the database we pull in and therefor cannot be selected from the list that is pulled from the Leidinggevenden database.

    • Substitute chairman (voorzitter) will ALWAYS have a mandate and therefor be findable in the database (not an issue to solve for)

    • Substitute secretary might not have a mandate. This will al ways be an ambtenaar, but might not be in the database.

  • Chicken/egg problem - is data quality important or database quality?

    • If we want to annotate the data (with linked open data), the substitute secretary MUST have a mandate, and therefore we should either use the mandaten databank (ownership elsewhere) OR create a new databank

    • If we do NOT annotate the data we might risk data quality

🕵️‍♂️ Use Cases

  • Personas

    • Person of "secretariaat" inputting the data of the meeting minutes

    • Civilians reading publication notes

    • People using annotated data

  • Usecases

    • When the chairman and/or secretary do not partake in the discussion and/or voting on an agendapoint, other ones should be appointed, and listed in publication.

Scope + future iterations

  • In scope

    • Person filling out the notes, selects the right chairman / secretary

    • Person filling out the agendapoint can add a new substitute secretary per agendapoint if this person is not in the mandaten DB

    • Design reason of absence, but without concrete input (requires as list from Business)

  • Scope in question, still to be determined

    • Updating Mandaten DB / Loket / OP to include mandatarissen not included in their DB

    • (Design the reason of absence)

  • Out of scope

    • Intelligence to know automagically who should be the substitute chairman/secretary

    • When the secretary or chairman changes halfway through the session, other ones should be appointed, annotated as such, and listed in publication. --> We will not solve for this

  • Future versions

    • Allow cities to set preferences who should be the secretary & chairman and in case of absence (so they don't need to fill it out at all times) so they do not need to input it at all times.

🗜️ Constraints

  • Strategic/business constraints

    • Do we need a reason why someone is not present?

  • Legal constraints

    • Can we use ID-number? Similarly we can use full name, DB and Place of birth

    • We cannot show ID in notules

  • Technical constraints

    • Via OP there is a database of ID-numbers, but we need to collect reason why we want to access it

🤔 Questions/Discussion points

  • 🔴 Legal blockers

    • Can/must a substitute secretary be annotated with linked open data (as having a mandate?)

  • 🔶 Business/product asks (not a blocker)

    • Do we need to capture reason of absence?

    • What is more important;

      • data quality & linked open data (meaning adding extra info to a Database somewhere) OR keeping a database clean (meaning not annotating data)

      • Data quality OR reducing complexity for a user

    • What tasks can absent chairmen & secretaries still take on? Should it be registered that chairmen & secretaries were in the discussion, but not in the voting? Or do they leave completely? Or can we just set per agenda point or that there was another chairman and/or secretary WITHOUT specifying what they did or did not do?

Kick-off meeting 8/11/22

Attendees; Caroline, Judith, Bart, Arne, Niels, Elena, Jurgen

  • How often does this happen that there is a role change? (to determine if we should build this as an exception OR standard possibility).What are the circumstances in which this happen? No answer

  • Edgecase: what should happen if someone is not in Mandatarissen DB?

    • Via ID

    • Via Name/DB/ Place of birth

  • Automatisme van de ranking van voorzitters; moet in de databankk zitten.

  • Is het mogelijk dat een voorzitter die niet actief is, toch geselecteerd moet kunnen worden? Neen.

  • Data quality vs complexity; should we use ID-number to authenticate?

  • Should we publish reason of absence? Unclear needs research

Product solution

Design

4 solutions;

  • Free text

  • Secretary becomes mandataris (leiding gevende databank would not be in correct), we need to take over fields; start mandaat

  • Model aanpassing (we annoteren dat het een afwijking is van het model)

  • Anonieme vervanger

This part of the feature passport is owned by the designer

Mock-ups

  • link to figma mockups

  • Any explanation or extra documentation

Usercases / userflows

After the designer finish their task, a technical feasibility meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.

Technical

This part of the feature passport is owned by the technical team

[Information about the technical solutions for expectations that need it - e.g. using mu-search for showing all types of positions in one table.]

Last updated