Wikiversity talk:Introduction Overhaul Taskforce/copy

From Wikiversity

< Wikiversity talk:Introduction Overhaul Taskforce

The proposal (below) was copied from Wikiversity talk:Introduction Overhaul Taskforce. This is a workspace to translate the proposal into the same namespace terminology used at Wikiversity:Namespaces. --JWSchmidt 04:58, 21 May 2007 (UTC)

[edit] Wikiversity organisation proposal

Sorry for the late response. I am new to wikis and have spent some time researching on my local copy. I planned posting a complete proposal to colloquium, but things are moving faster here than I can keep up. So I'll do my best to sell the idea with what I know. This has the side-effect of revamping the Main Page and Community Portal.

[edit] The Problem

(My reference is Wikipedia, I know little about the other projects, so my conclusions may be off.)

Wikiversity combines all administration, educational, support, and website management across all the namespaces. This complicates creating contribution areas and educational areas, that is, there is no distinction made between those who come to study and those who want to contribute. There is no clear separation between regulations that apply to contributors and those that apply to students. Finally, the content structure presented to students emulates the school's structure.

Comments. "complicates creating contribution areas" <-- Is a wiki page a "contribution area"? Is a content development project a "contribution area"? "educational areas" <-- huge sections of Wikiversity are "educational areas". Do you mean main namespace pages? "those who want to contribute" <-- People who want to do serious content development will probably want to participate at the content development projects in the School and Topic namespaces. People who just want to find existing learning resources will probably use the pages in the Portal namespace as a way to find pages in the main namespace. The Main Page puts links to the major Wikiversity portals in a very prominent location. Each major portal links to related content development projects. This is the same system used at Wikipedia except that all Wikipedia content development projects are in the "WikiProject" pseudonamespace. "regulations that apply to contributors and those that apply to students" <-- I'm not sure what you mean by "regulations". Do you mean that there should be distinct help pages for people who only browse content and for people who create content? Maybe these distinct functions could be provided by pages such as Wikiversity:Student union and Wikiversity:Content development. I agree that there should be different "tracks" for different types of Wikiversity visitors and participants. Some ideas are at Supporting Wikiversity participants, Talk:Main Page and Main Page/Draft version 0.2.--JWSchmidt 05:26, 21 May 2007 (UTC)

[edit] Subpages proposal

The proposal is a more basic structuring of the wiki itself, rather than how that structure can or should be used. I presented it as it would appear to Wikiversitians in the (mistaken) belief that would be more understandable than a technical description.

Technically, the proposal is:

Each namespace is treated as a path name. Additions to the namespace are appended to an existing path. For example, namespace A can have the following paths:

A:one/foo/bar/baz
A:one/foo/baz/bar/widget1
A:one/foo/bar/bar/widget1
A:two/baz/widget1/

In the above example, A:one and A:two are the root names in the A namespace. Now, A:two/baz/widget1 is a completely different page to A:one/foo/bar/bar/widget1, but the name widget1 can still be used by everyone else. Similarly, the name bar is used in three different places; the page A:one/foo/bar is distinct from A:one/foo/bar/bar. Currently, only one person can have a page with the same name (say a FAQ), but with this scheme, everyone can without conflict:

A:one/faq
A:one/foo/faq
A:one/foo/bar/faq
A:two/faq

Similarly, the B namespace can also have:

B:one/faq
B:one/foo/faq
B:one/bar/faq
B:two/foo/bar/faq

Again, users in the B namespace are free to reuse the same names without conflict. Neither the A nor B namespaces need use the names of the other, nor have the same structure (compare A:one/foo/bar/faq with B:two/foo/bar/faq).

However, if each page in namespace A should have a corresponding page in namespace B, then we can do this:

A:one
B:one
...
A:one/foo/bar/baz/gadget
B:one/foo/bar/baz/gadget

Which allows editors to know what to call a page in either namespace and ensures that names are 'reserved'.

The above description refers to those parts of Wikiversity that seldom change, such as the School namespace. Once the school structure is in place, it will seldom need to be changed. Although each school can define there own subdivisions, these subdivisions are made from the given structure. For example:

School:one/first/second/third
School:two/first/second/third
School:three/first/second/third
..
School:onemillion/first/second/third

If school one wants to add a subdivision, it can do so, and so for all the schools:

School:one/boo
School:one/boo/baz
School:one/boo/bar
..
School:one/first/baz
school:one/first/second/baz

Now we move on to navigating the namespaces. Because A:one/boo has A:one in its name, we link A:one downwards to A:one/boo. Wikiversity automatically includes a backlink in the path name, so A:one/boo will link back to A:one automatically.

This means people can see the navigation structure from the path name. We know, for example, both A:one/boo/baz and A:one/boo/bar are linked to the same page A:one/boo, as shown below:

Here, boo (A:one/boo), has two links to bar and baz. This also means the boo page should say something about the bar and baz pages. The baz page says baz things while the bar page says bar things. And this is where I'm at when I wrote about separating contributor and student content. Page boo deals with both issues, briefly or just as links, bar details contributing while baz explains editing a page. The two issues are related but distinct sets of knowledge. A reader, who is not interested in either bar or baz, never has to wade through them just to find the boo stuff, although they're there anytime the reader wants to look.

This allows baz 'admins' to manage baz pages without editing the same pages as bar 'admins', nor discuss how bar|baz should co-exist on the same page. similarly, boo 'admins' need not worry about bar nor baz because that content is not on the boo pages.

Wikiversity admins (or schools or projects or anyone really) can take this further by saying the if you want to talk about bar things use a bar name, and if baz things, use a baz name. If you want to talk about both, then make a boo page and refactor into bar and baz. The pathnames don't carry any meaning themselves, but provide the framework for linking up the content in a meaningful way.

The above deals with top level structuring. The content, courses, materials and tools, all the things readers will want to learn and get knowledge from, are not structured this way (although they can be). This enables anyone to create random pages without destabilising the navigation system while still allowing similar freedoms as other wiki sites.

This is acheived by reserving a namespace for linking up the actual study material. Assuming A is the top level namespace (highly structured as defined above), the B namespace is used to connect the content with the A namespace. For example:

A:one/foo/faq
B:one/foo/faq
C:FrequentlyAsked_Questions
C:FAQ
C:questions+answers
C:whatyoumayask

In this case A:one/foo/faq contains an overview on frequently asked questions which 'admins' update as required. The B:one/foo/faq page lists the C namespace FAQs, while the C namespace is plundered by contributors. The B namespace correcponds to the A pathname convension and also navigating the C namespace. For example the B:one/foo/faq might look like this:

 *[[C:FrequentlyAsked_Questions|FAQ about baz]]
 *[[C:FAQ|FAQ about boo]]
 *[[C:questions+answers|FAQ about foo]]

 [[../ans|prev]] [[../zap|next]]  [[A:{{PAGENAME}}|top]]

Because the B namespace corresponds to the A and it uses path names, we can use relative path names which change when the page does. The linking can then be moved into templates which provides the overall structure, links, look, and feel. All an editor need do is add the template, content, and links (in this example the C namespace links).

The template pathnames correspond with the other namespace path names. So the page A:one/boo/baz will use template Template:A/one/boo/baz. In practice, this is unneccessary because the pages one and boo might need the same template and should not be duplicated. However, the templates Template:A/number/fear, are general enough to recognise Template:A/number should be used with A:one, and Template:A/number/fear with A:one/boo, but not A:one/baz.

So what we are left with is:

Reusable names
well defined top level navigation and structure
A connecting namespace between the top level and content material.
Easy to find templates that provide the navigation links, look and feel.
Separation of info into well defined names.
Freedom to contribute without extra restrictions.
A flexible structure that can be manage automatically because parsing path names is trivial, so grafting and pruning is relatively straight forward.
No requirement on what specific namespaces should be used for.

PeterMG 09:07, 21 May 2007 (UTC)

[edit] Comments about the use of subpages

This (above) seems to propose that ALL Wikiversity pages would be subpages. When there are situations where multiple pages need to use the same word (example: foo) in a page name there are several ways to do this. One is to use a disambiguation page and give each page a slightly different name such as Foo (biology) and Foo (computer science). The other alternative is to use subpages. Wikiversity encourages the use of subpages. Wikipedia does not allow subpages in the main namespace. Wikiversity does allow subpages in the main namespace, but there is no need to make every page a subpage. --JWSchmidt 15:31, 21 May 2007 (UTC)

"if each page in namespace A should have a corresponding page in namespace B" <-- I cannot think of a reason why this would ever be the case. Do you have an example in mind? --JWSchmidt 15:36, 21 May 2007 (UTC)
When there are large numbers of content development projects in a school, they can be organized hierarchically as divisions and departments in the "Topic:" namespace.

"If school one wants to add a subdivision, it can do so" The fact that Wikiversity has both a "school namespace" and a "topic namespace" is an historical accident that arose because of the way Wikiversity participants established content development projects at Wikibooks (see). In general, each Wikibooks "school page" was a list of related topics (example). Most of the pages for those Wikiversity topics at Wikibooks had no actual learning resources, they were mostly plans for future learning resources and they were usually called "departments" (like an academic college department). In short, the Wikiversity community had created two "levels" of content development projects; schools for large subject areas and topics/departments for content development projects concerning a narrow academic topic. When the Wikiversity website was started, two new namespaces (the school namespace and the topic namespace) were created so that we could import the Wikiversity content development projects into them. The only other "innovation" was providing a way to organize very large numbers of related content development projects. It was decided to have relatively few school pages but allow unlimited numbers of topic pages. Example: The Division of Basic Medical Sciences is a subdivision of The School of Medicine. Yes: we could have decided to put divisions like "The Division of Basic Medical Sciences" on subpages of schools, but that was not the choice that was made. See: Template:Original School boilerplate. --JWSchmidt 17:47, 21 May 2007 (UTC)
"top level namespace" <-- I do not know what that means. As far as I can tell you use the term once and never explain what it means. Some of what you wrote seems to imply that maybe the "top level namespace" is only edited by administrators (they are called custodians at Wikiversity). What would be the purpose of a namespace only edited by administrators? --JWSchmidt 21:50, 21 May 2007 (UTC)
"the page A:one/boo/baz will use template Template:A/one/boo/baz" <-- Why? Any template can be used on any other page, as needed. --JWSchmidt 21:50, 21 May 2007 (UTC)

[edit] Preamble

Okay, you're exposing a weakness in the presentation, which I need to clarify as a preamble. The propsal is built from the bottom up, not the top down. You are looking at the bottom layer here, but as the top view. The proposal is more structured in layers, where each layer is discussed with respect to each lower layer. The rationale for a bottom up approach is:

1. It separates the implementation (MediaWiki) from the website (Wikiversity).
2. It maximises the wiki's features
3. It uses the features as intended

Fundementally, the specification (as the preceding picture shows) mixes the requirement with the implementation. This is bad because it needlessly constrains website developers without adding value to users. It is sufficient to determine whether the requirement has been met, not the means used to meet it.

When requirements include implementation detail, it shows the requestor is confused about what a requirement is. A requirement is what the end-user experiences, regardless of methods used to effect that experience. The problem with Wikiversity's requirements is that those who wrote them have good experience with MediaWiki and therefore defined the requirements in terms of MediaWiki's functions and not the end-user.

For this reason my proposal ignores the implementation constraints (imposed by various wikiversity articles) and focuses on meeting their requirements by implementing an end-user (wikiversity contributors and readers) solution based on MediaWiki's features. Clearly, this will conflict with "implementation requirements", which should not have been specified anyway.

A good example of missuse are the 'portals'. wiktionary defines a portal as,

 Portal - (internet) A website that acts as an
entrance to other websites on the Internet.

w:Wikipedia:Portal, however, says

Portals are pages intended to serve as "Main Pages" for
specific topics or areas.

So from early 2005 wikipedia has been redefining what everyone knows a portal is. From what I've read about wikiportals, it should be called a wikiview, or similar. Note: the missuse is between the internet's use of portal and MediaWiki's, Wikiversity does use portals as MediaWiki intended.

There are small websites and there are large websites. Most websites are small and they tend to point to other websites. Large websites (websites with many pages) need ways to guide visitors to those many pages. The English language has several words that can be used to describe webpages that guide people who are browsing the internet to other pages. For example, such pages can be called "directory pages". Here is a well-known directory page: Google directory. So let's imagine that Wikipedians had decided to call their portal pages "directory pages". If Wikipedia had made a "directory namespace" you would probably be here telling us that having a directory namespace is a misuse of the word "directory" because modt internet directories guide people from one website to other websites. By this kind of logic we can also say that having "talk namespaces" is a misuse of the word "talk". Nobody can actually talk on a MediaWiki talk page, "so it is a misuse of language and everyone will be confused". I find it hard to see the value in such complaints. In English it is natural for people to create new/multiple uses for words like "talk" and "portal". Just because most internet portal pages might point to pages at other websites, that does not mean that large websites cannot use the term "portal" to point to their own webpages. I do not think it is difficult for new wiki visitors to understand the idea of Wikiversity portal pages providing links to other Wikiversity pages. You can object to this meaning of "portal", but is there a better alternative? You suggest using a new term such as "wikiview", but I do not see how that is an improvement. It is different, but I doubt that it is better. If you think that use of the term "portal" is confusing, then there are options such as linking all instances of the term "portal" to the glossary or to Wikiversity:Portals. I think it is useful for each portal page to start with a sentence saying that the page provides links to other pages. I suspect that most new visitors to Wikiversity have no problem understanding the purpose of Wikiversity portal pages. Even if the Wikiversity community decided that it could not live with a portal namespace that would create new problems. Wikipedia has re-defined the term "portal", and many people who come to Wikiversity are familiar with how the term "portal" is used at Wikipedia. If Wikiversity decided to use a different name for directory pages, we would face the problem of having to convert Wikipedians to our new name. A different use of a word is not automatically a misuse of that word. --JWSchmidt 16:47, 23 May 2007 (UTC)

[edit] Defined uses for namespaces

A more pressing problem with implementation requirements are the namespaces themselves. Defining what namespaces shall be used for, prevents us from meeting the requirements as we choose. In Wikiversity:Namespaces it states,

Pages in the "school" namespace are concerned with
management and organization of the largest academic units at
Wikiversity ... schools contain departments. Wikiversity
departments do not contain schools. ...

which clearly intends schools to be hierarchically structured and absolutely have departments. It also requires the school content to be management and academically oriented. However, it commits two fundemental implementation errors, when it says,

The "topic" namespace contains pages that are for
management and organization of smaller academic units at
Wikiversity such as departments ... the pages in the "school"
and "topic" namespaces can be thought of as special types of
Wikiversity project pages that are concerned with creating and
organizing learning resources for broad subject areas ... The
Wikiversity namespace is a namespace containing pages that
provide information about Wikiversity

The first, and critical problem, is that it originally stated the school namespace is for academic and content management, and now asserts it is also for projects. Thus, one namespace is expected to serve two conflicting purposes.

This is not a conflict. Wikiversity participants working together on "content management" or "content development" for an academic subject area can think of those collaborative efforts as "content development projects". --JWSchmidt 16:55, 23 May 2007 (UTC)

[edit] The project namespace

The second, and less critical, is that it reserves the whole project namespace to Wikiversity itself. This causes the more critical problem with the school and topic namespaces. There is nothing wrong with defining wikiverstity as a project in the project namespace. What is problematic is disallowing the use of the project namespace for all other projects.

Both these problems can be solved by making proper use of namespaces and subpages. The fact is, both the Wikiversity project itself can co-exist in the project namespace with all other projects. The whole purpose of subpages is to allow multi-use of a namespace without conflict. By comparison with all the projects, the wikiversity project takes up very little of the namespace. The reservation is an implementation detail.

A wiki could function with only one namespace. The practice of dividing a wiki's pages into more than one namespace began as a way to keep the intended content pages of the wiki separated from pages that that are "meta content pages", that is, "meta pages" concerned with the operation of the wiki itself and the process by which its participants create the intended content in the main namespace. When Wikipedians discovered the value of dividing wiki pages into multiple namespaces (each namespace with a defined use) they continued this fragmentation and invented additional namespaces such as "Template:", "Category:" and "Portal:". I think most users of the Wikipedia website think (if they ever do think about it) of portal, category, and template pages as specialized parts of the Wikipedia encyclopedia. Even pages such as Wikipedia:Contents in the "Wikipedia:" namespace can be viewed as being part of the encyclopedia, just as many people would think of a table of contents in a book as being part of the book. The point is that wiki participants find it useful to have multiple namespaces with defined uses while at the same time respecting the need to be flexible in how the namespaces are used. For example, MediaWiki wikis have a "Template:" namespace, but pages in other namespaces can also be used as template pages. Some communities restrict certain types of templates to the "User:" namespace. At Wikipedia they use a "WikiProject" psuedonamespace that places all content development projects inside the "Wikipedia:" namespace. Rather than use a pseudonamespace for content development projects, Wikiversity uses the "School:" and "Topic:" namespaces for content development projects. This does not mean that there are no specialized projects within the "Wikiversity:" namespace. For example, there is Wikiversity:Introduction Overhaul Taskforce which is specifically concerned with how to improve the Wikiversity webpages that introduce new visitors to Wikiversity. I don't think there is anything wrong with trying to keep Wikiversity community projects that are relevant to the entire Wikiversity project in the "Wikiversity:" namespace while keeping other more specialized projects in other namespaces. --JWSchmidt 17:37, 23 May 2007 (UTC)

[edit] School and Topic namespaces

Namespace pollution occurs when it is used for more than one purpose, or, a single purpose is spread across namespaces. The topic namespace is polluted by having school departments. When users want to add a topic, they are also adding to the school's department and hence a project. If users simply linked up content in the main namespace, it would be cut-off from school access. There is no clean way to create courses without affecting departments. Again, departments in the topic namespace is an implementation detail, it is sufficient that departments are related to schools and link to courses.

A better implementation is to combine departments into the school namespace, where they belong, and leave the topic namespace to serve its purpose: create topics (modules, units, lessons, whatever). The main namespace remains as defined, it contains the actual resources.

The question of projects is resolved by removing all project requirements from the school namespace and put them into the project namespace, where they belong. Thus, the school namespace is now hierarchically organised into divisions, subdivisions, and departments whose sole purpose is to manage and organise academic material. In short, the school namespace is for administrating the topic and main namespaces.

There is no rule that says every wiki collaboration (project) has to be in the "project namespace". Think of the Wikiversity "project namespace" as pages that are relevant to the entire wiki project. There is one particular wiki editing project that is the concern of the Wikiversity "project namespace"; it is the Wikimedia project called "Wikiversity". Just because Wikipedia puts its content development projects in their "project namespace" does not mean that Wikiversity has to use Wikipedia's clumsy "WikiProject" pseudomnamespace approache to forcing content development projects into a single namespace. If you can accept the idea of having a new namespace specifically for content development projects, then you still might ask: why two namespaces for content development projects? The main reason that Wikiversity has both a "School:" and a "Topic:" namespace is because wiki community members naturally create hierarchical systems to organize content development projects. At Wikipedia there are both "higher level" "WikiProject" pages such as Wikiproject Science and "lower level" "WikiProject" pages such as WikiProject Molecular and Cellular Biology. In the long-run, I think it is going to be very useful to have both a "School:" and a "Topic:" namespace. Wikipedia has a smaller range of possible main namespace content than does Wikiversity. I expect Wikiversity to come to have many more content development projects than does Wikipedia. Wikiversity currently has mostly school pages corresponding to university schools. In the future there will be many other types of Wikiversity schools that organize many kinds of content development projects in a large number of different ways. The Wikiversity "Topic:" namespace may become as large as Wikipedia's main namespace. When Wikipedia's main namespace got too large, the "Portal:" namespace was invented. For the same reason that it makes sense to have the "Portal:" namespace to provide "directory" pages for the main namespace, it makes sense to have the "School:" namespace to provide "directory" pages for the "Topic:" namespace. --JWSchmidt 18:40, 23 May 2007 (UTC)

The topic namespace is now available to create and link resources. This allows other namespaces, such as portals, to bypass departments (and the whole school namespace) and link directly to the course material. Portals and schools can restructure course material by creating their own topic pages linked either to existing topics, or directly to the resources in the main namespace. Furthermore, the Category:Topic now lists all the resource material available as a table of contents.

Topics, moreover, provide critical information regarding the resources they link to. For example,

Topic page field names and description
name	type	description
ID	text	The school's unique identity for this topic
Title	text	The school's name for the topic
Description	text	Paragraph describing the topic
About	link	Topic Introduction or overview
FAQ	link	Frequently asked Questions on the topic
Volunteer	link	Contributor/mentor user names
Skills	link	what's need to complete the topic
History	link	A brief history about who, why, what, how, when, where
Help	link	On-line help on using the topic (e.g. mulitmedia)
Feedback	link	The topic's project page
Objectives	text	Itemized list on what the student will learn
Resource	links	A Table of Contents on the Resources

Thus the topic namespace contains all the relevant detail about resources without impacting on the departments. The departments need only link to the topics to gain all the neccessary info about the resources, while portals can build their own topics, lessons, lectures, and courses.

You are using the term "department" in ways that are not clearly defined. At Wikiversity, content development projects in the "Topic:" namespace can be called "department", "center", "institute", "WikiProject", "content development project" or anything else that participants feel is a useful way to refer to a content development project. Within Wikiversity, "department" is just a term used to refer to some content development projects. Given the way that the term "department" is used within Wikiversity, it makes no sense to say that the topic namespace functions "without impacting on the departments". --JWSchmidt 19:15, 23 May 2007 (UTC)

The type Text, link, or links identifies whether the field value is entered as text or as one or more links to a main namespace page.

You are going to have to define what you mean by "field". Why is "field" useful jargon for describing wiki pages? There have been technical proposals for MediaWiki fields, but I've been editing wikis for 5 years and have never needed concepts such as "link field". --JWSchmidt 19:15, 23 May 2007 (UTC)

NOTE Each of these fields can be categorised such that the Category FAQ contains a hierarchical structure of all FAQ pages, so that a FAQ group can easily manage and update all FAQs. Similarly, the Category:History pages can be mined by the Wikiversity history group to compile historical accounts on Wikiversity. Since each Topic MAY have its own project in the Wikiversity namspace (i.e. Project:), all projects are similarly hierachically structured for the Wikiversity project group to mine and summarise. This categorisation is based on a single subpage structure to synchronise related namespaces.

Only the topic id, title, description, and objectives are contained in the topic page. The other information is separated into the main namespace pages. Again, the subpage structure synchronises the pages between namespaces as ...

Namespace	Page Name	Page Link
School	Biology/resource/micro	[[Topic:School/{{PAGENAME}}/topicA]]
Topic	School/Biology/resource/micro/topicA	[[:{{PAGENAME}}/faq]]
Main	School/Biology/resource/micro/topicA/faq	-

The advantage of using the subpage (Biology/resources/micro) is that the user at the micro page in the school namespace immediately knows where the faq pages are in the Topic and Main namespaces. Further, the project and help pages are correspondingly ...

Project:School/Biology/resource/micro/topicA
Help:School/Biology/resource/micro/topicA

The resource page editor also knows the page is a subpage of

Category:Topic/School/Biology/resource/micro
Category:Project/Topic/School/Biology/resource/micro

... which simplifies to ...

Topic Page

[[Category:Topic/{{BASEPAGENAME}}
[[Category:Project/{{BASEPAGENAME}}

... and can correctly link back to the department (micro) in the School namespace.

Now the project namespace has school projects (among others), one of them being School/biology/resource/micro which has several subprojects TopicA, TopicB, ... TopicZ. The micro project and micro department share the same subpage and can link horizontally to each, so the school micro page may look like this ..

Department page field names and description
name	type	description
Title	text	The school's name for the department
Description	text	Paragraph describing the department
About	link	Department Introduction or overview
FAQ	link	Frequently asked Questions about the department
Volunteer	link	Department Contributor user names
Skills	link	what's needed to be a Department Contributor
History	link	A brief Departmental history
Help	link	On-line help on using the Department
Feedback	link	The department's Project page
Objectives	text	Task List and or to do list
Resources	links	Table of contents to Topic pages

Project and Category pages may contain similar information, all of which is contained in the main namespace. This simplifies running Wikiversity because the detailed information at the bottom (main namespace) is summerised at each higher level. For example, the micro department can summarise all the topic objectives (TopicA, TopicB, ...), which are passed up to the resource center (Biology/resource) who summarises the micro and all other departments for the school. So the information detail is structured such that the Biology school defines broad resource objectives which the resource center details according to each department, and each department similarly details for each topic.

This relieves the burden of defining all the school's objectives for all topics, by delegating the departmental objectives to the resource center, who in turn, delegates the topic objectives to each department. The information is separated into vertical and horizontal threads.

The various namespaces are similarly structured, but achieve different purposes. The following table shows how a user can move vertically and horizontally to access related information.

The path name Biology/resource/micro/TopicA used in various namespaces
Categoy (access)	School(admin)	Project(Reg)	Topic(edu)	Main(res)
School	n/a	School	School	School
biology	biology	biology	biology	biology
resource	resource	resource	resource	resource
micro	micro	micro	micro	micro
TopicA	TopicA	TopicA	TopicA	TopicA

The table shows a matrix of 24 pages and their horizontal and vertical relationship. The same page name is used in all namespaces, but with different purposes. By using the same subpage structure in all namespaces, it is easy to automatically construct projects, topics, and resource pages, link them horizontally (School:biology <==> Project:School/biology) as well as vertically (Project:School/biology <==> Project:School/biology/resource). Each page in the matrix only deals with its namespace information, such as access, admin(istration), reg(ulations), edu(cation), and res(ource).

The portal namespace is reserved for students to construct their own view of topic and resource pages however they like. Ideally, though, the User namespace should be used to link to resources and leave the Portal for external activities, such as interwiki news, translations, voip, radio, and video streaming.

The above preamble was intended to clarify that the proposal is based on the requirements intention, but not on their implementation. While paying due regard to the wiki community conventions, it equally responds to the inovation and visionary call to interactive e-learning. PeterMG 04:18, 23 May 2007 (UTC)

Even if you proposal is coherent (which due to large numbers of undefined terms I cannot establish) it is such a radical departure from the way Wikimedia Foundation wiki projects do things that I doubt it would ever catch on. I suggest you go to m:Wikimedia Incubator and create a set of demonstration pages for your idea. --JWSchmidt 19:15, 23 May 2007 (UTC)

[edit] Operation

Wikiversity has three main operational goals:

Attract contributors to produce quality material.
Attract students to consume the material.
Facilitate student and contributor collaboration.

The words 'student' and 'contributor' is defined by the editing they do. A student never, or only, edits articles, while a contributor edits more than one namespace.

[edit] Original proposal

The proposal redefines the available namespaces and how they used. It restructures Wikiversity similar to an enterprise: Products (education), management(administration), and customer relations (student council). Unlike the traditional enterprise, Wikiversity designates roles, rather than people, so people can switch between roles.

[edit] Namespace definition

Educational - The school namespace is rooted in Cateogry School. The school itself is divided into two areas: the school namespace provides contributor navigation and content acccess, and, the subcategory school discusses the school's policies, content evaluation, templates, and similar.

Administration - The Project namespace rooted in Category Project. Administration is divided into two areas: school administration and real world issues. The project namespace deals with template control, content assement, and school structure. The category projects, however, deal with format, copyright, vanalism and similar administration issues.

Student - The Article namespace is reserved for educational material and tools. The article structure is indenpendent from the school structure. This enables contributors to view the material their way and present it the student way. Students should never bee accidently exposed to other namespaces (except maybe Topic).

[edit] Student School and Inter-School schools

Two dummy schools complete the proposal. The Student school is structured for student access and provides navigation to materials and tools. It is not a school, but is in the school namespace. The student subcategory is the student council which discusses how well the student navigation works, how well they can get help from contributors, and anything that they think will improve Wikiversity. Students may edit the student school structure to better reflect their needs. This will not affect any other school, nor change the way contributors provide the material. (A student namespace might be safer than a school)

Initially, the school structure can follow all the other schools (except the interdisciplinary), and then students can restructure material as they choose. This should be no more than relinking topics to articles and creating/deleting student topics. Note, that students who edit articles will edit the same article a school contributed. Thus, students approach articles from the student school, while contributors do so from another school.

The student school structure contains content specifically targeted toward studying, while other schools content target education and material organisation.

The second inter-school school handles inter-disciplinary content. Any material that affects both social science and philosophy, for example, is provided here. Schools provide links to the inter-school, rather than duplicate effort, or interlink schools. The inter-school is responsible for negotiating between schools, avoid ownership claims, on the one hand, and neglect on the other. The subcategory interschool deals with inder-disciplinary education and multiple presentation without content duplication (Social science views content one way, philosophy another).

[edit] The Root Pages

The main Page links to the student school. It provides the motto, slogan, and a brief history of Wikiversity. It is student orientated and designed to encourage study. A topical list of courses allows direct access for power students. The subcategory student directs students to the council for advice and feedback.

The Category:School page lists all the schools, including student and interschool. It describes Wikiversity's educational goals, methods, and content recommendations. Each school's category describes how the school implements the above. Thus, every category that refers to the school namespace deals directly with education, in theory, practice, or both.

The Category:Project page lists all the school projects. This deals with administration issues, such as school structure, template, and content management. Each project subcategory (i.e. Project:Arts), describes how the school administers itself. At the lowest level, external tools and material projects focus on access, availability, and usefulness. Note: student projects (that belong to the student school) are reserved for students to conduct projects with mentors. So, projects can still be used as originally intented.

The Community Page is reserved for contributors, both students (for the student school) and others. It provides a cross-over for students wanting to expand Wikiversity and links to sister projects (like wikipedia, etc.) It also provides news, current events, and available tasks (what needs to be done).

[edit] Requirements

All the structures are based on the subpage feature. This means schools can use the same name within the school namespace without conflict. The art school can have 'fine' and 'applied' departments, which will be identified as 'School:Art/Fine' and 'School:Art/Applied'. To cleanup the page's title, {{DISPLAYTITLE:{{SUBPAGENAME}}}} should work if it is properly enabled. (It works on my wiki, but not on Wikiversity) The science school may also have an 'applied' department, but identified as 'School:Science/Applied' and distinct from the art's applied department. This approach avoids polluting the Topic namespace with school departments.

The Topic namespace servers as an entry point to articles. Each topic lists the articles it manages (toc) and describes it's objective. A topic defines an atomic unit, or module of articles. It may contain a related (student) project link that describes prerequiste units and/or external materials and tools. Each article should have back, forward, and up links to related articles and the root topic. This can be discussed on the Topic's talk page.

[edit] Summary

In summary, create a student school and interschool. Create the category:student as the student council to discuss the student school structure. Move regulatory material into projects and separate between school regulations (project namespace), and general (category project). Link the community portal to Category:School, and add each school to the school category. Move department topics back into the school namespace using subpages. Link school departments to Topics and topics to articles. The student school can organise topics as they see fit. Student school projects function as student collaborations, while contributory schools use them for format, copyright, robots, and similar. School navigation provides education content, category navigation provides school admin content, project navigation provides external admin content (formats, access, copyright). The Topic category provides material navigation (courses). PeterMG 04:42, 18 May 2007 (UTC)