Document/motivate relationships between plugins

[haesleinhuepf]

Hi all,

I would like to discusss about how to document (and motivate) relationships between plugins. With "relationship" I mean something like:

• If a plugin's output (e.g. measurements) can be used by another plugin (e.g. for classification), these two are related in a sense of "works well together with".
• If a plugin produces similar output like another plugin, these two have a "can be replaced by" relationship.

If we had documentation of those relationships for all plugins, we could knit a web of plugins and guide users through the jungle.

I'm wondering how to track those relationships and/or if this is of interest for the napari hub. I suggested earlier to add a section "Related plugins" to the readme template but this was rejected. There are some examples of how such a section can look like:

• https://github.com/haesleinhuepf/napari-skimage-regionprops#see-also
• https://github.com/haesleinhuepf/napari-accelerated-pixel-and-object-classification#similar-napari-plugins
• https://github.com/haesleinhuepf/napari-simpleitk-image-processing#see-also
• https://github.com/haesleinhuepf/napari-process-points-and-surfaces#see-also
• https://github.com/fractal-napari-plugins-collection/napari-feature-classifier#similar-napari-plugins
• https://github.com/DKFZ-TMTRR/Partial-Aligner#installation

I'm meeting users who feel overwhelmed by the possibilities in napari. It would be cool if we could guide them, Furthermore, I think it would be good to give some incentive to developers: If your plugin works well with the plugins of others, that's very cool.

[femtas]

This is extremely useful suggestions and I also think it should be formalized in some way for consistency.
Just not easy for find mechanism to get things updated besides mere 'keywords'.
What complicates the story is that some plugins can start with different kinds of data and also output different results depending on options selected.