Hey efiecho, Community Advocate from GitLab here! I'm sorry to hear that you are not a fan of our actions and/or decisions.

Can you please dive into specifics a little bit and explain what parts of GitLab could be improved and what are some high-level things that you don't particularly like?

I should probably have been more specific in my critique, as it sounds like I think GitLab has major problems. It's just regarding the web interface.

On every other Git repository manager, we can browse source code, view replies to both issues and merge requests without Javascript enabled. But not on GitLab. I don't expect anything advanced to work without Javascript, but these simple operations definitely should and I think it's very bad design to have this requirement. The result of this Javascript overuse is that GitLab is both slower and a bigger pain to use than the alternatives. Use Javascript in small amounts were it make sense for functionality, not just for showing text, pictures or other simple things.

There, my two cents. So, what I meant was that Microsoft should look at GitLab and NOT copy the web interface. GitHub has a nice web interface, with Javascript in acceptable amounts and where it make sense, even the language details bar works without.

Community Advocate from GitLab here! If I understand you correctly, you are looking for a way to aggregate analytics across GitLab, so that users can view information across multiple projects and groups in one place.

We have the Analytics feature designed for that [1]. Please be aware of the distinction between Group-level and Project-level analytics described there.

If you have any feedback on how we can improve this feature, or if you have other ideas, please open an issue [2] and share as many details and examples as possible. We'd love to look into it!

[1] - https://docs.gitlab.com/ee/user/analytics/index.html.

[2] - https://gitlab.com/groups/gitlab-org/-/issues

No, I just want an issue board where I can view/assign/create issues across users and projects, with common labels - so I have one board with todo/doing/blocked/in-review/done.

Ideally with a filter on which projects to show.

This works for hierarchical structures today, but not across them. (I'm not sure the current data model is easy to bend into this, so it's understandable - it's just one of the few things we've seen that would let us to more of the project mgmnt in gitlab directly).

Thank you for the explanation! I just opened an issue proposing this [1]. Please add a comment with any additional feedback that you might have or feel free to ping me if I didn't fully understand what you are proposing.

[1] - https://gitlab.com/gitlab-org/gitlab/-/issues/216573

Just wanted to chime in and add following links from our documentation:

Get the diff of a commit - https://docs.gitlab.com/ee/api/commits.html#get-the-diff-of-...

List repository tree - https://docs.gitlab.com/ee/api/repositories.html#list-reposi...

Repository files API - https://docs.gitlab.com/ee/api/repository_files.html

Hello all, GitLabber here!

We opened an issue for gathering feedback at https://gitlab.com/gitlab-org/growth/product/issues/164 and you can find the most up to date information regarding this topic there. Please join the discussion and let us know what you think.

You say "discussion", but many of the Gitlab developer comments in that thread consist of the same response copy-and-pasted verbatim in response to multiple different people, which comes across more as PR spin than as a good-faith attempt to engage in a discussion.

Why would there be a “discussion”? They knew their users didn’t want this anti-feature before they implemented it and they did it anyway.

Then they add insult to injury by pretending to “discuss” it as if user consent or participation has anything to do with this.

We have been taking the feedback seriously, we rolled back our ToS changes and are reconsidering our approach here. More info can be found on the issue

I don't believe that requiring explicit agreement to a new ToS before being able to access account deletion is kosher.

The ToS have been rolled back, and telemetry had not been implemented yet. I (of course) don't want anyone to leave, but hopefully that alleviates any concerns if people want to.

This entire thread kept me up last night. Revisiting it this morning, there's a ton of well expressed, clear, opinions and facts here in this discussion. On the other hand, the amount of information expressed in the issue, does not nearly contain enough of what's in this HN thread.

Good morning. If you commented yesterday, express your product needs for zero telemetry and trust here: https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672

(GitLab employee... of course) Sorry this thread kept you up (no sarcasm). If it helps at all, I'm responding to you right now because I'm here gathering all of the feedback, since there was so much discussion on here/reddit/twitter/the issues that need consolidating. I'll be making a lot of noise so the people in charge can truly see the impact this had

Please have your co-workers stop spamming the same comments in every HN thread about Gitlab's poor decision.

I realize this is also spammy, my bad, but I do wanna clarify that it's explicitly our job to respond to questions/concerns and relay feedback to the company: https://about.gitlab.com/handbook/marketing/community-relati...

I'm going to be honest: I don't care that it's your job. Don't do it.

I'm not looking forward to GitLab "taking into account" the community comments, then ignoring them and forging ahead with this change.

Hello, GitLabber here! We’re currently writing an issue explaining the situation, once it’s public I will link it here.

I think we as developers understand the rationale behind it. The outrage you may see is that in self hosted instances, the companies and people that pick that as their option do so because they want an isolated/independent system. Telemetry from a self hosted system is atypical, especially compared to SaaS that's hosted by you. It's more normal in apps people download that already use the internet, but you already have that option in what you host.

Frankly, I used to work at a DoD contractor and we ran GitHub Enterprise and GitLab behind secured networks. That kind of expectation -- that the software will never phone home -- was what let us run and justify them in the first place.

Edit: Looks like the comment I replied to has been changed, and essentially removed. I'm sorry if this is now out of context.

"Until the new Terms are accepted access to the web interface and API will be blocked. So, for users who have integrations with our API this will cause a brief pause..."

It's not even take it or leave it, one has to agree first in order to leave.

It seems whoever approved this, forgot why people arrived to GitLab from GitHub.

It's not that we do not understand that, we do, it's that we don't agree with such stupid and aggressive move considering enterprise setups (I certainly will not use this version if I can avoid it). Shame, this is exactly the opposite of why I migrated to Gitlab.

This is the issue they were talking about, I hope it clarifies some things! https://gitlab.com/gitlab-org/growth/product/issues/164

Not really, as you will see from the first user comment.

Then why don't you do region based pricing as well?

Customers really hate price discrimination, especially if the company has a reputation for transparency. Employees don’t mind regional discrimination so much (and if they do, they don’t work for Gitlab).

Not sure that reasoning flies.

Many more customers would be on gitlab if regional pricing exists. The profit number would go down though.

More candidates would apply to work for gitlab without the policy.

In both cases gitlab makes more money. Which is fine but spinning it doesn't seem right.

The Debian migration is actually finished.

Awesome, as a long-time Debian user myself that makes me very happy :)

We are offering our top tiers (Ultimate or Gold) for free to open source projects [1]. You can see the complete list in our repo [2]. Some of the most recent projects that received our free license are Arch Linux, the Tor Project, edX (currently migrating). Just to add a few more: Drupal, Haskell, VLC, Kali Linux, Lineage OS, and more on this comment [3].

[1] - https://about.gitlab.com/solutions/open-source/program/

[2] - https://gitlab.com/gitlab-com/marketing/community-relations/...

[3] - https://news.ycombinator.com/item?id=18724015

Part of the application for open source projects here requires you specify how many "seats" you need.

> The number of seats is the number of different users that will use this license in the next year.

This seems counter to how many open source projects work where contributors come out of nowhere to make a contribution and may or may not stick around. How does this work when you have hundreds or thousands of unique contributors a year, and you have no good way of predicting?

Note: not a GL employee, but EE subscriber

IIRC seats are calculated based on monthly active users, and are a soft cap: we've outgrown our license, so we will have to retroactively buy the missing seats on our next license renewal.

I expect this is no different from a OS license, except that that OS project doesn't pay for the license.

This was often a hot topic on HackerNews, so we decided to write a blog post explaining why we pay local rates. Please find more information here [1].

[1] - https://about.gitlab.com/2019/02/28/why-we-pay-local-rates/

This is something that always discouraged me from applying at your company, even though it sounds amazing. I make 150k at my current position working remotely, but based on your calculator I would only make 80k at Gitlab so almost half. What a joke.

You are missing on a lot of top talent due to this policy.