The `~workflow::production` label should be added to closed issues that are in production

Changes in this MR

• Clarifies that the ~workflow::production label should be added to closed issues that are in production
• Removes the option that ~workflow::verification might indicate production
• Removes "may" to imply that this should be done to clearly communicate with stakeholders

Problem

The Product Development Workflow says the following under "Outcomes and Activities" of "Build phase 3: Launch"

Stakeholders of a feature will know it's available in production

But then describes the following activity:

Prior to the issue being closed, the development team may set the workflow label to workflow::verification or workflow::production for tracking purposes.

This results in uncertainty and inconsistency.

Example of inconsistency

As just one example, these are the workflow:: labels applied to the 49 gitlab-org/gitlab Bug fixes that were contributed to the 15.6 release post:

• in review: 7
• production: 12
• verification: 15
• ready for development: 1
• in dev: 2
• no workflow: 12

Enables enforceability

If we wanted to move toward better adoption of workflow:: labels with GitLab Bot or team communication we need to at least be able to describe the expected state of a closed issue that is in production.

MR meta content

Please indicate the types of revisions being suggested for the Product Handbook (please check all that apply):

• Small improvement (typos, clarifications, etc.)
• Adding a new section
• Modifying existing section
• Documenting a new process
• Adding a new page or directory
• Other

Please indicate Milestone

• Assigned to Milestone

Author Checklist

• Provided a concise title for the MR
• Provided a brief explanation for this change (Say why, not just what)
  • (Attach screenshots, Slack conversations, etc. as necessary)
• Indicated the types of changes included in this MR
• Verified that no confidential data is in this MR
• Assigned reviewers for this change to the correct DRI(s)
  • 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 #product or #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.