Define pain points and weak spots of "docs-first" strategy for Support
Problem:
Docs-first and docs-first approach to ticket deflection can be problematic, difficult, confusing, and/or require a significant time investment.
Some common complaints, roadblocks, or problems when working "docs-first" in Support:
- takes too much time to create an MR
- MR conflicts for doc MRs that "sit" too long
- sometimes local rebase is necessary
- not sure if items are docs-worthy
- not sure where to put information in our documentation (example: FAQs)
- MR feels overwhelming for contributions more than just a few lines
- "Apply suggestions" button in MR creates a commit and a pipeline every single time
- docs MRs take too long to go live
- advice is specific to a not-very common situation or environment
- info is good advice for some, not good advice (or not applicable) for most
- somewhat related long-standing issues already exist
- plan to "do it later" + time = forget about it
- other issues/MRs exist but are stalled
- not of sure how each GitLab stage/group wants to communicate/document their features
- uncertain about documentation style guides and doc MR expectations
- uncomfortable with "public" by default
- fear of being judged or criticized
Proposal
- Collectively create a list of pain points, friction, and weak spots.
- Work with the Documentation team to see when and where the process can be expanded or improved upon to address these issues.
Updates:
Requested examples from Support Team in Support Week in Review actionable items