2713: Reviewer, not author, should mark issues as resolved/reopened
- Fixed
- Review Board
| zk***@novad****** (Google Code) (Is this you? Claim this profile.) | |
| Aug. 5, 2013 | |
| 2853, 2854, 2867, 3077 |
http://reviews.reviewboard.org/ What version are you running? 1.6.9 What's the URL of the page this enhancement relates to, if any? Describe the enhancement and the motivation for it. Perhaps this has been discussed before or we are using reviewboard incorrectly, but the "issues" workflow does not make sense to me. If the reviewer opens and issue, only a reviewer (and preferably the originator of the issue) should be the one who can mark it as resolved, not the author. Having the author be the only person who can mark it as resolved is a bit like the fox watching the hen-house. Perhaps a 3-stage workflow is required, where an issue is marked "Open" by the reviewer, "Fixed" by the author, and finally "Closed" by the reviewer. There doesn't seem to be a way for the reviewer to indicate whether an issue has been properly addressed or not. What operating system are you using? What browser? Windows, Firefox Please provide any additional information below.
-
+ Component-Reviews
-
+ Reviewer, not author, should mark issues as resolved/reopened
A three-stage flow would work. It's a little inconvenient (and also odd) for the author to not be able to indicate that an issue is resolved. I'd be okay if there was a site policy to disallow authors resolving issues, but I'm not sure it is the best way in general. As long as a reporter can reopen an issue if they disagree with the author that it was suitably addressed (the aforementioned "way for the reviewer to indicate whether an issue has been properly addressed or not"), I don't have a problem with the author being able to resolve issues. For me, it's more important that the reporter have the *ability* to resolve issues (e.g. if the author forgets, or if they realize something they thought was an issue actually isn't, or even just made a mistake, etc.). I'd be inclined to call that a separate issue, which would be a dependency of this. FWIW, most bug tracking tools allow reporters to close their own issues, and "commiters" (i.e. privileged users) to close any issue (in this case, equivalent to authors closing issues with their requests).
"most bug tracking tools allow reporters to close their own issues" This usually can be set up in project settings. Regardless of this statement a reviewer is always able to re-open an issue in such tools. There are two options for him now, each of them has disadvantages: 1) Add a comment to the existent dropped/resolved issue - code owner can just miss it because it is not indicated in the opened issues list. So "no unresolved issues" -> "can submit the code" scheme is broken. 2) Add new issue - no connection with previous issue is supported by RB. So all arguments should be duplicated or searched somewhere. The current use model is inconsistent because of more general architectural flaw. RB does not have elaborated roles and permissions support. A PM can't be confident that the standard workflow that he set up is followed by engineers. Engineers can't be confident whether they are following formal procedures if they are allowed to do everything.