Discussion: final GitHub hosting location for GeoZarr materials

[maxrjones]

When discussing new and existing GeoZarr repositories, a GeoZarr collaborator mentioned that it could be helpful for GeoZarr to have its own GitHub organization so it's easier to find relevant materials. I wanted to raise this issue to discuss how the final products of the GeoZarr SWG will be organized.

One consideration is that the OGC Technical Committe Policies requires the SWG specification product to be "vested to OGC" and that the collaboration environment be under ultimate control of the OGC. My interpretation of the former is that the vested part would be this repository (xref #125) with its OGC standard document, but not the geozarr-site, examples, toolkit or zarr-conventions. I'm not sure what the second part means, in particular whether we'll need to eventually transfer this repo to https://github.com/opengeospatial.

I'm very curious for people's thoughts on the final product organization. Here's some options:

Option 1: (if there's interest in re-consolidating zarr-developers and zarr-conventions and we don't need to transfer geozarr-spec in opengeospatial):

github.com/zarr-developers/
  ├── geozarr-spec          	(unchanged)
  ├── geozarr-site
  ├── geozarr-toolkit
  ├── geo-proj                  (from zarr-conventions)
  ├── spatial	
  ├── CF
  ├── multiscales
  └── geozarr-examples          (from developmentseed)

Option 2:

github.com/opengeospatial/
  └──geozarr-spec        		     (from zarr-developers)

github.com/zarr-developers/
  ├── geozarr-site        		     (unchanged)
  ├── geozarr-toolkit
  └── geozarr-examples        		 (from developmentseed)

github.com/zarr-conventions/         (unchanged)
  ├── geo-proj
  ├── spatial
  ├── multiscales
  ├── CF
  ├── license
  ├── zarr-conventions-spec
  └── uom

Option 3:

github.com/opengeospatial/
  └──geozarr-spec                    (from zarr-developers)

github.com/geozarr/
  ├── geozarr-site        		     (from zarr-developers)
  ├── geozarr-toolkit 
  ├── geo-proj        		         (from zarr-conventions)
  ├── spatial
  ├── CF
  └── geozarr-examples        		 (from developmentseed)

github.com/zarr-conventions/         (unchanged)
  ├── zarr-conventions-spec
  └── multiscales

[chris-little]

@maxrjones I like option 3, as it seems easier for newcomers to understand, and has clear scoping of the "authorities". I could see also how it would support migration, such as some conventions, into the OGC space if considered desirable.
Migration of components (actually prefix and context registers) into OGC is exactly what I am doing with CoverageJSON, as the components were rather neglected and lost in the original community space. HTH.