lkozloff
Joined 11 years ago
Joined 11 years ago
What you've done here is that and so much more. Congrats!
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!
Technical Program Manager at Oxide