Define process for stage-wide TW collaboration
Issue Description
If we would like to have multiple TWs work across the same groups in a single stage (2+ TWs covering 2+ groups), instead of one group per TW, we need to define a process to make this work.
Proposal 1:
At an early stage of issue refinement, a TW should be set as the DRI for TW tasks from start to finish for that issue. This can be done well ahead of time by adding the TW's name to a "header" in the issue. Similar to the header we have in MR templates for release post items:
-
Team members for review and approval: Engineer(s): `@engineers` | Product Marketing: `@PMM` | Tech Writer: `@TW` | Product Designer(s): `@ProductDesigners` Engineering Manager to merge when the feature is deployed and enabled: `@EM`
We can do it with a regular @ message to inform the TW they have been set as the DRI, or in backticks so that they can be directly pinged later by an engineer/designer when needed.
This gives everyone involved in the issue the information they need to ensure TW coverage for the work required. The designer knows who to ping the TW at the design phase to verify the UI text, the engineers know who to design at the MR phase. So the same TW shepherds all the work for a single issue from start to finish.
A "Stage TW Lead" tasked with the responsibility of managing everyone's assignments would need to handle this, a bit like an EM. This would happen as part of issue refinement, early enough that if a designer is working on designs at any time (which could be several releases ahead of the current release), they always know who to ping. If the work is part of a larger epic, the TW could be assigned to the entire epic, or the work could be shared.
But the TW Lead would need to keep everyone's workload in mind.
Advantages:
- Can be assigned early.
- Everyone involved would understand the DRIs through the entire process.
- Could allow for TWs to be assigned to multiple issues for larger projects, for a single DRI across the whole project (ex: CI/CD Catalog).
Disadvantages:
- Some issues complete refinement months before being worked on, and when the work actually starts, the assigned TW could have a different workload (be busier) than when originally assigned as the issue's TW.
- Related, the stage TW would need to try to predict everyone's workload far into the future, so there needs to be some readjustment as issues finally start being worked on.
Proposal 2:
Similar to proposal 1, but the assigned TW is only set "on demand". So when a designer starts working on an issue, they ping the Stage TW Lead to ask for TW assignment/review. Or potentially, for features that do not need any design input (ex: backend engineer adding API endpoint), it could happen when an EM assigns the engineer to work on the issue.
Advantages:
- More easily adapted to the TW team's current workload/OOO timing.
Disadvantages:
- More reactive than proposal 1, as TWs are only informed at the last minute and take more time to get up to speed on the issue.
- Could delay responses/review, if the designer/EM pings the TW Lead for TW assignment late in issue development. Could add an extra day or two to response times, so designers/EMs would need to know to ping with enough time.
Proposal 3:
TBD