Talk:Wiki Organisation

This is the discussion page for all things to do with our organisational system structure

Discussing Nested Templates

Some templates need to be nested, for example a book needs to contain resource properties in addition to its own specific properties, and many kinds of record such as transactions or worklog entries require time properties. We may need to make record templates more generic like a bullet list of name: value pairs which can then be given specific layout with CSS. This way they can be treated differently depending on whether they're used alone or within another template.

Template requirements

Starting a list of what is needed:

• Nestable
• Collapsible
• Hide non-filled in values
• Links to: v-d-e (view/discuss/edit a template a la wikipedia nav boxes) and portal of related topic see: w:Portal:Time/Categories and Wikimedia
• Easy to change to semantic forms
• Record template: Permissions

Book example

Let's go over the book example and analyse the components to see how these concepts apply. It might be good to also do a notebook/whiteboard sketch of what the book template should look like. I have just used whatever names seemed right but we can always change them to be more appropriate.

• Book info article - this embeds an infobox type template (Example: Human Ecology)

The book article contains the summary and discussion of a book and is a document, the template adds the book to books category and has parameters such as author, etc. which can be filled in. It could link to the books workspace/portal. Reader discussions and reviews may be placed on the talk page of this article.

• Book resource article - this embeds a Record Template, which in turn embeds at least some parts of the book template (book icon, link to book portal/workspace?) as well as linking to the appropriate book info article; because it is a resource of type "book". (Example: Milan/I Ging Das Buch der Wandlungen

The book resource article is a record which allows for resource management and accounting of an actual resource. Embedding the resource template categorises it in resources. The current naming convention is Owner/Resource and numbers starting from "1" if there are several instances like multiple copies of the same book, say. Further, the owner's notes and thoughts on the book may be stored here, which might not be for general public consumption on the main article of said book. The resource article has permissions implications, because I may want certain resources to be private or visible to a trust group.

• Book portal - Portal:Books an Organisational Portal/workspace where the user can access all aspects of dealing with books. Set up/enter a new book, request/borrow books, review books, buy/sell books, import books, etc. (Example: w:Portal:Time/Categories and Wikimedia NB - This portal only covers informational aspects and few if any of the resource management aspects. In organisational terms, portal:time should be a schedule interface). Probably best linked to from Template:Book.

To summarise my current understanding

• Book info article "Book" --> Embeds Info Template Template:Book --> which links to Portal:Books and categorises the article into Category:Books
• Book resource article "Owner/Book" --> Embeds Record Template Template:Resource --> of type:book, therefore it embeds Template:Book and cats into Category:Resources
• Book portal allows the management of both documents/information/discussions on books as well as accessing and managing actual physical books. This could be considered the equivalent of the Organic Design library homepage.--Milan 11:57, 4 June 2008 (NZST)

Examples

• w:Template:Navbox The basic template has some good features
• w:Portal:Time/Categories and Wikimedia They have workspaces there but they call them portals
• w:Template:Chronology Like how there is the icon for time with link to time portal --Milan 22:07, 2 June 2008 (NZST)

Templates & Packages

An organisational wiki relies heavily on establishing convention, and this come in the form of centralised repositories of documentation and templates. Templates are also used to add standard sets of attributes to articles, in effect allowing them to more like objects than text articles. Such templates can also include semantic annotations to further standardise the attributes and make them universally accessible.

Selections

DPL can be used to select articles based on categorisation and templates in use, and SMW can make queries based on specific attributes and relationships. Custom forms should be made for making selections on specific sets of criteria such as date or financial attributes and can also involve filters to reduce the selection down. The forms should be interchangeable without clearing the selection.

Reporting

Once selections are made the results are by default rendered in a similar way to a category page, but different templates can be used through which the selection is rendered such as a sortable spreadsheet table or a tax return form.

Workflow

Each job is an article in the wiki and it is categorised based on its state such as "in progress" or "completed". The idea of wiki workflow is to use categorisation to allow larger jobs to undergo interaction with multiple roles in the correct sequences.

---

We've been developing organisational systems and related ideas within the MediaWiki software for a few years now and have set up Organic Design as a platform for a team of us to work on these ideas together.

We work on a number of different development projects and use a variety of different software in the process, but our main organisational infrastructure is MediaWiki and ties all the other technology together. Our system has a lot of room for improvement, but over the years we've developed quite a refined idea of what we'd like to see in such a system. Following is a brief outline of our experiences and plans.

Navigation Tree

The tree is dynamically created and uses portals. At the portal one may gain an overview of an area of the organisation and create dynamic PDF reports. In the navigation part there is a link to PDF reports of the various categories of content (Document library). For creating the roles we propose working off Dave W's suggestion referred to in the roles portal. Looking at this tree, the 6W framework breaks down somewhat and proves too restrictive in terms of needing to match each branch of the tree with one "W" in a 1:1 fashion.--Milan 05:28, 11 July 2008 (UTC)

• People (Who)
• Resources (What) (New)
• Projects (Current work) (New)
• Places (Where)
• Calendar (When)
• Roles (What and How) Was best practises. Roles and procedures, only lists roles and links to main roles portal. Procedures are accessed from roles portals, not tree
• Departments (What and How) Was biz processes. Departments and business processes, similar structure to roles, only lists dep. portals and not biz processes
• Protocols (Organisation-wide) (Why) Was compliances. Internal and external policies of governance, also mission, vision and core values)

---

• Systems (New) The components of the organisational system and management interface. Maybe only some roles (IT Support, admin) need to see this one.
• Products (New) Maybe only for customer, sales roles?
• Services (New) Maybe only for customer, sales roles?

Time

Record admin for time requires

• User (auto populate)
• Calendar
• Client
• Project (auto populate)
• Task (dropdown from assigned, might come later)
• Hours (javascript calc from start/stop?)
• Set as Billable/Unbillable
• Notes

--phalseid 19:05, 29 January 2009 (NZDT)

Plain abstract

Wiki Organisation is about our vision to create an organisational framework that has specific procedures but is also generic, usable by any group working together on any mission. Wiki Organisation is a good start toward this, but the vision is not a specific technology, it is a way of working that can be encapsulated by or implemented within almost any collaborative environment. The system and its definition are continuously refined, as we use it to organise and manage our own jobs and projects. The whole system is encapsulated in an tree structure named the Organic Ontology, under which top-level aspects are called classes. We are working toward this structure's definition being such that a complete description of the system can be exported into an official ontology language such as OWL.

MediaWiki software (functionally) and projects like Wikipedia (in terms of application) exhibit a key feature where content as well as administration and organisation are described in the same collaborative environment, giving rise to a basic form of self-containment. In Wikipedia it is the actual content of articles and categories (Wikipedia: User administration, policy documentation, deletion or article improvement workflows, etc.).

The reason we chose MediaWiki is because it fulfilled our basic technical criteria, and it is also being used to run Wikipedia, which has a large and active community. The code is well-tested and under continuous development, and possesses proven scalability. We agree with the philosophy of Wikipedia's parent organisation (the Wikimedia Foundation): "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment." Using MediaWiki aligns us with that philosophy and with its development momentum. There are many people familiar with the software interface, and much freely accessible content and knowledge.

Next we will use MediaWiki in conjunction with a handful of extensions such as Semantic MediaWiki and ListView, to make the generic structure described in Wiki Organisation. We continue to develop this generic organisational framework while applying the technology to create actual functioning organisations within the Organic Design Wikia, where people collaborate to create content, to set up workflows and to refine procedures. --Jack 20:56, 8 March 2009 (NZDT)