Regarding performance, we've made some recent improvements (here's one example: https://gitlab.com/gitlab-org/gitlab/-/issues/30507#note_293...), but we know we need to do more. We're actively working to improve our sitespeed (https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7154), and we have several other improvements in process this quarter.
Regarding disabling features and the Git project screen, our UX research team has heard this feedback from other users. It's fair feedback, and we're looking at how to address it.
Issues fall through the cracks because there's no internal health oversight, take this issue for example: https://gitlab.com/gitlab-org/gitlab/-/issues/21907 It simply ceased to exist because the original staff member left GitLab.
I've also seen community MRs with weeks of work go to waste because GL staff couldn't take proper ownership/responsibility to see them through.
I think having a "all hands" week where all work stops except for going through current GitLab.org issues, fixing labeling/priorities, adding related issues and pinging the correct leads would do WONDERS.
Sadly, if GitHub adds scoped labels and descriptions we'll be making a move over as it's the final piece of the puzzle.
Then, after a year, a bot auto-closes the issue due to "inactivity"...
They're basically useless right now because I constantly have 6+ tabs open and they all have different numbers and I just now I need to do a full page refresh to get the updated number.
As a user I really like that they have their tickets open like that. I’d never contact Github and tell them about some minor feature that would be helpful or give them feedback on a new feature they’ve released because how would you even do that in a way that’s not annoying? And with Gitlab you often get to feed in at the design stage which you’re completely shut out from anywhere else.
I’m not sure if you’ve actually had issues go missing - I know they have loads of repos and I’ve only engaged with a few - but my experience definitely hasn’t been that things get lost in the weeds.
For what it’s worth I agree with all the extra features being too visible. I kinda get it - one day I’ll get round to learning Kubernetes and I’ll probably do something with Gitlab’s integration when I do - but while I don’t use them those features are definitely too visible and add too much clutter.
I kind of agree with the "too fast". It seems to me that many features are being created as a PoC to pad out features lists and having something new to market. It will then live on as barely useable and accumulates hundreds/thousands of issues as the devs seem to be spread way too thin over all the PoC, core and new features.
That said, I completely agree that we need to get better how we iterate and improve the quality and performance of existing features. We've more than doubled the number of Product Managers, Engineers, and UX Designers over the last 12 months to work alongside the wider community to help transition "barely usable" features into lovable features. Please ping me (@gweaver) on any long standing issues that are important to you and i'll do my best to route it to the directly responsible PM.
I've studied GitLab's code history for a while, and they have been moving at a very fast pace for years now. Below is a one year window (from today) into to their gitlab repo.
Some points of interest are:
1) 15k commits are merge commits.
2) The vast majority of the code churn is ruby, which is expected.
3) Based on the bus factor, a lot of files that are iterated on, have less than 10 unique contributors. And there are a handful of files that are iterated on a lot, by a lot of people.
4) A lot of the code changes are 10 lines of churn (lines added, changed, deleted) or less, which indicates incremental improvements/bug fixes/etc., as opposed to adding new functionality.
Something that I'm not doing right now, is mapping the churn, to the number of unique contributors. It would be interesting to see if there is a pattern to their churn vs number of contributors.
GitLab is definitely moving at a very fast pace, and it would be interesting to map this to their issues, but their API is extremely slow, so I've never bothered trying.
Edit: For the scatter charts, the x-axis represents the number of files. And the y-axis is number of contributors (bus factor chart) and churn size (churn chart)
25 of those are willing to pay for the advanced features at $100/month, but the entire instance has to be upgraded. It’s frustrating because there’s no way to pay $100/month so 950 people can view a private repo or edit markdown.
If we could enable features for just the devs who need it, we could. The GitLab folks were nice, but the only workaround for this was to have multiple instances that people would connect to depending on their need. That’s confusing for non-devs and also many projects have a few developers but 3x as many people who just edit markdown or view CI status.
Haven’t used them since they allowed an intern to purge the production database.
Kind of glad I have stuck with github thus far.
Really!?!?
a) Gitlab.com is ridiculously slow. Even the CEO admits they failed to invest in it.
b) You can't disable features you don't need so you end up with a sidebar full of Kubernetes and Security features for a Git project dedicated to documentation.
c) Staggering amount of open issues and merge requests so you feel discouraged from even raising anything since it just gets lost in the weeds.
d) On the main Git project screen there are 15 buttons. Including again ones for "Add Kubernetes cluster" or "Add License" which you can't remove or hide even though it's irrelevant for 99% of Git projects.
e) Feature set and billing are all over the place. It has great project/issue management but in order to get say roadmaps you need to have everyone in your team on the $99/month plan. Even though they aren't developers. So in some cases Gitlab ends up being much more expensive than Jira + Github.
I could keep going. But Gitlab is an example of a company that is moving too fast and needs much better product management. I would take Github's more deliberate approach any day.