My role in the project is primarily that of lead developer. I'm trying to put together a team of people to do some contract work for the next couple weeks, so if anybody reading this is interested, let me know ASAP because there is real $$ involved. We're going to be setting up and configuring a MediaWiki server with several existing extensions. We're also going to be creating some of our own extensions to support the use of MediaWiki in a classroom environment (reviewing and grading features, etc). Some of the extensions we are interested in deal strongly with usability: FCKEditor and the Uniwiki Extensions. We're also looking to use things like the Collections Extension, FlaggedRevs, and the Quiz Extension (with modifications).
This group is interesting in pursuing a particular mechanism for peer review. Each student writes their own page, and then is responsible for reviewing another page or pages. They review the page, leave criticisms, and give grades. Then students have the opportunity to respond to criticisms left for them and grade their reviewers. So it's an interesting two-way grading system that teaches the teachers not only to write teaching materials, but also to generate high-quality reviews.
The project that I'm planning in my head to address this issue is a commenting and reviewing tool. Here are some thoughts about how it might work:
- When a reviewer right-clicks a page (or something else) a comment box is opened where they can enter a comment, a grade, and maybe some other metadata about the page, as required by their class.
- The review may include a short quiz for material understanding, a rubrik about the page, etc. I'm not sure whether the quizzes and rubriks will be editable or not from the wiki interface, or if they are intended to be standardized and read-only.
- The review is saved somewhere, either onto a page somewhere in the wiki, or in a custom database table. Each review will include some information such as the page name and section where the review was left, the grade, the name of the reviewer, and the state of the review (open, rejected, resolved). In this sense, it becomes very similar to an issue tracker.
- Comments that are rejected or resolved do not appear on the page anymore (but will be visible in either a special "comments history" page, or through another interface). In this way, students can keep track of what issues are outstanding.
- Only unhandled comments appear on the page for the author to see, and he has the ability to interact with it. The author has the ability to leave a counter-statement, and a review of the reviewer before marking the issue as resolved or rejected.
But, what WB needs isn't really an issue that this project is addressing directly. Once primary development on this project is over, we will be more able to focus some attention on getting these extensions and improvements folded back into the WB and WV projects as necessary.