jadudm commented 1 year ago

At a glance

In order to handle tickets from the helpdesk as a content developer I want a documented process (with ticketing support) for content development and review

Acceptance Criteria

We use DRY behavior-driven development wherever possible.

Scenario: A ticket requires a new knowledge base entry.

Given that we want all our answers to be documented to benefit all users when we get a user question that we don't have documentation for

...

### then... 
- [ ] content should be developed to answer the question
- [ ] content should be reviewed, and the review process documented (GH checklist, etc.) 
- [ ] content should be published (and possibly tagged) for consumption by all users
- [ ] the user should be informed that their question has been answered, with a link
- [ ] the user should be asked to follow up and indicate if that addressed their issue

Shepherd

Design shepherd: @lauraherring
Engineering shepherd: @jadudm

Background

All helpdesk interactions ultimately become 1) an email pointing to content, 2) a content development exercise, 3) an engineering exercise, or 4) some combination of all three.

We should have documented processes/workflows for all of these. This speaks to the content development workflow.

Security Considerations

Required per CM-4.

None. This is about process and publication of data to the static website.

Process checklist

# Sketch [comment]: # "Notes or a checklist reflecting our understanding of the selected approach" - [ ] Design designs all the things - [ ] Engineering engineers all the things # Definition of Done ## Triage ### If not likely to be important in the next quarter... - [ ] Archived from the board ### Otherwise... - [ ] Has a clear story statement - [ ] Design or Engineering accepts that it belongs in their respective backlog ## Design Backlog - [ ] Has clearly stated/testable acceptance criteria - [ ] Meets the design Definition of Ready [citation needed] - [ ] A design shepherd has been identified ## Design In Progress - [ ] Meets the design Definition of Done [citation needed] ## Design Review Needed - [ ] Necessary outside review/sign-off was provided ## Design Done - [ ] Presented in a sprint review - [ ] Includes screenshots or references to artifacts ### If no engineering is necessary - [ ] Tagged with the sprint where it was finished - [ ] Archived ## Engineering Backlog - [ ] Has clearly stated/testable acceptance criteria - [ ] Has a sketch or list of tasks - [ ] Can reasonably be done in a few days (otherwise, split this up!) ## Engineering Available - [ ] There's capacity in the `In Progress` column - [ ] An engineering shepherd has been identified ## Engineering In Progress - [ ] Meets acceptance criteria - [ ] Meets [QASP conditions](https://derisking-guide.18f.gov/qasp/) ### If there's UI... - [ ] Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order - [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works. - [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate. ## Engineering Blocked - [ ] Blocker removed/resolved ## Engineering Review Needed - [ ] Outside review/sign-off was provided ## Engineering Done - [ ] Presented in a sprint review - [ ] Includes screenshots or references to artifacts - [ ] Tagged with the sprint where it was finished - [ ] Archived

lauraherring commented 1 year ago

@Carley-Sullivan I think you're working on this ticket, essentially? Creating documentation around what happens when a user question comes into ZDesk and requires a new FAQ in ZDesk and all the review steps, etc.?

jadudm commented 10 months ago

This is stalled and/or we effectively did this with a HD SOP, and given our ongoing work on process, I'm going to claim it should close, and a newer, more targeted ticket be developed when we're ready to pick up this work again.

GSA-TTS / FAC