jobvandervoort

Cool feature. Makes total sense. Pinged the relevant people.

Thanks for the feedback. To address each point:

1. I'd love to see everything versioned in GitLab. We're working on the issue descriptions, but I agree we should move toward versioning everything. There's an epic here [0], that we will be filling out with more issues to address what we haven't yet. Feel free to leave feedback there as well.

2. Most integrations are against projects, groups or instances. For those that require an acting agent, I recommend just creating a normal account for that and call it bot. I think it makes sense for us to have some sort of permanent solution for bots [1]. In the meantime, I propose you talk with our sales team about that. I'm sure they're willing to be flexible.

3. We believe the pricing for Ultimate is fair, given the broad range of tools GitLab replaces, from project management, to CI, to security, licensing and container management tools. That said, we're aware that it's challenging to see the value for every single user. With this release we're taking a step that hopefully helps out, by making guest users free for Ultimate [2]. We welcome further feedback on how we can make GitLab even more accessible to everyone in the organisation.

[0]: https://gitlab.com/groups/gitlab-org/-/epics/237

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

[2]: https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#un...

I just checked, user Vinnl is correct that you can already do this for every commit, and targeting every branch.

What is the output you get? Consider creating an issue here so we can help you debug: https://gitlab.com/gitlab-org/omnibus-gitlab/issues

Thanks for the feedback gorset. I'm curious to dig a little deeper.

With the irrelevant information, you mean the top part of the merge requests (ie description, CI status, etc)?

And as far as I can see, in the current version, we only hide the body part of the commit message.

I think we can make the experience better by autoscrolling down once you click on a commit in a merge request. I've made an issue [0].

I'm not sure about showing the full commit message. Many would argue that only the first line summary is crucial to show, which is what we do now. But I'm happy to discuss.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/48328

We got extensive feedback regarding the `Master` title. Renaming it to `Maintainer` is a relatively cheap thing to do, strengthened by the fact that it's a better reflection of the permission level: this is what Maintainers of repos will typically have.

Thanks for the feedback. To address some of it:

Regarding batch review: We wanted to ship this way sooner. We spent an unfortunate amount of time refactoring our merge requests to use Vue. That is now done, so work on this has started and should be shipping on August 22nd, with GitLab 11.2. See also the epic on the subject: https://gitlab.com/groups/gitlab-org/-/epics/23

All the other issues you referenced should get appropriate priority. I recently made a change in what team is responsible for code review, so that we don't have to choose between code review and issue tracking features, but rather between different features related only to Git. This should help. (i.e. responsibility went from the 'Discussion' team to the 'Create' team).

Regarding viewing large diffs: we're working hard on a better solution. Follow the epic for the full picture: https://gitlab.com/groups/gitlab-org/-/epics/15

We've not spent a lot of time on making this publicly readable, but the migration is moving forward steadily. We don't have a planned switchover data yet, but it's safe to say that it'll happen this summer.

We're writing a blog post on it here: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

Not yet, but I think it makes sense to support VIM keybindings in the long term. Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/47930

August 22nd: https://gitlab.com/gitlab-org/gitlab-ce/issues/46334

We called it IDE from the first commit, as we intend for it to be a full replacement of a local IDE in the future.

Besides having a vision ourselves of that, we also want to encourage and motivate others to contribute.

If you're not a software engineer, cloning, editing, staging, committing, pushing, creating a merge request is a lot to learn. I believe we can make this much easier, and that's the first problem we hope to solve with the Web IDE.

Ironically, once we introduced staging into the Web IDE, usability went down significantly (this is referenced in the blog post), as the core users were people that weren't comfortable with local editing. So we're addressing that next.

If you push a new branch to a GitLab project, we return a URL to immediately create a merge requests, which appears in the Git output in your terminal. So rather than going to GitLab, then clicking on a button, you just click the link in your shell.

GitLab is built on Ruby on Rails and a sprinkle of Go.

We have no relation to Oracle.

We currently run on Azure. GitLab integrates deeply with Kubernetes and specifically GKE, so it makes sense to run GitLab.com there: https://about.gitlab.com/2018/04/05/gke-gitlab-integration/

I have not heard it mentioned by any user / customer / other community member in the last year, but I think it makes sense to support it.

On GitLab: we do, but only if you host it yourself for now.

See: https://news.ycombinator.com/item?id=17226432

On the comparison with GitLab you mention we don't support IPv6. We do if you host your own.

We will enable it for GitLab.com once we're done with the migration to GCP [0].

Our pricing is per user, tiered. Not per-user and then per feature. Although I understand that's not far off from each other.[1]

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/47216

[1]: https://about.gitlab.com/pricing/

If you're moving from GitHub to GitLab, create an issue if one doesn't already exist [0] and send me a message (here, @JobV on GitLab.com, Twitter). I will make sure it ends up in the product.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new

If your project is public on GitLab.com, you can also mirror it for free to GitHub, bi-directional. Meaning you can receive contributions on both repos.

Docs: https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...

People told us the logo was scary, that was a good motivator.

When we changed, I wrote about it: https://about.gitlab.com/2015/05/18/a-new-gitlab-logo/

Exactly. Or at least teach them to use GitLab, which is a good motivator to make the product easy to use.

Yes, everyone == every single person employed by GitLab Inc.

Ours is here: about.gitlab.com/handbook - it's open source: gitlab.com/gitlab-com/www-gitlab-com/

My tips:

1. Maintain a clear single source of truth

2. Make sure everyone can contribute to it. We do this by requiring at least to edits to the handbook during onboarding

3. Embrace it as an organisation: if not everyone is committed to it, it's hard to maintain it as truth

4. Constantly iterate and improve it. Structure is highly dependent on the content.

You can run GitLab yourself, for free. Or even just supply your runner on GitLab.com: the builds run on your own equipment, but you don't need to host your own GitLab instance.

Is a world without Facebook one with a real alternative (everyone in the same place), or one where there are many alternatives?

Reddit is a single platform with many mostly-independent communities. Could a similar thing in the shape of a social network exist?

In short:

1. We mirror your project

2. We set up the integration with GitHub

3. We report the status and link back on GH's pull requests

We don't have a lot of incentives to turn down contributions. Quite the opposite.

We not only encourage this, we actively help people contributing to GitLab. It's humbling to be a steward to an open source project and something we don't take lightly [0].

And to be blunt, for an organisation as ours, with very ambitious goals, and highly demanding users, having someone else than us contribute something that makes the product better is the best possible deal we could do. We can compensate for the 'lost' value in our enterprise product by spending that time on other things that are maybe more interesting for our paying customers.

[0]: https://about.gitlab.com/stewardship/

So as landing page? That is an interesting idea. I've created an issue. Would love to get your thoughts there: https://gitlab.com/gitlab-org/gitlab-ce/issues/38954

You should be able to access them directly today by hovering over the navigation item on the left for issues and selecting board there.

Or do you mean as a landing page for the project (I see a comment below here that clearly indicates that, will follow up on this, there)?