Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab Handbook's HN Page

about.gitlab.com

Post reply on HN
Print view View original

181–190 of 200 posts

Re: Gitlab Handbook's HN Page

#181

Post by falcolas »

TheRealDunkirk wrote: post #174
oblio wrote: post #160

Earlier quoted context omitted.

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.

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.

Re: Gitlab Handbook's HN Page

#182

Post by danvillalon »

john_cogs wrote: post #170
radmuzom wrote: post #153

Earlier quoted context omitted.

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.

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

Mind to share if there's a video or something of the presentation? Would love to see it, thanks.

Re: Gitlab Handbook's HN Page

#183

Post by capableweb »

sillysaurusx wrote: post #180
john_cogs wrote: post #169

Earlier quoted context omitted.

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…

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.

Re: Gitlab Handbook's HN Page

#184

Post by sillysaurusx »

capableweb wrote: post #183
sillysaurusx wrote: post #180

Earlier quoted context omitted.

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

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…

It feels micromanage-y. I wouldn't want to work at a company that tried to restrict my HN usage this way.

Re: Gitlab Handbook's HN Page

#185

Post by capableweb »

sillysaurusx wrote: post #184
capableweb wrote: post #183

Earlier quoted context omitted.

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…

It feels micromanage-y. I wouldn't want to work at a company that tried to restrict my HN usage this way.

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.

Re: Gitlab Handbook's HN Page

#186

Post by AlwaysRock »

colechristensen wrote: post #117
gandalfgreybeer wrote: post #59

Earlier quoted context omitted.

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…

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.

Or at least use an alt so it doesnt look like self promotion right? :)

Re: Gitlab Handbook's HN Page

#187

Post by brudgers »

stonegray wrote: post #93
brudgers wrote: post #75

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…

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.

Re: Gitlab Handbook's HN Page

#188

Post by dnsmichi »

john_cogs wrote: post #173
anthonyjdella wrote: post #107

Earlier quoted context omitted.

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 ex…

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

https://gitlab.com/dnsmichi/tech-evangelism

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

Re: Gitlab Handbook's HN Page

#190

Post by geofft »

bromuro wrote: post #168
danuker wrote: post #4

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

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

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