This culture of radical openness must be quite refreshing for people inside the company.
A lot of companies would never want this sort of thing to be out in the open. But really, why not? I imagine it helps to keep things sensible if you know that a thousand eyes could be trawling over your employee policies. You're certainly not going to be promoting astroturfing or other undesirable activities.
At the same time, you aren't burdened with deciding what to share. Many (most?) companies tie themselves in knots trying to decide what to share, and end up sharing nothing.
Sharing everything means less time spent deciding what to share and more time developing the stuff in the first place.
Personalized analytics and tracking roll-out (including on-prem) was pulled back ~2 years ago[0], they're on another try[1] currently with a heavy-handed hiding approach. Including small additions to release notes[1], short lived and hard to find feedback threads[2] etc...
Including deleting/hiding tickets that get posted on HN[3][4] and contain plans/info that users might take negatively/provide negative feedback on.
PS: full disclosure, I've been an active opponent of these changes, as they are illegal in the EU and make it impossible to self-host the service while protecting our users privacy.
yeah, it's going to happen and someone else will come and win everyone over by acting nicely.
It's a cycle and I can confidently say, working in a company that has used the same approach to win customers over, it's really hard to keep the honest culture going.
> There's a reason (many? most?) people are jerks. Being a jerk works.
Yes, but I would argue that it only takes a few sociopaths to ruin an entire community, by exploiting trust, and doing other things that most other people wouldn't dream of doing.
You're not wrong. That doesn't mean it's going to change, however.
Might I recommend perusing "Meditations on Moloch"? It will both depress you (since you seem like a decent person) and give you a framework for why and how these things happen.
Also prompt departure of their VP of compliance after her concerns about discriminatory practices where dismissed/ignored in the open discussion thread.
Hey there, I’m a member of the GitLab Community Relations team. My team is responsible for this page. I shared the page today at a DevRel meetup where OP was presenting on Hacker News. I’m grateful he chose to share it with all of you. Thanks, Dan.
If there are ways we can improve how we engage with the HN community, myself and our team would love your feedback.
Hi, I think either I missed something or I see an insight that may not be in there yet, not sure if. In brief:
“Conveying without convincing.”
I think this guide is generally applicable to everyone interacting on HN, not just GitLab PRops, and while considering that I uncovered something I think would improve the value the guidelines.
Lots of online conversations get mired in back-and-forth persuasion, where each side is trying to convince the other of their viewpoint rather than just trying to convey it. This is essentially an impossible conversation to walk away from satisfied, because it’s rare that anyone can be convinced.
So, instead, focus on conveying. Ensure the facts are made clear and point out disagreements. Share your motivations and reasoning. Ask people to clarify when they say something you don’t understand, or could parse multiple ways. Leave disagreement alone, and don’t press it to change into agreement.
This is the toughest thing for anyone to do in conversation (“someone is wrong in the internet” xkcd here), but it’s absolutely the most essential skill and I don’t see it clearly called out. (Maybe I missed it though, it’s late!)
So, I would love to see that concept applied in guideline form. Teaching people to ensure comprehension rather than convincing, and to move on if it isn’t getting through, is the ultimate win in online chat, and I encourage adding it the the guide.
One thing that looked a little odd is the doc asks potential contributors to familiarize themselves with a fairly convoluted guide to 'unofficial' HN features but doesn't mention or link HN's own guidelines and FAQ. But maybe it's targeted at people who've read them?
Is it Gitlabs goal to overthrow GitHub as the most popular code repository tool? Or are you catering to a specific/specialized section of the market?
I haven’t used Gitlab, but since this is HN I’ll throw an advice your way anyway: I would LOVE to see a really good code review tool. GitHub has made improvements, but I love reviewable and want at least one of GitHub/Gitlab to have a really amazing code review experience. Things like being able to organize discussions, encouraging better code review etiquette (somehow)… just make it possible for developers to review code.
Devrel and evangelist is that a full time job or is it something a developer gets time off to do?
I think we’re I’m going is, when we see “Hi it’s Jon/Jane from gitlab …” is it a developer taking time out of their day to respond or is it a full time marketing person?
Yep they're full-time marketing people, not random devs taking time out of their day to respond.
Very rarely do devs at these companies feel comfortable enough to respond directly, I think, that's natural because most people aren't comfortable representing the company they work for. Usually when you see that happen, it's some coordinate effort internally to get a dev from some team to respond.
> I think we’re I’m going is, when we see “Hi it’s Jon/Jane from gitlab …” is it a developer taking time out of their day to respond or is it a full time marketing person?
When you see someone writing "Hi, Michael from GitLab here" it is not always a Developer Evangelist or a Community Relations team member. Everyone at GitLab can join the conversation here on Hacker News :)
> Devrel and evangelist is that a full time job or is it something a developer gets time off to do?
Developer Evangelists at GitLab have an engineering background, everyone has their own experience and preferences though. For example, I feel much more confident in C/C++, Go and Python, and want to learn Ruby on Rails, and Rust.
Potentially there's room to go more into detail in the team members overview: https://about.gitlab.com/handbook/marketing/community-relati... - all team member profiles are linked, where more social profiles are available. I'm using 'dnsmichi' nearly everywhere, keeping things simple.
Speaking for myself:
I was a maintainer of an OSS monitoring tool from 2009-2020, and love diving into backend engineering and Ops topics. At some point, I was doing development, community building, support, social media and marketing. And a bit of Developer Relations with speaking at events. This did not work out so well in 2019 in my previous job doing all of that, where other companies have different teams and multiple people for.
Then I saw the Developer Evangelist role at GitLab later in November 2019 in a tweet from Sid (https://poly.work/h/11Rk7Jqw), and toyed with a full time job, switching gears from full-time development to full-time developer relations / advocacy / evangelism. Friends had gone on their adventure too, Philipp Krenn from Elastic has been a great role model.
I made ambitious plans and took many notes in https://gitlab.com/dnsmichi/tech-evangelism preparing for my role, and got an offer to join GitLab in March 2020. It's been an exciting, wild ride in the past ~2 years. Not everything went well - I learned a lot from a comparison blog post discussed here on HN, and keep reflecting on how we can create better helpful content for everyone to benefit. Details in https://www.polywork.com/dnsmichi/highlights/a6f10cbf-515d-4...
I'm doing many things, sometimes too many, requiring me to refine scope and focus on the important topics. For example, 2022 will be a strong theme for Observability and OpenTelemetry, app instrumentation for developers and CI/CD Observability. I've started activities with launching a new community learning website on https://o11y.love/ and feature implementation ideas for CI/CD Observability in https://gitlab.com/gitlab-org/gitlab/-/issues/338943
A general problem in Developer Relations can be the feeling of not being successful, sometimes also called "imposter syndrome". I never thought that it could reach me, though I am reflecting on how to avoid these situations and keep writing my own "diary" / "log" in a timeline what I do. There are often small highlights which can make your day :) I have shared thoughts about it in a blog post which also dives more into Developer Relations activities: https://dnsmichi.at/2022/01/20/how-polywork-helps-devrel/
Hope this insight into my story and motivation helps :)
I think it's only you and Mr. Prince left from the IPO'd devtools crew, you're the only two I see still kicking around occasionally. But hey, big job so thanks for stopping by. Enjoy your dinner.
Oh yeah, I forgot about Mitch, although I don't see him around that much, sytse and eastdakota I see quite frequently. Also apparently Jeff Lawson is still active(ish)! https://news.ycombinator.com/threads?id=jeffiel
Will be interesting to see if, once stripe goes public Patrick sticks around.
A bit off topic, but if I would like to introduce such a handbook on my team as well, what technology does it use? It looks and feels so much fresher, clean and responsive than a simple wiki. I see it is markdown files with some CSS, but what engine do you use to build and render the handbook.
Is there a repo that holds the template to set up such a handbook?
Cheers and congrats. Always admired how you kept all your employees engaged with the handbook to not have it deteriorate, but thrive.
TL;DR: It is a JAMStack-style static site, which we publish with the Middleman static site editor.
However, there's a lot more to it than that, and it's always actively evolving.
There's not currently a page which summarizes the architecture, but there are multiple pages and docs which are focused on processes around editing and maintaining the site. Here is a link which is a good starting point to see what's under the covers and how we use it: https://about.gitlab.com/handbook/git-page-update/#11-start-...
Hey John, I'm interested in DevRel and Evangelism on your team. I've read some of your documentation and enjoyed what I've read. I'm a dev of 5 years and I'd like to apply to your team. Could you give me some pointers and tips about the interviews? Thanks!
Given we are so transparent, it seems that most folks who conduct interviews at GitLab expect candidates to have done a fair bit of research in advance of the interviews. So if you're looking to join the Developer Evangelism team, brushing up on our handbook and familiarizing yourself with what we do would be a good idea. That will allow you to come to the interview prepared to frame your experience and abilities through the lens of how we work and the results we aim to deliver to GitLab and our community.
Sharing my personal experience, not speaking for GitLab here:
One thing I did when I was excited about the Developer Evangelist role: I started writing a document in the open, collecting thoughts what I learned, what I want to do, and which ideas could help this drive forward. Markdown, Web IDE, Git commits. Don't check the commit times, they might be at 3am in the morning from an iPad :-)
It was too ambitious, and strategies changed. Still, it allowed me create a single source of truth and define a path forward, preparing for coffee chats and later interviews. I like to come back occasionally for ideas on new content :)
> Never submit GitLab content to Hacker News. Submission gets more credibility if a non-GitLab Hacker News community member posts it, we should focus on making our posts interesting instead of on submitting it.
I appreciate this policy, it makes it clear that HN is a place to engage with the community, rather than a free advertising channel. Looking at the CEO's profile, the last time he made a submission about Gitlab was in 2018, so I'd say the policy appears to be followed.
In my ideal world, most content sharing and even social media sites should be like this. Good content driving interest instead of gaming the algorithm to get clicks and views would lead to a better ecosystem of information with less noise.
Although I doubt we’ll ever reach that point so I’m wondering if there are other small communities around the web that are just more quality-oriented on the content shared (I just go to niche subreddits and mostly HN)
You should consider moving that slack to discord. Discord has unlimited server history for free with pretty good search. The only features you lose compared to slack are ones that are largely only useful for organisations.
> Discord has unlimited server history for free with pretty good search.
Until they pull a Google and either make it not-free, or drop it altogether. It is difficult to have any faith in the long-term prospects of all these services that depend mostly or only on the goodwill of a company.
this is a nonsense argument. you can moderate and restrict your discord channel to enforce whatever culture you want. if you don't want bad culture infesting your channel then don't let it happen. i would still suggest people use matrix over discord, but it has nothing to do with gamer culture.
Discord has a centralized profile system built around gamer culture and the idea of using a “handle” that is rightly disconnected from your identity. It has so many features designed around gaming.
> Discord has a centralized profile system built around gamer culture and the idea of using a “handle” that is rightly disconnected from your identity.
You make it sound like this is a bad thing?
Letting people use handles has been a thing since way before modern gamer and it is probably the only right way if you want interesting people to share stuff.
Some (most?) of the most civil places that exist on the internet - including HN - has pseudonymity.
The only people who thrive with mandatory Real Names policies are:
- people who operate under a false but real looking name anyway (trolls etc)
- people who are squeaking clean by todays standards (and even not all of them because what about tomorrow or next week or next year?)
- people who have nothing to lose anyway or don't realize the problem of Full Name Policies.
> Letting people use handles has been a thing since way before modern gamer and it is probably the only right way if you want interesting people to share stuff.
The issue is being unable to have, under a single login, completely isolated identities for each server (or group of servers).
> It works really nice for non gaming too.
IMHO the Discord branding (specifically the copy) works great for a gaming audience but is slightly off-putting for a non-geeky audience (think non-tech business types).
I'd like to mention though that one model I really liked was what the one that Google landed on with Google+: a central identity only known to one entity and then as many pseudonyms as you want that you can switch between but that can only be traced back by the provider, and where they promise not to do it except for good reasons.
Of course these days we know that such promises need to be backed by laws to really be effective, but what a nice idea - as long as the identity provider can be trusted!
Also, when I think of it Telegram has something very close to this if someone wants to test what it feels like. And just like Google+ it is not totally obvious: you first have to create a channel, then you can reply to other groups as that channel. Maybe you must activate something in your channel settings too.
Yeah, but the takeaway is that "coordinated responses" are the norm for even a relatively small tech company and we basically can't count on any genuine social media discussions about large companies. Disclaimer: I'm not saying you-know-who does or doesn't do any of this (though other pages on their wiki do describe some of what I talk about. You can read it for yourself.) At best what looks organic isn't remotely close.
"Coordinated response" is PR-speak for a company's PR team at best controlling the "message" and who delivers it, instead of half a dozen employees chiming in with "inconsistent messaging". Somewhere in-between: immediately calling/DMing certain employees known to toe the company line / have a good reputation publicly, and who are in a relevant department.
It's severely disingenuous, particularly since people interpret the quick appearance as the employee being active in the community, and never will you hear the employee say "well, actually, our PR team rang my phone off the nightstand and said "shmeddit is discussing _______, please immediately get on Slack to provide a response using talking points to some comments that are coming up."
At worst, it's also a company mobilizing, if necessary, a vendor who supplies an army of users (real or fake) on the platform to comment, upvote, downvote, flag, etc. They even have prearranged topics to boost/suppress, canned talking points, etc.
I think the most visible evidence of this is a certain electric car company, which routinely abuses the DMCA takedown process to suppress videos that are unflattering. Google their name and "dmca video" and you can read all about it.
The same technique has been used by a certain rich playboy who sucker-punched a restaurant worker while someone was recording him without him realizing it, and the video made it onto reddit. The video kept getting either removed by moderators or DMCA'd.
A large number of VHNWI's/UHNWIs have standing contracts with reputation management firms for exactly that sort of action.
Yes, almost every company has automated alerts for mentions about them on any platform. It can be a great thing and it can be abused. A great way for a company to handle social media is to clarify confusion and to answer questions but not raid every thread with defensive or astro turf content.
Often people post online about their complaints about how a product or service doesn't do x when it does but they haven't found it or its newly added. When the PR team can drop in and give a quick update its quite useful.
How do notifications for services like HN get triggered? Or YouTube/Tiktok/Twitch? More than half of online communication is video and less than 10% is "public" in the sense of tweets and reddit comments. (napkin math estimate)
I don't think anyone in marketing and PR believes social listening companies actually catch even a significant minority of mentions. The things you get an API or a scrapeable feed out of are drop in the ocean.
> How do notifications for services like HN get triggered?
Easy, the API allows you to see all the latest X comments/submissions. Setup something to just text-match your name and hit whatever notification endpoint when matching. I think there are services for this that includes HN already too.
> Or YouTube/Tiktok/Twitch?
YouTube often offers captions for videos, otherwise it's not too hard to generate yourself. Apply same strategy as for HN but for YouTube/TikTok/Twitch. If it has sound, you can usually automatically transcribe it.
This also goes for TV shows like news and whatever. There are services that are transcribing every single news show and scrapes the transcriptions for mentions of brands/companies and whatever. You can use those services to see when your brand gets mentioned, and some services even send you a five-minute snippet of when you were mentioned. I'm sure the same exists for basically every single multimedia medium out there.
Neither an API nor a scrapeable feed is required for you to get a scrapeable feed from it in the end :)
This works great in theory and as one off research projects (source: I've done this). The tricky thing is, can you namedrop any such services that actually work and offer a SaaS model?
I've heard dozens of pitches for such products, but they all end up being either
1) unable to grow due to legal reasons (transcripts are derivative works and thus even creating them, let alone publishing them, is restricted under copyright)
2) pivot to become Yet Another Social Listening Tool with a high-touch sales-heavy SaaS business model. They end up negotiating a deal for direct access to the firehouse feeds with the social media companies themselves, with all the strings attached (completely public content only, sometimes restricted to accounts of certain size, etc).
There are services constantly scraping all public social medias and you pay them some small fee and they let you subscribe to keywords. Of course they might miss some video content but it isn't terribly significant.
You're right, the text does mention Zapier, but what triggers Zapier? Zapier is glue that ties various services together. The web scraper and keyword detection is either a different service or in-house.
I was thinking about this policy "Never submit GitLab content to Hacker News."
It makes sense on one level; of course a submission has more credibility if someone else feels like the content is compelling enough to share.
But that's a bit like saying "get interviewed by the New York Times (or the Wall St Journal, your daily paper, etc) because that interview is going to have a lot of credibility". Sure, it's nice if you can do it, but most of us won't ever get interviewed (unless you're Corey Quinn[0]).
On another level, the ability to self-promote (a little bit) makes HN better, because it gives everyone a reason to submit and increases the volume and depth of content.
I unapologetically post content from my personal blogs and my employer that I think is valuable (you can see my submission history, of course [1]). I limit it to ~10% of my submissions. I also spend time submitting what I think are high value links and adding comments when I feel I have something to add. I won't say all my submissions have been perfect and I've definitely gotten feedback from the community over the years about some garbage submissions, but I've learned what kind of submissions spark interest and/or commentary.
In other words, I'm acting like a community member, rather than someone who dumps links for traffic and runs.
Of course I'd rather have someone else stumble on my sites/links and post them, but either my content isn't compelling enough (in which case the voting system will weed it out) or it isn't being discovered by people who want to share it (which is the problem allowing self-posting addresses).
Well their observation is completely wrong. Timing is the most important factor which matters. I have seen thousands of extremely good non-political, neutral, tech related articles not getting a single upvote if it is submitted at times most of US/Western Europe is sleeping.
I initially named the post "Mercurial being rewritten in Rust" and that's how it made it to the front page, if I recall correctly, close to the first spot, even.
As soon as mods renamed it, it dropped like a rock.
"When someone posts a Hacker News thread link, monitor that thread manually. Don't wait for the notifications in the #hn-mentions channel, because sometimes they're delayed by a few hours."
See ya in a couple hours "Manager, Developer Evangelism".
I agree. I suppose that’s a positive side effect of conducting business so openly. You’ll feel extra responsibility to set policies that are sensible not only internally but also to the general public.
> If a notification that a release post has reached the Hacker News Front Page is posted to the #developer-evangelism Slack channel by the "Hacker News Front Page" bot, a Developer Evangelism team member should quickly repost the message to the #product and #release-post channels to alert our Product Managers.
Why doesn't someone just update the bot to post in those channels as well?
Many of the posts that reach the front page are simply posts that contain GitLab in the URL (ex: a link to an issue from an open source project hosted on GitLab). Others are only relevant to specific teams. My team handles directing the posts to the right folks to avoid unnecessary distractions from “false positives”.
Not trying to belabor the point, and I'm sure there are nuances (especially with blog posts), but releases seem (a) likely to continue forever & (b) to use well-formed URLs.
What I feel is missing here is upvote/downvote etiquette, but I fear that's on purpose. Often times it feels like criticism of Gitlab gets downvoted easily in the comments of various Gitlab submissions, even if it's valid. Since it's now clear it's an official stance for Gitlab employees to lurk and comment on HN submissions, maybe including something like "Don't upvote/downvote comments based on if you agree personally or not with something, but based on if they are thoughtful and substantive, since HN is about curious conversations" or similar.
> Don't upvote/downvote comments based on whether you agree with them personally or whether or not they are critical of GitLab. Instead vote based on if they are thoughtful and substantive, since HN is about curious conversations.
This is an incorrect view of HN. The last bit is true, but it's fine on HN to upvote or downvote based on whether you agree with it personally. This was established by pg himself many years ago.
I don't think that controlling your employees' upvote or downvote rights is a good idea. You may want to add an advisory that downvoting a comment about GitLab could be unproductive, but anything beyond that feels micromanage-y.
I agree it's an incorrect view of HN, in general, for the general HN user. The people who come from Gitlab to HN just to reply in Gitlab-related subjects I feel like are not the general HN user. I figure most of us are here because we're curious individuals, that's why we like HN and that's why we're here. The Gitlab employees coming here to get involved in the threads with a Gitlab-HN-manual behind them are not the same (but just as valuable as the rest of us, obviously). Hence my wording around "not upvote/downvote based on personal preference", as that would hopefully correct their impulse of downvoting anything critical of Gitlab, and automatically upvoting anything that paints Gitlab in a good light. Just to help them steer their comments and threads to not become one-sided.
Same here! I wouldn't even work at a company that has a handbook page about how to act on HN, but then most companies are too big for me nowadays anyways.
I wish karma represented how experienced someone is with HN. I know users (AFK) who only interact with HN submissions if it's about their company, and they've raked up 5000+ karma with just answering stuff in those threads. That doesn't mean these users know anything about HN etiquette outside of that.
Since it is a common usenet/forum/flame warrior method, I have a strong opinion about:
Address multi-faceted comments by breaking them down and using points, numbering and quoting.
Except when the facets are purely technical, this approach trends toward full defensive point by point rebuttal.
Once the points counting starts, the logic of points-counting becomes part of the public performance.
In general, people don’t like to have their comments picked apart in public because it doesn’t solve their problem. And because it is an aggressive response to what is usually just wanting to have ones say.
It is a tactic better suited to the context of private communications and with the appearance of having given the matter a few hours thoughts. Otherwise it tends to “broaden the front” when done in public performance.
I do like that it provides certain guarantees that the post was read fully, and that each question/issue was addressed and not missed, sort of like a Shisa Kanko (Point and Call) for online replies.
Copying and pasting and adding numbers is violent editorial surgery and allows the respondent to cherry pick quotes and remove them from context.
In a public discussion, it provides a public performance that might lead spectators to imagine the respondent read everything.
As a general form, it implies that the first comment wasn't very clear and/or it's thinking not well organized...while of course showing that the response is well structured thought.
On the other hand, all stakeholders consent to Shisa Kanko in the context where it is used, and the communication channel is strongly bounded. The channel excludes opinions, expressions of deep feeling, and open ended questions. There's no circumspection.
I think it's quite situational, but I quite agree. I also find that when you do this and get into a conversation with somebody who does this, the back-and-forth also just bloats up and gets bigger and more multi-faceted as the conversation progresses.
I find that it's much better to just address the general argument and maybe the very major points specifically if necessary. I think bad-faith arguments on the internet have made a lot of people really defensive and aggressive, though. I've seen a lot of people smugly arguing past each other about how they aren't discussing things properly ("you didn't even address all of my points"), and the discussion always devolves to just arguing about arguing.
I applied to GitLab and got declined during the initial phone screen. Stuff like this and other parts of their guides are the big reason this place appealed to me in addition to loving the product itself. Sigh...one day...
For some reason, I find it much easier to remember to visit Cloudflare blogs, solely due to the fact the URL is blog.cloudflare.com and most of the good content is located there.
It might be worthwhile for the Gitlab community team to consider changing https://about.gitlab.com/blog/ to something not tucked away on the about subdomain.
I also realize I might be in the minority of users typing out URLs (no use of bookmarks).
GitLab's been good for our company, having it all under one roof has been nice.
But recently I've had (and continue to have... still not resolved) a pretty unpleasant experience with their support software. It just seems like the typical comedy of errors where a series of software integration papercuts between them and Zendesk adds up to a really bad experience, made much worse by the fact that our issue hasn't been fixed which is making us more stressed.
I am a member of multiple Gitlab groups and owner of one. I am simply not able to log in to the support portal to leave a ticket. Then I replied to a zendesk ticket and then somehow I get this message about support entitlement. I mean why not just speak in English? Why use terms like "Support Entitlement" – just say, which org/group are you with? Or just look me up in your database. An email address is unique. So that's confusing.
This roundabout has caused us to spend days and days just to reactivate an account that was locked out due to 2fa (not Gitlab's fault). We haven't even gotten to actually solving the problem. We're stuck on basically "I don't know who you are from your email address so you need to tell me who you are" even though I'm using the owner email address for that account.
I'm sure Gitlab's support TEAM must be great, but it fails spectacularly due to what seems to be flawed Zendesk <-> Gitlab integration itself. Please fix this guys, I know you're on top of everything else. It just feels like a forgotten set of tools.
Why can't I just SSO using my GitLab credentials into Zendesk?
Not directly relevant, but I've had all sorts of issues, similar in nature, with other companies that use Zendesk and integrations with Zendesk. It seems surprisingly bad given its popularity.
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.
Thank you for your really detailed and thoughtful response (not surprising coming from your company). Someone did reach out to me and this might get resolved after all this got escalated.
I'll keep an eye on these issues and will reach out at some point. The support entitlement stuff is more about just using plain English language. Most users don't know what that means. I'm the owner of the org and I barely know what that means.
> Never submit GitLab content to Hacker News. Submission gets more credibility if a non-GitLab Hacker News community member posts it, we should focus on making our posts interesting instead of on submitting it.
I can think of a couple of projects that I wish they'd followed this policy.
Every time there's a post about [REDACTED], I check the submitter's history, and 9 times out of 10 their history consists exclusively of promotional posts for [REDACTED].
The Social Media Guidelines part of this really resonates with me. Whoever wrote it is trying to improve the quality of discourse and not just generate traffic to their service.
This is remarkably different from how a previous employer of mine treated HN. When we were on the front page, the most frequent internal response was to quote from https://digital.library.unt.edu/ark:/67531/metadc1279277/ to encourage people to stay away.
So as john_cogs mentioned above, I did a presentation on the best way to engage with HN today. The benefits I listed included:
* traffic (which is nice, but not super sticky)
* the comments (which I've found to be insightful and useful in showing both flaws in my arguments as well as additional areas for research/writing)
* the follow-on traffic, as people share it in newsletters, slacks, facebook groups, twitter, etc, etc
The best way to engage with the HN community? To be part of the community (comment, share interesting things that are not your own, etc) :).
A community used to drive interest in marketing ops/acquisition/IPOs up
People at HN know that very well, in fact, very often, the companies that get to front page are somewhat related to HN, very often they are investors ;)
That's not what Hacker News is. If it were, it wouldn't be interesting. If it weren't interesting, it wouldn't have a valuable community. If it didn't have a valuable community, people wouldn't be using it to try to get attention for their companies in the first place.
I am loving this tool. This is a great example how we can automate information flow between technical communities and foster faster response and technology iteration.
If you have to game the "system", sorry, I mean, provide "social media guidelines" to this extent, maaaaybe your [whatever you're trying to push/advertise/spread] isn't all that worthwhile...? Especially in the "nerd" world, it seems word of mouth will get out without having to rely on such inane strategizing.
I understand that this is just the tip of the iceberg, and other companies/orgs likely have similar strategy pages, but it all seems a bit, i dunno, anti-HN to me.
Imagine yourself as an excited, enthusiastic young engineer working at a relatively big company. A blog post relevant to the product you work on comes up - what do you do? Should you post to HN? If it comes up there, should you engage enthusiastically? What's appropriate?
Having guidelines can help with this kind of thing. Of course, guidelines that advised a lot of astroturfing or disingenuous engagement would be pretty icky indeed…
It is so easy for an entire company to come off as "tone deaf" in a public forum due to avoidable errors.
Smart people deserve to be allowed to speak in places like HN. GitLab has gotten it pretty darn right in creating a some guidance for such people, AND by making the guidance public.
This document looks less like guidance for gaming a system and more like instructions for being respectful to an influential community, but that's just my read.
It may seem icky but I think once a company hits a certain size it is important to define some basic rules for external communication of any type, otherwise it becomes a garbled mess.
Overall the policies seem pretty common sense and hands off which is good! Hopefully this community is robust against astroturfing (something I'm worrying about with Reddit)
Absolutely. True story: I was at a small startup and our company organically made it to Hacker New's front page. I was so excited. At that point, I was only a reader. I made an account, upvoted it, told our social media manager. Next thing I knew, it fell off the front page and we suspected I or the manager accidentally set off the fake vote detector. We had no idea such a thing even existed. The CEO was so disappointed in us. We learned the hard way.
Edit: to be clear, I wasn't trying to game the system. I was just so excited that the product I'd been working on appeared on a site I often read. Only in retrospect did it occur to me why one would have anti-vote ring detectors. Yes, I was naive.
Par for the course for Gitlab, like how they claim they don't adjust compensation based on cost of living[1] before describing in detail why they adjust compensation based on cost of living[2]
On the contrary, I think it's refreshing to see a company have policies that are appropriate and understanding of the community they want to be a part of.
1. Other companies probably have similar strategies but it's behind closed doors to act however nefarious they would like, not open docs that can be criticized here publicly like Gitlab has.
2. The MO (modus operandi) here seems entirely about reading customer feedback and engaging with it. That's like YC startup advice numero uno. They explicitly mention not to submit content or get people to upvote.
I'd summarize most of their guidelines here as: "Don't try to game the system, it doesn't work on HN. Honest engagement and thoughtful replies win out."
For Gitlab, it is not. They're incredibly transparent.
I hope other companies will follow the sane trend, but realistically this will probably never happen.
In any case, Gitlab's strategy is IMHO a winning one. It's literally embracing the Open Source culture, where you get contributions from people outside your company and help back the community. Good job Gitlab!
Hi GitLab #hn-mentions, Vsauce Michael here. Did you know that HN’s voting detector works partly by checking whether the upvote is done on the /newest page? cue Vsauce music
Gitlab really trying their hardest to seem like a "nice" company here.
The software is OK (the cloud offering is unstable compared to similar offerings). The company though is another thing altogether not a great place to work. This is a pure PR post which is being used to show them in a better light.
> The company though is another thing altogether not a great place to work
I have no affiliation with Gitlab besides I've tried their self-hosted option years ago. But comments like this without any substance behind it leave a sour taste in my mouth. "why is it not a great place to work at?" and "how do you know this?" are the first two questions that come to mind that are the bare minimum that should be added, otherwise your comment is just borderline gossiping.
A lot of companies would never want this sort of thing to be out in the open. But really, why not? I imagine it helps to keep things sensible if you know that a thousand eyes could be trawling over your employee policies. You're certainly not going to be promoting astroturfing or other undesirable activities.
At the same time, you aren't burdened with deciding what to share. Many (most?) companies tie themselves in knots trying to decide what to share, and end up sharing nothing.
Sharing everything means less time spent deciding what to share and more time developing the stuff in the first place.