New features or tools
Should X feature be added to the OpenActive libraries or tooling?
The OpenActive infrastructure must be designed to support the OpenActive specifications and associated beta functionality.
When new functionality is requested in an OpenActive library, one of the answers to the following questions must be yes:
Does this functionality support a feature that is already in the OpenActive specifications?
Example of "yes": A library should support a property that is included in one of the specifications, but does not currently
Example of "no": An implementer wants to use a property defined in a specification outside of intended use within the specification (e.g. embedding a Video in an Image)
Does this functionality support a feature that has been proposed in a "beta" status through the OpenActive W3C Community Group
Example of "yes": A library should support a property in the "beta" namespace, but does not currently
Example of "no": An implementer wants to add a transform to a "beta" property that maps values to their own custom vocabulary
Is this functionality required for the library to be extended by implementers who are implementing custom extensions (i.e. those outside of the OpenActive Beta namespace)?
Example of "yes": A library includes a class that is "sealed" that is preventing it from being usefully extended by another implementation to support a custom extension. For an extension to be built on top of the library, the mechanism for extending the class must be provided.
Example of "no": An implementer wants to add custom code specific to their implementation or extension to the library.
This ensures that libraries continue to support a broad range of use cases for OpenActive, while protecting them from customisations that are specific to particular implementations.
Should a new tool be created?
OpenActive's infrastructure always aims to absolutely minimise centrally maintained and centrally hosted production services. Centralised should only be centrally maintained or hosted if there is absolutely no other way of achieving the objective.
Is the tool designed to be relied upon by production implementations of OpenActive?
If yes: it must use only static GitHub pages. OpenActive does not have the capability to maintain services (e.g. on Heroku) that are intended to be used in production.
For example: the data catalogue must always be crawled to be used by end users. A data catalogue "aggregator" would introduce unnecessary
Last updated