CSC/ECE 517 Fall 2019 - E1994. Mentor management for assignments without topics: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(79 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== '''Problem Statement''' ==
For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic  However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects.  The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.
== '''Links to the project''' ==
Github Pull Request: https://github.com/expertiza/expertiza/pull/1651
<br/>
Video Presentations:
https://youtu.be/fyAiyzUsHH4
https://youtu.be/KBdiqPe-wLE
https://youtu.be/avjdLbw28K8
<br>
Deployment: http://152.46.18.18:8080
== '''The goal behind this project:''' ==
== '''The goal behind this project:''' ==


#When a rubric is replaced or the items/questions attached to it are changed, all the active students’ responses object to that rubric will be deleted are created again, that means students need to redo the reviews if they have already done.
Develop a trigger that:<br>
#The system will email the students who have done reviews to notify a redo request after deleting the response object and all associated answer objects.
1) Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity<br>
#The “active” in the first goal means the replacement action happened during the task duration and the student responses have done in the task duration before the replacing rubric action. For example, a rubric starts from Sep.9th and ends at Sep.13th. An instructor replaces the rubric on Sep.12th, when 60 of 100 students have already finished their reviews. Then the response objects will be deleted and re-created to be new objects in the system, and students need to redo their reviews based on the new rubric.
*ex) max members = 4, trigger activated when the team size reaches 3
#Write comprehensive tests for the above implementation to confidently prove they are correct.
2) Assign a mentor to the team<br>
*Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
3) Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.<br>
4) Possibly notify the team members that they have been assigned the mentor with contact information (further discussion here)<br>


== '''Design Pattern''' ==
Since the trigger we implemented would need multiple handlers and each of them responses in different actions, we decide to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.<br>
[[File:Chain of Responsibility.png]]
<br>Implementation for our project<br>
[[File:CoR.png]]
== '''Project Description''' ==
== '''Project Description''' ==


=== Old version: ===
For assignments without a topic, there is no way to assign a mentor to the team on Expertiza system but to manually assigned one via Email out of the system.
[[File:Assign Mentor.png]]
<br>In the above case, there is no mentor role for the current Expertiza system, only to assign mentor manually
=== New version: ===
Assignments with or without a topic could be assigned with mentors automatically<br>
[[File:AddMentor.png]]
<br>Also, mentor and team members will be notified by Emails (Results showing in UI Test).


=== Current version: ===
== '''Design Diagrams''' ==


=== Workflow Diagram ===
General workflow and specific add member workflow<br>
[[File:usecases.png]][[File:specific_workflow.png]]


The function classification change as two kinds: Minor change & Major change.
== '''Proposed Solution''' ==
 
Minor Change defined as the change makes no difference to reviewings so that we could also use reviewing before change made.(e.g. Delete questions or clarify the statement).
And Major change would modify or add some new questions which can’t be found in previous rubric. In such situations, system would delete all related reviewing records and email those reviewers to redone reviewing.


=== Predict version: ===
'''The solution we proposed generally follow the chain of responsibility and the work flow'''<br>
'''The solution will follow steps list here:'''
*Allow instructor to assign mentors for assignments without a topic
*Check the topic of assignment and number of team members whether reach the requirement or not
*Assign mentor for the team automatically
*Notificate both mentor and student
*Team member added after the mentor assignment will also get a email notification about mentor




For Minor changes, we still make no movement to database since it makes no effect on scoring process. But Major changes have to be made further development as concerning about Time.


Time_1: Changes should be determined if it is changed in duration, when some students have started and the others not. If change isn’t made in this period it would have no effect.
== '''Code Implementation & Explanation''' ==
Since we implemented a whole new feature and kept the original work flow unchanged at the meantime, most modifications are in models:<br>
Models:
*app/models/assignment_team.rb
*app/models/assignment_participants.rb
*app/models/team.rb
*app/models/team_users.rb
*...
<br>
Views:
*app/views/student_task/view
*app/views/student_teams/view
*app/views/shared_scripts/_add_individual
*app/views/participants/_participant
*...<br>
Here we present some essential codes with explanation<br>
[[File:Mentor_role.png]]
<br>First, add mentor role for assignment. Set authorization for mentor which could not do review, take quiz or submit.<br><br>


Time_2: When changes are made at reviewing period, we should make a further consideration about record in DB. The records which were made in this period should be deleted but records in previous semesters are supposed to maintain.
[[File:Add_mentor_view.png]]


== '''Design Diagrams''' ==
<br>Add a mentor role for instructor/admin when add participant for assignment<br><br>
=== Use case Diagram ===
[[File:Ucdiagrame.png]]


=== Data Flow Diagram ===
[[File:DesignFlow.png]]


The main goal of the code is to edit the rubric. There are 3 types of action: edit, add, and delete questions. We classify these actions into two types: major change and minor change.
[[File:Mentor_requirement.png]]
<br>To assign a mentor, there are several requirements:
*There should be at least one mentor in this assignment
*The current team size is greater than half of max size
*The team do not have a mentor yet
<br>


Note: Editing questions refers to editing only the text of the questions. Changing the type (multiple-choice, simple-text...) of a question is not allowed in Expertiza. You have to delete the old question and add a new one.
[[File:Assign_algorithm.png]]
<br>Always assign mentor with lowest number of mentoring teams, in order to do so:
*First, get all mentors for this assignment
*Traverse all mentors and calculate how many teams he/she mentored, store the one with lowest number
*Return mentor with lowest number of team she/he mentored<br><br>


Minor change: Edit questions. In this case, we simply update the text of the questions. There’s no other actions needed.


Major change: Add/Delete questions. In this case, we have to check if there are any reviews done by students in the active period, i.e. the period of time when students can submit reviews. If there are any, we have to notify the affected students by email asking them to re-submit a review using the updated rubric, and delete their old reviews.
[[File:Assign_algorithm.png]]
<br>Use Mailer class to send email notification about mentor and team members information(method used to send email notification for student is similar to this).<br><br>


== '''Test Plan''' ==
To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.


== '''Proposed Solution''' ==
*Run and pass existing RSpec Tests after Modification
*Develop New RSpec Tests for the new features
*UI testing on the deployed project
==RSpec Test==
1. Add new participant type mentor in factories.rb<br>
[[File:Mentor_factory.png]]<br>


'''The solution has five parts:'''


* Check the changes made by instructor. Major or minor?
2.Test new added method in team_respec, like half, add_member, size...<br>
* Check if the change to the rubric is made during the task duration (or if there is any active response?).
[[File:Add_member.png]]<br>
* Process updates when a major change is made.
[[File:Half.png]]<br>
* E- mail notification is sent to request students to redo their reviews.
* Test the implementation thoroughly.


=== Check if the change to the rubric is made during the task duration ===
==UI Test==
1. Instructor/Admin add mentor for specific assignment<br>
[[File:AddMentor.png]]<br>
2. Student create team and invite others<br>
3. When team size greater than half of max size, assign mentor and send emails<br>
[[File:Members_email.png]]
[[File:Mentor_email.png]]<br>
4. When student accept from a team which has already been assigned with mentor, he/she would receive a email<br>
[[File:New_member_email.png]]<br>


After a change is made, the system will check if the date is during the task duration to determine whether it needs to update existing response objects. The function method will get params as the start time and expire time of the target rubric to proceed a checking. If the change is not during an active task duration, then nothing further needs to be done. If the change is during an active task duration, then the system will do the following work.
5. Also we extend our work to make all teams visible to mentors<br>
=== Check the changes made by instructor. Major or minor? ===
[[File:Extend_work.png]]<br>
Changes are categorized to be major or minor. Minor changes affects only the wording of a particular rubric item. In this case, no action is necessary. Major changes involves rubric replacing and changing items/questions. In this case, all the reviews that have been done need to be redone. To tell a major change, the params passed to the controller includes a tag/identifier that indicates if a new question was added, hence a major change.
=== Process updates when a major change is made. ===
If the previous process returns that a major change has been made, the system deletes existing response objects and re-creates new updated object in database when a student press on “review”. As for minor changes, updates affects only the objects that created after the change.
=== E- mail notification is sent to request students to redo their reviews. ===
Once controller notice instructor makes a major change of the rubric, and some students have begun the peer review, email notification module is initiated. In this circumstance, the system will generate ActiveRecord and send it to those students. (Their email address could be found in user’s table.) After email successfully sent, record of this student in this assignment and period will be deleted from the database.
When students receive the email and update their review, the questions now correspond to the new rubric. And students can see all the details of the old questionnaire in the email, so they won’t have to rewrite the same questions’ answer.
=== Test the implementation thoroughly. ===
Our test is designed to three parts: common cases, invalid cases and extreme cases. Details of test plan are included in the Test Plan section below.


== '''Code Change''' ==


== '''Future Work''' ==
1. Mentor could not see teams' submissions since authorization control is working on the view assignment page and mentor does not have rights to submit<br>
2. Rspec Test for email functions


== '''Test Plan''' ==
== '''Team Member''' ==
Each component of the system is tested in a dedicated test file in the spec directory, and the test file name is according to the function tested. Our unit test is accomplished in questionnaires_controller_spec.rb. We should test each (reasonable) method of the controller with at least the following scenarios:
Our team members: (Sorted in Alphabetical order)<br/>
* Common Cases
*Hongli Wang, hwang85@ncsu.edu
** If the instructor only edit a particular rubric item (e.g. to clarify the statement), no action is necessary.
*Minghao Liu, mliu25@ncsu.edu
** If the instructor only delete a particular rubric item (e.g. to delete one of the peer review's criteria), no action is necessary.
*Ruiwen Wu, rwu5@ncsu.edu
** If the instructor add a particular rubric item (e.g. to add a peer review's criteria) in the student peer review period, the controller should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects. (However, the response_map should not be changed.)
*Siwei Wen, swen4@ncsu.edu
 
* Invalid Cases
** If the instructor add a particular rubric item (e.g. to add a peer review's criteria) out of the student peer review period, no action is necessary.


* Extreme Cases
Mentor: Mrs. Carmen Aiken Bentley
** If the instructor change the whole rubric (e.g. to delete the old rubic, create a new rubic and assign it to this assignment) in the student peer review period, the controller should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.  (The response_map should be changed since the id of rubric change.)

Latest revision as of 00:54, 14 April 2020

Problem Statement

For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

Links to the project

Github Pull Request: https://github.com/expertiza/expertiza/pull/1651
Video Presentations: https://youtu.be/fyAiyzUsHH4 https://youtu.be/KBdiqPe-wLE https://youtu.be/avjdLbw28K8
Deployment: http://152.46.18.18:8080

The goal behind this project:

Develop a trigger that:
1) Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity

  • ex) max members = 4, trigger activated when the team size reaches 3

2) Assign a mentor to the team

  • Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.

3) Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
4) Possibly notify the team members that they have been assigned the mentor with contact information (further discussion here)

Design Pattern

Since the trigger we implemented would need multiple handlers and each of them responses in different actions, we decide to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.

Implementation for our project

Project Description

Old version:

For assignments without a topic, there is no way to assign a mentor to the team on Expertiza system but to manually assigned one via Email out of the system.
In the above case, there is no mentor role for the current Expertiza system, only to assign mentor manually

New version:

Assignments with or without a topic could be assigned with mentors automatically

Also, mentor and team members will be notified by Emails (Results showing in UI Test).

Design Diagrams

Workflow Diagram

General workflow and specific add member workflow

Proposed Solution

The solution we proposed generally follow the chain of responsibility and the work flow
The solution will follow steps list here:

  • Allow instructor to assign mentors for assignments without a topic
  • Check the topic of assignment and number of team members whether reach the requirement or not
  • Assign mentor for the team automatically
  • Notificate both mentor and student
  • Team member added after the mentor assignment will also get a email notification about mentor


Code Implementation & Explanation

Since we implemented a whole new feature and kept the original work flow unchanged at the meantime, most modifications are in models:
Models:

  • app/models/assignment_team.rb
  • app/models/assignment_participants.rb
  • app/models/team.rb
  • app/models/team_users.rb
  • ...


Views:

  • app/views/student_task/view
  • app/views/student_teams/view
  • app/views/shared_scripts/_add_individual
  • app/views/participants/_participant
  • ...

Here we present some essential codes with explanation

First, add mentor role for assignment. Set authorization for mentor which could not do review, take quiz or submit.


Add a mentor role for instructor/admin when add participant for assignment



To assign a mentor, there are several requirements:

  • There should be at least one mentor in this assignment
  • The current team size is greater than half of max size
  • The team do not have a mentor yet



Always assign mentor with lowest number of mentoring teams, in order to do so:

  • First, get all mentors for this assignment
  • Traverse all mentors and calculate how many teams he/she mentored, store the one with lowest number
  • Return mentor with lowest number of team she/he mentored



Use Mailer class to send email notification about mentor and team members information(method used to send email notification for student is similar to this).

Test Plan

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

  • Run and pass existing RSpec Tests after Modification
  • Develop New RSpec Tests for the new features
  • UI testing on the deployed project

RSpec Test

1. Add new participant type mentor in factories.rb


2.Test new added method in team_respec, like half, add_member, size...


UI Test

1. Instructor/Admin add mentor for specific assignment

2. Student create team and invite others
3. When team size greater than half of max size, assign mentor and send emails

4. When student accept from a team which has already been assigned with mentor, he/she would receive a email

5. Also we extend our work to make all teams visible to mentors


Future Work

1. Mentor could not see teams' submissions since authorization control is working on the view assignment page and mentor does not have rights to submit
2. Rspec Test for email functions

Team Member

Our team members: (Sorted in Alphabetical order)

  • Hongli Wang, hwang85@ncsu.edu
  • Minghao Liu, mliu25@ncsu.edu
  • Ruiwen Wu, rwu5@ncsu.edu
  • Siwei Wen, swen4@ncsu.edu

Mentor: Mrs. Carmen Aiken Bentley

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics&oldid=133466"