Live data from Hacker News

GitLab Direction

about.gitlab.com

51–60 of 137 posts

Re: GitLab Direction

#51
post #39
post #35

Earlier quoted context omitted.

Could you elaborate about the salaries for remote workers? I'm a frontend developer in southern Europe and I'd love to work for Gitlab because I love the product.

Example: https://about.gitlab.com/job-families/engineering/developer/... Full details are here: https://about.gitlab.com/handbook/people-operations/global-c...

The QoL adjustments seem less granular than needed in the UK. "Everywhere else in England" covers a wide range of living conditions/costs. Areas like York & Harrogate are far more expensive to live in than the not-all-that-far-away Grimsby & Hull, to give one of many possible examples. If you are going to change what you pay geographically, I would suggest you need more local variance to do it properly.

Re: GitLab Direction

#52
post #5

Earlier quoted context omitted.

Thanks! Incremental progress in the form of iteration is one of our core values https://about.gitlab.com/handbook/values/#iteration

I have some questions to ask of you. 1. Why does gitlab have so many tiers? It would be better if you guys could repackage the features into fewer categories. 2. Why is the Gitlab UI so ugly? IMO, bitbucket and github are leaps and bounds ahead of you guys when it comes to design. 3. Can we get a dark mode for us night owls? 4. Finally, the morality question, You guys proudly associate yourselves with open-source and…

1. They only have four tiers (four equivalent tiers for hosted and on-premise technically). This is quite reasonable, as they need to provide flexibility for their customers. They are quite clear about which tiers provide which features.

2. This is purely subjective. I quite like the design, both more than GitHub and Bitbucket. They do have a UX team, and they conduct regular user tests. They've also made a lot of improvements and continue to make improvements, but design will always be subjective. You CANNOT please everyone

3. I suggest putting a thumbs up for https://gitlab.com/gitlab-org/gitlab-ce/issues/18596, but ultimately it does create additional work for the UX team so I don't know if they'll end up doing it or not. You could try a user style, e.g. https://userstyles.org/styles/125366/gitlab-simple-dark

4. GitLab is a company and needs to make money to continue employing developers to continue developing their product. Open source devs volunteer their time on GitLab CE, not any of the closed source features, and GitLab has open sourced enterprise features in the past if the demand is high. Also, there is nothing wrong with comparing them to Microsoft, as Microsoft has thousands of open source projects and is quite the open source contributor.

I'd flip #4 on it's head. They aren't greedily restricting features, they are generously open sourcing features and giving them away for free. As a business, they have no obligation to do so.

Re: GitLab Direction

#53
post #35

Earlier quoted context omitted.

Could you elaborate about the salaries for remote workers? I'm a frontend developer in southern Europe and I'd love to work for Gitlab because I love the product.

I don't have any first-hand experience, and I'm sure there are exceptions. I've heard that GitLab will pay around $80k for a remote software engineer in a country with a low cost-of-living. That engineer could be earning $150k-$250k at a different company (e.g. Basecamp, GitHub, etc.) I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of the US. But if you're a top engineer, you could double…

There are other advantages of being a cheaper remote worker, cheaper than 'market rates'. One is that since you are cheaper, there may be less pressure on you to deliver at a certain speed. Which, in turn actually may allow you to work more carefully and over time deliver your work at a higher level of quality. This combination can lead to you being happier in the job and wanting to remain at it for longer and since you are cheaper your position is less at risk when your employer is going through restructuring.

Re: GitLab Direction

#54
post #53

Earlier quoted context omitted.

I don't have any first-hand experience, and I'm sure there are exceptions. I've heard that GitLab will pay around $80k for a remote software engineer in a country with a low cost-of-living. That engineer could be earning $150k-$250k at a different company (e.g. Basecamp, GitHub, etc.) I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of the US. But if you're a top engineer, you could double…

There are other advantages of being a cheaper remote worker, cheaper than 'market rates'. One is that since you are cheaper, there may be less pressure on you to deliver at a certain speed. Which, in turn actually may allow you to work more carefully and over time deliver your work at a higher level of quality. This combination can lead to you being happier in the job and wanting to remain at it for longer and since…

That might be true sometimes, but I've also heard about some cases that are the exact opposite [1]. There are some software engineers making high six figures (e.g. > $600k including RSUs and bonuses), and the company respects them a lot more and values their output. These engineers aren't frantically cranking out code or working 12 hour days all the time. They're often doing very important work and have to be very careful.

And I've also heard about cases where lower pay means worse employers, higher expectations, and higher levels of stress, because the company doensn't value or respect the employee as much.

[1] https://twitter.com/sehurlburt/status/992779314532790273

Re: GitLab Direction

#55
post #4
post #3

GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control. This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.

What is the nr. 1 performance/ux/bugfix you would like to see? BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...

Treat server responses taking over 100ms as failures and keep fixing that.

There isn't 1 thing that's wrong, it's the entire UI, every operation that feels like it has a lag. Using GitLab is like using an app via remote desktop. It's tiring.

Re: GitLab Direction

#56
post #35

Earlier quoted context omitted.

Could you elaborate about the salaries for remote workers? I'm a frontend developer in southern Europe and I'd love to work for Gitlab because I love the product.

I don't have any first-hand experience, and I'm sure there are exceptions. I've heard that GitLab will pay around $80k for a remote software engineer in a country with a low cost-of-living. That engineer could be earning $150k-$250k at a different company (e.g. Basecamp, GitHub, etc.) I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of the US. But if you're a top engineer, you could double…

> you could double or triple your income by working for a different company (or as a consultant.)

... and relocate? Many remote jobs require you to move at the very least in the company's country.

Re: GitLab Direction

#57
post #56

Earlier quoted context omitted.

I don't have any first-hand experience, and I'm sure there are exceptions. I've heard that GitLab will pay around $80k for a remote software engineer in a country with a low cost-of-living. That engineer could be earning $150k-$250k at a different company (e.g. Basecamp, GitHub, etc.) I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of the US. But if you're a top engineer, you could double…

> you could double or triple your income by working for a different company (or as a consultant.) ... and relocate? Many remote jobs require you to move at the very least in the company's country.

No, I'm talking about as a remote employee living in any country. It's true that most high paying software jobs require relocation, but there's some that don't.

Re: GitLab Direction

#58

Triggering pipelines only in merge request is what we’ve really really been hoping for for quite while. Still seems pretty far out unfortunately...

If you use the GitLab convention of naming your branches from the issue (like it does when creating a MR straight from the issue), the MR branches will be named /^\d+-/ so you can add a only: clause to .gitlab-ci.yml steps matching that.

Re: GitLab Direction

#59
post #43
post #39

Earlier quoted context omitted.

Example: https://about.gitlab.com/job-families/engineering/developer/... Full details are here: https://about.gitlab.com/handbook/people-operations/global-c...

Thanks, this made me discover that GitLab doesn't hire everywhere it seems; these countries are excluded: Brazil, Crimea, Cuba, France, Iran, Ireland, Japan, North Korea, Portugal, South Korea, Spain, Sudan, Sweden, Syria https://about.gitlab.com/jobs/faq/#country-hiring-guidelines

I wonder why Spain, France, Portugal, Ireland, Sweden… are excluded, but not Germany or the United Kingdom or many other EU countries.

Re: GitLab Direction

#60

Earlier quoted context omitted.

https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits. I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.

It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.

I'd agree that, depending on usage model, this isn't a major issue, in that if you symmetrically encrypt a password, you still need to store the key somewhere to do the decryption.

That said it is possible to improve the security of this kind of model, although there is a trade-off in availability. What can be done is that the decryption key (or a passphrase controlling access to it) is stored offline and manually input at application launch.

The downside is that if the application restarts it needs human intervention to be operational. the upside is that you reduce (but not eliminate) the risks of the credentials being compromised from that system.

Post reply on HN