Project 'gitlab-com/gl-infra/infrastructure' was moved to 'gitlab-com/gl-infra/production-engineering'. Please update any links and bookmarks that may still have the old path.
Knowledge sharing to improve customer support self service
To help scale Support as GitLab grows (both in terms of product scope and customer numbers) we will create high quality resources to help GitLab users.
The Support team can generate content to complement documentation based on the questions and issues we see in support tickets.
Enable support team to create 30 updates to docs to help capture knowledge and improve customer self service. Track contributions and views to measure 'self service score' (support edited doc visitors / customers opening tickets).
This area was developed by Support: https://docs.gitlab.com/debug/ (source: https://gitlab.com/debugging/debug/ ) built when docs are built - not linked from docs, but nothing to stop Google indexing. Was discussed and set up following conversation in Slack #support-docs-collabo
Improve https://docs.gitlab.com/debug. We now have an agreement with Technical Writers that allows for this so now we should move forward, clean that up, and create more content. However, 'public' docs in the gitlab-ce repository should always be the default.
@dblessing thanks for the suggestions. Consolidating rather than fragmenting is important and certainly a goal of this effort to make it easier for customers to find solutions.
Here are two scenarios to help illustrate the aim:
When people are learning they tend to read docs to get things set up and learn how to use features. They search for things like 'Configure uploads storage'.
When people have a problem they will often go to support. At this point their question is usually phrased in terms of a problem or error - 'Excon::Errors::SocketError: getaddrinfo: Name or service not known (SocketError) when uploading to S3'
Scenario one is covered well by docs. The 2nd scenario is where it would be good to provide a coherent search to help people locate solutions to their problem. Currently they could search the web with a search engine, search GitLab issues or maybe our community forum. Ideally we could have place for people to locate approved solutions written by GitLab (especially support) so we don't need to repeat information on tickets. Creating this content should be low friction. The content should be searchable before submitting a ticket to help us deflect tickets. So I'm anticipating that the search from the support portal would focus on issues and troubleshooting sections of the docs. (We could also offer general guidance on how to search the web to see if someone has written about the issue before.)
Maybe we should have a quick chat via Zoom with you, me, @lbot and maybe Mike Lewis. We've talked about a lot of this second point with Technical Writers prior to the beginnings of #support-docs-collabo channel.
What came out of that discussion is that Job and the tech writers are on board with us having https://docs.gitlab.com/debug but with some caveats.
Edit: Read through the updated description you made. It makes more sense now and I think ultimately we're on the same page.
Outside of the docs and where they should live, I'm 100% with creating a good landing page on https://support.gitlab.com pointing people where to go and steps to take prior to creating a ticket. The search thing is still a little nebulous to me. Having a separate place to search still seems to fragment things IMO. Would that not benefit all users, not just customers? Why limit search improvements to https://support.gitlab.com, then?
@tatkins You mentioned in today's support call that this is being worked on. Do you have any updates? I still have strong opinions on this so I'd prefer if we can keep any progress or thoughts in the open for discussion.
Tom Atkinschanged title from Knowledge sharing to improve customer support self service (WIP) to Knowledge sharing to improve customer support self service
changed title from Knowledge sharing to improve customer support self service (WIP) to Knowledge sharing to improve customer support self service
We had a brief discussion on this topic today and I heard many of my own concerns echoed. I've outlined some topics and questions for further discussion.
Where should knowledge live?
I think the docs should be the single source of truth. I think the purpose of the docs site is for learning and self-service. I think the forums should be for community discussion and for us to engage with GitLab users. If there is no separation of concerns, or if the separation of concerns isn't clear, then it can cause more fragmentation and confusion.
If a user could not find the answer in the docs, and they needed to ask for help via Support or the forum, then we probably need to update the documentation. I think all GitLab features should be documented well enough to deflect support. When they're not, we should update the docs.
I don't think we should be doubling or tripling our maintenance as things change.
What kind of knowledge would we not want to share in the Docs and why? Could we outline some examples in this issue and discuss them?
How can we increase Docs contributions?
I'm having trouble finding it in our handbook, but I'm pretty sure I read something at one point along the lines of:
Reply with documentation, or write it.
I loved that bit and I'm doing my best to embrace it. Another way to put it may be "if the docs aren't good enough, then improve them".
The word "friction" has been used a few times when discussing docs contributions.
How can we reduce friction for support to update the docs?
@sytses I think you mentioned something about wanting support to have merge access to the docs. Even if this isn't accomplishable, is there anything else we can do to reduce friction? I think there is a general feeling of tediousness around docs contributions.
I know that when I'm trying to contribute to the docs, and I'm trying to help, it can be a bit de-motivating to have my contribution poked, prodded, dissected, etc. I don't think it needs to be perfect as long as it's an improvement. If there is something wrong or incorrect about the contribution, then it probably makes sense to block it until it's fixed.
Adding to the "troubleshooting" section of a doc is easy
Maybe I should say starting a contribution to the section is easy. If you found during the course of working on a ticket that the "troubleshooting" section of a doc page didn't at least give you a hint of what to look for, then a small contribution would probably go a long way.
Where should the new "search engine" live?
I agree with Drew that it shouldn't be isolated to just the support application. If having a search tool available on the support portal is preferable to a simple link to the docs, then maybe having the search available in both places would be a compromise?
Just to add to Cody's point, I think any search we can provide on the support portal would be useful for all users: docs, forum, Zendesk. We can start with just docs and then investigate integrating other sources, such as the CE, EE, and runner open issues
How can we reduce friction for support to update the docs?
I'm curious what friction currently exists? Maybe we can pull together a list and and work with the docs team to reduce or get rid of them.
Personally, I found the process fairly straightforward. The only thing I can think of is about having a different template for "quick" fixes e.g. formatting issues, typos, etc.
The only thing I can think of is about having a different template for "quick" fixes e.g. formatting issues, typos, etc.
this x100. I'd really like to see some smaller templates for small and quick fixes. If 13 out of 15 points are irrelevant for what I'm adding, I'm probably not going to use the template.
I'm curious what friction currently exists
I added some bits to my comment that may explain that a little better. But honestly I'd be guessing at what others consider friction. I still contribute to the docs, so it's not really a make or break thing for me
@cwest1 "I think there is a general feeling of tediousness around docs contributions. I know that when I'm trying to contribute to the docs, and I'm trying to help, it can be a bit de-motivating to have my contribution poked, prodded, dissected, etc. I don't think it needs to be perfect as long as it's an improvement. If there is something wrong or incorrect about the contribution, then it probably makes sense to block it until it's fixed."
Thanks for highlighting this. I think this is the nr. 1 problem. I proposed a troubleshooting section on every docs page that is fair game for anyone to address it but I don't think that was implemented. If you have examples can you maybe add these?
Hey @sytses. So far, I've only made a few docs contributions, but I'm trying to increase velocity. I recently opened a couple of Docs issues that I'll get merge requests opened for soon. The only ones I've had trouble with so far have been these two, but some of that trouble is probably just because I'm new and adjusting to how to work on Docs contributions.
I think having a "troubleshooting" section on any docs page is a great idea, and I'll try to efficiently fit into my workflow. The "fair game" part has not been implemented afaik, but I would imagine that reviewers would and should scrutinize those sections less.
I know that when I'm trying to contribute to the docs, and I'm trying to help, it can be a bit de-motivating to have my contribution poked, prodded, dissected, etc. I don't think it needs to be perfect as long as it's an improvement. If there is something wrong or incorrect about the contribution, then it probably makes sense to block it until it's fixed.
This is problematic, and I've experienced it myself even though this is my job :)
We can do better there. Some thoughts:
Automate the docs reviews some more, so we have less back and forth gitlab-org&221
Create videos to guide support engineers how to write better docs and what to be aware of.
Create a universal guide on how to set up your local editor to lint the changes before you create the merge request (we have some info in out docs about linting, but we don't enforce it).
The only thing I can think of is about having a different template for "quick" fixes e.g. formatting issues, typos, etc.
That's a neat idea, but we also need to communicate and educate everyone on using templates (and following them!).
Broaden maintainer access
I don't particularly agree on this. Like we have standards and styleguides that need to be followed when contributing to GitLab's codebase, this is the same as docs. Let's not treat them differently please. We've come a long way refining our styleguide and workflow process. Instead, let's first try to fix the "de-motivating" aspect that @cwest1 expressed.
If we are to give someone else merge rights, they'd have to be "trained" to make sure that the submitted docs meet our standards.
I don't particularly agree on this. Like we have standards and styleguides that need to be followed when contributing to GitLab's codebase, this is the same as docs. Let's not treat them differently please. We've come a long way refining our styleguide and workflow process. Instead, let's first try to fix the "de-motivating" aspect that @cwest1 expressed.
I totally second @axil here. We can simplify the docs review process, but for the reasons stated by him I don't think we should simply skip it.
Great to see that this is being discussed! Let me add my feedback:
I agree with @cody that it could be hard and not straight-forward to modify the docs sometimes, good to know that the doc team is ready to work on it as well!
Adding some kind of troubleshooting section sounds fine as a starting point, but I foresee that it could be problematic. In many cases troubleshooting steps are formed in the form of a short article with symptom/cause/resolution sections, the question is how to integrate such articles into our current documentation. If we just add new troubleshooting pages to each section of our docs, it can become too huge. Therefore, I think it would be better to have a separate knowledge base in addition to docs
When we modify the docs, the MRs are not added immediately as I understand, they are included to the next version of GitLab release. It causes a delay. If we'd have a knowledge base, we could modify and publish articles immediately without any delay
With knowledge base it is also easier to see the demand on improving various fields of the product using some kind of statistics of the tickets linked to an article. Say, there is an article regarding some error, we know the reason and the resolution, and it was used N times to fix customers' issues. If N is more than some critical value, it means the error is very popular, and the product should be improved. I am not sure if it can be done with the troubleshooting section integrated into the docs
Adding some kind of troubleshooting section sounds fine as a starting point, but I foresee that it could be problematic. In many cases troubleshooting steps are formed in the form of a short article with symptom/cause/resolution sections, the question is how to integrate such articles into our current documentation. If we just add new troubleshooting pages to each section of our docs, it can become too huge.
I have to agree with that. We need to be vigilant and always try to port the troubleshooting sections to the general docs. For every troubleshooting item, we should question ourselves why this happens and try to fix the problem at its root.
When we modify the docs, the MRs are not added immediately as I understand, they are included to the next version of GitLab release. It causes a delay. If we'd have a knowledge base, we could modify and publish articles immediately without any delay.
That's true for the internal /help page, but the merged changes appear on docs.gitlab.com almost instantly. The site is built from master every hour. We'll always have master deployed in the docs site one way or another so we can link to whatever we want.