Modular architecture of the Workshop module
Modularity is one of the key features of Moodle. We have pluggable modules almost everywhere around a Moodle site: course activities, course formats, enrolment plugins, question types, authentication plugins, content filters, side blocks etc. Plugins may define their own database tables, permissions and language strings. Having independent modules implementing the given interface allows developers to relatively easily extend the standard distribution and customize it for their needs.
I have decided to follow the principle of modularity in the new Workshop module. The core of the module defines the required behaviour for the main features. Then, there are plugins that implement the functionality of the given component. Workshop consists of three main process components: submission, allocation and assessment.
The process of a student’s work submission is controlled by a submitter. Technically, submitter is an instance of a class implementing the submission interface. Its main purpose is to render a submission form and save submitted data. There will be a default submitter shipped with the workshop, which offers a submission of an online text with optional attachments.
The process of allocating submissions for review is controlled by an allocator. Allocator is a tool that assigns submissions to peers to be reviewed. So far, I plan to have two allocators available: Random allocator and Manual allocator. As the name suggests, random allocator implements the behaviour of the pre-2.0 Workshop. The manual allocator is a new feature that allows teachers to manually assign submissions. See the screenshot of the user interface (click to enlarge).
The screenshot of the manual allocation user interface
Other allocators can be simply added by writing a custom class that implements the allocation interface. So, I can imagine a plugin called Sorting Hat that checks the students’ grades received so far and tend to assign a work to a reviewer at the same grade level, for example. Similarly, the method described in a paper by Joan Codina and Josep Fontana can be implemented as an allocator. The important point is that allocation can be combined. For example, teacher can allocate several submissions manually and then let the rest of submissions allocate randomly.
Finally, the process of assessment is controlled by so called grading strategy. Grading strategy encapsulates the assessment form definition and the computation of grades. Four default plugins that implement this component will be available and they are described in the Workshop 2.0 specification.
So far, I have working drafts of the core code and some component plugins implemented. I have refactored them several times and I suppose I will probably do yet in some details. During the development, I am still learning the object oriented style of thinking. Luckily, there are three new friends that help me with this task: git branch and rebase, unit testing and design patterns 
