
Maturity - tosh
https://about.gitlab.com/direction/maturity/
======
KaoruAoiShiho
I was sucked in by Gitlab's feature list and marketing. But holy shit so many
things are half assed and so many features are buggy and broken. Like their
wikis would sometimes just straight up delete text and their webhooks would
break images. I started a bunch of issues but they really have no chance of
getting fixed anytime soon. Just shows how different your impression of
something is after actually using it.

~~~
sytse
The wiki is GitLab should not delete text, please file a bug if you had
dataloss.

The current state of the wiki isn't great but we're also not seeing a lot of
people care about it. Many people are switching to static websites. Therefore
we're not investing to get the wiki better than the current state of a half
circle.

BTW We've recently measured experience baselines in GitLab and we agree we
still have a lot of work to do [https://about.gitlab.com/2019/09/05/refining-
gitlab-product-...](https://about.gitlab.com/2019/09/05/refining-gitlab-
product-experience/)

~~~
KaoruAoiShiho
A wiki's not the same usecase as static site, a static site is for marketing
and wikis are for project management. I mean maybe people would use it if it
weren't crappy? I would've been happier if the wiki didn't exist and I didn't
invest time into wrangling it. ATM it's just a frustration.

It's not dataloss but it deletes text in the same line as wiki internal links.
And what kind of wiki doesn't use lots of internal links.
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/67132](https://gitlab.com/gitlab-org/gitlab-ce/issues/67132) This
basically makes the wiki unusable but it's marked as "backlog".

If you really do feel this way about the wiki then it should be clearly marked
in your marketing. I read about your "integrated devops experience" and was
onboard, but if your intent is as you say then you need to put parentheses
next to the wiki feature item list that says "this is crap and we intend for
it to stay crap" and we'll know to value it appropriately when choosing a
provider.

~~~
phikai
> A wiki's not the same usecase as static site, a static site is for marketing
> and wikis are for project management. I mean maybe people would use it if it
> weren't crappy? I would've been happier if the wiki didn't exist and I
> didn't invest time into wrangling it. ATM it's just a frustration.

Hi! I'm the current PM for our wiki's and I agree that the experience isn't up
to par at the moment. As Sid mentioned, historically wiki's were not a
priority as many users weren't coming to GitLab for those features. We're
starting to see shifts in that thinking as we've penetrated deeper in to some
markets so we're working to adjust accordingly.

> It's not dataloss but it deletes text in the same line as wiki internal
> links. And what kind of wiki doesn't use lots of internal links.
> [https://gitlab.com/gitlab-org/gitlab-
> ce/issues/67132](https://gitlab.com/gitlab-org/gitlab-ce/issues/67132) This
> basically makes the wiki unusable but it's marked as "backlog".

That issue is interesting because it's a link mechanism that relies on the
underlying wiki project that we use. (i.e. that's no common markdown syntax).
Discoverability of things like that is limited to some power users who know
that we're using Gollum underneath and know of some of the supported syntax.
What we've seen is that most users don't use that functionality and instead
just use absolute links in markdown. This likely explains why the upvotes are
so low on the bug report as well.

For comparison, we've seen more demand to support linking to projects:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/20726](https://gitlab.com/gitlab-org/gitlab-ce/issues/20726), than
within the wiki itself.

As an FYI, I've also asked a couple of our engineers to take a look at that
specific issue to see if it's something that can be relatively easy to fix. No
guarantees on anything here, but we'll try to get a bit more relevant
engineering information to assist in understanding scope.

> If you really do feel this way about the wiki then it should be clearly
> marked in your marketing.

That's a lot of what our maturity pages are trying to do. We're being honest
with ourselves and with our users about where we think the functionality of
certain features are. In fact, when I started we had the Wiki listed at a
`Complete` maturity which I reduced to viable: [https://gitlab.com/gitlab-
com/www-gitlab-com/merge_requests/...](https://gitlab.com/gitlab-com/www-
gitlab-com/merge_requests/23525)

If you take a look at the wiki strategy
([https://about.gitlab.com/direction/create/wiki/](https://about.gitlab.com/direction/create/wiki/))
our next focus is going to be on making editing easier and improving
navigation. We think these things will start to move the conversation forward
for users and we'll see more adoption.

Even more, if you think we're not moving in the right direction with the
Wiki's please be vocal on the issue tracker, or open an issue for the Wiki
Strategy or even a merge request to change something. We're happy to have the
feedback, and don't hesitate to tag me on wiki issues I'm @phikai on GitLab as
well.

~~~
KaoruAoiShiho
Thanks for explaining and for taking another look at the issue. Your comment
makes sense to me in context of your company's strategy. I'm not saying that's
wrong, as surely the breath allows you to gain an niche that is less
competitive and less risky than a depth strategy that forces you to compete
head to head with great products like notion... but as this thread shows it
has enormous downside.

But anyway the double brackets is not a Gollum feature. It's a wiki thing,
going back to wikipedia.

Since you're here I think this issue is also misprioritized:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/66898](https://gitlab.com/gitlab-org/gitlab-ce/issues/66898) You
should reconsider as a lot of integrations rely on webhooks and broken images
make the whole thing impossible.

~~~
phikai
> But anyway the double brackets is not a Gollum feature. It's a wiki thing,
> going back to wikipedia.

That's fair, the point was that it's syntax specific to the wiki system vs.
the rest of our markdown filters.

> Since you're here I think this issue is also misprioritized:
> [https://gitlab.com/gitlab-org/gitlab-
> ce/issues/66898](https://gitlab.com/gitlab-org/gitlab-ce/issues/66898) You
> should reconsider as a lot of integrations rely on webhooks and broken
> images make the whole thing impossible.

I'll take a look at this - it popped on to my radar recently but I need to dig
in further to understand the use case and functionality here. Thanks for
bringing it up.

------
jon-wood
Somewhat unrelated, but I’d like to give a shout out to whoever designed
Gitlab’s cookie consent interface. Rather than the usual “accept or gtfo”
modal they allow you to choose which categories to select, and even list every
individual cookie that will be issued, along with the origin, purpose, and
expiry. My only criticism would be classifying a few cookies from Slideshare
and/or LinkedIn as necessary because they share a name with Gitlab’s own
Cloudflare cookies.

At some point tomorrow once I’m on an actual computer I’m going to have a dig
and verify that they also don’t cookie you until you’ve consented - if that
the case then I’m deeply impressed.

~~~
hadrien01
They use Cookiebot:
[https://www.cookiebot.com/fr/](https://www.cookiebot.com/fr/)

------
mistursinistur
I love using Gitlab SCM, but I'm surprised that Gitlab CI is described as
"Lovable" while major bug fixes are gated for months on an uncertain future
feature release:

"Job marked as success when job terminate midway in Kubernetes"
[https://gitlab.com/gitlab-org/gitlab-
runner/issues/4119](https://gitlab.com/gitlab-org/gitlab-runner/issues/4119)

IMO a production CI bug that falsely reports success merits a high priority
patch release but Gitlab doesn't seem to see it that way.

~~~
sytse
This bug took too long to fix. We are not happy how we prioritized the last
few releases for CI. In 12.4 we'll focus on fixing 8 of outstanding CI bugs
[https://gitlab.com/groups/gitlab-
org/-/issues?scope=all&utf8...](https://gitlab.com/groups/gitlab-
org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=12.4&label_name\[\]=Category%3AContinuous%20Integration&label_name\[\]=bug)

~~~
Operyl
So, can you shed some light on how the actual prioritization works? There are
some bugs, one specifically I've mentioned elsewhere, that just get infinitely
shoved into the void.

~~~
sytse
The Product Manager (in the case Jason Lenny who is out of office today)
prioritizes between bugs, vulnerabilities, new features, and tech debt. He or
she uses customer input, user input, and company input. Read more on
[https://about.gitlab.com/handbook/product/#prioritization](https://about.gitlab.com/handbook/product/#prioritization)

To find the relevant Product Manager see
[https://about.gitlab.com/handbook/product/categories/](https://about.gitlab.com/handbook/product/categories/)

~~~
Operyl
So, the unfortunate reality of prioritizing customer wants like this is that
you're always going to focus on big shiny new features, and not quite so much
the smaller (while still important) bug fixes that really need consideration I
feel. I felt like I got shoved into a black hole, and it does not inspire
faith in your product anymore. Even if I did become a customer, which I was
seriously considering before this, we're going to be "too small" to make a
dent compared to your bigger customer base.

~~~
sytse
Existing customers tend to prioritize stability (fixing bugs) over new
features.

Please note that even if you're not a customer our issue trackers are open so
you can @mention the Product Manager to help them understand the severity and
help to diagnose and fix things if you're so inclined.

~~~
Operyl
As seen in [https://gitlab.com/gitlab-org/gitlab-
runner/issues/4029](https://gitlab.com/gitlab-org/gitlab-runner/issues/4029),
a few people did show frustration, and why. And then began the never ending
push back after push back.

~~~
sytse
I agree this issue hasn't been prioritized as high as it should. I meant to
indicate that with "This bug took too long to fix." but I should have said it
took to long to schedule.

We concluded the same internally recently and hence the focus on bugs and
wider community contributions in 12.4. We overly focussed on getting the DAG
[https://docs.gitlab.com/ee/ci/directed_acyclic_graph/](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/)
and Merge Trains
[https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipeli...](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/)
out the door and missed a bad bug, we're sorry.

~~~
sooheon
Not a GitLab user, but I'm deeply impressed with your openness in handling
issues on this thread.

~~~
Operyl
I've always appreciated how open he is, I just wish it never came down to
having to flag him down on Hacker News to get something properly fixed
(although, I appreciate that is still something I can do).

------
rossmohax
Gitlab isn't big company, 100 devs or so, they try to target much bigger fish
(>2000 devs) with their product, yet they can't make it work even for their
scale: Kubernetes , monitoring, CI workflows like merge trains and others. So
when it comes to putting you money (gitlab.com subscribers) where you mouth is
(gitlab.com/features page) they are not there yet.

Kubernetes story is quite telling. They released "cloud native charts" a year
or so ago , that is their official way to run Gitlab on Kubernetes, yet when
they just dip their toes into kubernetes world, when they switched their
docker image registry to run on kube, they've quickly discovered glaring
omissions like missing liveness probe and storm of errors on any version
update. That is what their customers were sold under the label "ready for
Kubernetes".

Same goes for almost every feature.

~~~
YorickPeterse
> Gitlab isn't big company, 100 devs or so

384 engineers, out of a total of 873 employees. I'd say that's a pretty
reasonable size.

~~~
emilycook
Hi! GitLab employee, since the OP mentioned something from a year ago I
thought it might be worth mentioning that we haven't been this size for very
long. Around this time last year we were at 300ish employees, but we've almost
tripled this year thanks to a huge hiring push.

------
bureaucrat
Gitlab is slow. It’s so unbearably slow, even their official server. Guys, why
should a static content load after page loading is done? Page loading done,
and the code still loads with a loading circle. Why? Just compare it with
github. Average 500ms makes a huge difference.

Also gitlab UI is a huge mess. It got all the features, sure. But the UI is
not that user friendly. Don’t use flat the wrong way. Use contrasts for
buttons PLEASE. Github is sort of flat and their interface is great with
adequate use of contrasts.

[https://imgur.com/a/EIlV7ri](https://imgur.com/a/EIlV7ri)

~~~
joshlambert
Thank you for the feedback. We aren't happy with performance and we are
working hard to improve it. We have two major projects under way, switching to
Puma
([https://docs.gitlab.com/omnibus/settings/puma.html](https://docs.gitlab.com/omnibus/settings/puma.html))
as well as reducing the overall memory consumption of GitLab
([https://about.gitlab.com/handbook/engineering/development/en...](https://about.gitlab.com/handbook/engineering/development/enablement/memory/)).

You can follow along on some of the progress we are making in each release
post in the "Performance Improvements" section. For 12.2 you can see we had 58
MR's related to performance: [https://gitlab.com/groups/gitlab-
org/-/merge_requests?scope=...](https://gitlab.com/groups/gitlab-
org/-/merge_requests?scope=all&utf8=&state=merged&label_name%5B%5D=performance&milestone_title=12.2).

On the UX front, two efforts under way are establishing experience baselines
([https://about.gitlab.com/handbook/engineering/ux/experience-...](https://about.gitlab.com/handbook/engineering/ux/experience-
baseline-recommendations/)) as well as a common design system
([https://about.gitlab.com/handbook/engineering/ux/pajamas-
des...](https://about.gitlab.com/handbook/engineering/ux/pajamas-design-
system/)). Hopefully these efforts allow us to look at our UX holistically,
and to focus on making high quality components that are used throughout the
product.

Again thanks for the feedback, and hopefully we will have some more concrete
improvements here soon.

~~~
bureaucrat
With those harsh comments being said, I use self hosted gitlab and I am
thrilled to see your product improve.

Keep up the good work.

~~~
joshlambert
Thanks, and please keep up the feedback. =)

------
flocial
Gitlab is a great product for self-hosting a GitHub-like service and I'm
grateful for its existence. Having said that, I'm not a big fan of their bait
and switch approach to feature creep. Every time I try to update our GL I end
up in a world of hurt.

No straight upgrade path when you skip major-ish releases. I end up wasting a
day sifting through cryptic issues and docs from vague error messages.

Suddenly can't commit because now my branch is "protected" and failed a deploy
pipeline I didn't implement courtesy of GL's "vision".

Not to mention all this comes at the cost of increased complexity and resource
usage.

I wish there was a "thanks but no thanks" setting to keep our instance the
bare minimum without having to adopt features whole hog every time they get
inspired to incorporate the next "big" thing.

~~~
joshlambert
Hi, I'm a PM for our linux packages. I'd love to learn more about the cryptic
issues and vague errors mention.

We've put a lot of effort towards making the upgrades as painless as possible,
with few surprises. One way we've achieved this is by requiring users to
update to the last minor version, before making the jump to the next major
version, as you note. The reason for doing this, is that we add a lot of
validation to that last minor package which checks for any deprecated
features/configuration.

This way if you try to upgrade with a configuration that would result in
GitLab no longer functioning, we abort the upgrade and tell you exactly why,
leaving you with a functional instance in the interim.

~~~
flocial
It was a while ago but the upgrade was from 9 to 11. The first problem was the
error message didn't give me a simple command to go step wise through the
upgrade like:

\---- Please upgrade to the next GitLab version before trying to upgrade to
the latest. The command for upgrading to a previous version is as follows:

sudo apt-get install gitlab-ce=10.8.7-ce.0 -V

See the url below for available releases:

\----

Going from 10 to 11 was even more difficult because the gitlab.rb file format
changed and I was missing required information that was not apparent from the
error messages after running "gitlab-ctl reconfigure" (I think the error was
Chef related but my memory is hazy, below are the GitLab issues that finally
provided a hint). This wouldn't be so bad if my GitLab 10 instance was working
but after going from 9 to 10, all I got was a blank page so at this point I
had no choice but to go all the way.

After finally replacing the gitlab.rb file with the template and adding back
info from the old file, I was able to finally run reconfigure and update as
needed. Of course, I was soon alerted by coworkers that their commits were
suddenly being blocked for failing a commit pipeline. Overall it was not a fun
experience and I'd rather not upgrade GL unless I have to but I also don't
want to skip versions if I have to repeat the hellish upgrade process by
manually babying the upgrade.

Issues referenced: [https://gitlab.com/gitlab-org/omnibus-
gitlab/issues/3610](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3610)
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/46219](https://gitlab.com/gitlab-org/gitlab-ce/issues/46219)
[https://gitlab.com/gitlab-org/omnibus-
gitlab/issues/2153](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2153)

~~~
joshlambert
Thanks for the additional information. The `git_data_dir` and gitaly
configuration changes are indeed why we've started requiring moving to the
last minor version first. The 10.x to 11.x upgrade was the first major upgrade
with these checks, but it doesn't look like we captured all the possible
scenarios. (We did prevent a few upgrade failures though, based on customer
feedback.)

It is very important for the team to ensure upgrades are smooth. Right around
50% of our installations are running a version at most 3 months old, and we
want to continue to improve that number so everyone can take advantage of the
latest fixes, features, and security updates.

The team has opened another issue to explore ways to make it more apparent
which version should be upgraded to: [https://gitlab.com/gitlab-
org/distribution/team-tasks/issues...](https://gitlab.com/gitlab-
org/distribution/team-tasks/issues/484).

------
johnsnowtho
I moved all my repos to GitLab almost 2 years ago. I just use the online
version.

One of the main reasons I moved was because of price (free), and the available
CI. I use a $5 DO droplet to do all my CI running - which gets me unlimited
usage. It's awesome, and has only had to be rebuilt once it 2 years due to
unresponsiveness.

I've been a big fan of the CI - I use it to build my Docker images, then they
get run on k8s. Note - I do not use the AutoDevops feature - so I really don't
know how that works for people.

I pack the `gitlab-ci.yml` file with my main building steps and all the other
tasks I need to run: deploying to k8s, deleting pods if necessary, running db
migrations, stuff like that. It works great - everything just works at the
push of a button. And now that I've ironed out the `gitlab-ci.yml` file, I
don't even have to think about it anymore when it comes to a new project.

Honestly - I like GitHub's UI a bit better as it's a little more modern, but
with GitLab's free private repos - it just lured me at first and I'm content
for now.

~~~
bobbylarrybobby
Since MS acquired GitHub, GitHub also has free private repos

------
Operyl
I’m growing a bit frustrated with GitLab myself. There’s a bug in their runner
that they’ve pushed back god knows how many releases now that causes the
runner to spam a ton of (incorrect) warnings into our logs. I get it, we don’t
pay for support or the product, but I was sure hoping after many months that
they’d either roll back the change that caused this or given us a work around
or something ... I guess it’s time I try to learn the code base and hope they
actually take my contribution.

~~~
lbotos
Do you have a link to an issue for this? I work on the Support Engineering
team and while our central mandate is not committing code, I think this could
be something we could address quickly.

~~~
Operyl
[https://gitlab.com/gitlab-org/gitlab-
runner/issues/4029](https://gitlab.com/gitlab-org/gitlab-runner/issues/4029)

~~~
lbotos
Thanks! I messaged some of my teammates to see if they can take a crack at it.

Thanks for the issue!

------
colechristensen
This is great, addressing a common and real criticism of gitlab that it seems
has been in recent history much more focused on adding features than
maintaining quality. The maturity schedule as I see it seems quite slow
though, it shouldn't take years for a new feature to have high quality.

~~~
CameronNemo
The GitLab team will readily admit that they have a breadth first policy. This
gives transparency for that policy, and does not change it.

~~~
sytse
That is still our policy but we recently added something to
[https://about.gitlab.com/company/strategy/#breadth-over-
dept...](https://about.gitlab.com/company/strategy/#breadth-over-depth) that
might be relevant:

"So breadth over depth is the strategy for GitLab the company. GitLab the
project should have depth in every category it offers. It will take a few
years to become best in class in a certain space because we depend on users
contributing back, and we publish that journey on our maturity page. But that
is the end goal, an application of unmatched breadth and depth."

~~~
colechristensen
My first experience with GitLab, several years ago, felt like it needed this
policy. I actively didn't like it, and did not see the point or added value.

Now my experience is exactly the opposite. I like all of the things GitLab
does, it is an obvious and significant value add _but_ ... when I have
experimented with it in a home lab and elsewhere there were several things
which gave me pause, and I've seen the same expressed elsewhere which
alleviates doubts I may be wrong.

Now I'm in the position where I like something and hesitate to recommend it
worrying that the details will make my life more difficult and my users' lives
more difficult and not less, not because of missing big features but because
of quality and depth, as you call it. Maybe it's the right thing for your
business to go for breadth even for years longer and seek depth in the future
to solidify your position. But for now, as a potential user, GitLab might not
be right for me, which I think is unfortunate.

~~~
pritianka
Hi there! I hear what you are saying especially if you are considering
recommending the full single application. As our maturity model shares, we are
better at some stages than others. So I would share parts of the product that
really work for you all the time and let people experience for themselves.

~~~
colechristensen
If I could have GitLab Mature Edition that was restricted to the high quality
more complete parts, it would go a long way. Otherwise shipping a product
where I have to sell the good parts and hand-wave the rest as incomplete -- it
makes the product much less appealing.

~~~
pritianka
Hah, I love the "GitLab Mature Edition" idea!

------
atsaloli
> Lovable: Provides an elevated user experience that customers love as
> measured by NPS.

NPS = Net Promoter Score

[https://en.wikipedia.org/wiki/Net_Promoter](https://en.wikipedia.org/wiki/Net_Promoter)

~~~
ekianjo
Not sure why NPS is being used everywhere these days. Basically it makes all
levels of "bad" just as bad as each other. What's so hard about using
distributions?

~~~
lucasmullens
Distributions are harder to track over time. Coming up with a single metric is
really helpful for A/B tests and seeing how your product changes over time.

~~~
pritianka
Agree. It's about consistency over time (and now across companies and products
with the adoption) vs perfect.

------
sofaofthedamned
I've just read all the comments here, it's a roller-coaster ride but is
exactly what I saw with my self-hosted GL.

Each new release there'd be a new release with great new features - yay! -
followed by 3-4 patch releases to fix the bugs. You eventually get worn down
by it and don't bother using these things.

I see the same with other dual licensed stuff. Kong is a good example - bugs
that actually _stop_ routing traffic are eventually acknowledged, but with no
feedback unless I keep chasing them. However i'll get regular emails with new
products. They've got a new Service Mesh they announced recently. There's not
a chance in hell i'll use it until they fix the bugs/issues i've reported in
the core product.

------
Aeolun
Cool, requirements management is coming!

Not cool, it’s only in Ultimate. No way am I going to be able to get my
company to shell out for that.

~~~
gabeweaver
Hi! I'm one of the product managers at GitLab that will be contributing to the
development of requirements management. I don't believe we've decided that it
will only be an Ultimate level feature. The label was added to the epic
([https://gitlab.com/groups/gitlab-
org/-/epics/707](https://gitlab.com/groups/gitlab-org/-/epics/707)) before any
conversation had taken place...or even before there were concrete requirements
to build requirements management ;)

We do our best to align features with the likely buyer according to our
pricing model
([https://about.gitlab.com/handbook/ceo/pricing/](https://about.gitlab.com/handbook/ceo/pricing/)).
Sometimes we don't get it right and need to fix our mistake after a feature is
launched based on feedback from our wider community (example:
[https://gitlab.com/gitlab-org/gitlab-
ee/issues/13856](https://gitlab.com/gitlab-org/gitlab-ee/issues/13856)). We
have been and will always be transparent about our pricing model and our
mistakes in aligning new features with it.

If you're interested in collaborating with us as we build out requirements
management, we would love that. It will help us build the right features for
the right likely buyer. Please leave some additional thoughts on the epic
discussion if you have them!

~~~
Aeolun
Oh, I don’t doubt that the feature would make most sense in the Enterprise
tier, but we’re on Atlassian right now, whose price is often equated to free
compared to Gitlab.

Convincing them to spend $20/developer/month is going to be hard. Convincing
them to spend $100/dev/month is going to be a whole different ballgame (even
if it’s ultimately perfectly great unit economics if gitlab increases
productivity by at least 2%).

------
dcchambers
Very pretty graphics and a good way to see a complete listing of products they
offer.

I fear that GitLab has simply bitten off more than they can chew. They try to
implement so many features that many things feel half-baked. Ultimately -
those features that aren't finished are useless to paid or enterprise
subscribers.

GitHub has been successful because they focused on doing one thing very well.
Now that they have established market dominance, they are slowly introducing
new features - but in a way that makes them feel like useful pro-level
products right away.

I don't know how GitLab recovers from that other than continuing to march
forward. If I were them, I would stem the tide of new product introduction and
focus on building out what is already there. It's a very ambitious roadmap
they have given the number of features they want to implement.

------
trumbitta2
I'll add my two cents and feedback:

I like the GitLab flow, and I absolutely love the "Create merge request"
button in the issue detail. I miss it dearly whenever I'm working on GitHub,
and `hub pull-request` isn't quite the same.

I don't like the code review functions: for example when I'm in the changes
tab, where I can both resolve discussions and double-check the code, cycling
through unresolved discussions breaks every time and I have to go back to the
discussions tab where to check the code I have to open the linked diff in
another tab.

I don't like the settings UI, with all those "expand" buttons so far on the
right side. I mean, there's even one of those buttons in places where you have
only one fieldset worth of settings.

~~~
ecbrinkman
Thanks for the feedback. I just spun up a test MR ([https://gitlab.com/gitlab-
com/www-gitlab-com/merge_requests/...](https://gitlab.com/gitlab-com/www-
gitlab-com/merge_requests/29655)) to understand if I could quickly see what
was bothering you on cycling through unresolved discussions but it seems to be
working ok. Would it be possible for you to elaborate a bit more or link me to
a MR where you can replicate the breaking functionality?

I did notice there's a bug where the hover text doesn't go away after clicking
on the "Jump to first unresolved discussion" button and I've created an issue
to fix that ([https://gitlab.com/gitlab-org/gitlab-
ee/issues/15462.](https://gitlab.com/gitlab-org/gitlab-ee/issues/15462.))

~~~
barret7sc
My biggest issue with gitlab code review is that it's unusable for large
changes and large files. On large changes it sometimes won't even show all the
changes.

Also the auto-collapse size is far too small, and the fact you can't even see
the diff for some large changes in infuriating. It makes using it for code
review a struggle. My company is trying to move us all to gitlab-ee, but the
lack of features and polish to the code review tool is preventing some teams
from making the jump.

I feel like the code review portions are more like a half-circle, and not a
heart. There are so many deficiencies that make it unusable for large
projects.

If I were gitlab I would look at gerrit for inspiration on what you should use
for code review. It's ugly, but it's very functional and performs quite well
on meager hardware.

I know there are feature requests to make code review more usable but I can't
understand how you could dogfood that code review tool and not go insane.

Also, merge trains for FF-only repos, please!

~~~
jramsay
> it's unusable for large changes and large files. On large changes it
> sometimes won't even show all the changes.

Improving the performance and scalability of merge requests is the priority
for the Source Code team right now, and we are starting with progressively
loading the diffs over coming releases. See [https://gitlab.com/groups/gitlab-
org/-/epics/1816](https://gitlab.com/groups/gitlab-org/-/epics/1816).
Currently we load them in a single request which is a serious bottleneck.

In parallel we are exploring a range of UX changes to streamline and improve
the code review experience. If you have any specific ideas please let us know,
or create an issue!

> Also, merge trains for FF-only repos, please!

Absolutely! We are iterating towards this [https://gitlab.com/gitlab-
org/gitlab-ce/issues/58226](https://gitlab.com/gitlab-org/gitlab-
ce/issues/58226)!

------
archon810
This is beautiful.

Made me think of
[https://www.reddit.com/r/dataisbeautiful](https://www.reddit.com/r/dataisbeautiful),
so I submitted it there
[https://www.reddit.com/r/dataisbeautiful/comments/d1xqfz/git...](https://www.reddit.com/r/dataisbeautiful/comments/d1xqfz/gitlab_maturity/).

~~~
sytse
Thanks for submitting it!

------
neighbour
Unrelated to the post but I interviewd with GitLab this year and want to give
them a shoutout. The whole process was smooth and the people I dealt with were
SUPER friendly, even after I withdrew my offer for another.

Since then, I've moved most of my personal projects over to GitLab and try to
evangelise them whenever possible.

~~~
emilycook
We're really glad to hear that!! :)

------
mleonhard
I think Gitlab is doing a great job. I like how their feature requests and bug
reports are all open.

------
bovermyer
I used to use GitLab for my personal projects, but moved away for a couple
reasons. The primary one is that GitLab is heavily opinionated, and its
opinions differ irreconcilably with my own in a few areas.

Now, most of my code is hosted on GitHub, with a few projects hosted in a
Gitea instance that I run myself.

------
uluc_aydin
I'm curious, is this an open-source component? I like the way they visualize
the maturity of their products.

~~~
sytse
We use Chart.js for this. Credit goes to Josh Lambert who made this.

------
jrochkind1
> Provides an elevated user experience that customers love as measured by NPS.

What's NPS?

~~~
whoisjuan
Net Promoter Score. Is a score calculated with a periodic survey that tries to
determine cohorts of promoters (people who like your product so much that they
are willing to recommend it to colleagues) and detractors (people who hate
your product so much that they usually talk bad about your product if the
opportunity to do so arises.)

This is calculated through those surveys you get sometimes that say something
along the lines of "From 1 to 10 how likely are you to recommend X product to
a friend or a relative".. or something like that.

~~~
jrochkind1
Huh, I'm confused how that score would tell you if a particular specific
feature/area of the app provided "an elevated user experience that customers
love". Any ideas?

~~~
whoisjuan
Hmm. Good question. In my experience an NPS study isn't just the survey. I
have done it in the past and usually after you get the results you do a
baseline a call/contact your promoters and detractors to learn more about
their issues.

So I think it's determined by a combination of personal reach-outs and
probably the same questions scoped to particular features.

~~~
joshlambert
Hi - we've been discussing how to better anchor these on quantitative data,
rather than the subjective opinion of GitLab PM's.

You can see some of the discussion here ([https://gitlab.com/gitlab-
com/Product/issues/323](https://gitlab.com/gitlab-com/Product/issues/323))
which continued to some degree here ([https://gitlab.com/gitlab-
com/Product/issues/386](https://gitlab.com/gitlab-com/Product/issues/386)).

If you have feedback on some other metrics to use, please contribute! I don't
think we've landed on the right formula just yet. But directionally, we'd like
these to be based on user outcomes rather than our own opinion.

