datatracker
datatracker copied to clipboard
ietf-tools
When assignee rejects a review request, it seems to mark him for next for assignment
Describe the issue
When someone rejects an assignment, for example because they are too busy now, the system seems to automatically mark that parson to "someone who has indicated he wants to be next in queue", which they definately have not done.
As a secretary I always need to go and edit those users information and remove that checkbox from them before I can continue my assignments, as otherwise it will try to assign next document to them, which they will reject as they are still busy etc.
Code of Conduct
- [X] I agree to follow the IETF's Code of Conduct
The reject workflow may need to have an explicit "why" added if it's not already there. This was added because of people rejecting documents because they had a conflict of interest that the review system didn't already detect, and they should go review something else instead.
That said, People who are too busy should be marking themselves as unavailable (or you should do this for them for the period that they are too busy for.
Robert Sparks writes:
The reject workflow may need to have an explicit "why" added if it's not already there. This was added because of people rejecting documents because they had a conflict of interest that the review system didn't already detect, and they should go review something else instead.
That has not happened ever on secdir. All rejections have happened because people suddenly find out that they are too busy to do review, especially if the document they got to be reviewed happened to be long...
That said, People who are too busy should be marking themselves as unavailable (or you should do this for them for the period that they are too busy for.
Yes, but usually they notice they are too busy to do reviews after they get review assigned... Also as they only get review requests every 2-3 months, they might not want to bother to mark themselves unavailable for every single one or two week time.
@.***
It does happen at genart, and a radio button at the reject step would let the right thing happen for either use case.
Checking this, it seems to mark them to be next in queue ONLY if you are using the RotateAlphabeticallyReviewerQueuePolicy.
LeastRecentlyUsedReviewerQueuePolicy will simply ignore the rejected/withdrawn reviews. Is the genart also using the rotate alphabetically policy?