Should adoption of registered extensions become part of the spec update process?

[tychonievich]

Many of the changes we have made in the next-minor branch of this repository, and by so making have nominated for inclusion in v7.1, could have been made as registered extensions instead. Doing them in that way was not previously considered in part because the extension registry system and the subsumes keyword in YAML that allows them to be this flexible is newer than most of those changes.

We could establish a policy that a proposed addition to the spec be first registered as an extension, and only added to the next minor version of the spec once that registered extension is used widely enough to justify making it standard. We might need some sort of exception to handle cases that go beyond what a registered extension can handle, but there could also be a case made that if a change is larger than an extension it's not a minor change.

If we did this, it would change what a new version of the spec means. Currently we have people hoping for 7.1's eminent release so they can start using some of its additions; this change would let them start using them now. Currently we have people who avoid using any extensions; this change might impact their decision there. Currently we expect the release of a new version to be a significant news-worthy event; an extension-first model may make somewhat less significant as an event.

If we want to do this, we'd need to change and resolve several things. For example,

1. We'd need to nail down how we handle the extension-vs-standard tag and version-change semantics in YAML (see extension tags in YAML format GEDCOM.io#114)
2. The changes in next-minor would need to be registered as extensions
3. "Used widely enough to justify making it standard" is a nice idea, but we currently have no reliable way of measuring that.
4. Should "add this feature" issues be moved to the registries repo, or should this repo remain the place for community conversation and issues about all topics, new features included?
5. Should there be filtering applied to which extensions we allow to be registered? For example, Extension that adds GEDCOM-X names to GEDCOM 7 GEDCOM-registries#6 describes an extension that I use in my software, but which Albert rightly pointed out overlaps with a standard structure and shouldn't be added in an minor version of the spec. Should such an extension be registered so others know it is being used, or not registered because it shouldn't become standard, or registered in some way that makes it clear it is not on a standards track?

There are probably other things to consider too (e.g. does this impact attribute-event-requests?) and anticipates quite a bit of work, but I still feel like it might make our process more clear and flexible.

[Norwegian-Sardines]

If the GEDCOM Steering Committee ("The Committee") wants to try out a set of extensions in a minor release for feedback and potential inclusion in the next major release of The Standard, then The Committee" should be in control of these additions. These additions should have some room for discussion before they are added to a minor release to be sure that they meet database design standards, have internationalization potential, move GEDCOM forward rather than sideways! All extension from The Committee must be registered to The Committee's URI regardless of the person or persons that put forward the design! The URI must register a clear use case and where appropriate some kind of design document to outline how the extension was intended to be used, defined variable list, and feedback about the design.

I'm still very apprehensive of using the GEDCOM-X and other "Fact" extensions that seem to be minor changes/definitions to the interpretation of other proposed "Fact" extensions, where using a fact.TYPE would be more appropriate! This is one of the areas that is not supported well by many of the players in the Genealogy Software workspace. We may think that some new "facts" can be added without much controversy for example DNA, but should this fact be added as a single new fact DNA and require the use of DNA.TYPE to define MtDNA and Y-DNA values or should there be two "facts" MDNA and YDNA? These decisions are important to moving GEDCOM forward rather than sideways! The Committee must remain the owner of the GEDCOM Standard and the extensions it wants to try out!