MoinMoin goes business :-)

This feature request summarizes some specific detailed feature requests and gives an background how this could be useful for business users of MoinMoin.

Background

I'm working mainly in companies with a very large IT department and a very large set of IT equipment. Those companies are not IT companies itself, but they rely heavily on usage of IT.

In this area my work is usually focused on writing or reviewing concepts (requirements papers, standardisation, IT architecture initiatives etc). The amount of people who create or need the input is usually quite large - one time I had to deal with 30 authors for the same concept, 1.500 word files and an final document with over 6000 pages.

I did myself a lot of tooling in this area - from Word scripts up to Framemaker API based tools for automatic converting.

I have also been myself quite heavily involved in designing processes within and for the IT departments - how is requirements/demand management designed, how is the delivery process structured and so on. This included also working intensivly with the "real" users and/or analysists working as mappers between the real users and the IT departments (seperating geeks from "I don't have a "any" key key on my keyboard...". You see.... content - content - content.

You can't manage and communicate and structure this stuff with Word or any other "document file" based software. Final conclusion, case closed. Since 2000 I'm in "open source" (mainly Python) and I detected the wiki approach. Fine and quite suitable for what I need. But the technology wasn't enhanced enough to kill Word use even in IT departments... You can't imagine how many "IT professionals" I've met who aren't able to use at least intermediate functionality of Word and XLS. To get them to use some webbased stuff and wiki markup... forget it...

Nowadays we have GUI based input with web frontends and web browers... seems that we'll finally come to the right point. I did various tries with TWiki - which I admire for the possibilities for structuring and organizing of content. Unfortunatly I'm pythonic - and adding some functionality to TWiki is painful, since its Perl. Good perl, documented perl, but Perl... arg... I evaluated MoinMoin several times, but it's not powerful enough for what I need... TWiki, by the way, worked quite fine. Some special additions and I would have what I need and what I want... but Perl... arg.

If I get what I want I can easily convince some larger IT departments to give MoinMoin a try. As well as that I would probably convince some people to sponsor the MoinMoin development... Heck... I will sponsor parts of this from my own budgets...

Basic aspects

The content

The content is mainly textual with a certain amount of graphics and diagrams. It is more abstract, technical stuff - the stuff of knowledge geeks need to know to build the software - and the kind of content which describes what the users want - or at least what they believe what they get and paid for. We have a large group of people who will read the stuff (users, analysts, developers, testers, administrators and some times lawyers... just a joke... they don't read, they just claim...).

The content who is read by...

We have a large group of "anonymous" readers. If we would use a client-side tool (Windows application e.g.) every person who is involved needs this app. A nightmare for the support people. Not applicable.

We need web access - configurable, read only, review only. author read/write. The people who read need "their" views. The database people won't need the GUI requirements, the GUI people will need the use cases but don't care for anything database relevant stuff. Hey, yes, it would be beatiful if everyone has read the whole spec... but that's not possible. Most geek would not ever care to read this stuff, they just want to code... code... code... So we need some sort of filtering, searching and sorting. We need some functionality for making content sortable/filterable/searchable/distinguable in/between/for "high level" and "detailed" for the same topic... This sentence has obscure grammatics...

The geek may need the requirements for log files, but the project leader just need to know that thereis some standard for logfiles. Understood?

The content which is changed

Yep, this is the area of troubles. Specifications and requirements change. Often, unplannable, and unfortunatly mostly untraceable for all people who have to deal with the changes. The farther the implementation goes the more troublemaking the changes are. And even harder is it to identify all people who must know about the changes - you may remember the name of the developer, but you will fore sure forget the tester with his written test case. Or the people who write the installation scripts.

You can surpress changes (no customer will really allow that), you can install a demand management, you can make risk management... but finally the implemented software fails because some information or change hasn't been transmitted to all who should know. Hopefully while testing... but if change requires a new test case and this case will never be executed... happy production... Believe me: this is the brutal reality... One of the companies had to re-issue 200.000 invoices due to such software errors...

The key feature: don't push the change, let the people who are interested pull the changes. Let them subscribe to the data they rely on...

Ah, yes, I know about "agile development". But: in larger IT departments this is not a feasible approach. The "customer" will sign off a certain document version - and this is what he pays for. If he want's to have the stuff changed he will pay again.

Agile development is fine, but this doesn't allow you to play the budget games all people in large IT departmens are accustomized to.

The changers and the reviewers

We have obviously various editors and large groups of reviewers. The review is a process which should be supported by MoinMoin. And even here we have various levels or variants: some reviewers must review, some reviewers can review. Some reviewers must be included quite early ("I may want to change this, let's talk about"), some peopel are "just informed".

To talk straight: this is know commonly as "knowledge management" or "management of information structures". But if you have around 150 people who have various roles you just need such stuff...

Requirements

Let's get down and let it be specific. Of course I already have some specific funtionality/concept in mind how I believe this stuff can be solved - including some additional use cases...

Meta data

I know - this has been discussed quite often so that I will elaborate a bit more on what I need instead of implementation ideas. The meta data handling is inspired from what I had in TWiki. This handling is already quite good - combined with the web formulars. The meta data definition should be done within the wiki with help of definition pages. This allows that the metadata can be changed without having to release a new version of moinmoin. "Old" pages which have previous definition versions attached should be accessible. Old fields should be kept, new fields should be added while editing the page. Additionally it may be useful in later versions to retrieve the definition from XML files or databases (mysql) which arenot write-accessible from the wiki itself. The meta data definition should not be changeable by everybody (the usual page rights management). The definition should be attached mandatory to certain kinds of pages (maybe regex to the pagename). As well it should be possible to attach the definition to template pages. The meta data should be accessible via searches (see also searching) from within pages. The definition should be accessible from within the pages via web forms. The webform uses then the definition to judge the display/entering of the meta data (e.g. take a option input field). Nice would be to have some input validation functionality (python expression e.g.) to prevent wrong inputs or to enforce input. Also nice would be to see which meta data definition version a page uses - and to search for this information (to find older versions).

• As you might have seen, we work on a new storage implementation which includes separate storage of metadata (see discussion about 1.6 / 2.0). I don't think we will make metadata related changes to 1.5 as development of 1.5 is closed. For the form stuff: we currently don't have any. FlorianFesti began working on form related stuff for one of his moin-based web projects, but he didn't publish any source code yet.

Web forms

Web forms are used for editing the meta data. The data itself is stored as part of the page content. The form definition should be stored as a wiki page. The Twiki webforms could be taken as an example:

The various options as well as the table format should be specified more (this is just an example). The "options" (especially in the option/select box) should be generic. This means that this list should be producable by some sort of search, query, database access. Most important would be to be able to insert a list of wiki page names - a variant of the "category" approach. This would enable the following construction, e.g. for a bux fixing system: - you would define 3 wikipages BugFixStatusNew, BugFixStatusOngoing, BugFixStatusFixed - you would define a webform which refers as part of the option parameters to all pages with the prefix "BugFixStatus" - you attach the webform to the bugs entered as pages - the three status pages itself contain queries for all bugs of the said status If you enter a bug it will apear automatically in the corresponding BugFixStatus-Page. If you add a new BugFixStatusPage (e.g. BugFixStatusRejected) the webform is updated automatically. This eases the handling of webforms dramatically.

Global and personal variables

It should be possible to refer to "global" variables like $username (username of the current logged in user). It should also be possible to define personal variables (derived from the users homepage) which can be used within pages. The global and local variables can be refered by a specific notation. If the page is rendered the variable is evaluated and the found value is inserted instead of the variablename.

• If I understand this correctly I think we already have this with dictionaries, see HelpOnVariables. -- ThiloPfennig 2006-10-20 06:04:49

Searching

It must be possible to search for metadata - and it must be possible to display the results filtered as table (<li> <li> - lists) in a page. The table fields must be configurable, and it must be possible to fill the table fields with data out of the meta data stored per page. Searches within searches should be possible. Search should refer to global and local variables ("search all pages: searchfield: "Author" - searchvalue = $username" ==> this would show all pages where the current user is entered as author).

Subscriptions

The subscription to a page should be extended by a role definition (earlyreviewer, latereviewer, justforinfo), and the subscription should be visible. This would help to identify the right people at the right time if a change is pending.

Mirror pages

The content of mirror pages is stored in a database. The pages are seemingly part of the wiki, but in reality they are just mirrored (online). The display should be customizable by special webforms. Very useful for combining structural data (e.g. configuration management systems) with content data as stored in wikis. Read-access first sufficient, write-access would also be interesting in later releases.

Summary

For all requirements I'll write a specific feature request document. But not know - it's 00:45 and I'll have a full day tomorrow.

Comments

Taking into account so many differences with the WikiWay... are you sure you don't need Drupal?

CategoryFeatureRequest