Love this - I had a similar idea years ago, specifically for looking at long-text privacy policies and displaying the `diff`... but obviously never built it.
What you've done here is that and so much more. Congrats!
For those unfamiliar, 99% Invisible + Hidden Levels did an episode about the backstory of development of Segagaga that is really worth a listen. I really enjoyed it... and without having listed to it months ago wouldn't have even known what this headline was about!
I rolled this out when it was "Facebook at Work" at an education non-profit I was working at in Cambodia. It was generally successful and useful for doing the type on internal storytelling we were trying to do. Particularly because teachers and staff didn't have, need or want Slack.
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.
Interesting - this was actually a feature that got me to convert. I have some slight annoyances with how it handles natural pauses as I collect my thoughts and speak, but overall it's been great.
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.
I've found the act of prioritization to be one of the hardest practices to build. I know I should prioritize. I know it takes time to do it well... but if I spend just 10m doing this one thing I can get a nice dopamine hit for having accomplished... 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.
So happy to have this small mystery solved. I lived in SE Asia for years where we avoided the local tap water, including for ice at home.
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!
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.
> 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.
Support Manager (and person who wrote that line) - it's certainly not meant to be dismissive or tongue in cheek. If you've got some suggested wording to help take away that feeling, I'm happy to submit (or merge) and MR to the blog post to make it feel less that way.
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.
I don't think you're wrong here. Remote itself does unlock advantages that aren't accessible to colocated companies (e.g. hiring anywhere), but one of the primary things that remote-practices unlock are surrounding communication.
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.
I've only been a free user on GitHub, but I've also been impressed with their support. I once had a question about how they handle a very particular situation with forking workflows and private groups.
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.
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.
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.
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 think this error is caused by a mismatch between the monitors capacity to deliver power and your Macbooks desire for it. The HP Envy 27 is rated to deliver 65W, but MBPs want 85W. The MBP will negotiate down to 65W (although the battery may discharge under heavy usage).
I could be wrong though. I've got a similar setup and I've only seen the error once or twice.
I suspect you're right, but I believe (not a user myself) most users consume many fewer joints than cigarettes. I've known many "2 packs a day" tobacco users, but never someone who smokes so much weed. I'd guess that average marijuana users have similar lung issues to 'light' smokers.