Master/slave terminology in documentation

[JulianHn]

Hi all,

I am in the processing of doing some more in-depth research into OMERO.grid and have found a lot of master/slave style terminology to refer to the various nodes in this setup.
I don't know what the stance of OME on the naming conventions is, but at least I am making an effort to move to more inclusive language in my coding and documentation, in line with major open source projects like the Linux Kernel or big organizations like google.
I would be happy to go through the documentation and provide the appropriate patches to change to a different terminology (primary / secondary?).

// Julian

[joshmoore]

Hi @JulianHn. Thanks for opening this. The team had previously started investing the rewording. Unfortunately, there are a number of breaking changes that would be associated since the terms are used in code not just documentation. If you can see a way towards updating the public facing documentation, we can include an explanation that there may still be cases where the terms are used for historical reasons.

[JulianHn]

Hi @joshmoore ,

thanks for the reply. I understand the problems with the code (which I hadn't looked into before opening this) and I assume it's a more complicated transition than running s/master/primary/ && s/slave/secondary on all OME repositories (not to say that this alone wouldn't be a big enough headache).
I think adjusting the documentation would already be a step in the right direction, but it will need to be checked carefully if this doesn't introduce conflicts between documentation & actual code.

// Julian

[JulianHn]

I've grepped through the documentation and unfortunately it looks to me like I have to agree with OME results, that this is not an easy undertaking. The file where I noticed this in the first place, i.e. the grid documentation, would be the only place where the terminology change could be done at all, although it still would require a lot of explanation to avoid confusion with templates etc. Everywhere else, the terminology is taken straight from the code or repository structures and can IMO not be touched without changing the underlying code.
So if this migration is ever planned, it would probably need to be a full source code overhaul of all things OMERO, which of course would need to be planned and organized by OME to prevent breaking. And there are probably limited resources for that on your side.
Therefore: Probably bigger fish to fry - I'll close this issue.

// Julian