[openbeos] Re: The Wiki

Hi,

Waldemar Kornewald wrote:
On 9/29/06, Jorge G. Mare (a.k.a. Koki) <koki@xxxxxxxxxxxxxx> wrote:
Waldemar Kornewald wrote:
> On 9/29/06, Jorge G. Mare (a.k.a. Koki) <koki@xxxxxxxxxxxxxx> wrote:
>> Wikis are a very good collaborative tools, easy to use and flexible. I
>> agree with Austin that a wiki would be beneficial to Haiku.
>
> But what do we want to use it for?

For example, for community contributed how tos, tips, troubleshooting,
etc., and as a sandbox for creating documents in a collaborative way.


Basically, you are talking about a knowledge base and the drafts area
I mentioned. I'm not sure if the sandbox is really useful...maybe it
introduces more confusion by giving the impression of a second website
(no strict rule on where to place content).

In order to define the role of the wiki, I fell we need (at least IMHO)
to understand the scope of the website too (first?). I have to be
honest: this is where I am having difficulty; there is a lot of content
in the new website, but I am having difficulty understanding under what
criteria it was included, and how it is intended to be organized. But
then, maybe it is just me...


What exactly do you think is causing this confusion?
I guess the problem is that we mix end-user content with developer
content. My intention is that our developers use Drupal as a tool for
writing RFCs and anything else which is useful for development. There
should be no other tool. This makes up most of our website content
which is organized using categories because there will be too many
articles for tree-based navigation. The rest is the most
relevant/useful information for end-users and companies. The website
should prove our three target audiences (devs, users, companies) with
sufficient information. Anything going beyond the normal use-case
(e.g.: installing Haiku on your mobile phone, hacking kernel&driver
configuration files, creating non-standard distributions, etc.) should
be part of the knowledge base.
Does that answer your question?

I think the problem with the new website is that there is no distinction between different types of content, and that there is no apparent organization or structure that would help people with different interests find the information that they need. Everything from (but not limited to) news and technical stuff to blog entries and RFCs is treated the same way, regardless of whether it is complete or incomplete, or in draft or final form.

For example, articles, announcements and news are written and should not change. However, informational pages (such as the About and/or FAQ) as well as documentation (for end users or devs) may have to be maintained. You throw everything into the same bag, which is a problem.

The wiki may be also a good place to put the BeOS documentation that has
been abandoned but that may still be useful to Haiku. Putting such
documents in the wiki could also make it easier to adapt old
documentation to Haiku.


This should really be part of the official documentation system (which
doesn't have to be a wiki).

Once you make something official, you cannot label it "it is not complete" or "it may not be acurrate". Which is why it would be better to put any documentation that may need to be revised and/or qualified into the wiki. 
I would also move all the articles on the website that have the "This is
not finished..." label to the wiki until they are finished.


I think this is not a good idea because it separates our development
content between two systems. All development articles must be
accessible on the Drupal site. Even if something is just a small idea
we should not move it away from our primary content management tool
(otherwise it might get lost because other developers don't use the
wiki so much). As long as development content is useful it should be
on our site. Nobody really expects perfectly worked-out RFCs. The name
RFC (Request For Comments) already suggests that it's unfinished.

RFCs are a different animal, and that's ok. But I think having unfinished documentation in the website is a double sided sword: you can (will) expose users to information that is potentially misleading and/or inaccurate.

The existing wiki has already build up a nice knowledge base, so I don't
see why it cannot continue. We would just need to define better what
goes into the wiki and what doesn't.


Okay, we can give it a try. Let's only use it as a knowledge base.

But I think that we still need a better solution for end-user
documentation.

We should not limit the wiki to end-user docs. It can be useful to develop technical documentation too.

Does MediaWiki support something like branching (via
namespaces?) and locking a whole namespace (for finalized
documentation)?

Yes, I believe MediaWiki supports namespaces. Btw, when a particular document in the wiki matures enough, it can be considered for migration to the website.

Koki


Other related posts: