Management and Process

May 21, 2003 (Yue)

1. Idea

1.1 The proposed model

Interested parties may create a topic in the proposed Web site of the project. A topic contains modules and submodules that are related by a composition relationship. (A submodule may also be divided into units?) A submodule may belong to a module. A module and submodule may have many artifacts:

• Lecture notes
• Examples
• Homework assignments (with or without solutions)
• Programming assignments
• Examination questions
• Resource links
• Briefs
• Additional information
• Supporting software

A topic also contains other items besides modules and submodules:

• sample courses: that are made up of a subset of modules and submodules.
• FAQ?

The creators of a topic are the working group (WG) of the project. The Website must have some say on whether a topic is allowed or not (to avoid duplication, assure quality and enforce content policy; for example, a topic on "how to be a suicide bomber" will be inappropriate.) Exactly how this is done will require additional study.

There may be only one person in a WG. The WG can invite more people to join the group. The WG makes the ultimate decision on the structures of the topic (modules, submodules, units, relationship among them.) The WG is also responsible for the quality assurance of the project. It may solicit helps in content development and/or reviewing.

Whereas the Website provides support reviewing and provide examples in the review processes for the WG to choose from, the WG will decide on how review is done. It will determine on a voting mechanism and arrange a way to coordinate with the content developer on editing (for example, either WG or the content developer may do the editing.) This flexibility allows the broadest set of coursewares can be developed while retaining the ability to have formal reviews. Our assumption is that as a topic becomes very popular, it will be to the benefit of WG to have more formal review, and the user community may demand it. On the other hand, on relatively minor and obscure topics, an "one man band" may still be welcome (there are a lot of one man bands in open source software development.)

...

1.2 Design Criteria

• The process should be designed using the following criteria, which may sometime be conflicting:
  • relatively simple: so it can be supported easily by a Website.
  • flexible: Topics can vary a lot. Some topics may only require one lead. Others may require a group. Labs and examples may be important to some topics. Briefs and discussions may be important to others. The submission/review/editing/decision process must be flexible to accommodate different requirements of these topics.
  • efficient: update/feedback loop/decision should be quick and can be efficiently supported by the Web.
  • quality assurance: some review processes may be established. Whereas the only lead person may do the review himself for some topics (e.g. "Peasant dressing clothes in early Ching Dynasty"), the WG may want to set up a semi formal review mechanism (reviewers may be invited) for other topics (e.g. computer security).
  • reward system: the process should include certain reward system (having some review mechanism and the attribution license will help, for example. Maybe we can also add some 'notification' license to find out who is using the courseware so we can post them in the Web.)

2. References