Investigate naming options for invite_email quickaction

Problem to solve

One thought on the semantics of the quick action /invite_email, which partially overlaps with /add_contacts due to being provided an email address, though in a different path.

When adding external participants to a work item with /invite_email, they are immediately added as recipients to the next and following comments. This means, the term invite in the quick action is a bit misleading, as there will be no voluntary choice to be confirmed for being added as an email participant.

With looking at the verbs invite and add, without assuming a manual opt-in workflow is neither desired nor considered right now, would it appear more conventional to speak about a quick action /add_email or /add_participant instead? Also, talking about participants instead had the benefit that the level of abstraction used to describe the object is the same as with /add_contact.
This way both actions starting with /add_ would appear above each other in the autocomplete box. This in return would render the description texts visible at the same time and allow for a better disambiguation of the two similarly appearing functionalities with diverging side-effects.

If /invite_ is settled as a prefix for the existing action, I would like to propose to add an additional new_invite message sent to invited participants, allowing them to opt-in explicitly.

This is proposal is slightly different than the automatic notification service_desk_new_participant_email proposed in Adds Service Desk new participant email (!150706 - merged), as it requires explicit consent to opt-in.

Proposal

Explore adding an alias for /invite_email like /add_email or /add_participant (thus also adding /remove_participant).