Live data from Hacker News

GitLab Direction

about.gitlab.com

111–120 of 137 posts

Re: GitLab Direction

#111

A few years ago I really wanted to join GitHub as a software engineer. I was living in San Francisco and visited their office for some events, and I thought it would be an awesome place to work. I tried reaching out to a few people who worked there, but I could never get my foot in the door. There were a lot of things I would have loved to build at GitHub, and they were all the same things that GitLab is doing now. I…

I will address the concerns around compensation. I appreciate the comments and understand that working remotely is not valued the same by all and has its own unique challenges. However, the challenge of location influenced pay is not unique to remote companies. I worked at large, traditional companies for years who had different pay for team members in the Silicon Valley, and those in other offices. Of course, with team members in so many different locations, many without meaningful local compensation data, the challenge grows. We don't have it perfect at GitLab yet, but we continue to try to make it better. It's a complex topic, but I will add some thoughts to the discussion.

We do look at rent index as a factor within Compensation. It is not the only factor but it would be unfair not to take it into consideration. Afterall, there are not many locations in the world where $117,000 is considered low-income. (https://sanfrancisco.cbslocal.com/2018/06/26/hud-117000-low-...). I'm thrilled that we can provide team members with a meaningful career without forcing them to move to a high-cost area. I have often seen cases at other companies where we make a great offer to an out-of-area candidate. They think the compensation is amazing and jump on a plane to start their new job in the Silicon Valley only then realizing that they can't afford a home here and may need to get a roommate to pay the rent unless they live far enough away and endure a long commute. The big salary suddenly looks a lot smaller after seeing the cost of living.

However, it is not the only factor we look at and we are continuing to improve the model we have for compensation. We also set a minimum rent index so those very low cost areas are actually paid above market. We do this to ensure that the gaps are not too large. We also pay the market data for a region widely. If you're within a 90 min. commute of San Francisco, for example, you would still make the SF pay.

Where you see region broadly represented (like the example of "the rest of the UK), that is because the rent index across the region was less or equal to the minimum rent index set. When you see a location that you perceive to be a lower rent index, getting higher compensation, that could be because we also add a contractor factor in those locations where we are hiring as contractors, knowing that there are often additional expenses to cover as a contractor.

With that being said, we are constantly trying to get meaningful compensation data in various locations so we can rely more on the market data and less on the rent index. It is my intention that if we see that the market is changing with more remote companies, we will also adjust our benchmarks to be an accurate reflection of the market. I know that there will always be a company out there willing to pay more and that we will lose some talent because of that. I also know and have seen, that GitLab is able to attract and retain some of the best engineers I've seen (and I've seen some great engineers!) due to its product, culture, and all remote work life.

Re: GitLab Direction

#112
post #42

GitLab is a great service, not perfect but a good alternative to GitHub. I actually use Gitter far more than GitLab these days, GitLab acquired them a while back and I'm really disappointed to see it reduced to stagnation. The product hasn't improved at all since the acquisition, you can argue that it's "finished" and it is 90% there. There are rough edges that make it more annoying to use than Telegram, Slack, etc.…

Heya, I'm the current Gitter developer and was working on Gitter before the acquisition.

After the acquisition, Gitter did stagnate with no movement as we settled into our new GitLab roles and responsibilities but since May, we have been actively shipping things again. Changelog: https://gitlab.com/gitlab-org/gitter/webapp/blob/develop/CHA.... Catching up from the break in development, a lot of work so far has been technical debt. We do have more user-facing changes in mind like removing the disruptive large embeds (https://gitlab.com/gitlab-org/gitter/webapp/issues/714#note_...), improving search (https://gitlab.com/gitlab-org/gitter/webapp/issues/1925), and decoupling unreads from emails (https://gitlab.com/gitlab-org/gitter/webapp/issues/1205).

One of the goals this quarter is to open source the Android/iOS apps, https://about.gitlab.com/okrs/2018-q3/ but there isn't a plan to keep improving them with new features. We are focusing on fixing the rough edges of the webapp and are happy to review your Merge Requests for any project.

By Android notifications being broken, I assume you probably mean our double-buzz avoidance, https://gitlab.com/gitlab-org/gitter/webapp/issues/1846, but please make sure your particular issue is tracked, https://gitlab.com/gitlab-org/gitter/webapp/issues?scope=all...

Re: GitLab Direction

#113

A few years ago I really wanted to join GitHub as a software engineer. I was living in San Francisco and visited their office for some events, and I thought it would be an awesome place to work. I tried reaching out to a few people who worked there, but I could never get my foot in the door. There were a lot of things I would have loved to build at GitHub, and they were all the same things that GitLab is doing now. I…

I will address the concerns around compensation. I appreciate the comments and understand that working remotely is not valued the same by all and has its own unique challenges. However, the challenge of location influenced pay is not unique to remote companies. I worked at large, traditional companies for years who had different pay for team members in the Silicon Valley, and those in other offices. Of course, with t…

More information in our handbook! https://about.gitlab.com/handbook/people-operations/global-c...

Re: GitLab Direction

#114
post #9
post #8

Earlier quoted context omitted.

I just wanted to add that I have been absolutely loving gitlab. Signed up in 2014 and use it pretty much daily. One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy. Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped m…

Thanks so much for commenting, awesome to hear you're loving GitLab. We made a lot of performance improvements, I'm glad you're benefitting from them. On https://about.gitlab.com/handbook/engineering/performance/#p... you can see what we're measuring. The monitoring of our biggest merge request https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-sum... shows of our fixes regressed and we're looking into what is…

The migration to GCP is now scheduled for August 11. See https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuT...

Re: GitLab Direction

#115

Earlier quoted context omitted.

You pay 200 employees but don't want to spend $19/user/month on software for a company hub? That's not really a small company, and this seems like a budgeting problem if money is that tight. You can also try running multiple installations with a separate dev-only instance with more features. Also have you tried contacting Gitlab to negotiate? A few emails can go a long way.

I would say 200 employees is fairly small company; and depending on the line of business it is certainly small enough that profit margins and thus spending may need to be closely watched. If you consider that the OP has only 10 out of 200 users that need the advanced features, but has to purchase the advanced features for all 200 users for anyone to use those features that is $45,600 a year. Now if it were possible f…

As stated, they can run separate instances, or spend 5 minutes contacting GitLab to negotiate.

200 employees is not small, that is considered a medium sized business. Millions of companies around the world never get past single-digits. With payroll extending into 10s of millions, $35k sounds rather trivial if it really is powering the company hub and the value that brings.

Re: GitLab Direction

#116

Earlier quoted context omitted.

I mean surpass GitHub in both usage and revenue.

Revenue? GitHub has been operating at a loss right up to the moment that MS bought them for over a thousand times what they had to start making annually to not run a loss.

You're confusing revenue with profit.

Re: GitLab Direction

#117
post #73

Earlier quoted context omitted.

When my company subscribed there was only a community and enterprise tier. Now this has become the starter edition and I feel we are losing a lot of value. We are 200 employees, but only 10 developers using the advanced features. We really want to make GitLab our hub (GitOps and all), however the the cost of going beyond starter edition is mind blowing (x5). So if we are to embrace GitLab further we must abandon the…

You pay 200 employees but don't want to spend $19/user/month on software for a company hub? That's not really a small company, and this seems like a budgeting problem if money is that tight. You can also try running multiple installations with a separate dev-only instance with more features. Also have you tried contacting Gitlab to negotiate? A few emails can go a long way.

[deleted]

Re: GitLab Direction

#118

Earlier quoted context omitted.

I would say 200 employees is fairly small company; and depending on the line of business it is certainly small enough that profit margins and thus spending may need to be closely watched. If you consider that the OP has only 10 out of 200 users that need the advanced features, but has to purchase the advanced features for all 200 users for anyone to use those features that is $45,600 a year. Now if it were possible f…

As stated, they can run separate instances, or spend 5 minutes contacting GitLab to negotiate. 200 employees is not small, that is considered a medium sized business. Millions of companies around the world never get past single-digits. With payroll extending into 10s of millions, $35k sounds rather trivial if it really is powering the company hub and the value that brings.

"200 employees is not small, that is considered a medium sized business"

I'm just curious what your basis for that is? To go with some kind of standardization on the term "small business" I would say the safest definition (within the US) would be to follow the SBA guidelines that define a small business. Depending on the industry a small business is defined by the SBA as a maximum of anywhere from 100 to 1500 employees. So it is not cut and dry that this is or is not a small business; industry and also potentially revenues in millions of dollars would need to be known to determine absolutely if it by definition a small business.

Re: GitLab Direction

#119
post #102

If you want to compete with GitHub for open source projects you are going to need a 'releases' page that's similar (at least in function) to github's. I would like to see that prioritized more, I think it's more important for many projects looking to switch than many of the other features listed here

I just link to the project tags page, since the only tags we have are releases, this works great.

Re: GitLab Direction

#120
post #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.

Probably a different issue, but one of my greatest gripes with CI is that I can't limit steps to (for example) master branch AND having a tag. It seems such a basic requirement, but is unfortunately not possible via .gitlab-ci.yml.
Post reply on HN