FP Absent chairman/secretary
Status
Status of this feature: In progress: https://binnenland.atlassian.net/browse/GN-2052
Status of this feature passport: In progress (Scoping)
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:
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?
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