POAS Assignment development

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Moodle 2.0

This was a proposition of Assignment module development from POAS department of Volgograd State Technical University. We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.

Assignment 1.9 improvements

Just several simple, but useful improvements that can be done in stable version too:

1. Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
2. New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
3. Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

Assignment 1.9 Refactoring

Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:

• 'types' will be no longer considered separate activities, just a option in the mod_form
• 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
• there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
  • no one is effectively an offline task
  • files (reworked upload) can serve for both single and multiple files uploads
• there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins

POAS Assignment Refactoring

We are planning to reorganize our code base. The main purposes are:

• make it more flexible,
• distribute a responsibility correctly.

Along the way, calls of deprecated functions and methods will be removed (e. g. Logging).

Key points are:

• Namespaces. All classes will be organized using namespaces (like java packages).
• Automatic class loading. Reduce usage of require().
• Usage of modern API. Events 2, Logging 2, etc.
• Advanced Grading Methods. The criterions will be replaced with a separate AGM plugin (POAS Criterial Grading Method or Accumulative Grading Method^{[Issue link?]}). The POAS Assignment will support AGM.
• Usage of Assignment 2 submission methods.
• A minor visual changes.

Known issues:

• The Assignment 2 submission methods does not allow their usage with other plugins (MDL-47344).

Planned namespace structure for mod_poasassignment is:

• classes/
  • model/
    • assignment
    • individual_task
    • ...
    • submission/
      • base
    • distribution+strategy/
      • base
    • grader/
      • base
  • view/
    • form/
    • page/
      • base
  • event/
    • instance_available
    • assessable_submitted
    • ...

New Features

Teams

 This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

Team is a group of students whose work will results in one submission. Teams features:

• submission is one per team, but a grade can be given on per-team or per-student basis
• teacher can define a minimum and maximum number of students in the team
• self-organization (with possibility of confirmation by teacher) or forced by teacher teams
• maximum date of team membership editing
• teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
• 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
  • teacher-defined roles is a list, from which one or several roles can be selected for students
  • if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

Individual tasks

Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:

• adding/editing/deleting of tasks by the teacher
• standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
• custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
• some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
• student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
• maximum dates of selection (and approval if necessary)
• column with task name (link to the task) when grading
• random filling of some task fields (number or menu mainly) on selection or approval
  • there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

User interface - tabs

Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;

• for students
  • if he is late to select a task/become a member of team
  • if he is late to submit work
• for teachers
  • if student from his/her group asks to delete him from team (or task change)
  • if there are students without task/team after date of last approval

Grades aggregation

Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

Grading semi-plugins

Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

maybe One user can get several tasks

That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

Tasks workflow

Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

• initially task is free (1)
• (1) student or teacher can create a team -> creating team (2)
• (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
• (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
• (2) after the team will have at least minimum number of participants -> have enough people (3)
• (3) all (2) operations still available
• (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
• (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
• (3) after the students (if allowed) approved a team and task -> ready (4) (if teacher approvment needed) or working (5) (students and teacher notified)
• (4) after teacher approval -> working (5) (students notified)
• (4) in case of teacher disapproval -> have enough people (3) (students notified)
• (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
• (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> await grading (6) (teacher notified)
• (6) the teacher can only grade a team in await grading status
• (6) teacher grades, but grade isn't final -> reworking (5) (students notified)
• (6) teacher gives final grade -> graded (7) (students notified)
• (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

Files handling

There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

1. assignment files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
2. task files - some file(s) that teacher want to give students before they start to work on particular task;
3. submission files - files that was submitted by a particular student (team);
4. reply (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

Implementation

New options

Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:

• use individual tasks
• use teams
• last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
• team options (active only if teams selected)
  • min and max count of members of team
  • the grade will be individual or one per team
  • if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
  • if teacher must confirm team membership
  • if all team members must confirm a submission before grading
• individual task options (active only if tasks is selected)
  • allow using same tasks - can several students do one task or all tasks must be different?
  • allow using same tasks in one group
  • individual date - allow individual due dates to the task
  • individual team members count - if teams used, can particular task override min/max number of students in team
  • teacher must confirm task selection
  • random task assignment

DB structure

The new db structure have such tables:

• poasassignment - main table which have new options :
  1. maxmembersontask - maximum count of members which must to do the task
  2. minmembersontask - minimum count of members which must to do the task
  3. mintaskonmember - minimum count of tasks for one member(needs discussion)
  4. maxtaskonmember - maximum count of tasks for one member(needs discussion)
  5. timedistrib - initial time for task distribution
  6. timeconfirmation - the date after that a student not may create/come into new working group
  7. timereception - start time for tasks reception
  8. flags - all binary options
• poasassignment_tasks - table for task list of instance of activity:
  1. name - the name of task
  2. descripiton - task "body"
  3. deadline - individual date for task reception
  4. factor - factor for grade
  5. maxmembers - maximum workgroup members on task
  6. minmembers - minimum workgroup members on task
• poasassignment_fields - define list of custom fields:
  1. ftype - type of the field
  2. name - name of the field
  3. showintable - additional column in table of tasks
  4. maxvalue - maximum value for the field(only numbers)
  5. minvalue - minimum value for the field(only numbers)
  6. optional - optional field?
  7. rndparam - if this field used to define filter for random selection of task
  8. rndshow - if this field will get random value on task selection (number or menu fields only)
• poasassignment_field_consts - define consts for the fields type of list
• poasassignment_values - values for particular task/workgroup
• poasassignment_workgroups - table for teams, also submissions stuff go there
• poasassignment_workgroup_members - members of teams, grade stuff go there:
  1. userid -
  2. grade - this is the grade for submission
  3. submissioncomment -
  4. format,teacher,timemarked,mailed - old fields of assignment_submissions
  5. ownrole - role which student want implement during task execution
  6. finalgrade - final grade(yes/no)?
  7. deletefrom - please kick me from this working group (or task)
  8. deletecomment - explanation why student needs to delete from this working group
• poasassignment_role - roles for the task:
  1. one task have many roles
  2. one student perform many roles

 Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --Oleg Sychev 11:12, 11 September 2009 (UTC)

Tabs

Info/submit

This is an initial tab, that will work basically the same as before.

New abilities:

• show additional dates (i.e. dates of last approval and so on)
• student: show individual task (?tasks?) when the individual tasks is selected
• student: show task status (see workflow of the task above)
• student: show team members (when teams used)
• student: can approve team and submission, select or type his roles
• teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
• teacher: the number of submissions will be showed as <need grading>/<all submissions>

Custom fields

This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

Tasks

New tab, accessible when individual task feature activated.

Abilities:

• teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
• student: browsing task list, viewing task details
• student (without teams): selecting a task
• student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

Grading

This is an evolved grading page (submission.php), for teachers use.

New abilities:

• the table will reflect a status of task (maybe with icons)
• individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
• teams: the table (and popup for grading too) will have two modes:
• teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
• grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
  1. team grades - each string represent a team
  2. individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
• make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
• dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

Capabilities

Current capabilities

• mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
• mod/poasassignment:submit - ability to submit a work
• mod/poasassignment:grade - ability to grade submissions

New capabilities

• mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
• mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
• mod/poasassignment:managetasks - ability to create, edit and delete tasks
• mod/poasassignment:managefields - ability to manage custom fields of tasks
• mod/poasassignment:finalgrades - can make grades final
• mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
• mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
• mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
• mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
• mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

Events

Events will be added in future releases.

Event name	Event data	Description
\mod_poasassignment\event\instance_available	contextinstanceid Poasassignment course module ID.	Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.
\mod_poasassignment\event\instance_unavailable	contextinstanceid Poasassignment course module ID.	Fired when time for submissions expired, course module hidden from students or deleted.
\mod_poasassignment\event\task_selected	contextinstanceid Poasassignment course module ID. userid Student's user ID.	Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)
\mod_poasassignment\event\assessable_submitted	contextinstanceid Poasassignment course module ID. userid Student's user ID.	Fired when the student adds a non-draft submission.
\mod_poasassignment\event\submission_graded	contextinstanceid Poasassignment course module ID. userid Teacher's user ID. relateduserid Student's user ID. other->isfinal Is this grade final.	Fired when the student's attempt is graded by the instructor.