I have similar discussions with respect to the (very immature)
algoritmeregister standard and algoritmeregister management application.
Thinking about it, my solution would be to call such features "pilot"
features, both towards the client and the steering group; if they are
rejected later, the client needs to know that either they will end up with
a non-complient solution, or it will need to be rolled back/switched with
whatever comes in place.
Op wo 10 nov. 2021 11:33 schreef Joeri Bekker via openzaak-discuss <
After the summer vacation, the technical steering meetings didn't
continue. In my opinion, this is fine and we only need to meet if
necessary. But, I think it's necessary to discuss a topic that we're
struggling with at the moment.
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's
implemented. The ZGW API specifications however are evolving. Some of these
API changes are needed "now" and the question arrives if we should just add
this filter, this extra field, etc. without moving the entire API to the
next version (because that takes more time/money). Some features might even
be planned for a future version of the specification that is not released
yet (but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23
openzaak-discuss mailing list -- openzaak-discuss(a)lists.publiccode.net
To unsubscribe send an email to