Creating consensus regarding page types in wiki

[sparkes]

another long one guys, bear with me while we sort out what's best for 
the wiki ;-)

Ben Edwards wrote:
> On Thu, 28 Oct 2004 21:09:58 +0100, sparkes <sparkes at westmids.biz> wrote:
> 
>>Ben Edwards wrote:
>>
>>>Thats common sence to me - i've been developing interfaces for 0ver 15 years.
>>
>>well why are you prescribing a method that runs totally contry to this idea?
> 
> 
> well - I think having the wiki look the same as the polished
> documentation is going to lure the user into a false sence of
> security.  If I do something off an official page that trashes my
> system I am going to be upset.  If i know the information was provided
> by another user and is done at my own risk that is another story.

GPL documentation offers the same promise that GPL software does.

Sections 11 and 12 NO WARRANTY

we should endevour to provide the best possible support but no warranty 
can be provided, YMMV, IANAL etc, etc, etc.
> 
> 
>>>Not exactly sure what your point is.  My point was that the wiki and
>>>the official/polished documentation are diferent.  I think the wiki
>>>should be as easy as posible for new users to edit and the
>>>documentation use a very flexable standardised markup.
>>
>>your point was the wiki and the main site should look and work
>>differently.  My point was they shouldn't ;-)
> 
> 
> Look a little different - maybe just a different background colour. 
> and have a 'warning' on it. The only way I think the wiki should work
> differently is that the editing should be easier.  Anyway if it a wiki
> it will work differently - i.e. anyone can edit it.
> 

They should work and look in harmony with each other.

They aren't used any differently by the average user so they certainly 
shouldn't look/work different.
> 
>>The normal user is not a wiki editor they are a wiki browser.  The use
>>case requirements are exactly the same from the end user perspective and
>>they should therefore be expected to work exactly the same and look
>>exactly the same.
> 
> 
> And the information should be of the same quality?

yes that was my point earlier on.  If the content is not of the required 
quality team members need to get it up to the required quality.

It's no good having a second class citizen site when you can have 
intergration.
> 
> 
>>>I think having the wiki looking a little diference is good.  Users on
>>>the main site who do a search and end up on a wiki page may be
>>>'suprised' if it is not as polished as the main site.
>>
>>well any pages that aren't polished should be clearly marked as work in
>>progress.  Documents that are growing and evolving in the wiki might not
>>always have the same polish as the rest of the site but they should
>>always maintain the same professionalism.
> 
> 
> The wiki is a work in progress so making it clear visitors are in a
> wiki will show this.   If it is not obvious the only way to do this
> would be to mark the page as edited automaticaly and have someone from
> the doc team check it is OK and 'passing' it.  I however think that
> having a wiki and doc area gets round this.  Also the whole site is
> going to look unprofesional with pages sprinkeled all over the place
> marked as work in progress.
> 

The whole wiki shouldn't be considered a work in progress it should be 
considered a brainstorming zone on the way to the finished work.  Just 
the other day you where pissed of that docs would be moved away from the 
wiki and now you are conceding that the wiki isn't a place for finished 
docs ;-)

you would rather have the whole wiki marked work in progress than have 
some odd 'unprofessional' pages ;-) I still don't see your reasoning 
that the wiki should look and feel any different to the main site.

What you seem to be saying is we should ditch the wiki and work in an 
offline versioning system and only let people join in if they understand 
how to get the source from cvs and submit back to it.  Because the 
picture of the wiki you are painting is not a good one considering that 
you where always one of it's strongest supporters.
> 
>>If a contributed page isn't up to scratch one or more of the core team
>>needs to wade in a bring it up to scratch.  I thought that was the main
>>job of the wiki gardeners, to prune and maintain the flowers that make
>>life unique ;-)
> 
> 
> In an ideal world but anyone can edit the wiki and the garderers are
> not going to have the time to polish all the pages quickly .  Also the
> gardener would have to check for technical acuracy and all the
> examples work  - what if the information involves an area the
> gardeners do not understand?  Of if it would take a houre of so to
> check something works?

If a document is written with such techical detail it can be considered 
acurate and solicit bug fixes where it is found not to be in the same 
way that free software does.  See GPL sections 11 and 12 again.  We 
can't go checking that every line of a doc doesn't fry someones computer 
just like the devs can't know in advance it won't.  We have the GPL to 
protect us from this (one more reason why it would be a good choice)

The type of gardening I am talking about is fixing the spelling a 
grammer of a person whose natural language might not be english. 
Putting the page into a better place on the wiki and maintaining the 
information architecture and later moving more polished how-to's to the 
main site.
> 
> 
>>>There seems to be a bit of confusion here - there is a big diference
>>>between the requierments of a wiki and a documentasion CMS.
>>
>>not really.  The wiki backend is a tool for document development but the
>>front end should work exactly the same as the rest of the site.  The
>>principle of least astonishment again you see ;-)
>>
>>Think a little about the requirements you are talking of.  The end user
>>requirements are exactly the same for the wiki and the plone cms.  I
>>can't think of any end user requirements that are different for the two
>>systems (and would therefore potentially justify any differences) but I
>>stand to be corrected if you can think of one ;-)
>>
>>remember end user requirements not editor requirements.  Count the
>>number of editors on the wiki and compare that to the number of site users.
> 
> 
> I am not saying the end users requierments are the same as the editors
> but I think they need to know if the information may be misleading.

So the whole system should be broken just because you want YMMV added to 
every page? ;-)

All information may be misleading.  Unless we create a nanny state and 
tell our users *everything* may mislead your worse lead to dragons we 
have to trust they already understand this fact.

I still think the user will be savvy enough to understand that 
information may not be perfect.  The licences we choose can protect us 
but I agree that that rapidly evolving pages should be marked as such. 
It should be obvious that some pages are being used for brain storming 
and are not the finished article. But the site works better as it is 
than it did before, plus we now have more flexibility and the choice to 
move docs into the docs section and out of the wiki when they mature.

Isn't this what we are here for?

sparkes
-- 
<davee> "Sparkes, the Pete Best of LugRadio"