@@ -205,13 +205,13 @@ FY24 was a year of better understanding the needs of our customers. In FY25 we w
## Dogfooding in Support
Citing our [dogfooding](/handbook/values/#dogfooding) operating principle, people sometimes ask why GitLab Support doesn't use [Service Desk](https://docs.gitlab.com/ee/user/project/service_desk/).
Citing our [dogfooding](/handbook/values/#dogfooding) operating principle, people sometimes ask why GitLab Support doesn't use [Service Desk](https://docs.gitlab.com/user/project/service_desk/).
Dogfooding is using a piece of GitLab *for its intended purpose*. For example, one *could* use GitLab issues as a newsletter (and we do! See: [Support Week in Review](#support-week-in-review)), but creating merge requests to help Issues serve as a newsletter more effectively wouldn't be dogfooding unless that improvement also helps its core use case.
In other words: Dogfooding is using the product in the way that our customers would use it to the end of discovering and solving pain points that they have. Dogfooding supports [customer results](/handbook/values/#customer-results).
At GitLab Support we use Service Desk to process [Personal Data Requests](/handbook/legal/privacy/gdpr/), but not for our global support because the customer for Service Desk is primarily small teams soliciting [*bug reports, feature requests, or general feedback*](https://docs.gitlab.com/ee/user/project/service_desk/). Through our use of Service Desk in this smaller setting we've been able to influence product direction towards adding features like [internal notes](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note).
At GitLab Support we use Service Desk to process [Personal Data Requests](/handbook/legal/privacy/gdpr/), but not for our global support because the customer for Service Desk is primarily small teams soliciting [*bug reports, feature requests, or general feedback*](https://docs.gitlab.com/user/project/service_desk/). Through our use of Service Desk in this smaller setting we've been able to influence product direction towards adding features like [internal notes](https://docs.gitlab.com/user/discussions/#add-an-internal-note).
We continually evaluate product features for use-cases within Support and provide feedback and feature requests where blockers exist. Support will always prioritize [customer results](/handbook/values/#customer-results) over any other consideration.
@@ -543,7 +543,7 @@ or accountability.
Artifacts of approval can include:
- Getting a peer or manager to review and merge your MR
- A peer or manager showing their approval using [MR approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
- A peer or manager showing their approval using [MR approvals](https://docs.gitlab.com/user/project/merge_requests/approvals/)
- A peer or manager commenting "looks good to me"
### Support Workflows
@@ -563,7 +563,7 @@ Each Slack channel within Support has a number of [Workflows](https://slack.com/
#### Issue Notification
Some workflows are meant to notify the team of new issues created in the relevant project.
In these cases, a [project webhook](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) passes information to [Zapier](https://zapier.com/app/zaps/folder/210292),
In these cases, a [project webhook](https://docs.gitlab.com/user/project/integrations/webhooks/) passes information to [Zapier](https://zapier.com/app/zaps/folder/210292),
which then sends the information to a Slack workflow.
-`#support_gitlab-com`
@@ -666,29 +666,29 @@ The [Support Slackbot (archived)](https://gitlab.com/gitlab-com/support/toolbox/
@@ -39,7 +39,7 @@ A **Deep Dive** is a session is to share knowledge about a particular topic, wit
Some examples of deep dives would be:
- GitLab Geo on Omnibus (building off the [Geo module](https://gitlab.com/gitlab-com/support/support-training/blob/main/.gitlab/issue_templates/Geo.md))
- ElasticSearch with GitLab (building off [GitLab's ElasticSearch documentation](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html))
- ElasticSearch with GitLab (building off [GitLab's ElasticSearch documentation](https://docs.gitlab.com/integration/advanced_search/elasticsearch/))
- Configure CI for an advanced use case (e.g., Configuring docker-in-docker, using it to build an image, and then optimizing the Docker image build time by utilizing Docker layer caching) (building off the [CI module](https://gitlab.com/gitlab-com/support/support-training/blob/main/.gitlab/issue_templates/CI.md))
@@ -282,7 +282,7 @@ As Product has implemented the minimal viable versions of [#27074](https://gitla
Here are some options to get basic seat count information:
1.*Plan* and *Seats Currently in Use*:
-[chatops](https://docs.gitlab.com/ee/development/chatops_on_gitlabcom.html#chatops-on-gitlabcom)(requires dev.gitlab.org account) with the command: `/chatops run namespace find group-path`
-[chatops](https://docs.gitlab.com/development/chatops_on_gitlabcom/#chatops-on-gitlabcom)(requires dev.gitlab.org account) with the command: `/chatops run namespace find group-path`
1. Info from 1 plus Subscription (or trial) *End Date*
1. Info from 2 plus *Seats in Subscription*, *Max Seats Used*, and *Start Date*
-[Customers portal admin](https://customers.gitlab.com/admin/customer)(requires access via Okta)
@@ -300,7 +300,7 @@ with the `Other` option providing the Group URL and any additional context.
> **Note:** The public facing version of this information is on the [Licensing and subscription FAQ page](https://about.gitlab.com/pricing/licensing-faq/#how-can-i-get-a-list-of-billable-users-for-my-plan).
Customers can get their subscription information and a list of users using a seat on their group's **Billing** page (under the group **Settings**) or by using the [Billable members API endpoint](https://docs.gitlab.com/ee/api/members.html#list-all-billable-members-of-a-group)
Customers can get their subscription information and a list of users using a seat on their group's **Billing** page (under the group **Settings**) or by using the [Billable members API endpoint](https://docs.gitlab.com/api/members/#list-all-billable-members-of-a-group)
---
@@ -363,8 +363,8 @@ For information relating to priority prospects, please see
The customer has more than likely run into an issue during the purchase process, or is unaware how to apply their subscription to their group. The following documentation outlines how to subscribe to GitLab.com, link their GitLab.com account to [CustomersDot](https://customers.gitlab.com), and apply that subscription to their group.
-[Obtain a GitLab Subscription](https://docs.gitlab.com/ee/subscriptions/#obtain-a-gitlab-subscription)
-[Manage Your GitLab Account](https://docs.gitlab.com/ee/subscriptions/#manage-your-gitlab-account)
-[Obtain a GitLab Subscription](https://docs.gitlab.com/subscriptions/#obtain-a-gitlab-subscription)
-[Manage Your GitLab Account](https://docs.gitlab.com/subscriptions/#manage-your-gitlab-account)
### Users in an account I own would like more visibility into their organization's support tickets
@@ -381,7 +381,7 @@ If you'd like to enable this, please:
To view the group's number of billable members, a member of the group with `Owner` permissions may visit the **Settings -> Billing** section of it to see a breakdown. The number of billable members is the amount listed under `Seats currently in use` and this is the amount that will come up whenever they link their group to a paid subscription. Billable members [consist of every user](https://about.gitlab.com/pricing/licensing-faq/#who-gets-counted-in-the-subscription) who is added to a group, subgroup, or project within a paid namespace with the only exception being Guest users within a namespace on certain subscription levels.
We have a [billable members API endpoint](https://docs.gitlab.com/ee/api/members.html#list-all-billable-members-of-a-group) that will produce a list of all the billable members for the group. This must be run with your own PAT.
We have a [billable members API endpoint](https://docs.gitlab.com/api/members/#list-all-billable-members-of-a-group) that will produce a list of all the billable members for the group. This must be run with your own PAT.
All the billable members are also currently displayed on the group billing page in an unsorted list. This is a first iteration; if interested, you can view the [epic](https://gitlab.com/groups/gitlab-org/-/epics/4547) to see the planned work. If you have any feedback on the billable members list or want to request functionality or UI changes that are not planned in the epic, please feel free to leave a comment on the epic.
@@ -11,7 +11,7 @@ The voice in KB articles should be concise, direct, and precise. Since many user
## Formatting
Follow the [Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide) and use the [recommended word list](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html) unless otherwise specified. The important thing is that we deliver clear information following a standard template that customers know they can trust.
Follow the [Documentation Style Guide](https://docs.gitlab.com/development/documentation/styleguide/) and use the [recommended word list](https://docs.gitlab.com/development/documentation/styleguide/word_list/) unless otherwise specified. The important thing is that we deliver clear information following a standard template that customers know they can trust.
Pay special attention to things like:
@@ -22,7 +22,7 @@ Pay special attention to things like:
### File naming
File name should be as similar to the title of the article as possible. Follow the conventions in the [structure guide](https://docs.gitlab.com/ee/development/documentation/site_architecture/folder_structure.html#work-with-directories-and-files). Specifically:
File name should be as similar to the title of the article as possible. Follow the conventions in the [structure guide](https://docs.gitlab.com/development/documentation/site_architecture/folder_structure/#work-with-directories-and-files). Specifically:
- Do not use special characters, spaces, or capital letters in file names, directory names, branch names, or anything that generates a path. This will break things when submitting the article to the Support Super Form for Zendesk.
- When creating or renaming a file or directory and it has more than one word in its name, use underscores (_) instead of spaces or dashes.
@@ -70,7 +70,7 @@ The environment quickly highlights what custom configurations, installation type
- Impacted offerings - aligns with the Offering section of Docs pages
- If the document affects all versions of the product, use your best judgement to either omit the versions section, or state that all versions are affected.
- Use [earlier](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html#earlier) and [later](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html#later) when talking about version numbers.
- Use [earlier](https://docs.gitlab.com/development/documentation/styleguide/word_list/#earlier) and [later](https://docs.gitlab.com/development/documentation/styleguide/word_list/#later) when talking about version numbers.
- Note the product with the version, like `GitLab 17.4.4` or `GitLab Runner 14.3.1`.
- Always indicate which patch versions are affected, for clarity. This differs from the Documentation Style Guide.
- If all patch versions of a minor version are affected, say `All GitLab 17.4.x versions`.
@@ -146,7 +146,7 @@ Providing additional information is optional, but can be useful for sharing rela
### Related links
Optional. Add links to relevant feature requests, bug issues, or other info as necessary. Follow the format used for [related topics](https://docs.gitlab.com/ee/development/documentation/topic_types/index.html#related-topics).
Optional. Add links to relevant feature requests, bug issues, or other info as necessary. Follow the format used for [related topics](https://docs.gitlab.com/development/documentation/topic_types/index/related-topics).
Even when links have been included inline in other sections, it's useful to consolidate the links in one section as well, for quick reference.
including [the type of Runner being used](https://docs.gitlab.com/ee/ci/pipelines/compute_minutes.html#additional-costs-on-gitlab-saas)
in a pipeline. A customer [can purchase additional units](https://docs.gitlab.com/ee/ci/pipelines/compute_minutes.html#purchase-additional-cicd-minutes)
