Community
Participate
Working Groups
Created attachment 172467 [details] Summary task page
Created attachment 172468 [details] Wizard for creating new reviews
Created attachment 172469 [details] Reviewing a patch
Here are comments from the R4E gang since we are on holiday on June 24th. Summary task page: - Should patch reviews be restricted to only one reviewer? - Should patch reviews be restricted to only one comment? Wizard for creating new reviews: - It is good practice to add step numbers in Wizard at the top of the page (e.g. step 2 of 3). - In page two, how are file added? Is this page listing all files attached to the bug? Or is this where users will attach diff files? - In the third page, the UI should allow more than one reviewer. - In the third page, should there be a pull-down menu with list of reviewers? I guess those should be pulled from the repository. Another option is to support auto-complete when users enter the e-mail address. Reviewing a patch: - There seems to be only room for one comment for the whole review. It could happen that reviewers has comments on more than one file. Actually the scope section looks very good. Shouldn't there be a similar section for anomalies or review findings where users could see the list of files, the line range that applies to an anomaly and the actual reviewer comments/description of the anomaly (those could who up in the marker section of the editor)? We can discuss further if you want. - In R4E, we have a check mark for each file (in the scope area) to help reviewers keep track of what was reviewed so far. It might sound like an overkill for patch reviews, but some patches can get quite large... - What is the difference between the "Submit" and "Submit Review" buttons? Wouldn't it be simpler to only rely on the "Submit" button for any bug or review changes? There is also a "submit" radio button in the scope section. There is an opportunity to simplify that part. Other comments: -We are not very familiar with ReviewClipse. Shouldn't there be a UI portion to capture the fact that the patch author has implemented the anomalies/commments of the reviewer? Maybe by assigning the review back to the author and changing the status to reflect? Or maybe that is taken care of by resolving/closing the bug. -It would be good to keep a review history somewhere a bit like Bugzilla does it already. That's all we can think of for now.
Created attachment 173789 [details] Review editor embedded in the task editor
Created attachment 173790 [details] Create review in context menu.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
