3 ms·

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 t

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 5y 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.
- capableweb 5y 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_cogs 5y 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_requests/97312 https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
- sillysaurusx 5y 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.
  - capableweb 5y ago
    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.
    - sillysaurusx 5y ago
      It feels micromanage-y. I wouldn't want to work at a company that tried to restrict my HN usage this way.
      - capableweb 5y ago
        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.

nacs 5y 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.

capableweb 5y 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_cogs 5y 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_requests/97312 https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

sillysaurusx 5y 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.
- capableweb 5y ago
  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.
  - sillysaurusx 5y ago
    It feels micromanage-y. I wouldn't want to work at a company that tried to restrict my HN usage this way.
    - capableweb 5y ago
      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.