Recently, our team released an update to our support page, with a new Statement of Support. This is a document defining how and what we support in terms of our products, services, and applications. Many of the policies defined in this document have existed before, and nearly all of it was what we practiced all along. However, we wanted to be clearer on our policies and stricter in practicing them to ensure we're providing the best level of support to our customers and the community.
I want to cover two areas of our Statement of Support that might need a bit more clarification.
Scope of support
One of the more important parts of the Statement of Support is defining the scope of support. Scope of support, in the simplest terms, is what we support and what we do not. Ideally, we would support everything. However, without drastically reducing the quality of our support or increasing the price of our products this would be impossible. The "limitations" actually help us to create a more consistent and efficient support experience.
Scope allows us to streamline our expertise
This means our support teams will be experts in the necessary fields rather than being stretched thin. We don't want to widen our coverage at the cost of depth. There are core aspects of our services that we need to nail down, and we can't afford to be shallow in these areas.
Strict adherence to the scope means more consistent support
Teams that don't follow (or have) a scope of support often enable customers to play "support roulette" – a practice where a customer might continually contact support for the same issue in the hopes of finding a representative that is willing and able to extend outside of scope. We don't think this is a good experience for either side. We want there to be clear understanding of what support will do.
So, what do we support and what do we not?
Support for paid users
For our paid users, we have pages describing the scope of support for GitLab.com (SaaS) and the scope of support for GitLab Self-managed Licenses.
What about free users? For our wider community members who don't need the features in our paid plans, I'd like to go a bit more in-depth.
Community-first support for free users
For our free users, support options will always be "community first." Official support at GitLab is a paid feature, and we encourage our free users to first use resources such as our documentation and community forums.
When you run into bugs or have feature requests, it is best to submit an issue to the appropriate issue trackers. For example, the Community Edition Issue Tracker or the GitLab Runner Issue Tracker would cover bug reports and feature requests for GitLab and GitLab Runner. You can browse all of the repositories in our open-core offering in the gitlab-org group on GitLab.com.
This type of community-first approach is standard in open source/core and free-to-use applications. Internally, we used the support model of a very popular open source application, WordPress, and in particular, WordPress.com (SaaS), when designing our Statement of Support.
It's a major goal of ours to better foster the community resources. We want the answers to general technical questions about GitLab to be readily available, and we want to build a strong community that helps one another solve issues. We are working with our community team to make the forums more active. It is a community resource, however, and we would appreciate your contributions here as well.
Having said this, we understand there are certain things that require the attention of our support team, even for our free users. If in doubt, please do submit a ticket, and our team will triage as appropriate. We don't want there to be any discouragement in seeking help from our team. Please understand, however, that priority may go to paid users.
See more details on the scope of support for free users.
The GitLab support team is here to help. Whether you are a free user or an Ultimate customer, we want to ensure you have the best experience possible. We believe that this Statement of Support is an important tool in that process. Everyone at GitLab is a member of the GitLab community and we all play a role in making the entire ecosystem better. We look forward to working with you all to make our projects, issue trackers and forums better, more resource-rich, places.