Align the Pipeline Authoring validation track and collaboration process to the product development flow

Why is this change being made?

Problem

Recently we've had several occasions where we struggled with effectively collaborating on a solution and moving it into implementation. There are several problems we've been encountering:

• The issue descriptions are often not kept up-to-date based on the discussions that are happening in threads.
• The discussions get scattered over multiple issues.
• Issues are sometimes moved into workflowplanning breakdown before the design discussions are finished, leading to unnecessary amount of design discussions during the implementation and incomplete proposals in the issues that were created for implementation.
• It's been difficult to keep track of the BE and FE work when it's in one issue.

The recent MR introduced a new process for splitting issues into FE and BE. It involves moving an issue from workflowdesign into workflowplanning breakdown and into either FE or BE. It means that in most cases an issue that is being worked on by UX will become an implementation issue. This will help us create a SSOT for feature development and keep FE and BE work organized, with all dependencies easy to identify.

Proposal

• The suggested changes in this MR are meant to align the validation track activities of the PA team and our collaboration process to the product development workflow, especially the parts of it that are required according to our handbook.
• These changes are also meant to work well with the new process for splitting FE and BE issues, and moving issues from workflow::design to workflow::planning breakdown and all the way into the implementation.
• Good issue refinement practices maintained by the DRIs of each phase of the workflow are crucial to maintain a SSOT for any solution and for the effective delivery of a feature, so I added those practices directly from the product development flow to our handbook.

Author Checklist

• Provided a concise title for the 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 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 in 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.

---