LibrePlanet: About/Development/Proposal/Website
This proposal outlines the website's structure, functions, and features
Contents
Libre Planet Website structure proposal
Here is the proposal the Libre Planet development team suggested I submit for approval. I have been working on a similar project for eight months now and am keen to implement it for the Libre Planet project. Although the website has been up for over two years it has remained a standard wiki and is neither useful in managing groups, nor very inspiring. With the renewed interest FSF is showing in developing a membership network, this is a perfect time to brand the website and design its infrastructure.
The proposal defines a page schema, a wiki upgrade, implementation, and adding it as an educational tool for both webmasters and editors. The proposal defines the website layout, content structures, and the benefits for doing so. It includes the methods to develop the schema, costs, time-line, and my qualifications.
Proposal to define and implement a page schema
This proposal defines a page schema for webmasters and editors. After reviewing the wikipedia and wikiversity navigational systems, it became evident that mediawiki does not provide a page navigation system, and, in the absence, visitors and editors have difficulty accessing related pages. After reviewing the situation with wikiversity, I realized that, by suitably structuring the page namespaces, a useful navigation system could be implemented that would not burden editors and webmasters. This proposal explains the need for a structured website approach, the process by which it is achieved, the resources to do so, a time-line to complete the proposal, the costs involved, and my qualifications to oversee the implementation. I am currently working on the FSF Group website and know what is required to complete the proposal. All I need is the approval of the FSF development team and assistance in configuring the wiki itself.
The need for a page schema
mediawiki creates and uses namespaces for specific purposes, but otherwise provides no page structure. Editors can create pages in any namespace and with any name, ultimately leading to an unmanageable wiki.
Libre Planet want groups to create and operate their own website on the FSF Groups wiki. Each group needs to be distinct from all the others and yet accessible by visitors. Most groups will want to advertise and manage annual events. This means groups must be able to create pages for their group and link them to the main group page, without interfering with other group pages.
The wiki must also provide documentation, so groups must be able to create their own in a consistent and structured way. The FSF itself needs to provide educational material and resources, which should also be organized and self-contained.
The top-level pages are the most important because they provide the initial access points for browsing the wiki. However, without a navigational system, the top-level pages will appear scattered and hard to access.
Benefits of a page schema
Top level pages will be easily accessible and give the wiki a coherent look and feel. Editors will know where to create pages and what links to create between the new and existing pages. The wiki layout can be easily understood and the whole site becomes understandable. Groups can continue developing their own schema below the top levels, so the schema is extendable and flexible.
The Process for developing a page schema
The proposal defines a page schema, navigational system, namespace usage, and template design. It provides an overview of the wiki layout identifying different areas for users, visitors, groups, editors, and resources.
The process is divided into six phases:
Software
Upgrade and apply extra functions to the wiki and suitably configure it. A modified wiki is essential to fully implementing a page schema. I have the essential extra functions written and ready for installation. I need a designated person who has the time and skill to physically make these changes on a continual basis.
Namespace
Namespaces are used to allow the same page name to be used in different contexts. We use this approach to create namespaces so we can add new contexts to a page. Other namespaces, such as Category and System, are used to provide distinct content. So, we can combine Group and Project namespaces to provide two contexts, a group's website page and a group's project page. The project page defines the website page and the website page provides feedback to the project page. By separating a page into two, we enable navigation by content.
We may separate a page into several namespaces, so that the wiki content is well defined, accessible, and structured. Each namespace forms one or more tree structures, where each tree consists of an unique prefix followed by the page name. We define the content at each level in the tree. Context trees in different namespaces will share the same page names, but have different content. A page in one namespace will, by definition, have the same page name in other namespaces.
Page schemas
We will define the first three or four levels of each tree. This will provide enough structure for editors to expand their trees in a consistent manner. Root pages will be identified and some will actually have predefined names. We will devise a mapping of pages from several namespaces into one, and vice verse, so we can calculate a page name for all namespaces, given any page name.
The Template namespace will be used to define all the tree structures and the template names will be the level names. This means the templates not only act as a reference, show the current state of the wiki's structure, but also provide each page's markup and content. Anyone can see whether the right template was used for any page's namespace and level.
Navigation system
The navigation system consists of built-in and extension functions to link between parent and child pages. In addtion, template menubars will provide hard-coded links to pages in other namespaces, providing inter-namespace access.
All the tree structures will be rooted in designated categories, which will form the top-level entry points to the whole wiki. A main menubar will thus provide the categories and enable visitors to access every page on the wiki.
While the pages are constructed as nodes in a tree, the Category namespace provides horizontal page access at each level. Each category, therefore summarizes the content at that tree level, giving an overview of the wiki.
We will construct the memnubars and include them in the templates, as well as categorizing each template. All editors need do is create the page and include the proper template. The menubar and tree links will automatically point to related pages, which the editors can create if they don't already exist.
The proposal in action
Every page will have a parent link (except the root page), a menubar of related links, page content, zero or more subpage links, and one or more categories. A template will define the title, accept page content, generate the subpages, and categories. All the editor need do is fill in the content and click on the menubar links to create the related pages. For each related page, the editor need only enter the template for the page type and repeat the process. The template page types are designed to interlink with related templates, both within and between namespaces.
Articles are created from the Group and Project namespaces. Group and Project templates automatically link to Articles, so the article namespace is split into four sections: threads, events, groups, and projects. Groups can create calendars to record events in the own group pages, or, add events to global calendars.
Another kind of calendar uses an educational schema (such as mat 101, 102, ...,201,...,301..) which displays a matrix of articles according to its schema. This allows groups to create, manage, and display resource materials in a compact manner. Templates group individual articles into modules and provide menubar links between the calendar and the modules. Similarly, articles are linked horizontally (previous, up, next) via templates and to the module article. This calendar only works from a group/project page, so each group can create their own resources, while users can link from their User page to any article module.
Costs
The major costs are in developing and testing the templates, and, restructuring the existing pages. I estimate about 30 templates will take 120 hours to debug, about 10 categories will take 10 hours, and restructuring 200+ pages about 240 hours. This gives a total time of 370 man hours. Upgrading and testing the patches should take about 8 hours.
Conclusion
The proposal has omitted many details which I am happy to discuss on my User_talk page, irc (freenode.net), or Email. I hope the development team can see I am up to the task and will provide the kind of wiki the FSF is expecting for their group network. Blacky 22:38, 21 March 2009 (EDT)
