Great start Ayush! Could you please embed here (or else link) the video, or screenshots are fine.
My comments below are based off the video shared last week--

For the missing modal - could this be fixed before this work is presented to the larger team at the end of September, to avoid confusion and so Debug mode can be fully useful --:
What's missing is the ability to review past comments and add further comments -- Please see where this is visible in the sketches in #9268. This means the Edit Issue button should be called New Comment and it should trigger a modal per the bottom sketch provided.

The reason why --:
We don't really Edit the Issue Description because that would modify/overwrite the original report coming from the client-user research team. So instead the person debugging the issue must add new comments and also review prior comments -- we realize this was not detailed in the #9268 text though quite visible in the design sketch.

@racostas @regisoc let me know asap if this has already been discussed among you.

Thanks Ayush, it's looking solid otherwise.

Hi @ay-bh, I reviewed the PR and is looking like a good start indeed.
Yes, the functionality @christinerogers is mentioning it's important, I'm thinking now if it can be somehow be part if this same "view" in place of a new one ( do you think @regisoc that having the latest comments in this same view) will be defeating the purpose of the new view (because will be making the windows too big) or in facts can help to take the decision faster (without going throw the modal windows).

@SantiagoTG, your inputs here are also very welcome since you have been working a loot with issue tracker. If you have time to take a look to this proposal you opinion is very important. Thanks.

@racostas @ay-bh to keep you updated, we did not have time to test that together with @SantiagoTG.
The video was looking good. We will try to update you later today.

Hello @ay-bh great start indeed! Here are some comments from both me and @SantiagoTG.
There is a lot to say, but I tried to be exhaustive and integrated description/images/gif to be clear on the reasons behind each point, so don't be discouraged! I love the clean design, and those are more enhancements than problems.

I tried to group comments:

1. global view:
   1. Number of card displayed: How many cards are displayed? Some projects have lots of issues (e.g. around 14k on HBCD right now). Even with a filter active, it might be a very long list. Paginating them could be a good idea.
   2. Card ordering: Not thought at first but would be good: have an ordering system, e.g. order ASC/DESC by last comment date. Can be done later.
2. cards/individual issues: looks good! Good and simple design.

   1. issue (?) card date not updating: I tried to update a card but the last update date was not updated. Maybe a bug on my end. Other data were updated.

   2. Display last comments: Going back to what @christinerogers and @racostas mentioned: having a quick view on the last few comments is important. It can be up to 3 (maybe?) but would depend on the space required for it. We could split the card horizontally, with the left side = description and the right side = last 1-2-3 comments. I do not think we have a restriction on the maximum height a description can have but we do not want to have cards too big on a screen. So, it could be a fixed max height, if the text in height of the description is more than that, it should be managed as an overflow (collapsible text area).

   3. Clearer disabled elements: if the ticket/issue is disabled, do not show it as a clickable dropdown element. it should be an unambiguously non-modifiable static text. Moreover, for each element, there should be a clear text to say which field it is i.e. category, priority, status. We only have 3 right now, but this will be changed.
      

   4. New comment modal: Still missing the comment modal attached to the card, but this still looks good start.

3. filters: more things to say here. Globally still good, and we can enhance than side.

   1. filter checkboxes with lots of items: having an inline list of elements works when there are few, but not on some projects with dozens of them. It will not be ergonomic (e.g. see gif after). A collapsible with a max height, overflow, and listed elements could alleviate that (see issue).
      

   2. Issue redimensioning text area: description label goes wild.
      

   3. Active filters indication: because we can travel from one filter on one tab to another, we can lose the active list of filters. E.g. activating a filter in status tab, then going to another tab category. The first filter is still active but we are not able to see it.
      
      Two things here to help on that side:

      • active filter tracking: something like a number of active filters on each tab title will be a good first step. Something like a badge/pill maybe.
      • reset filter button: a quick way of resetting all filters to the default (no active filters).

   4. Site as a base filter/tab: sending issue to people in different site, we could automatically apply some filters based on people location. Site should be a new tab.

That was a lot more to write than expected, but I tried to describe each point.
This PR is good work, and I am eager to see the next steps!

Hi @regisoc, very good review in facts. I'm sure @ay-bh can address all of this points before the end of the coding period (end of October). Maybe he can present some of the advances he had been making in two weeks from now. (then do a second final presentation in November 5). I will keep you posted with more details after consulting it with him because he have other commitments in the school as well.
I'm very happy with this first review. What he (and @christinerogers and myself) wanted the most if to have a work that users find useful... and as you mention there are already some steps in this direction.

Can we also make sure this has a more descriptive name than "Debug View"? I suggest something like "Batch Mode" since that seems to be what it's doing.

@driusan @ay-bh oh yes I forgot this one :) Good point, batch mode is a good one.
I did not have any good idea the moment I created this ticket.

Thank you all for your detailed feedback and suggestions. I'll start working on implementing these improvements.

Hi @ay-bh, this two changes are looking good. Thanks for the update !
I will be continuously testing, feel free to push any change as soon as its ready since this PR can get big very fast and will be not to easy to test if we wait until all is addressed.

Great work !

Great progress @ay-bh - looking forward to seeing this presented.

Just to check the outstanding permission for issue_tracker_batch_mode_edit (see PR description at top) -- Is this still needed @regisoc @racostas ?
If so, @racostas should it go in this PR or could you help create a new followup issue?
Thanks

@ay-bh I will try to do another review before the end of the week.
@christinerogers good question. Maybe a bit of context: when I thought about it at first, I wanted to have a clear separation between people viewing/editing in "classical" mode (i.e. doing punctual and few assigned tasks), and those who can "batch" process a lot of issues (i.e. reviewing/solving issues, coordinating with people, closing issues). This is because HBCD has quite a number, and the main page takes some time to load i.e. ~10 seconds (can be longer when pressuring the server).
In my mind, "batch" mode is always for editing (and acting on several tickets), there is no big incentive in only viewing (searching information should be done in "classical" mode with numerous filters).
So to answer you, not sure if that is needed, but I am still in favour of having this separation for now.
Maybe you and @racostas have another view on that? I am not strongly attached to it anyway.