Regulatory statements
Questions due to Demo
"voer inhoud in" next to chapter and section could be "opschrift"
how to style the different "chapters", and other titles+?
in Register : ik wil een instructie kunnen invoegen in het sjabloon // een instructie is visueel opvallend en zorgt voor een richtlijn/instrutie m.b.t. gebruik sjabloon. // een instructie wordt niet gepubliceerd (wel beschikbaar gemaakt in GN) // een instructie is niet bewerkbaar // wel kopieerbaar
In GN : idee : de gebruiker duidt zelf aan "draft" "definitief"?
Sjabloon: wat is aangepast t.o.v. vorige versie is belangrijk (eventueel manueel o.b.v. wat we deden in POC anonimisatie?, of aanduiding "wijziging" nadat iets op definitief werd gezet / of beschikbaar gemaakt in GN?)
bug: codelijst "keuze 1 / 2 / 3" wordt in GN 1 / 3 / 2
bug: register spreekt over "hoodsftuk" -- dient Hoofdstuk te zijn
In Register: ik wil een retributiereglement invoegen in een reglement?
In GN: Ik heb een schoolreglement en een besluit omtrent 2021-2022. Wat moet ik doen in 2022-2023? (1) obv mijn oud schoolreglement een nieuw maken, rekening houdend met de wijzigingen in het nieuwe sjabloon (2) obv het nieuwe sjabloon, alle parameters edm opnieuw aanvullen (3) hoe kan dit vlot?
In GN: Ik kan geen parameter invoeren
Value
Value stream
Enabling a higher adoption of GN(E) by creating features that facilitate and support qualitative decision making in line with existing legislation.
Regulatory statements are part of a large amount of decisions. The principle supports our goal to facilitate decision making by providing interactive text templates based on authentic sources. The specific content templates are not part of this feature passport.
By annotating more information, reporting on decisions can be automated and fine-tuned. Hence, reporting is mostly performed by manually check decisions one by one.
The text techniques / features of regulatory statement will be transferrable to legal attachments, i.e. the "statutes" (articles of association).
The strategy is to create templates for specific regulations and so involves possibly an extra target audience (e.g. fiscal department, mobility department,... though when making several fiscal templates, the target user stays pretty the same). The standard user of "ontwerpbesluiten" en "notuleringssoftware", i.e. cabinet of the general director, is always involved to some extent.
Main Goals:
Adding a legal requirement to the RDFA-editor and GN(E): the regulatory statement is a legal means to structure text / decisions, and make it more readable and needs to be annotated.
Extending technical features to introduce text annotated as "regulatory statement" with structure, measures & specific parameters.
High level solution
Text as regulatory statement, connected to a decision in stead of PDF, Word or other documents
Structure this text following the law technique
Add parameters
Publishing on local government website
Examples and their target audience
Below non-exhaustive list of possible applications in the future. The specific content templates are not part of this feature passport, though one might use them to illustrate the extra value created / requirements.
Each template application has its own specific target audience depending on the regulations' content. The administrative personnel of the general director is always involved plus the content owning department personnel (e.g. fiscal, education, mobility, ...)
Tax regulations (Fiscale Reglementen)
Shorter (max. 15-20 pages, commonly 2 pages), see examples above.
Extra Target audience? The fiscal dept. is always involved.
The first iteration will be about integrating Tax regulations as Regulairy statements
Additional traffic regulations (Aanvullende verkeersreglementen)
Already implemented, possibly needing change based on new functionality created. (today not annotated as regulatory statement)
Extra Target audience: administrative personnel responsible for traffic regulations
School regulation (Schoolreglement)
To support the education department in supporting local governments in updating their e.g. "school regulations". A Word template is available.
The template is: - longer then 50 pages - has a Table of Contents - consists of several chapters and articles per chapter. Extra Target audience? Mainly the Education dept. / Possibly the Personnel dept.
Legal status regulation (Rechtspositieregeling)
Similar to School regulation. We should be able to support this in 2023
Extra Target audience? standard user + personnel dept.
Roles
Having a role within the register, I want to be able to select a content part where I have rights, and do the things that my rights enable regarding that content part.
As a user, I want to be able to consult templates and regulatory statements
Requirements derived from legislation
The DLB (law - decreet lokale besturen) doesn't contain details on what should be annotated. Basically "text decision" or regulatory statement (reglementaire bijlage) could be interpreted as sufficient.
Below text should further be elaborated based on the above requirements in perspective of fases of the development.
Resources
Overview on Miro (architecture - sneuvelnoot)
Structure
Lexicon
See INDEX NL/EN for translations and descriptions of technical wording. https://app.gitbook.com/o/-MP9Yduzf5xu7wIebqPG/s/-MVupYAHNVzLJMwHA9lT/glossary/index-nl-en
Decision
Regulatory statement
Aggregated version of a Regulatory statement
Regulatory update
Registry
Intertitles: all possible structures that are added to a regulatory statement: like part, book, title, chapter, section, subsection
Overview
Relation Decision and Regulairy statement
In the backoffice (edit) a regulatory statement could be viewed without the decision (or decision to take). Though when publishing (on a website, to the public), the decision and regulatory attachment are one, and should be viewed/stand as one.
Publishing of regulatory statements happens via the decision within GN. A regulatory statement within the register can be saved. Optionally we make the difference between a minor version or a major version. The latter is made available in GN templates.
Regulatory statements are an integral part of the decision.
Problem statements
How Might We?
HMW make Regulatory statements or updates integral part of one or more decisions
HMW make the Regulatory statements and their templates available for 3rd party vendors
HMW make the (by definition latest) aggregated version available for local government in order to import them in external systems
HMW make large Regulatory statements easily manageable
HMW give the power to Regulatory statement writers to create and maintain the structure of chapters and articles?
HMW guide local governments with defining the required parameters based on input of the central government
HMW support the publication of Regulairy statements on local government platforms
Solution
1. Structure of statements
Feature passport Structure of statements
2. Initial creation of Regulatory Statements
At the initial creation the starting point can be the following things:
An empty document
A copy of an existing RS version, created within GN by that local government
A copy of a template provided by ABB
The content of a Regulatory Statement is stated by The FP: Structure op Statement. A RS can also have documents (pdf, word, excel,...) attached to it.
Status
Draft: Default state, editing is possible
Scheduled (geagendeerd): The linked decision is scheduled for decision (and so publication). The RS is still editable.
Published: The RS is out in the open and cannot be changed anymore.
3. Updating Regulatory Statements
When a Regulatory Statement is published (at the moment of signage), an edit or the Regulatory Statement requires a new version of the RS. A published version cannot be changed.
HMW Make that history of all versions of a Regulatory Statement accessible?
Small changes
Sometimes typos and spelling mistakes need to be corrected. Also renumbering articles is part of this category.
Small changes are not necessary to be declared within the decision (and on top of the published RS)
Subject-matter changes
Changes in text and structure that change the actual content of the legislation are always linked to the change of an article.
These changes do need to be declared and motivated in the Decision
HMW create this declaration correct and with low user investment?
4. Publication of Regulatory Statements
A RS is always published through its accompanying Decision. This Decision (solely created for this purpose) can have one or more articles. In one of those articles it links to the RS.
HMW show the relationship (or the lack of it) of a RS with a Decision to the user?
Initial RS
When a RS is initially published, the RS has the following structure:
The name of the RS
The mention of and link to the decision. "Goedgekeurd door Decision title on Decision date" (translated: approved by decision title on decision date)
The RS content (text and structure) of the document
Updated RS
When a RS is published after the first update, the RS has the following structure:
The name of the RS (can be changed with an update)
The mention of and link to the decision to update. "Gewijzigd door Decision title op Decision date in artikels Updated Article List" (translated: this list of articles was changed by decision title on decision date )
The RS content (text and structure) of the document
This content shows where updates have happened. . How these are shown is not legally bounded. ⚠️ We show only the updates since the latest publish
Export
In order to import the RS into noting software of third party suppliers, user should be able to export the aggregated version of the RS as HTML.
The structure of this export is not clear yet.
5. Manage Regulatory Statements
A local government has an estimated 50 to 150 RS, which are typically managed by one person within a local government at a time.
A draft version of the RS is updated several times before it get published. The RS is shared with colleges and updates occur on several moments during the proces. Therefor Date of last change can be a relevant indicator.
An update of a published RS may occurs months or even years later. In this case subject-matter info is know. Therefor searching in the title or content can be relevant.
Only a draft version of an RS can be archived, once published a RS cannot be removed from the registry. This should follow the pattern of decisions.
6. Decisions that update a Regulatory Statement
A decision containing a Regulatory Statement should contain the following:
Name of the Decision
Location of the Decision
Date of the Decision
Attendees of the Decision meeting (also who couldn't make it)
Legal bases for initiating or updating the Regulatory Statement
Motivation for initiating or updating the Regulatory Statement
A list of the articles that were updated in the Regulatory Statement ⚠️ We show only the updates since the latest publish
A link to the corresponding version of the RS
A RS decision can also have illustrative documents (pdf, word, excel,...) attached to it.
HMW Make that history of all versions of a RS Decision accessible?
7. Templating
ABB should be able create structured Regulatory Statements that can be used as a base for an initial RS.
Parameters
Parameters - defined in a codelist- can be introduced everywhere. Codelisten are relevant to a specific type of reglement (e.g. different codelijst for School RS ("schoolreglement") and Fiscal RS ("fiscaal reglement")
Examples of codelists:
Price
List of streets
From -> Until dates
Tax rate (Aanslagvoet)
8. Embedding decision on 3th party website
HMW embed a selection of RS on an external website?
Things that need to be cleared out
Js or iframe or API?
What website technologies do local governments have?
What knowledge of technology do they have?
What do they want to show on their website?
What must they publish on their website?
Open Questions
How can we technically handle 50+ page documents in the editor
Last updated
