[openbeos] Re: The Wiki
- From: "Waldemar Kornewald" <wkornew@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 30 Sep 2006 14:26:50 +0200
Hi Jorge,
On 9/30/06, Jorge G. Mare (a.k.a. Koki) <koki@xxxxxxxxxxxxxx> wrote:
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.
AFAIK, only RFCs are incomplete. Only the development content could
give users the impression of unfinished content. Yes, currently even
end-user content has "TODO" markers, but that will change (we just
need people working on those articles).
In what way do you want to treat static content differently from
non-static content?
I do see a problem with the development section which I find too
overloaded. That's why moved the non-contributor content to
"Documentation".
>> 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.
With "our official documentation system" I didn't mean that it's the
"official documentation". The documentation system should have two
sections for "finished content" and "draft content". The old BeOS
documentation could stay in the draft section and slowly get
transformed into real documentation.
> 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.
That's why we have an additional note at the top of each RFC. What do
you expect? Even if we had a separate developer website users would
find their way to our RFCs. That information is just a little bit more
accessible on our website, but I think this is an advantage because we
show more progress and we can get end-user feedback (if you don't like
something you can add a comment). We don't lock our developers into
their own world.
Bye,
Waldemar Kornewald
Other related posts:
