E2145. OSS Project Beige: Difference between revisions
| (2 intermediate revisions by one other user not shown) | |||
| Line 15: | Line 15: | ||
This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions. | This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions. | ||
[[File:Workflow-Diagram.PNG| | [[File:Workflow-Diagram.PNG|600px]] | ||
The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes. | The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes. | ||
| Line 53: | Line 53: | ||
==Testing== | ==Testing== | ||
===Rspec=== | ===Rspec=== | ||
[[File:Test_Ready.PNG|600px]] | |||
This basic test checks that a review gets status as "Ready" when the user requests for a new review. | |||
==References== | ==References== | ||
Latest revision as of 21:55, 20 October 2021
This wiki page provides description of changes made under E2145 OSS assignment for Fall 2021, CSC/ECE 517.
About Expertiza
Expertiza is an open source project based on Ruby on Rails framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.
Problem Statement
When a participant updates the submission after the reading the review comments, the reviewer will have to review it again when the second review cycle starts. However, since the reviewer may have multiple submissions to review, some of which are updated, and some that are not, it becomes difficult for the reviewer to identify the updated submissions that need attention. Currently there is no way of identifying the difference between updated and stale submissions.
Proposed Solution
For identifying the submission status of the project in next review cycle, the reviewer should be able to quickly identify the submissions that need attention. This can be done in the UI of the reviewer’s page. The submissions can be color-coded using a scheme like the one used in the “Review Report” page.
- Red – If the review has not been started
- Orange – If the review was started, but not completed
- Brown – Submission has been reviewed
This solution will allows reviewers to identify and prioritize their work without having to dig deep into individual submissions.
The following diagram illustrates how the control would flow. As the user acts on a review, the status of the review changes.
Tasks
The following would be the key tasks:
- Add a new model to track the status of a review
- Upon change of review stage, update the data in the database.
- Change color in the UI based on the status of the review.
Implementation
List of Changes
We came up with the following model to capture the status of a review.
We will keep of the stage a review is in. The following would be the three stages of a review:
- Ready : As soon as a student requests for a new review.
- Started : Once a student has started the review.
- Completed : Once a review has been submitted.
This will allow us to designate a unique color to each stage and update accordingly.
As soon as a review is assigned to a user, create a new entry in the Review Status table with the status of "Ready".
Once a student starts doing the review, we fetch the record from Review Status table and update the status to "Started".
Once a review is submitted from student's end we mark the status of the review to be "Completed".
Testing
Rspec
This basic test checks that a review gets status as "Ready" when the user requests for a new review.