Renaming guides

[jburel]

• Convert any image read by Bio-Formats to ome-tiff pyramid.
• Capture the process into a pipeline e.g. nextflow pipeline
• Import generated output to omero

this should become a guide on how to link 3rd
This is not only "BF" or omero only it is more "ome-guide", we need to write out to deploy, run such
We could rename omero-guides to ome-guides
if we opt for a change of name, we will need to check the implication on readthedocs

cc @sbesson @joshmoore @olatarkowska

[sbesson]

Renaming omero-guides to ome-guides (using /omero/, /bio-formats/, maybe eventually /idr/ prefixes?) generally makes sense to me and is a good direction

Re implications, there might be a jekyll_redirect_from-like solution at the readthedocs level but this is something that vanilla Sphinx has always lacked. Assuming all URLs would be broken by the renaming, the best solution might be to create a shallow compatibility repository similar to https://github.com/openmicroscopy/openmicroscopy.github.io that solely redirects all published guide URLs to the new ones.

[sbesson]

As guides are being created outside the initial OMERO scope and these guides are getting increasingly promoted across our resources (see #2 and ome/www.openmicroscopy.org#393), we might need to come back to this issue in the near future.

Collecting a few thoughts while reviewing URLs recently:

• handling guides across separate components can be handled either via URL path i.e. http://<guide_domain>/{omero,bio-formats/...} or via the URL domains. My personal preference goes towards the first solution as it aligns more closely with our current strategy (reference doc, website)
• if we use a single guides domain, we might look into the options for using e.g. guides.openmicroscopy.org and defining a CNAME in readthedocs
• most guide URLs include a /docs/ subpath which is inherited from the source code layout and could be reviewed

in all cases, a first step might be to create a list of all the published guide URLs to start scoping the redirection work.

[jburel]

the line between omero/idr is not as clear as one would like especially on the analysis front. We went that path for ITR/IDR notebooks and it creates a good amount of overhead in the setup for only the "saving step to OMERO" being the difference.

[jburel]

we also have guide starting to use other tools e.g. qupath-guide using https://github.com/glencoesoftware/ome-omero-roitool
in that case the "ome" (as ecosystem) will make more sense