UnderDevelopment/WiKi (2006-03-16 04:43:08)

Brainstorming page for how to improve efficiency of team communications

Critical problems

Due to glitches in manual migration, some pages had been cleared before they made their way to the manual properly: We are losing data


Wishlist

Turing test related - worst part solved

I almost got a heart attack the other day when using a browser at a friend. After 1 hour of page editing, the turing test refused. The browser "Back" button did not display the edit (only the empty page as came from the server). In opera "Back" works, that's what I'm used to. Unfortunately not in some other borwsers, eg. firefox (with default settings) and MSIE comes to mind. I changed the wiki engine (added a "!" to the php code for a few sec to do preview when save was asked) and "forward button" and resubmit worked, but that is no solution for others. I later solved it:

Turing test - still a bit annoying

Other wishes


The big question: how to store info?

There are some information that must be stored in CVS (or SVN), some that must go to ofbiz, but for some information it is not clear where would be best (most efficient).

In many case, the format (of human readable info) is a question. Information should be organized by content, not by layout. Major goal is that anyone can find the interesting info relatively fast. This requires an established index and easy maintenance of content.

Note that email is not sufficient to store information, it's just useful for a nudge.

Now looking for wiki engines that have CVS or SVN backend (or provide CVS or SVN interface to the page-set) tools that work on local files:

When I last looked at wiki engines, I wasn't sure of what's most important.

Having used many systems since, now confident about the necessity of CVS/SVN interface.

Have to review wiki engines, in this perspective.


clean up the rest sometime... - note: not just delete, that does not solve the discussed issues.

target audience of change

As our wiki traffic increases, people want to filter what they read and what they skip.

The good way is to have explicite information of the target audience - in some cases.

Which wiki has this feature?

a clumsy workaround would be offchannel notification: email groups (a few more than what we have now) that are manually notified for major changes - with the link included. Ofbiz workeffort will be the perfect way to keep such meta-info noise out of the wiki, but still available.


Search engine proposals

To find information in wiki easy, we need some conventions:

Search for Ionsense first (verified there is an ionsense page).

Broken google links, like ionsense site:www.vems.hu

were caused by a change in CGI location (a /wiki/ prefix was added). I'm sure he had a good reason because this broke all external links. The google links fixed themselves by now, but the other external links will become broken.

Also searched on wiki itself and got the following results:\nÿ1ÿ

So we obviously have a problem. the Ionsense page is about 20th down on the list. the exact match for the title and its child pages should be first. maybe we should try to glom on google? set it up so that the search is effective?


See also