Gitlab Handbook's HN Page

https://about.gitlab.com/handbook/marketing/community-relations/developer-evangelism/hacker-news/

by mooreds • 5 years ago

523 191 5 years ago

about.gitlab.com

"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".

john_cogs16• 5 years ago

I’m here.

dreadlordbone3• 5 years ago

H-he's fast!

Honestly the article is business focused but straight laced, seems like pretty good PR for Gitlab.

ethbr04• 5 years ago

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?

gzer02• 5 years ago

Impressive speed, John. And a hello to the Gitlab #hn-mentions slack channel.

howdydoo• 5 years ago

We learned that the key to a post reaching the front page was the content itself.

Well that's good news, at least

yjftsjthsd-h• 5 years ago

I am torn between joy and depression that this is a notable finding. Nice that they noticed and followed the logical conclusion, at least:)

throwthere• 5 years ago

Kind of makes you wonder what they learned was key on other channels.

floober• 5 years ago

Presumably there would be a similar page in the Gitlab Handbook if they had findings

gumby• 5 years ago

They Found Out What Worked On Other Platforms And The Answer Will Astonish You.

radmuzom• 5 years ago

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.

oblio4• 5 years ago

And clickbaiting works for sure: https://news.ycombinator.com/item?id=15845419

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.

john_cogs16• 5 years ago

Your point about timing is a good one (and was also something Dan mentioned in his presentation yesterday) so I created an MR to add it to the page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

danuker2• 5 years ago

Title should be "Gitlab's HN handbook page". It is about managing marketing/advertising on Hacker News.

geofft2• 5 years ago

It's part of the broader GitLab handbook, which is interesting reading, e.g., https://about.gitlab.com/company/culture/all-remote/guide/

0xbadcafebee• 5 years ago

I love the handbook. So much. I want to work there because of the handbook.

gzer02• 5 years ago

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).

bromuro• 5 years ago

Is what I am reading a guide for using HN as ad platform? I feel cheated.

geofft2• 5 years ago

You expected news dot most-famous-company-whose-business-is-starting-other-companies dot com to not be an ad platform?

ethbr04• 5 years ago

Someone should add a link to id=30003221 on that page, just to complete the ouroboros.

john_cogs16• 5 years ago

On it: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

sytse6• 5 years ago

Set to merge.

sillysaurusx4• 5 years ago

Heyyy, HN rolled over to 30 mil. Neat.

romanhn2• 5 years ago

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.

gandalfgreybeer• 5 years ago

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)

mooreds7• 5 years ago

Lobsters is a good one. (You need an invite.)

And I'm a member of some slacks that are just killer in terms of content and discussion.

Too bad about the memory hole.

colechristensen• 5 years ago

Nothing wrong with posting your stuff on your own feed/group/list, but it is good practice to not spam external ones or to do so only rarely.

KennyBlanken• 5 years ago

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.

Gigachad5• 5 years ago

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.

oblio4• 5 years ago

Yeah, but the takeaway is that "coordinated responses" are the norm for even a relatively small tech company.

They have 1500 employees around the world, how is Gitlab a small company? :-))

kirso• 5 years ago

I wish all marketers in the world can read this...

mooreds7• 5 years ago

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).

0: https://www.nytimes.com/2021/02/17/technology/corey-quinn-am...

1: https://news.ycombinator.com/submitted?id=mooreds

VeninVidiaVicii• 5 years ago

This is so meta, I'm having trouble wrapping my head around it

romanhn2• 5 years ago

The funniest part is how quickly this got upvoted to the top. HN sure loves meta! (Not to be confused with Meta ;)

ethbr04• 5 years ago

We're kind of experts at technological navel gazing.

dang2• 5 years ago

Meta is the crack of internet forums.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

john_cogs16• 5 years ago

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.

neom3• 5 years ago

Not GitLab CEO here.

john_cogs16• 5 years ago

Definitely not.

mooreds7• 5 years ago

Hi John! I thought it was great content and shows the (typical) thoughtfulness and systems approach of GitLab. Hope others find it interesting.

pvg2• 5 years ago

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?

john_cogs16• 5 years ago

Good point. MR to add the offical HN links: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

dgellow• 5 years ago

What does DevRel mean? I’ve never seen this term.

Arnavion• 5 years ago

Developer Relations.

pvg2• 5 years ago

Developer Relations

chrismorgan• 5 years ago

This is particularly amusing given the guideline “Avoid using corporate jargon like 'PeopleOps'.”

pm90• 5 years ago

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.

polote• 5 years ago

Gitlab is b2b enterprise and Github is b2c + b2b smb. Going down market is almost an impossible feat in business. And going up market is super hard.

In both case to be a success you need a complete reoorg or your company. Which makes it unlikely to happen

anthonyjdella2• 5 years ago

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!

john_cogs16• 5 years ago

Thanks for your interest.

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.

We share details on the process in our handbook: https://about.gitlab.com/handbook/hiring/interviewing

ayewo• 4 years ago

In case you are looking to spray and pray by applying to multiple places, I maintain a list of several open devrel roles: https://ayewo.com/exploding-career-opportunities-in-devrel/

wodenokoto• 5 years ago

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?

slimsag2• 5 years ago

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.

https://about.gitlab.com/job-families/marketing/developer-ev...

https://about.gitlab.com/handbook/marketing/community-relati...

every dev tools startup out there does this.

dnsmichi4• 4 years ago

Adding my thoughts to resources shared in https://news.ycombinator.com/item?id=30005358

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 :)

John shared this thread with all team members in Slack, and Chad Wooley joined to answer the question how the handbook is built in https://news.ycombinator.com/item?id=30043995 Another example is Lyle Kozloff helping answer a support related question in https://news.ycombinator.com/item?id=30015461

You will see the Developer Evangelism team engage more often, as it is defined in the responsibilities (https://about.gitlab.com/handbook/marketing/community-relati...). The team currently covers PT, ET, CET timezones. I am located in Germany, CET.

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 :)

floatingatoll• 5 years ago

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.

john_cogs16• 5 years ago

While we regularly discuss this as a team, it was not documented. You are right that it should be so I opened an MR (which also links back to and quotes your comment): https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Thanks for the great feedback.

enriquto2• 5 years ago

I shared the page today at a DevRel meetup

It looks that you don't follow your own advice about avoiding corporate jargon :)

PufPufPuf• 5 years ago

Avoid using corporate jargon like 'PeopleOps'.
DevRel

Oh no, you broke the rules!

oblio4• 5 years ago

Off with his head! :-p

splittingTimes2• 5 years ago

Hi John,

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.

thewoolleyman• 4 years ago

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-...

HTH! -- Chad

Yhippa• 5 years ago

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...

mattl6• 5 years ago

I miss seeing Sid reply “hey GitLab CEO here” tbh.

sytse6• 5 years ago

Hey GitLab CEO here

mattl6• 5 years ago

Hey Sid! Long time! Still in SF?

dreadlordbone3• 5 years ago

What did you have for dinner?

danuker2• 5 years ago

The art of herding cats is a difficult one.

You must let the cats come to you instead of chasing them.

erwincoumans• 5 years ago

Engagement with the Hacker News community. An euphemism for "the next best thing to free ads" :)

mooreds7• 5 years ago

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) :).

mfrw• 5 years ago

I wish more places adopt this culture.

atonse3• 5 years ago

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?

john_cogs16• 5 years ago

Thanks, I’ve shared this feedback with members of our support team.

davidb_• 5 years ago

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.

lkozloff• 5 years ago

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.

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!

atonse3• 5 years ago

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.

carlosdp• 5 years ago

This is very meta

ljm• 5 years ago

We learned that the key to a post reaching the front page was the content itself.

Content is King.

Gigachad5• 5 years ago

Eh, on reddit it seems that the content of the post doesn't matter much at all and that links are simply titles for starting a discussion on site.

denysvitali3• 5 years ago

https://reddit.com/r/me_irl would like to disagree

slater• 5 years ago

Anyone else think this is a bit... icky?

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.

roland35• 5 years ago

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)

rectang• 5 years ago

It would be foolish and self-destructive not to have such guidelines. Like it or not, social media such as HN can be crucial to company success.

Additionally, a lot of the rules on the page make it more likely that contributions to HN by Gitlab team members offer good community value.

salomon812• 5 years ago

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.

pottertheotter• 5 years ago

I initially felt that way but less so as I read.

Also, any large company has procedures for PR. It’s a part of life.

Gigachad5• 5 years ago

It's only weird because it's public. Every other big company has this on their internal wiki

OJFord2• 5 years ago

Same, I especially liked the 'don't submit content, make interesting content that someone else wants to submit' point.

ceocoder• 5 years ago

How is it gaming the system to have clear guidelines that respect community rules and the spirit? Genuine question.

King-Aaron• 5 years ago

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.

reducesuffering2• 5 years ago

Not really because:

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.

rattray• 5 years ago

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…

xbar• 5 years ago

Well said.

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.

lolinder• 5 years ago

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."

drstewart• 5 years ago

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]

[1] https://about.gitlab.com/handbook/total-rewards/compensation...

[2] https://about.gitlab.com/handbook/total-rewards/compensation...

redisman• 5 years ago

Hi #hn-mentions

john_cogs16• 5 years ago

To reach there, your comment must include either "gitlab" or "devops platform".

sillysaurusx4• 5 years ago

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

beachy• 5 years ago

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.

simpss2• 5 years ago

Starting to change though.

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.

[0] https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/5672

[1] https://about.gitlab.com/blog/2021/07/20/improved-billing-an... - "4. operational data"

[2] https://forum.gitlab.com/t/updates-to-de-identifying-service...

[3] https://gitlab.com/gitlab-org/gitlab/-/issues/342078 - "Pseudonymization MVC Rollout Plan"

[4] https://news.ycombinator.com/item?id=28840685 - issue submitted to HN[3] that got deleted/hidden quick.

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.

rossmohax2• 5 years ago

Also prompt departure of their VP of compliance after her concerns about discriminatory practices where dismissed/ignored in the open discussion thread.

oblio4• 5 years ago

It's going to be a slow process, but they'll become a regular company over time.

There's a reason (many? most?) people are jerks. Being a jerk works.

Companies, being groups of people, are also jerks.

bovermyer• 5 years ago

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.

brudgers2• 5 years ago

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.

It’s not likely to make HN better. YMMV

stonegray• 5 years ago

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.

brudgers2• 5 years ago

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.

Taywee• 5 years ago

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.

rhacker2• 5 years ago

Your slack channel must be blowing up.

Starlord2048• 5 years ago

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.

Shadonototra• 5 years ago

That sums up what Hacker News exactly is

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 ;)

dang2• 5 years ago

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.

https://news.ycombinator.com/newsguidelines.html

Havelock• 5 years ago

Plot twist. Posted by a Gitlab employee

trenchgun2• 5 years ago

nah. https://news.ycombinator.com/item?id=30003590

trenchgun2• 5 years ago

https://news.ycombinator.com/item?id=30003807

mooreds7• 5 years ago

Actually, I am not a GitLab employee.

I work for a company called FusionAuth. Check out my profile: https://news.ycombinator.com/user?id=mooreds which includes my LinkedIn: https://www.linkedin.com/in/mooreds/

Cheers!

ChrisArchitect• 5 years ago

Isn't it weird that this internal marketing strategy guidebook is public?

denysvitali3• 5 years ago

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!

rossmohax2• 5 years ago

This explains why some negative Gitlab mentions are taken off from HN front page so quickly.

tpoacher• 5 years ago

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].

Dave3of5• 5 years ago

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.

dubcanada• 5 years ago

You can’t just say it’s not a great place to work without expanding on that with details of some sort.

capableweb7• 5 years ago

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.

capableweb7• 5 years ago

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.

nacs• 5 years ago

The only people who can downvote on HN are people with 500+ karma so I’d imagine such an experienced HN-user already knows that.

capableweb7• 5 years ago

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.

john_cogs16• 5 years ago

Thanks for the suggestion. I created an MR to add a slightly edited version to the "Best Practices" section of the page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

sillysaurusx4• 5 years ago

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.

sciurus• 5 years ago

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.

AitchEmArsey• 5 years ago

You're so meta, even this acronym.

Gitlab Handbook's HN Page

Related Stories