Skip to content

How to increase the performance of GitLab while simultaneously creating new features

Right now we have a problem I believe we can solve.

How do we create new features while continuing to aggressively fix performance problems and polish? How do we make GitLab fast while creating new features?

Also: How do we unify the teams so the frontend gets more involved in the backend and the backend can be more involved in the frontend and we all get more involved in infrastructure. The more knowledge we have together, the faster we can fix issues by having more wide spread knowledge and potentially more hands on deck and using the people we already have.

To solve this we create what @awhildy and I have penned "Experiences":

One important note: Every thing we create or fix should be the solution to an existing problem. We wouldn't want to create new features if they don't solve a problem. Making the site work with anaglyph glasses does not solve a problem. Making commenting and viewing comments faster solves one problem, but the whole comment section we can called the comment experience.

An super simple example: Right now this is the comment experience: You write a comment and you press Cmd+Enter. The comment usually takes a 1 to few seconds (sometimes more) and it appears above. Problems:

  1. It doesn't have a sense of instantaneousness.
  2. It's kind of boring, but maybe that's ok.

To solve this we must combine multiple skill sets.

  1. From the infra and BE side that submitting a comment is slow. The actual HTTP request is variable and on the fast side it is almost good enough and on the slow side it's miserable and on the bad side it doesn't work.
  2. To solve this we must look at the SQL, and what rails is doing. Maybe it's asking permissions and the permissions are slow.
  3. From the UX side, the commenting could submit right away to create a sense of instantaneousness. Regardless of if the server is ready. When the comment submits it can show a loading thing on the comment itself like facebook does. This will make it feel more instant.
  4. From the frontend side we can implement the UX changes and check if the JS that get's run is slow also. We can run the profiler on that and see what is actually running to submit a comment.

Anyone from any team can tackle an experience and it would be good if they did cross disciplines to spread the knowledge.

This is what the meta issue essentially is but we didn't ever take it far enough. These issues will be multidisciplinary, and should figure out the problem and attempt to solve it in one issue.

We need to:

  1. State the problem.
  2. Check for infrastructure solutions within the problem.
  3. Check for BE solutions within the problem.
  4. Check for FE solutions within the problem.
  5. Check for UX solutions within the problem.

I think if we followed these steps it would create the "polish" we seek while simultaneously creating new features, no doubt.

cc @stanhu