Skip to content

Update description for TW PTO and share the effort across team

Evan Read requested to merge eread/remove-backups-for-technical-writers into master

Why is this change being made?

This MR is now limited to:

  • Updating the description of what happens when writers take PTO.
  • Removing backups from "other projects".
  • Promoting some topics to avoid nesting so many sections.

The rest of the proposal (removing the assignments etc from the handbook) can come later.

Proposal

This proposal for removing backups as a concept for the technical writing team is so that coverage for a Technical Writer's PTO can be more dynamic and flexible.

This change would:

  • Simplify group assignments (and reassignments), because backups don't need to be found.
  • Avoid the team having to find backups for groups that don't yet have a backup writer.
  • Allow backups for PTO to scale better and spread the load over more folks. Some PTO will overlap with a busy period and some will overlap with a quieter period, so the pool of technical writers helping out expands and contracts to suit.
  • Account for the fact that a technical writer who provides coverage for a technical writer on PTO only covers a subset of that writer's work. Previous subject matter expertise is helpful, but not essential.
  • Allow for the possibility that a backup writer might have very little capacity at the time required to fully cover another writer during PTO. It's very hard to predict that one writer is a good backup for a writer in advance.

Backups as they were documented here were only ever for relatively short periods of PTO. If a writer needed to take months off, a more permanent arrangement would need to be made, but that could be made at the time needed, rather than being a permanent fixture.

I think this solution is better than moving from fixed backups to backups selected shortly before leave, because it's better for writers to volunteer for things they can see as needed rather than volunteering for an unknown amount of work.

Other changes

While I was here, I've moved some sections up to be top-level.

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.
Edited by Evan Read

Merge request reports