I'd really like for UI updates in the future not to be jarring and seemingly pointless. I really liked the UI right before the overhaul, only minor tweaks seemed truly necessary. Many of the tweaks I would have suggested before have come through; such as putting profile information and notifications in the upper right hand corner. I'm glad about that.
Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
The sidebar is a global navigation and not always necessary when interacting with page-specific content on the site. GitLab is very content heavy and by allowing the sidebar to be collapsed, it allows users to have more space on smaller screens to read/scan the information that they need. As you mentioned, the sidebar can be pinned so users can view the navigation all the time if they prefer, esp if they are using a larger screen.
If you have other examples of changes that you felt were pointless, I'd love to find out the reason for the change for you!
I also urge you to voice your opinion by making an issue for changes that you think would help improve the user experience. https://gitlab.com/gitlab-org/gitlab-ce/issues/new
> Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
Could you elaborate on what kind of features we'd be required to add given your suggestion? What do we miss?
That said, I'm holding off for now because I'd love for it to replace both Github and our current ticketing system, and rather than doing two migrations, I'd rather wait a few months until you guys have fleshed that out and do it all at once. The issue boards on your roadmap look absolutely fantastic, but the true killer feature I'm waiting on is time tracking, which I'm hoping makes it in later this year. Get that in and I think you'll see people flock to Gitlab.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/18687 - https://gitlab.com/gitlab-org/gitlab-ce/issues/20608
If you have ideas to improve the current vision, don't hesitate to join the conversation!
Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features.
My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes.
https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitla...
For example, take a look at the drop in response time in the middle of last month: http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07
We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application!
Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository).
Ceph issues are here: https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
GitLab.com is too slow. We're working on it here: https://gitlab.com/gitlab-com/infrastructure/issues/59
GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0].
However, you can already deploy from GitLab quite easily to Heroku, it just requires a single line in your CI config:
http://docs.gitlab.com/ce/ci/examples/test-and-deploy-ruby-a...
[1]: https://githost.io/
We now have strengthened the team that works on these issues. I'm seeing whether it's possible to ship this with 8.12 (due Sept 22nd).
We'll be rolling out a major release next week, might be the right time to spread a word to colleagues ;)
Mostly, we need a way to defined custom fields to be able to triage, query and reassign automatically. Like for example components or platform. And labels are clearly not enough for that.