support VS foxear

Not OP but strace gives you a ton of info even if you filter by syscalls with -e. You really need something like https://gitlab.com/gitlab-com/support/toolbox/strace-parser to get information like what this seems to provide out of it.

Hi @atonse - I'm a Senior Manager at GitLab Support. I appreciate you taking the time to put together your feedback. I'm happy to discuss the particularities of your support experience if you send me an email at lkozloff[at]gitlab.com

There's a couple of general points though that I'd love to comment on.

> Why can't I just SSO using my GitLab credentials into Zendesk?

I'd love to have this as well - it makes complete sense (especially for our SaaS customers - it wouldn't help as much for self-managed). In order to get it implemented we need GitLab.com to become a SAML or JSON Web Token source. We have an open feature request for that here: https://gitlab.com/gitlab-org/gitlab/-/issues/238419

Even with that implemented we'd still have some challenges identifying who should be getting support without occasionally asking for proof of a support contract. As you said, you're part of multiple GitLab groups. It's well possible that some of those are on our Free tier and others on Paid tiers. In some contexts you'd be eligible for Support, and in others you might not be.

Usually this speed bump only hits the first time you contact support. Once you've opened a ticket we'll have you linked up correctly.

Recently I've been working on improving contact management and making sure customers are aware of what they can do to make their first support ticket the best experience it can be. You can track that effort in https://gitlab.com/groups/gitlab-com/support/-/epics/156

> Why use terms like "Support Entitlement" – just say, which org/group are you with?

We have to consider both our self-managed customers and SaaS customers with our language. For GitLab.com customers naming a path completely works (and is one of the ways you can prove your entitlement: https://about.gitlab.com/support/managing-support-contacts.h...). For Self-managed we have to map account names exactly and need a bit more as some organizations have visibility of tickets between users, in which there may be sensitive data.

I think you're right that it could sound more human. I've opened up https://gitlab.com/gitlab-com/support/support-team-meta/-/is... to discuss improvements.

If you have any thoughts, feel free to participate!

Full disclosure, I have some rather strong feelings about telemetry on gitlab and the implementation process itself.

-----------------------

I originally posted a different issue labeled "Pseudonymization MVC Rollout Plan"[1] but that issue went private rather quickly after appearing here. Sadly it wasn't archived.

To keep this issue from just going private, it (and some other relevant issues) have been archived: http://web.archive.org/web/20211012193943/https://gitlab.com...

There is atleast one more telemetry related issue that[2] has had their access limited after being mentioned in the feedback thread.

Also, I'd recommend checking out:

* the last telemetry attempt from 2019: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/5672

* feedback from last time: https://gitlab.com/gitlab-com/support/support-team-meta/-/is... & https://gitlab.com/groups/gitlab-org/-/epics/2280

* self-hosted instance telemetry(operational data section) that is already live and has a pretty severe dark pattern for opting out: https://about.gitlab.com/blog/2021/07/20/improved-billing-an...

[1] - https://news.ycombinator.com/item?id=28840685

Training used for support personnel: https://gitlab.com/gitlab-com/support/support-training/-/tree/master/.gitlab/issue_templates

GitHub: https://github.com/KernelErr/foxear