I remember being very surprised when I was signed up to their mailing list after I made an account on my self-hosted instance, and I'm not sure about the ethics (and legality) of collecting these in the first place.
At least that was my experience.
When people sign up, their email is shared with our customer experience team (combo of inbound sales reps, customer engineers, and support depending on what information is shared), and then that assigned individual reaches out manually AND puts you into what is a called a 'nurture' campaign that provides helpful information, updates on Cody, etc. Those are automated unless you specifically request to talk with someone. If / when someone wants to talk to Sourcegraph, a member of our GTM team (sales / customer engineering) reaches out.
If you can provide me with your email (DM it) I can look into what happened with you and get you the help / support you need.
Otherwise, I think someone on our end just dropped the ball. Sorry about that! It happens when there is a human in the process and it isn't 100% automated. To your larger point, we agree that having a real human to interact with is important to a great experience.
Please let us know how we can help you try and use Cody!
Agree; either use facts (days, hours, etc) or nothing, but no vague adjectives.
Our regular reminder to try keep credentials and other security tokens well away from any source code where-ever possible, even if that might mean making things a touch less convenient.
I'd guess that most of us have checked in or otherwise posted a credential at some point in our careers. I've certainly done it in the past with an application DB connection string and had to do the quick reconfigure to revoke that access¹ – in that instance resolution was quick & easy but for other environments it might be a lot more admin.
Being careful isn't the solution because mistakes will always happen, making it damn near impossible to accidentally post credentials is the way to go.
--
[1] even though the repo checked into could only be accessed from within the company, and the DB instance in question was locked down so only the application servers and the limited few with access to a VPN connecting to its subnet, good practise dictated immediate full revocation just in case
I don't buy that, it always seems to me like an attempt to downplay something.