[openbeos] Re: The Wiki

Waldemar Kornewald wrote: 
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).

What is the purpose of publishing incomplete (and potentially inaccurate or outdated) documents? What's the expectation? That someone may pick it up and finish it? I thought we wanted quality over quantity for Haiku, but this does not seem to be the case...

In what way do you want to treat static content differently from
non-static content?

I think there should be maintainers for each area that oversee the informational pages and works/coordinates with the contributors to make sure the content is accurate and up to date. The "go change it if you don't like it" method will just open the door to constant changes with no end in sight...

Also, don't think comments are necessary for anything other than RFCs and blog entries.

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.


And what are the benefits of having draft content in the website?

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

I repeat: I am not against RFCs (I do think that putting that disclaimer on top of every RFC is redundant and a waste of space). It is the other articles that are not finished that I am referring to.

Koki


Other related posts: