Working group for ongoing development and iteration of the Singer Spec, the de-facto protocol for open source data connectors. Please use "Issues" to create discussion items - or use "Discussions" for general questions.
There are many directions we can evolve the Singer spec in.
Performance: Focus on a standard that makes data extraction/load tasks very high performing.
Versatility: Provide a standard that produces Taps that can handle many pocket cases and have lots of optional features
Reliability: Focus on self-healing features, error handling, reporting, observability. Features that make integrations more dependable and less likely to throw off errors.
Compatibility: Update the specification to stay current with the ecosystem (i.e. JSON schema updates, Python version updates)
Accessibility: To grow the community we need to put effort into making the specification accessible to less technically savvy users. For example, catalog.json current throws off new users. Some of this is addressed through tools/SDKs but should we evolve the standard itself to be easier to learn?
Clearly, these areas of focus will compete with each other for time and attention, and may actually require compromising between these objectives. If we can score the interest of the community in developing these aspects of Singer, we can help prioritize development efforts. One proposal would be for the leaders to force-rank these priorities to facilitate a conversation around where to focus.
There are many directions we can evolve the Singer spec in.
Clearly, these areas of focus will compete with each other for time and attention, and may actually require compromising between these objectives. If we can score the interest of the community in developing these aspects of Singer, we can help prioritize development efforts. One proposal would be for the leaders to force-rank these priorities to facilitate a conversation around where to focus.