CSC/ECE 517 Spring 2019 - Project E1924. Regulate changing of rubrics while projects are in progress: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 19: | Line 19: | ||
Further descriptions about how the project will be implemented and what files will be changed are mentioned in subsequent sections. | Further descriptions about how the project will be implemented and what files will be changed are mentioned in subsequent sections. | ||
== | =='''Proposed Solution'''== | ||
The solution is divided into 2 phases viz. Identification of edit and Notification. | The solution is divided into 2 phases viz. Identification of edit and Notification. | ||
===Identification of edit=== | |||
When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question and a minor edit corresponds to editing any existing questions. The params passed to the controller also includes a tag/identifier if a new question was added. We plan on using this identifier along with the number of questions to identify it the changes made were major or minor. | When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question and a minor edit corresponds to editing any existing questions. The params passed to the controller also includes a tag/identifier if a new question was added. We plan on using this identifier along with the number of questions to identify it the changes made were major or minor. | ||
Revision as of 00:43, 9 April 2019
Regulate changing of rubrics while projects are in progress
Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). It consists of multiple features, one such feature is the ability to setup an assignment by an instructor. While setting up an assignment, the instructor would be asked to choose different kinds of rubrics. Any of these rubrics can later be edited or changed to a different rubric. A problem arises when an assignment is underway (students have already started reviewing) and a rubric is edited or changed. Some students started reviewing with the old rubric and the rest of the students who had not started a review will be presented with the updated rubric. This usually happens when an assignment is copied from a previous year and the rubrics are not updated to match the current topic. It could be at a later point that the instructor/TA realizes this and changes it. The goal of this project is two-fold: One, If a rubric is replaced, or the items/questions are changed, then all the reviews that have been done need to be redone and two, the system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.
Setting up and Building the Project
Follow the Guidelines mentioned in the read me page of the project's Wiki Page for building the Project in a Local Environment.
Project Description
Current Scenario
Currently, when an instructor updates a questionnaire rubric of an ongoing assignment, the reviews are not reset and moreover, no notifications are sent to reviewers to update them of the changes made. Moreover, the instructor, post making changes, would have to individually inform each reviewer of the changes made and ask them to change the reviews accordingly.
Expected Solution
The project aims to resolve the two main issue arising from the problems mentioned above:
- If a rubric is replaced, or the items/questions are changed, then all the reviews that have been done need to be redone
- The system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.
Further descriptions about how the project will be implemented and what files will be changed are mentioned in subsequent sections.
Proposed Solution
The solution is divided into 2 phases viz. Identification of edit and Notification.
Identification of edit
When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question and a minor edit corresponds to editing any existing questions. The params passed to the controller also includes a tag/identifier if a new question was added. We plan on using this identifier along with the number of questions to identify it the changes made were major or minor.
E-mail Notification
Once this solution finds that the rubric has major edits and there exists some user who has started the response (corresponding records exist), email notification module is initiated. In this phase, these records are pulled from the ActiveRecord and sent to the user through email. Once the email is sent successfully, records are deleted from the DB.
At this stage, the user has all the details already added by them and when they click on "Review", the questions now correspond to the new rubric. This lets the user to edit on the new rubric without losing data for any question. One of the motives behind sending these responses as email is that the first few questions in the review may be similar across rubrics and the user may re-use the same responses when prompted with the new rubric.
Proposed Code Change
Test Plan
The current rspec file describes various contexts for testing such as adding new questions if attributes weren't correctly entered etc. As stated in the earlier sections, the update method of the questionnaire controller would be edited to identify major changes and trigger emails and deletions of records of responses. A context corresponding to this in the spec file for questionnaire controller under the describe block for update would be added.
At this moment we are thinking of at least 2 new test cases, both these cases correspond to editing a rubric:
- If there is no new question added and the question id's match with the ones in the record - validate the existence of the record
- If there is a new question added - assert if the email was sent