I'm curious, is this an open-source component? I like the way they visualize the maturity of their products.
Maturity
11–20 of 127 posts
Re: Maturity
#12I’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.
Re: Maturity
#13> Lovable: Provides an elevated user experience that customers love as measured by NPS. NPS = Net Promoter Score https://en.wikipedia.org/wiki/Net_Promoter
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?
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.
Re: Maturity
#14I’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…
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.
Re: Maturity
#15I’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…
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.
Re: Maturity
#16I 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 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.
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...
Re: Maturity
#17I 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.
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-...
Re: Maturity
#18I 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 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.
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...
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.
Re: Maturity
#19Earlier quoted context omitted.
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...
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.
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
To find the relevant Product Manager see https://about.gitlab.com/handbook/product/categories/
Re: Maturity
#20This 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.
The GitLab team will readily admit that they have a breadth first policy. This gives transparency for that policy, and does not change it.
That is still our policy but we recently added something to https://about.gitlab.com/company/strategy/#breadth-over-dept... 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."