Wikipedia Education Program

Purpose of this document:


 * Describe what functionality is needed for the Wikipedia Education Program, and how they can be implemented.
 * Estimate the complexity/feasibility of implementing features, and how long it would take, so we can decide which ones to go for, in what order.
 * Provide current status updates about the development of these features.

Status
No dev work started yet - figuring out what to implement and how.

New features
The new functionality would go into some new extension specially created for the Wikipedia Education Program.

I put the last section of the spec first here, since it makes more sense to start with that one when creating this extension.

Course management
Currently the process of creating courses and managing data linked to them is rather ad-hoc. The extension would provide interfaces for creating and managing courses and linked data.

Signup and tracking of students
The main goal here is to replace the current process of manually aggregating student names (after students list themselves on their course wiki page) into an off-site tool to an automatic process integrated with the user signup process (but not dependent on it) on Wikipedia itself.

On the course pages, a link is provided for enrolling in the course for logged in users, or signing up and (simultaneously) enrolling. Much like done in the Contest extension. Teachers can then either provide their students with this link, or point them to the course page where they can then click it themselves.

Users would have a page where they can manage their courses (Special:MyCourses?). By default a link to this page would appear in the top link menu, but it can be disabled via user preferences.

Course reporting and monitoring of student contributions
Several groups need to be able to either access the course and student data (including student activity) or summaries of this data.


 * Teachers want to be able to track their students progress so they can appropriately guide and grade.
 * Students want to be able to see their own progress - this is not in the spec, but KA does it, and it does not seem to hard if you already make this available for teachers anyway
 * Wikipedia ambassadors and other veteran contributors want to see what students are working on, to provide support/guidance where needed
 * Several parties, including the WEP itself, want to be able to get to all data and summaries, to analyze the success of the program and find trends.

So we'd have several interfaces:


 * Special:WikipediaEducationProgram: lists summary data about the whole program
 * Special:University: lists universities, Special:University/$name lists courses for the university and summary data
 * Special:Courses: lists all (current) courses, Special:Courses/$name lists students and summary data
 * Special:Students: lists students, Special:Students/$name shows detailed course progress data
 * Special:MyCourses: lists the same course progress data as Special:Students/$name does for user $name
 * All data accessible via the API (to those who have sufficient privileges)

Open questions

 * How do we want to handle different iterations of the same course? Instead of having "AI at Stanford, Fall 2011" as a course, we might want "AI at Stanford", and then have a "Fall 2011" "instance" of it. This would make it a lot easier to track trends of a course over multiple iterations.


 * Can a single student be enrolled into multiple courses?


 * Do we want to keep old data, such as passed courses, accessible to teachers and students?


 * How will we make the course and university management robust? In other words, how to make it as open as possible while not making it vulnerable to vandalism. How open does it need to be to being with? (Who needs to be able to manage this data?)


 * Remark: University in this document should probably be replaced by a more generic term.

Time estimation
Without detailed progress stats and fancy visualizations (so just the basic functionality and summaries), creating the extension ought to not take longer the the Contest extension, which took about 50 hours. The effort required in detailed progress stats and fancy visualizations ofc depends on what we go for. It can probably be seen as "optional niceness" for which we "can go as far as we get if we have time".

Code review will take several hours. Testing will also take some hours. Ideally we cab get a preliminary version running that can be tested by people that will be using it before it actually goes live, so we can hold their feedback into account and have an extra guard against bugs.