20180815 - Aug 15, 2018 - Technical Council Meeting Notes

Date

Aug 15, 2018

Attendees

@VBar
@Zak_Burke
@Tod Olson
@Jakub Skoczen
@Mark Veksler

Guests

@Ian Ibbotson (Use this one)

Goals

Wrap up hard-coded lists quickly
- what kind of tools are available to help module builders make controlled vocabularies?
- do module builders know about these these tools, do they need encouragement?
Expand AES discussion and resolve questions on draft AES document
- Try to make as much progress out of band before meeting
Main event: Workflow discussion. Consider this presentation
- Come to agreement on resources on scoping Camunda implementation (slide 11)
- Discuss steps and timeframes for teams integrating with Camunda and then coming up to speed (slide 12)
Consortia model (if time)
Backlog:
- Potential item: is OKAPI-241 a topic for the TC backlog? Description fields in JSON schemas are useful documentation and there is potential to use the to generate data dictionaries.

Discussion items

Time	Item	Who	Notes

Time	Item	Who	Notes
5min	Assign notetaker	@Zak_Burke
10min	Hard-coded lists	@Jakub Skoczen	PC recording from 2018-08-09, discussion spans15:02-25:28 folks at Stacks (who are doing the dev work) and @Ann-Marie Breaux (Deactivated) (from the related SIG) are discussing the current implementation; hard-coding lists was a deliberate choice at the time. we do have a generic UI component for maintaining "controlled vocab" lists though data-storage is module-local @Ian Ibbotson (Use this one) notes it would be great to link to live examples from the Ansible Playbook @Jakub Skoczen will coordinate doc updates with @David Crossley
20min	AES discussion (followup on out-of-band discussions)	@VBar	Okapi Asynchronous Event Service (AES) DRAFT goal is a detailed-enough proposal that we can establish features and expectations without requiring a specific implementation, i.e. a publication/subscription service that generates events we can feed to a message-queue such as Kakfa or RabbitMQ current assumptions system is built into Okapi; source of a message is Okapi itself, not an individual module message producers are implicit: Okapi will capture data, produce messages message consumers are explicit: could be other modules, could be completely external systems @VBar will continue to refine this document in preparation for formal RFC
30min	Workflow	@Ian Ibbotson (Use this one)?	there are some specific technical concerns about Camunda: how will it handle multi-tenant interactions; what does its concept of a "user" mean in the context of use by Folio? consensus that we need detailed use-cases to move ahead with evaluation of any particular solution; probably we can only get that by assigning a PO, an architect/senior dev, maybe (probably) some time from devops to fill out the backlog for a meaningful proof-of-concept implementation @Tod Olson will confer with @Mike Gorrell to whack out a rough proposal to PC within the next week or two
20min	Consortia model		did not discuss; pushed to backlog
5min	Backlog and action items		OKAPI-241, use description field in JSON schemas consensus: probably this is good policy; first set policy and add to documentation (@Jakub Skoczen will ask @David Crossley), then can become an execution task for teams

Action items

@Jakub Skoczen to contact @David Crossley to include pointers to controlled vocabulary component in the onboarding docs

@Tod Olson and @Mike Gorrell to draft Workflow proof-of-concept proposal for Product Council