www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Wiki - we have a problem :)
Date Sat, 01 Feb 2003 22:15:19 GMT
Interesting conversation.

http://everything2.com/ is another interesting example in this space.

They keep all the content associated with an author.  They have a 
surprisingly complex scheme for getting a feedback loop that they hope 
will create quality.  One thing that fascinated me about was that they 
users of that system seemed a little unclear what 'quality' they were 
trying to create.  After a while the quality being maximized that 
seemed to emerge was 'cool'.  I had a fun discussion with somebody from 
that group about how it might be entirely different if people rated the 
content using icons.  I might say that one entry has very "smilie-face" 
while another bit of content was very "tree", "bicycle", "cloud", etc.  
That it would have created multiple quality vectors that the system 
could hill climb over.

In any case that system is kind of 80% wiki plus 20% slashdot with a 
mess of learning from the slashdot experience thrown in for free.

Sorry for not really replying to your note.  It's a big fuzzy topic...

   - ben

On Saturday, February 1, 2003, at 02:50 AM, Costin Manolache wrote:

> On Fri, 31 Jan 2003, Ben Hyde wrote:
>
>>   Costin Manolache wrote:
>>> My point was: if someone posts a mail with pointers to warez or porn 
>>> or
>>> spam -  it will get through and will be archived in the mailing list
>>> archives.
>>
>> Humm, are we arguing with the stop sign here?  We seem close to a
>> settling in on that rare and wonderful thing - a consensus about what
>> to do.  Is this hair splitting moving us toward that delightful goal?
>
> I'm sorry for not beeing clearer - I fully agree with most of what you
> say, and I think making the wiki more structured is good for many
> reasons. There is no doubt that having oversight - people keeping the
> wiki under control - is good.
>
> My concerns is over where do we draw the line - after the oversight is
> in place. The extremes are clear - porn will be removed, and excelent
> documentation will be included in the products and their authors may
> become committers.
>
> What happens in between is a different story. My opinion is that wiki
> should be treated as mailing lists - and not as source code in CVS and
> subject to consensus.
>
> The real problem is not the warez or porn - that's something we'll know
> how to handle. What if someone creates a page ApacheFooSucks ( where 
> Foo
> is one of the apache projects ) ? And it includes a list of problems
> and arguments - just like he would do it in the mailing list. Are we
> going to remove it - or just create ApacheFooIsGreat with
> counter-arguments ? What if it's about JCP ? Or GPL ? Or the
> best web development technology ? Do we keep or remove those pages ?
>
>
>> Maybe I'm missing the scale of the point your making.   I'll admit I
>> find it an interesting analogy, so I'll take the bait ... but first 
>> ...
>
> I think the problem is a bit larger than warez and the need to monitor
> wiki. Chosing where to draw the line between free  opinions ( as
> in mailing lists ) and full consensus ( as in code committs ) is a bit
> harder than sending notifications to the mailing lists ( where we
> seem to have a pretty broad agreement ).
>
> The really important argument you make is:
>
>> I do see a striking difference between the wiki and the mailing list.
>> The mailing list is the transcript of a conversation among assorted
>> parties.
>
> I do see wiki as a transcript of opinions and ideas of a user.
> It's better than the mailing list because it has structure and link
> and doesn't get lost. But it's fundamentally the same - an unbound
> number of people posting their toughts.
>
> If we treat the wiki as:
>
>> The Wiki, on the other hand, give the impression of being the document
>> of the organization (or I hope a PMC).  The readers and the writers of
>
> then we are bound to be disapointed and we'll misuse wiki.
>
> IMHO what's important is to find a way to make it clear and agree that
> wiki is not the oficial document of apache, just like the opinions of
> apache members posted on mailing lists are not the apache oficial
> position.
>
> ( sorry for cutting parts of your reply )
>
> Costin
>
>
>
>> that document are encouraged to treat it in that way.  So if I go in
>> and write something stupid, rude, lame, illegal, embarrassing in the
>> Wiki the first impression of the reader is not "who ever wrote this is
>> a twit" it's that "this document's authors are twits."  The 
>> association
>> seems much stronger.
>>
>> You could argue the same thing is true in a mailing list.  If I enter 
>> a
>> mailing list and the first few posting are twit-rich(tm) I am as 
>> likely
>> to think "The people on this list are twits." as the more accurate
>> "Those three are being twits today."
>>
>> It's interesting to consider the very nice example of PHP's easy to
>> edit manual annotations.  When you read those pages you get a very
>> clear dividing line between the content that is reflects upon the
>> reputation of the PHP doc team and the vs. the content that reflects
>> upon random individuals.  As a user of that manual I know to take the
>> comments with a grain (often a very large grain) of salt.
>>
>> Of course this whole business about how to design systems that have 
>> low
>> barriers to entry but then filter out the really good stuff is at the
>> heart of open source, source forge, everything2, etc. etc.  Lots of
>> room for experimentation.  Presumably when people dis source forge 
>> they
>> are critical of the balance they have struck between barrier to entry
>> and filtering.
>>
>>   - ben
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: community-unsubscribe@apache.org
>> For additional commands, e-mail: community-help@apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message