CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

From Expertiza_Wiki
Jump to navigation Jump to search

E1698: Instructor/student control of anonymity + group-based reviewing

Introduction

Purpose

The scenario: An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them. For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members. Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

What needs to be done: The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.


Scope

The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

Background

Expertiza is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using Ruby on Rails framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments. Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

Design

Assignment Creation:

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

Group Formation:

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed. In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team. Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

Non Anonymous Reviews

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

Design

Key People

Developers

  • Bhavesh Kasliwal
  • Bhavya Bansal
  • Chinmoy Baruah
  • Rishabh Sinha

Mentor

  • Ed Gehringer