Wikimodule
|
Wikimodule
I have been asked to lead a WMUK project to set up a distance learning system. We shall be using Moodle as course management system (CMS).
My approach has to been to abstract from WMUK's situation. What I call "wikimodule" is a system depending on three inputs (or four, if you included choice of CMS). In WMUK's case these are:
- The Training for Trainers system, leading to accredited trainers;
- the broad purposes of the community summed up as "the Wikimedia movement";
- the specific purposes defined by WMUK as a charity.
The system specification includes an auxiliary wiki. My default assumption is that WMUK would use this wiki as its auxiliary wiki.
Details of wikimodule under a CMS
- There is a concept of "good module". Any account holder can deem a module good. The stated objectives of a good module must include one that is concretely about the broad purposes of the system. The criterion for a good module is a box-ticking checklist.
- There is a concept of "featured module". Modules become featured by consensus of the trainer status group. Review of featured modules is by threaded discussion. The objectives of a featured module must include one that is concretely about the specific purposes of the system.
Details of wikimodule under its auxiliary wiki
The wikimodule work goes on on its auxiliary wiki in a number of namespaces and associated talk namespaces. There need to be portals: Portal:Education and Portal:Educational quality; the latter portal would be edited only by trainers, with discussion on its Portal talk page (open of course to all). There need to be namespaces for Topic, Lesson, Module and Workshop. Module and Workshop pages must have a Lesson page transcluded into them to be well-formed. Besides its Lesson, a Module page must be named after and link to a module on the CMS and include metadata from its associated module.
Initial deliverables
To set up such a system, there are initial or baseline deliverables:
- Explicit list of topics, marked Y or N according as to whether there will initially be a Topic page or not. These can be divided into categories such as "Core topic" and "Outreach topic" for clarity. The community will then, after the initial population, take control of these categories and update them in lines with criteria (which will likely apply to individual categories).
- Explicit list of "module specifications" fit to populate the Lesson namespace. Topic pages without an associated Lesson page should be tagged at this stage: they are not obviously teachable, in other words, and the work should be done to investigate.
- VLE in beta. This will mostly consist of seeded modules, i.e. modules with content copied-and-pasted from existing CC-by-SA sources. The point is to do proof-of-concept.
- Good module package. This is the checklist for a good module, covering (a) format, (b) metadata that must be supplied, (c) standard header and footer.
In greater detail, I'm giving below a lightly-edited version of how I have proposed these to WMUK.
Topic Document
This document will be a long list of Wikimedia-related topics denoted Core, and a much shorter list denoted Outreach. Each will be Y or N for inclusion as baseline topic; obviously the point is clarity about the comment “we didn’t forget X, we actually left it for later”. Workshops and presentations on Outreach topics will initially form a disproportionately large part of seed material (less kindly called “text dump”). It is clear enough that updating the two lists should be by two independent review processes. Ephemeral presentation material is not likely to be upgraded to good module level in most cases, but its interest as a resource for teaching is quite otherwise. To be clear, we can be “inclusionist” at ordinary module level, “deletionist” in removing modules from public view, and also focused in our selection of topics (which only means we have a self-conscious scope that is reviewed by the community). The VLE does not have to be a Jack-of-all-trades. If we are concentrating on the featured level, i.e. pursuing excellence, we need to have a good answer to the question “why is having an excellent module about topic T key?” in mind, and not be driven solely by what writers want to write.
The compilation of the topic document requires a search that will turn up neglected areas, and should cover several directions. The Help: namespace on Wikipedia is one place to cover thoroughly. The outline of How Wikipedia Works I know intimately, of course. Most of its chapters fall tacitly into three “cells”, as we said at the time. Some cells, for example, the Main Page structure, are of interest but will become N topics. My pride and joy, “Life Cycle of an Article”, probably cannot be a topic in its own right. There is work to do in splitting up good material into topic-bound seed material, therefore.
There is work to do in reducing duplication and overlaps; and in getting the granularity sensible. The Honey-Mumford theory may enter in the background: all “how to” topics must be considered seriously for inclusion, at very fine granularity (as would follow from the theory) as being the most useful for some learners. (Example: short module that only answers the question “how do you add citation needed like that?” is perfectly viable.) Likewise FAQ material, including standard OTRS queries, should be worked over for similar clues.
Specification of modules
Some fundamental thinking may enter, and I'd want to consult on the completed topic document before getting too committed. We can agree that modules will have metadata fields, and that no module is good until all the fields are filled in. A topic may admit one or many sensible specifications that are within in it. Any module may have versions with the same spec.
The point of specification raises the question: are we sure that this topic can be taught in at least one way that would allow us to fill in metadata? Some topics may therefore have to be left aside at this stage. This is a way of looking at the traditional “aims and objectives” discipline, naturally, and will throw light on ambiguity of aim. E.g. the topic of blocks could be taught to educate the blocker or the blockee.
Emphatically this will be a baseline list, for later revision. The list will be presented with explicit audience levels A, B, C and X included in the title.
Since the approach will be driven by the metadata, the result will be a sort of catalogue, necessarily incomplete. It will
- exclude some topics (parked as not yet having a plausible lesson, let us say);
- be well-populated, i.e. represent a fair cross-section of teaching aims at least;
- enable the process of pasting in placeholder text to be done sensibly as a first pass.
VLE in beta
This will be the first implementation of the VLE, and will serve as proof-of-concept. Placeholder CC-by-SA text will seed a representative range of modules as specified in (2). The VLE will be a Moodle system with hosting arranged by WMUK. In order to demonstrate the concept of editable metadata a related wiki may also have to be set up (by WMUK). The VLE as delivered will include sample good modules.
Good modules package
“Good module” is the short and familiar form of “WMUK standard module”. The specification will include: construction of metadata; standard module header and footer; consistent format per a short manual. It will be accompanied with a rationale directed at trainers. The complete package will therefore amount to
- a checklist for good modules such as could be applied by any account holder on the VLE,
- annotated with remarks that explain what is going on at the educational level, consistent with the Honey-Mumford theory and
- explaining at the level of intentions the upgrade path to featured module.
| Wikimedia UK education projects |
| Annual Conference — Campus Ambassadors – Student Societies — Schools — Committee — VLE |