Package review use cases #121

New issue

Open

opened 2021-08-08 18:24:06 +00:00 by oturpe · 2 comments

oturpe commented

2021-08-08 18:24:06 +00:00

One use case is displaying open review requests opened by me.
I would like it to work as follows:

All review requests opened by me that not CLOSED are shown,
as these all need work.
Status of fedora-review flag is shown,
because from that I know
if a reviewer has claimed the request (fedora-review: ?),
or if the review is completed, but still need to request the repository
(fedora-review: +, but the issue still open).
If there is a needinfo flag open for me,
because the means that the review won't proceed without my action.

Another use case is the reviewer point of view.
I would also like to see

All review requests that are not CLOSED that have been assigned to me,
as those are the ones where I am the reviewer.
It would be even better to also see those
where fedora-review flag has my name on it.
According to the process, these should be covered by the preceding point,
but keeping assignee and fedora-review in sync is a manual procedure
and accidents happen,
so it would be good check both.
Also here I would also like to see if there is a neednfo open for me,
because that is used to signal that the reviewee has addressed my comments
and I should do another round of review.

Currently, package reviews are not visible on the Packager Dashboard. In order to make the Dashboard even more useful as the place to check for outstanding work items, it would be great to support some package review use cases as well. One use case is displaying open review requests opened by me. I would like it to work as follows: 1. All review requests opened by me that not CLOSED are shown, as these all need work. 2. Status of `fedora-review` flag is shown, because from that I know if a reviewer has claimed the request (`fedora-review: ?`), or if the review is completed, but still need to request the repository (`fedora-review: +`, but the issue still open). 3. If there is a `needinfo` flag open for me, because the means that the review won't proceed without my action. Another use case is the reviewer point of view. I would also like to see 1. All review requests that are not CLOSED that have been assigned to me, as those are the ones where I am the reviewer. 2. It would be even better to also see those where `fedora-review` flag has my name on it. According to the process, these should be covered by the preceding point, but keeping assignee and `fedora-review` in sync is a manual procedure and accidents happen, so it would be good check both. 3. Also here I would also like to see if there is a `neednfo` open for me, because that is used to signal that the reviewee has addressed my comments and I should do another round of review.

jskladan commented

2021-08-10 11:16:03 +00:00

Thank you for the suggestion, sounds intersting to me.

As a bookkeeping note (after talking this throught briefly with @frantisekz ) - the most important issue we see here is mapping the bugzilla email to the fas username the dashboard is currently all based upon.

Is there a list/api that would be able to do it? Would we need to keep track ourselves? TBD Any tips welcomed!

Thank you for the suggestion, sounds intersting to me. As a bookkeeping note (after talking this throught briefly with @frantisekz ) - the most important issue we see here is mapping the bugzilla email to the fas username the dashboard is currently all based upon. Is there a list/api that would be able to do it? Would we need to keep track ourselves? TBD Any tips welcomed!

jskladan commented

2021-08-10 11:18:42 +00:00

As a current implementation limitation on the backend part, we now only take a list of "allowed users" from some pagure list of packagers that own at least one package.

If a reviewer does not fall into the category, she won't be shown any information. This is absolutely easy to fix (e.g. adding reviewers with outstanding reviews to "the list"), just so we don't forget about it, and be bitten by the issue in our rear later on :)

As a current implementation limitation on the backend part, we now only take a list of "allowed users" from some pagure list of packagers that own at least one package. If a reviewer does not fall into the category, she won't be shown any information. This is absolutely easy to fix (e.g. adding reviewers with outstanding reviews to "the list"), just so we don't forget about it, and be bitten by the issue in our rear later on :)