What you've done here is that and so much more. Congrats!

https://99percentinvisible.org/episode/hl-06-segagaga/

It was loads better than Google+, which we had tried before.

These days I suspect things like Slack started to take over here, but for that particular time and place it was a great fit.

I've had some interesting discussions and it's helped me structure some thoughts by asking questions and follow-ups, then summarizing our conversation... all while I'm on a walk.

One fun thing I did with my family was have it do an interactive adventure story starring us. We had an adventure, and then used the built in DALL-E to generate images of scenes from our adventure.

But maybe that's what you want from a tool - something so good it essentially replaces the previous way you were doing something?

One of the things that has helped me most recently is building out a better set of rules for my inbox that let me segment out unknown priorities from known priorities.

Previously, I'd get so many bids for time the act of even enumerating the tasks TO prioritize was too much and I'd end up in a push-workflow, rather than pulling tasks by their appropriate priority.

So, hopefully this is some encouragement for you to think about what's urgent/important in your inbox, what's unknown and needs triage, and what can be scheduled for later.

My kids and I observed these ice spikes every morning when I took out the trays to for iced coffees, and I always wondered why I'd never seen them anywhere else in the world.

It's almost a nice retroactive confirmation that the water delivery service we relied on was selling distilled water as advertised!

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!

I appreciate this feedback, and you're right. We don't want folks to get themselves in a position where they lose access.

Our current language when you enable MFA is here: https://gitlab.com/gitlab-org/gitlab/-/blob/adc7dbeb387adc69...

> Should you ever lose your phone or access to your one time password secret, each of these recovery codes can be used one time each to regain access to your account. Please save them in a safe place, or you will lose access to your account.

We're directly emailing our most at risk users and are still processing resets in the mean time. Additionally, many users will see a CTA banner reminding them to regenerate their recovery codes if they haven't recently.

If there's anything else we can do - I'm happy to hear it! I've had to rely on recovery services in the past because of pure bad luck and a move to a new country, so we didn't take this decision lightly.

We did use to do identity card verification. The issue that we had was that we often didn't have a lot of information about the folks who opened free accounts.

Often names would be pseudonyms or match only partially with their ID. Not to mention, of course, the difficulty of verifying the authenticity of IDs from all over the world.

We wrote about this back in 2018: https://about.gitlab.com/blog/2018/10/08/enforcing-managing-...

We actually do want (and care) about your feedback and wanted to provide a clear way to give that. In the past we've gotten support requests, tweets, comments on GitLab issues and a myriad of other creative ways of voicing thoughts, opinions and ideas.

My hope was to streamline feedback into a single place that GitLab support and our community teams are actively monitoring. There's been some helpful discussion there (and here) already.

Organizations approaching remote have a helpful speedbump that encourages them to take an intentional look at the way they disseminate information. Being fully remote is an accountability structure that helps ensure that everyone is following those practices.

There's nothing that would prevent a well-run colocated company from capturing those particular advantages, but such a company would probably slowly drift remote as companies like Buffer (and GitLab!) have as they grow and look for new talent.

https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#p...

You can purchase directly from the customers portal at https://customers.gitlab.com and apply them to your group.

Hope that helps!

The rep was very knowledgable and took the time to explain exactly what would happen.

This was years ago, but I appreciated the support at the time, and as a Support Manager at GitLab would still point to it as an example of a quality response.

> Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore.

I believe you're referring to: https://about.gitlab.com/support/#we-dont-keep-tickets-open-...

I think it's a bit more nuanced than that, although I can certainly understand your reading. If your support ticket does end up as revealing a fault in the product or a feature request, we will close out the ticket and prefer further communication on the resulting issue. This is in keeping with our Transparency value. We want to make sure that others who are affected can also chime in, and that the resulting issue is the single source of truth.

For issues with configuration, up-time or other support-related things that aren't feature requests or bugs, we would be handling those directly.

On those cases that do result in bug reports or feature requests, it's certainly true that sometimes they aren't prioritized, don't get attention, or have milestones slip.

Again though, that happens transparently where you can interact directly with the PMs in question.

Ultimately, it is a _different_ support experience, but we believe that it's better to have our community as close to our development process as possible.

We do consider this an ongoing discussion, and have a long running issue where a number of customers have provided some feedback: https://gitlab.com/gitlab-com/support/support-team-meta/issu...

Please do feel free to join the discussion.

It was me who helped your tickets along last time, and I'm sorry to hear that you're having trouble again. Someone should be in touch on your renewals issue soon.

If you're interested in the story; there's a bit of nuance here. Support actually falls under Engineering in GitLab, and licensing falls under Sales. That means that technical issues and upgrades/renewals fall under different teams.

The good news is that we're working hard in both areas to improve. - We've significantly increased the headcount of the licensing team, this should mean faster responses on licensing queries in the near term future. - We've formed a Fulfillment team who is hard at work automating away some of the manual process associated with renewals. (You can see their priorities here: https://about.gitlab.com/direction/fulfillment/#-current-foc...)

Specifically from the Support side, we're discussing process improvements that will mean fewer languishing tickets like you've described. There are a few in flight, but the one I'm personally most excited about is https://gitlab.com/gitlab-com/support/support-team-meta/issu....

You'll note, I did just write it up - so there's not much discussion there yet. If you're feeling up for it, we'd love to have your input. Feel free to leave a comment there if you have any colour that could help.

I hope next time we bump into each other on HN it'll be under happier circumstances.

As always, if you'd like to discuss this more, feel free to email me directly at lyle[at]gitlab[dot]com.

I'd like to follow up on this to see where we dropped the ball and how (or if) we can make things right. Feel free to email me at lyle[at]gitlab.com and I'll look into your ticket history and move things along.

For others, performance issues with EFS and GitLab have been frequent enough that we specifically call EFS out in our documentation: https://docs.gitlab.com/ee/administration/high_availability/...

This isn't to say that EFS doesn't have its place, it's just that git operations quickly exhaust burst credits and many of our users on EFS end up with difficult to diagnose performance problems.

This may or may not have anything to do with @Roritharr's problems, but it's worth noting!

I could be wrong though. I've got a similar setup and I've only seen the error once or twice.