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.
Gitlab Handbook's HN Page
171–180 of 200 posts
Re: Gitlab Handbook's HN Page
#172You're so meta, even this acronym.
Re: Gitlab Handbook's HN Page
#173Hey 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.
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!
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
Re: Gitlab Handbook's HN Page
#174Earlier quoted context omitted.
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/p…
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.
> 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.
Re: Gitlab Handbook's HN Page
#175Plot twist. Posted by a Gitlab employee
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!
Re: Gitlab Handbook's HN Page
#176Earlier quoted context omitted.
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.
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. (If you do move it to discord, invite pls :P)
Hahah, thanks! They aren't my slacks to move, I'm just a member. I'd love to move them, but I'd probably suggest a forum rather than a discord.
I actually wrote a piece: https://www.mooreds.com/wordpress/archives/3451 ( discussed on HN here: https://news.ycombinator.com/item?id=29154216 ) about the advantages/disadvantages of various chat/discussion software options.
Re: Gitlab Handbook's HN Page
#177Earlier quoted context omitted.
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.
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 disappoin…
Heh, we've all done it. Takes some time to acclimate to a community and learn the norms.
Re: Gitlab Handbook's HN Page
#178Hey 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 sid…
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.
Re: Gitlab Handbook's HN Page
#179> 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 Gitla…
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...
Re: Gitlab Handbook's HN Page
#180What 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 persona…
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...
> 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.