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

 * Dev work started on Education Program extension.
 * Detailed design available
 * Roadmap available
 * Demo wiki here

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 into an off-site tool (after students list themselves on their course wiki page) with an automatic process, integrated with the user signup process on Wikipedia itself (but not dependent on it).

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
 * Sitename shouldn't be part of the special page name (this might be useful in other contexts/projects). Not sure if it would be additionally worth generalizing to the level of allowing multiple "education programs" to exist. As long as permissions are set up in such a way that the community can easily add universities and courses, and the folks running the program (Frank etc.) are OK with that, having a single directory is probably sufficient.--Eloquence 19:20, 28 November 2011 (UTC)
 * Yeah, I'll just name it Special:EducationProgram. I don't think it's useful to add support for multiple programs right now, but this can always easily be done later on if it turns out we need it. --Jeroen De Dauw 21:18, 10 December 2011 (UTC)
 * 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. yes, students will enrol in terms of courses


 * Can a single student be enrolled into multiple courses? - yes they can


 * Do we want to keep old data, such as passed courses, accessible to teachers and students? - keep old data, read only courses after they ended


 * 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. - use institution

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.

Documents

 * User requirements:
 * Specifications:
 * Software design document
 * Test plan:
 * Documentation plan:
 * User interface design docs:
 * Schedule
 * Task management:
 * Release management plan:
 * Communications plan:
 * Status updates