Plot twist. Posted by a Gitlab employee
nah. https://news.ycombinator.com/item?id=30003590
Gitlab Handbook's HN Page
131–140 of 200 posts
Re: Gitlab Handbook's HN Page
#132Hey 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.
Re: Gitlab Handbook's HN Page
#133Hey 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.
> I shared the page today at a DevRel meetup
It looks that you don't follow your own advice about avoiding corporate jargon :)
Re: Gitlab Handbook's HN Page
#134Hey 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.
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 experien…
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
Re: Gitlab Handbook's HN Page
#135Earlier quoted context omitted.
> 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…
> 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 i…
> IMHO the Discord branding (...) is slightly off-putting for a non-geeky audience (think non-tech business types).
I strongly dislike Discord because it is a proprietary platform. But the off-putting of "business types" sounds like a great feature!
Re: Gitlab Handbook's HN Page
#136Earlier quoted context omitted.
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 cl…
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 fou…
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.
Or maybe such services are out of my budget?
Re: Gitlab Handbook's HN Page
#137This 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, yo…
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.
Re: Gitlab Handbook's HN Page
#138Hey 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.
> Avoid using corporate jargon like 'PeopleOps'.
> DevRel
Oh no, you broke the rules!
Re: Gitlab Handbook's HN Page
#139This explains why some negative Gitlab mentions are taken off from HN front page so quickly.
Re: Gitlab Handbook's HN Page
#140> 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].