[META] : Frontend Pre-Planning

Based on my proposal in this issue : gitlab-com/organization#89 . This is a pre-planning list for the frontend :

Technical changes

• Enable webpack code splitting to improve frontend performance. (Mike - gitlab-org/gitlab-ce#33391) => 9.4
• Replace PhantomJS with headless Chrome (Mike - gitlab-org/gitlab-ce#30876) => 9.4
• Compile SCSS with webpack (Mike - gitlab-org/gitlab-ce#29346)
• Integrate Google Lighthouse into our CI to evaluate frontend code performance (Mike - gitlab-org/gitlab-ce#33392)

Technical debt removal

• Add custom linter for inline JS to haml_lint (Winnie - gitlab-org/gitlab-ce!9742) - 2/3 of it are done
• Use filename linter for FE files (Winnie - gitlab-org/gitlab-ce!9497) - 2/3 of it are done
• Limit our dirty javascript global scope (Filipa - gitlab-org/gitlab-ce#20983) - Its huge should be splitted in smaller digestable issues
• Remove the IIFE's from each JS File (Alfredo - gitlab-org/gitlab-ce#29219)
• Clean up errors and warnings logged by karma (Winnie - gitlab-org/gitlab-ce#32830)
• Using keyCode and magic numbers for checking keypresses (Simon- gitlab-org/gitlab-ce#28464)

Timeboxes

• Responsive Polishing (ex. gitlab-org/gitlab-ce#25102)
• Graphs / D3 / Responsive (Jose)

AC specific topics

Moonshots

• Improving The GitLab Visual Management Experience
• Team Dashboard
• GDK JS

DC specific topics

• Improve CI - Frontend performance (Filipa - gitlab-org/gitlab-ce#32098) - Performance yeah !

mentioned in issue gitlab-com/peopleops#271 (closed)

mentioned in issue gitlab-com/organization#89

changed the description

changed the description

@timzallmann There's more interest in getting frontend monitoring up and running (https://gitlab.com/gitlab-com/infrastructure/issues/1881) -- it would be great if we could figure out how to prioritize work on it during the release. Up til now it's just been considered a "spare-time project", which means not a lot of time gets invested in it.

changed the description

Can we add #33391 (closed) as an item for %9.4?

Also, after headless chrome is implemented, I think #33392 (moved) is worth considering

changed the description

changed the description

changed the description

added OKR OKR-FE labels

Hey @timzallmann. First off thank you for making this. Glad we are looking ahead. Second, we should close this. We have a ton of FE issues that are pre planned for future release. If you check the %Backlog milestone, and frontend label you'll see a bunch of issues. If you want you can even schedule them for a future milestone. Like adding them to %9.5 or %9.6 or later. But best is to give them all the label OKR-FE. We want to avoid creating meta issues for planning. It turns out to be really hard to keep track and search in the future.

Also in the future, with issues related to FE, it's always good to cc the appropriate people. Like cc @jschatz1 at the bottom of the description so I get notified.

@jschatz1 That was the main idea of this issue to have an additional list of issues that make sense from a FE Team perspective to schedule soon , cause there are way too many issues in the backlog, which didn't get scheduled in the past and its hard to distinguish which of them would make the most sense to tackle them next, thats why people proposed stuff and needed to argue why it makes sense and how much effort. So I would rather leave that open as a discussion point what makes sense to tackle next from technical debt/improvement side.

I thought you are already on the notification list as you added your own stuff a month ago ?!

cause there are way too many issues in the backlog,

Then we should clean up the backlog. I don't personally think we should have 2 backlogs.

I thought you are already on the notification list as you added your own stuff a month ago ?!

I guess so. Lol. Honestly I don't remember. My fault

I suggest we cleanup the frontend backlog and delete junk we truly aren't going to do. I'd be happy to go through it with you. There are tons of great of ideas in there too. We shouldn't just forget about it and leave it to gather dust. The usual protocol is people comment on the issues themselves and not the meta issue. Like "Hey can we get this in a future release?" And the good thing is that we can already fill up parts of those releases. We have the spreadsheet. I've added pages 9.6, 9.7, and 9.8 to it. Might as well just schedule this stuff or it won't ever happen. Like this release, we already filled up most of the allotted time and no time for anything special. If we preplan our stuff we can reserve space!

I have so many issues I keep track of, a meta issue is not something I can keep track of.

Does that work for you?

I also suggest we label everything we (as FE) want to do in Q3 with the OKR-FE label. Then at the end of the quarter we can remove everything from that label and start over. That way we can search the issues easier.

We already did stuff from that list in 9.4 and also in 9.5 from this list will be done (more webpack code splitting / inline JS).

Thats a good idea to go over the backlog list, i think for now we need to have such a list to pick urgent/important stuff out of the big pile. I am happy to keep track of it and then lets move over to a cleaned backlog + full scheduling for the future

Main problem that i see with the technical pre-planning is that it also depends a little bit on how much stuff we got in from all the other sides.

I am happy to keep track of it and then lets move over to a cleaned backlog + full scheduling for the future

@timzallmann great. I just went through all 154 issues in the backlog and removed the ones that don't concern us and kept only the most important. A lot of these are there. Please put all these issues in in the backlog that are not already there. We are now down to 42! Feel free to trim more out of the backlog if you it feel nessesary.

I am closing this issue since we agreed to put these issues in the backlog once it is cleaned up.

closed

@jschatz1 what are you referring to when you remark

We have the spreadsheet.

?