Hi, sorry you haven't noticed any improvements. We've been chipping away at performance for the last 6 months and have made some pretty noticeable improvements in various areas of the application.
For example, the average response time of an issue page has come down from 2.5s to 750ms over the last 6 months.
We still have a lot to do, but we're getting there.
We've been working quite a bit of our NFS storage topology and have recently introduced some remediation to prevent outages based on NFS availability. Previously an NFS failure would have pretty wide-reaching implications, now it's a lot more isolated.
We're also working on an entirely new storage architecture for scaling and are slowly rolling this out. You can see more here: https://gitlab.com/gitlab-org/gitaly
We've been spending a lot of effort making GitLab.com more performant over the course of this year. We still have some ways to go, but every release includes performance enhancements based on performance data from GitLab.com.
We no longer see GitLab.com as a mechanism to stress test GitLab and we're certainly pushing hard to improve performance and availability.
Thank you for the kind words, we've been working hard on improving the UI (have you tried the latest update in https://gitlab.com/profile/preferences#new-navigation) and have tried to make our free offering as valuable as possible as well as treating our existing free customers respectfully.
As Gitter was originally built as closed source with a team of people working exclusively on Gitter, this has never really been a problem for us.
This is very much v1 of the setup/instructions and would be delighted to improve them with any MRs or contributions. We'll certainly improve them ourselves over time as we get more people in less controlled environments adopting the project.
We're trying to achieve two things with open sourcing Gitter.
Firstly, we see Gitter as more of a community than a product. That we have nearly 1,000,000 developers coming together on the platform to talk about code and open source software where public rooms far, far outweigh private rooms, is testament to that. So we're not trying to compete with MatterMost.
What we're trying to facilitate is to allow the community and users of GitLab to contribute to the experience of the community. We've always had a very small team at Gitter and the surface area of the product is massive. This way the community can help us make it a better place by improving the product.
We also have some communities who are interested in running their own public instance entirely. Sure they could use other products, but Gitter is built community and public first and suits a lot of different needs that other products don't necessarily facilitate out of the box.
We started Gitter before React was A Thing and Marionette had a lot of the functionality we needed. We even hacked it to do server-side pre-rending and live collection binding. Topics was an experiment in how we could look to move towards react and evaluate blending technologies.
Not having started out as an open source project, this was always a major consideration.
Once we've finished fully open sourcing everything, we should look to write up our experience around the conversation, in particular, the tools we used.
Great point. We "soft launched" this yesterday so are still working on the documentation and hadn't made any official announcement yet until we've ironed out in any kinks.
Feel free to let us know your thoughts. This will start making it's way into the application in 9.4 (July) and will be activated through a feature toggle so people can experiment with the new UI, give us feedback and we'll iterate and improve it before we switch it over.
If you're interested in what you can build with Bubble, check it out - I'd love to get feedback.
And if you're so inclined, I'm on Product Hunt today too.
https://www.producthunt.com/posts/troupe