Community Context Types

[nkolba]

Proposal

Host "Community Context Types" within the FDC3 project and on the FDC3 microsite.

What are Community Context Types?

These are context data type definitions contributed by and used by members of the FDC3 community. The purpose of these types is to promote knowledge sharing and collaboration around context data ahead of a formal standards process. While Community Context Types don't need to meet the level of rigor that would be applied to a standard, it is expected that they will help drive the process by seeding a pipeline of potential new context types to standardize.

Great. What do we need to do to get started?

• add a community context type area on microsite
• create a contributor guide for authoring and submitting context types
• socialize with the community to get submissions

@rikoe @kriswest @donbasuno @mattjamieson

[kriswest]

We're strongly in favour of this and believe it will aid in uptake of the standard, whilst also providing fodder for future rounds of standardisation of the context types. We'd like to see such extended types made available both via a github repo and in an NPM module so that they can be depended on (ala the highly successful Definately Typed module: https://definitelytyped.org/) - rather than just detailed in webpage.

@lspiro-Tick42 raised a related issue when we discussed this: in addition to creating their own types, firms may also need to share how they are customizing or extending the existing standardized types (correct me if neceesary Leslie). The most common example being the extension of fdc3.instrument with additional identifiers in the id Object or other addition fields (e.g. equity type). This needs discussion and handling in a contribution guide.

One approach to supporting that under the same initiative/approach/repository would be to recommend that firms extend the type name (e.g. type = "fdc3.instrument[myFirmsName]"). Standardizing how that should be done is likely worthwhile so that it can be interpretted in code (such that something listening for an fdc3.instrument can also receive a fdc3.instrument[myFirmsName] - if the destkop agent implementation supports that).

[rikoe]

My main concern is how interactive Docusaurus is (not a lot) - do we require this type submissions to be in the form of a PR? We would need to provide guidance on how to hook into Docusaurus menus etc. I think for it to work, it should ideally be more like a wiki.

Docusaurus is a static doc site, and not really geared for interactive collaboration...

Would I would like to propose though is that we take the tooling repo that nick created, call it fdc3-contrib, and create an microsite for it. Official versioned and standardised fdc3 apis and types can be documented in the fdc3 main repo, and we can do community context type contributions in the "contrib" repo (along with other types of contributions), from where they can be promoted to "official" types.

[donbasuno]

I certainly think we need to provide the infrastructure for submitting this via PRs - both for adding new community types as well as describing usage and "community additions" to the standardized types.

Attached is a quick mockup for how the end result could look but the tricky part is probably the input and templating infrastructure.
fdc3_community_types.pptx

[donbasuno]

Added some more details to the mockup based on offline discussions:

• Template suggestion for Community Usage
• Template for Community Types more like the one for reference types

fdc3_community_types.pptx

[kriswest]

@donbasuno thanks for making a start on this. In terms of the navigation, I think that listing each member of both sets of types in the navigation will make it unwieldy. Further, you may want an alternative grouping by application. How about a structure like:

• Community Type & Usage
  • Overview
  • Community types
  • Usage by Applications

Each of those pages can have its own navigation (list of types and applications) and link to each other (The community types page listing the types, with a subsection listing the applications that reference that type and the Usage by Applications page listing the applications with a subsection for each type used).

We then use your templates for contribution of references and types to feed a database that the website implementation uses to populate the pages and their nav.

Regarding the <community type name> template, does the <company/app> entry relate to who contributed the type? I would consider moving <type> to the top level, then renaming <company/app> to <contributed by> or <maintained by>. Should we also consider a version field?

Regarding <reference type name>, it needs a <type> field matching the <community type name> template.

[rikoe]

Closing as we now have #317.