Make "move to another form" generic

Why is this change being made?

Support tickets in one of the SGG queues are often moved to the L&R queue by manually changing the Form field.
After a short discussion, it was stated by @jcolyer that it would be best to use the Incorrect form used in all cases.

https://gitlab.slack.com/archives/C018C623KBJ/p1656427093975149

Ben Prescott  39 minutes ago
Hi.  Request for a license file in this ticket as they're too back level  to use cloud activation - https://gitlab.zendesk.com/agent/tickets/303259
Would this usually be sorted by y'all ?  I noticed a similar request above.
:white_check_mark:

Rene Verschoor  37 minutes ago
Hey Ben. Just slap the Incorrect form used macro on it to have it properly moved to the L&R queue, and we'll take it from there.

Andrew Conrad:spiral_calendar_pad:  31 minutes ago
I switched it to L&R.

Rene Verschoor  30 minutes ago
Next time, please use the macro.

Andrew Conrad:spiral_calendar_pad:  27 minutes ago
@jcolyer told me (at least as I understood it) that the macro isn't needed unless if it is for something outside of Support (like Billing).

Jason Colyer  27 minutes ago
Either works, but the macro tends to make the most sense

Jason Colyer  26 minutes ago
Havent looked at the ticket, but 90% of the time the macro makes the most sense. Ops can look it over and figure out if a new one is needed or if it can be moved

Andrew Conrad:spiral_calendar_pad:  26 minutes ago
Hm. That wasn't the impression I had earlier, but okay. I can use it for L&R tickets again.

Rene Verschoor  24 minutes ago
No harm done, the ticket will be handled. But as Jason said (AND HE'S THE AUTHORITY) the macro is the safe way.

Jason Colyer  24 minutes ago
Yep, macro is always the safest way

Andrew Conrad:spiral_calendar_pad:  24 minutes ago
I understood the following handbook page to support the idea that the macro is only needed for non-Support forms:
https://about.gitlab.com/handbook/support/workflows/ticket_triage.html#moving-to-non-support-forms

Rene Verschoor  23 minutes ago
Fair point

Andrew Conrad:spiral_calendar_pad:  23 minutes ago
I think you told me because I sent a lot of L&R requests to Ops before.

Jason Colyer  21 minutes ago
Safer to blanket say "just use the macro". Too many exceptions and such exist, so best let ops handle em
:+1:

Rene Verschoor  20 minutes ago
maybe change the handbook?

Jason Colyer  20 minutes ago
if yalls workflows say otherwise, i would recommend changing em to align with the "just use the macro" approach

Rene Verschoor  19 minutes ago
If you're ok with the extra load, I'll create an MR
:thank_you:

Jason Colyer  19 minutes ago
Yeah it's fine.

Jason Colyer  18 minutes ago
Good incentive to find out why it happens and try to make things better

Rene Verschoor  18 minutes ago
coolio, added to todo list soonsoonsoon (edited) 

Author Checklist

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
• If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
  • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

---