Add team documentation to GOV.UK Design System team docs website

[kellylee-gds]

What

Assess existing team documentation in the Google Drive which has value being made open. Also identify missing documentation.

Why

• The team should not be dependent on any individual's knowledge and it should be shared
• To work in the open and share good practice
• Serves as proof of our processes

Epic lead

TBC

Who needs to work on this

Wave 1: Accessibility specialist, product manager, delivery manager

Prerequisites

Preview Give feedback

1. Audit what content we already have
2. Establish our boundaries (what should be kept private)

How to get help from other roles

Preview Give feedback

1. Add a guide on asking for PM / DM help #38
   +0
2. Add a guide on asking a designer for help #51
   +0
   

   
3. Ask a Frontend Developer for help #43
   +0
4. Community designer
5. Senior accessibility specialist
6. Content designer / technical writer
7. Add user researcher guide #68
   +0
   

Upcoming

Preview Give feedback

1. Add accessibility documentation to Design System Team Docs website govuk-design-system#3077
   0 of 7
   epic +1
2. How we use GitHub to manage work
3. Add delivery cycle documentation #67
   +0
   
4. Add guide on how to purchase something #54
   +0
   
5. How to give feedback
6. How to propose work
7. How to run a community workshop
8. Publish Scope of User Research within the Design System govuk-design-system#3384
   research ops +1
   

Ad hoc

Preview Give feedback

1. Add doc on how to contribute #33
   +0
2. Add documentation on supporting our users #28
   documentation +1
3. Create how-to-run-a-Design-System-team-ceremony-or-workshop #30
   +0
4. Create how-to-be-an-epic-lead #34
   documentation +1
5. Create how-to-update-the-support-rota.html.md #40
   +0
6. Add team charter to playbook #50
   +0
   
7. Add guide on how to seek approval for travel #53
   +0

[dav-idc]

Initial thoughts on scoping:

Based on a timeline from now until end of Q2 (September 30)

Main sections, and what priority to aim for (1 is highest, 5 is lowest):

• About these docs: 1
• Who we are: 2
• What we do: 2
• How we work: 3
• Principles: 2
• Accessibility: 1
• Community: 2
• Delivery management: 4
• Design and content: 4
• Development: 3
• Engagement: 5
• Product management: 4
• Support: 2
• Technical writing: 4
• User research: 4
• Weeknotes: 5

[dav-idc]

A scoping session took place on Thursday, 17 August to figure out what portions of this work would be planned out for Q2 2023 (now until end of September 2023). Steve, Kelly and I were in that session. I believe a separate scoping session took place with Chris, but I don't have the notes from that session.

As far as I can recall, we agreed that the items marked as priority 1 above would be the scoped work for Q2.

Those items and their rationale for being priority 1 are:

• About these docs
  • it's the homepage and sets the tone for the rest of the docs
  • items to add here:
    • disclaimer about the docs being a work in progress
    • licence and copyright information
    • purpose of the docs
    • set the tone
• Accessibility
  • We're doing a lot of work with WCAG 2.2
  • There's team makeup reasons to prioritise the recording of accessibility process knowledge before Q3

Following that, the items marked as priority 2 would generally be the next to be worked on
The rationale for why these are marked as priority 2:

• Who we are
  • a natural follow-up to the 'about these docs' content, and a lot of it is already written in other places
• What we do
  • same as 'who we are'
• Principles
  • this playbook is a better place to store our existing principles, and new ones coming from the coaching sessions
• Community
  • one of the areas that affects all specialisations across the team
• Support
  • one of the areas that affects most specialisations across the team