Add "change" to glossary

[apinnick]

Issue: None

Additional information:

[IngridT1]

Could you add more context for why you feel this addition is necessary, @apinnick ?

[apinnick]

Could you add more context for why you feel this addition is necessary, @apinnick ?

@IngridT1 The verb "change" is not an industry standard except in contexts such as changing passwords or directories (even then, we tend to use "navigate to", although cd command means "change directory"). ISG does not use "change" or "changing" except in the context of changing passwords or default settings.

I noticed "Changing ..." in Importing content, Satellite Managing content guide. It is only used in modules that were written more than 4 years ago. It looks strange and vague when the rest of the document uses more descriptive verbs such as "Creating", "Adding", "Removing", etc. I don't think "Changing" should be forbidden, just used sparingly.

The Satellite writers used descriptive verbs when they wrote abstracts for DITA migration (see screenshot). However, it was too much trouble to change the titles because the upstream repo require anchor IDs to match titles, which would have resulted in a lot of broken links and xrefs.

[IngridT1]

I don't think this is a necessary addition, but I would love for @jherrman @bergerhoffer @lburcher7 @bburt-rh to weigh in. They might not agree with me.

[jherrman]

Personally, I don't see anything wrong with using the term "change" in situations where you replace an existing setting/item with a partially or completely different one. In that way, the change in "changing the default download policy" is semantically very close to "changing the password".

Still, Avital has a point that if you can use a more specific verb like "create", "add", or "remove", then "change" is unnecessarily vague. Nevertheless, I'm not really sure how much that could be an issue across our doc sets. Still, it shouldn't hurt to have a shortish mention about avoiding the term where possible, as a best practice.