[openbeos] Re: The Wiki (or MediaWiki-powered semi-wiki)

This is quite a long e-mail — bear with me . .
On Sep 29, 2006, at 10:45 PM, Waldemar Kornewald wrote:


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.

I understand Jorge's problem, and I have it too in fact. End user content isn't compatible with developer content. That is why major companies seperate the content. developer.apple.com, msdn, etc.

The drupal site as it is now is a good developer website, but it isn't a good end-user site. Its presentation of data is too strict. Part of this is due to our setup and what data we are choosing to present. I also believe that part of this is due to our near exclusive use of text. We need more images! Further, when you examine the consumer-end of a lot of websites you see that that are often html-based or more static (at least the entry points). Apple.com is html, redhat.com is an interesting and effective mix; all of the Novell open-source sites (MediaWiki powered). There is nothing wrong with a more static website — as long as there are people to maintain it.

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).

BeOS documentation should be integrated and rewritten, we can maintain a .tar.gz with old Docs in it, but Haiku is assuming its own identity.


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. . . .

I agree, which is why we should consider a separate venue for end- user content.

 Having a simple wiki where
everyone can modify the final end-user documentation is bad (write
access should be limited to the draft version, for example).

Not everyone can modify everything. I am already working on enabling ACL's and advanced permissions. As a matter of fact, there are already new groups waiting to be populated. The wiki isn't simple, but it does convey simplicity (thats an important part of design).

The wiki should really require email verification and/or captcha
validation.

Yes we should.


Ah, that's a wrong statement, then (except if our developers really
want to use the wiki instead of Drupal, of course).

Yes it was, and it is actually contrary to my actual opinion (read on . . ) I changed the wiki accordingly.

- MediaWiki is a powerful tool, and its presentation of data is simpler and more streamlined than Drupal. That being said, we currently have both, and both are waiting for good purposes. There is no reason why we can't maintain the wiki for end-user content instead and have a Knowledge-base namespace that allows for more editing. Check out tango-project.org, hula-project.org, mono-project.org, and opensuse.org. Drupal works well for developers and communities because it has very good data flow and I think it works well with the developer mentality. The wiki as it is now is very readable, easy to maintain, and rich. I implore everyone to consider using it as the holding place for end-user content.

- The wiki as a knowledge base is also a good idea. It is easier to create and integrate content than on drupal and its category system works well.

- In summary: better content and better presentation for end-users and a separation from developer content.

- Austin B.




Other related posts: