Request Workflow Redesign lowers efficiency

[suntorytimed]

Issue Description

This is to provide feedback on the Request Workflow Redesign, which is currently in Beta (https://openbuildservice.org/2022/08/15/request-workflow-redesign).

As a Release Manager for SLE, I have to review a big list of changes on a daily base. For this I look out for:

• code changes, especially changelog changes
• submit request message (for JIRA references)
• build results
• comments by other reviewers
• mentioned issues to quickly find the current ticket state of such

In the end I provide my review for sle-release-managers and sometimes origin-manager.

With the old workflow all information is on one page and I can quickly browse through the relevant information. The new workflow design requires me to go through three tabs and then back to the first tab to provide my review. Therefore it requires way more clicks and scatters the information in different places, making the review less efficient and less intuitive. This makes it also harder to search for removed references, which might be back-referenced in the submit request message itself, requiring a back and forth between "Conversation" and "Changes" The review itself requires more clicks as well, as it is now hidden behind a drop-down field with additional confirmation steps.

While all this is not a problem for single reviews, it gets tedious for the daily business when we receive more submit requests. Take as an example a yast2 stack update, or a gnome update, which can easily require a hundred package reviews for a Staging.

Expected Result

An option to still show all information on one page and directly enter the review decision. It would be great to have a reviewer view or something like that, which is close to the old page layout.

How to Reproduce

1. Do a submit request review with the beta feature for the Request Workflow Redesign activated

I can also record a demo of how the review differs between both designs, if this is helpful.

Further Information

• Any OBS/IBS instance with the beta feature for the Request Workflow Redesign active.

[DimStar77]

To add to the 'increased workload': it gets worse when one wants to copy parts from the diff (spec/changes) to the decline message to make references with hints on what to fix

[kdave]

With the old workflow all information is on one page and I can quickly browse through the relevant information. The new workflow design requires me to go through three tabs and then back to the first tab to provide my review.

Agreed with that, I had the same impression when I first saw the redesigned page. Having the relevant information on one page is a good thing, even if I myself am not a heavy OBS user (maintainer/packager role) I still prefer to have quick overview and not spend time clicking. The tool should be built for effectivity for those who need to use it for work and not necessarily for visual pleasure. These are contradicting goals and the UI updates are departing from the effectivity with additional steps (clicks, paging, hiding info behind tooltips, excessive padding).

[fcrozat]

Additional input: a single review which was taking 1 click (since review buttons where directly accessible) is taking 3 clicks: 1 click to open the group reviewing, one to select the action and one to confirm.
I'm also not convinced "declined" should be preselected by default.

[coolo]

Note that #7591 (comment) explains why "everything in one page" is not a good thing.

[hennevogel]

I'm alone not convinced "declined" should be preselected by default.

Decline is a situation you can get out of (reopen) without any changes to the code or resulting builds. Accept isn't @fcrozat

[hennevogel]

Additional input: a single review which was taking 1 click (since review buttons where directly accessible) is taking 3 clicks: 1 click to open the group reviewing, one to select the action and one to confirm.

You have to do one click more now to open the dropdown. The rest of the clicks you would have to do previously too (select the right review, select the action and confirm). We are all for avoiding excessive clicking but just driving the number of clicks down for the sake of less clicks is not a dogma we subscribe to 😃

[aaronpuchert]

Note that #7591 (comment) explains why "everything in one page" is not a good thing.

That's indeed ugly, but ~100 builds isn't all too common, I'd say. And perhaps this could be solved by rearranging things rather than splitting up into separate tabs. In this screenshot there is an awful lot of empty space.

The thing is, looking at the diff and build results is not an optional step in reviews. And if you have to look through them anyway, they might as well be on the first page.

[coolo]

build results are just useless to be honest: the request page shows you the build results of HEAD (which may be 'blocked') not of the sources submitted.

[coolo]

You have to do one click more now to open the dropdown. The rest of the clicks you would have to do previously too (select the right review, select the action and confirm). We are all for avoiding excessive clicking but just driving the number of clicks down for the sake of less clicks is not a dogma we subscribe to smiley

That's not true if you only had one review open - it was shown inline and you had one button to press. And I agree with Frederic that the review handling should be inline in the conversation.

[coolo]

But how I personally envisioned the review handling (having done a review or thousand) is documented here: https://user-images.githubusercontent.com/1067203/57966151-c7529980-794e-11e9-98ac-6f6161afcf1b.png

[aaronpuchert]

build results are just useless to be honest: the request page shows you the build results of HEAD (which may be 'blocked') not of the sources submitted.

Their usefulness is limited, but “useless” might be taking it a bit too far. I've definitely been saved from some submissions because I saw the builds failing. If a package takes hours to build, submitters sometimes file a request without waiting for the builds (understandably). Or I could see that some build is indeed fixed as claimed.

Apart from that, build results are sometimes those from staging, and then they are from the submitted sources.

[coolo]

Still it's worth adding more information to it - and as such put them in a separate tab. There can be a summary on the index page, but there is good use in splitting this. While @suntorytimed talks about looking at build results, but in reality staging managers rely on the staging dashboard to identify broken packages when they fail - and not when the review.

[hennevogel]

but in reality staging managers rely on the staging dashboard to identify broken packages when they fail

If a request is staged we show the build results from the staging project instead...

[kdave]

Note that #7591 (comment) explains why "everything in one page" is not a good thing.

That does not explain anything, only presents a page layout that's not well designed for your case where you have tons of build results. The comment and decision forms are unnecessarily placed below the container with the overview + build results.

What if: the build results are in a separate div/container so that the user controls like comment or accept/reject are not pushed downwards? IOW make the left side of the request page independent of the build results. That sounds like a reasonable fix to me. The typical flow on the review page goes from the changelog, diffs, changed files, and then there's the comment and ack/reject buttons. All in one go, scrolling down only, not much unnecessary clicking.

Today I used the new SR review dialog that's been mentioned in previous comments where I need to click three more times to complete the same thing that before. Repeating that 5 times left bad user experience impression.

[suntorytimed]

I'm alone not convinced "declined" should be preselected by default.

Decline is a situation you can get out of (reopen) without any changes to the code or resulting builds. Accept isn't @fcrozat

Well, in case of SLE Staging it's actually the other way around. With SLSA we can't reopen a declined request anymore, but we can still decline an already accepted review.

[hennevogel]

...in case of SLE Staging...

In that case many things are different yes, we are aware.

[juliogonzalez]

I guess there are different cases according to each one's role, and the kind of request. So the redesign could increase efficiency in some roles and decrease it in other roles.

Personally, as a SUSE Manager and Uyuni release engineer, I agree with @suntorytimed.

For the kind of reviews I need to make (usually one package, with not a lot of repos, and not big conversations), the single view was better than having tabs, and allowed me to review and approve/reject faster than with the new workflow.

I guess having two different views, is not an option? That way each one will be able to decide what view to use, according to the most common use case.