You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2003/01/31 11:41:17 UTC
Wiki - we have a problem :)
Folks,
I am seeing this weeking discussion reaching conclusions of sorts. However
there is still a significant problem with oversight.
What I mean here is -not- the ASF cultural thing of having things
validated by your peers; but the oversight of the type that the ASF as a
US incorperated is supposed to maintain.
In this role's I am not as much concerned with pages going up which say
'Thou venomed swag-bellied skainsmate!' or other types of respect lacking
community interaction; but specificaly of the type which gets us in
real-live(tm) trouble; warez, child-porn, list of license keys, etc.
So unless I hear this group establishing some very clear policy with
respect to WiKi's I will propose to the board that they go and instruct
the infrastructure@ folsk as follows:
-> No Wiki(s) will be ran under ASF auspicien unless there
-> is a PMC or similar body who duly provides oversight
to any abuse.
-> and the infrastructure@ pmc has validated that whatever
access control, metrics and what not are appropriate and
that each resource can clearly have an 'owner'.
Note that I did not add things such as acceptable use policies or
charters. I leave that to the PMC.
Though I personally would certainly encourage PMC's wanting a PMC to think
about that; as 'scope' helps to foster quality discussion. Though simply
saying that use should be on topic or in line with the mission/goal (which
usually is firmly embedded in the resolution which created the PMC in the
first place) helps.
Note that this is what is effectively happening on the push based mailing
list; moderation, warning being send to pwersons going off topic and other
non appropriate postings, and a community sense of 'scope'.
I'd appreciate feedback to solve the 'NOW' problem (not getting sued by
the scientology church or abetting (US) crime) - and to help me ask the
board for the right thing. We can solve the 'real' issue later.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we have a problem :)
Posted by Aaron Bannert <aa...@clove.org>.
On Friday, January 31, 2003, at 02:08 PM, Costin Manolache wrote:
> Are we now going to have similar "oversight" over the mailing lists and
> archives ? If someone posts a pointer to warez or porn on one of the
> lists
> - are we going to have to remove it from archives ?
You wouldn't believe how much porn-spam I get being one of the
dev@httpd.apache.org moderators...
-aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we have a problem :)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, 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
Then it -will- be noted by the committers and the PMC in a very timely
manner; no (resonable) doubt about that.
And thhey can remove, or have it removed, from the archives which the ASF
maintains which have visibility.
What -other- archives do with that is a different question and in my
opinion largely irrelevant when it comes to minimizing exposre to a
resonable level. (And yes - my personal take is that we ought to have
acceptable use notifications on mailing lists).
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Costin,
I see several differences between mailing list and Wiki content:
1. posting policy
If you manage your Wiki with Wiki pages in conversation mode, shouldn't you
want similar control over Wiki posting as e-mail posting?
2. representation
> I do see wiki as a transcript of opinions and ideas of a user.
E-mail is signed by the sender, and the presumed representation is that it
is the opinion of the sender. If you want your Wiki to be a transcript of
user opinions, don't you want the content coming from specific users to be
clearly represented as such?
Also, there are two types of Wiki pages: one represents the opinions of
individual users, but the other reflects a gestalt view. I've done both,
and I prefer the latter; the Wiki best practice known as document mode. A
document mode page may not represent the official position of a project, but
nor can it be said to represent individual opinions.
> IMHO what's important is to find a way to make it clear and agree that
> wiki is not the oficial document of apache
I agree with Danny Angus' proposal that the Wiki code place a disclaimer in
a page footer.
3. ownership
In my opinion, the Wiki is part of the project documentation. It may be
less official, it may be user-to-user, but it is part of the project
documentation.
> where do we draw the line - after the oversight is in place.
If someone submits a web page for the Tomcat help section stating as fact
that Tomcat sucks, that it won't install properly, that the developers don't
answer questions, that members of tomcat-user@ are rude and unhelpful, are
you going to commit it? We have both seen those sentiments expressed on the
mailing list by a handful of vocal malcontents.
4. Mailing list content extends over time. Wiki content morphs over
time.
The ability to morph content to reflect an evolving consensus is one reason
why document mode pages represent Wiki best practice. I consider it to be
the benefit of a Wiki, contrasting sharply with a mailing list, bulletin
board or weblog.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we have a problem :)
Posted by Ben Hyde <bh...@pobox.com>.
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
Re: Wiki - we have a problem :)
Posted by Costin Manolache <co...@apache.org>.
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
Re: Wiki - we have a problem :)
Posted by Ben Hyde <bh...@pobox.com>.
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?
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 ...
My sense is that people are reasonably comfortable with attempting to
move toward a model where there are N wiki are owned and operated by
individual PMCs. Those PMC can then strive to make those 'documents'
reflect their sense of what makes them proud. Meanwhile interlinking
and good search tools should make this just as delightful as the
current ownerless wiki.
I see a few good things about that. It resolves a problem for the
board, i.e. that it's their legal responsibility requires that they
have a simple awnser to the who's in charge question. It creates pools
of light were pride of ownership can illuminate the work of polishing
the content. It lets us get some diversity of approaches. It makes me
happy since it's an idea I've been advocating - and really that's all
that's important. Right now I think the Wiki is really neat, but I'm
not proud of it. I don't feel enough ownership to fight the good fight
to fix that; but I am willing to advocate a restructuring that would
create - ah - smaller oceans to boil.
To get at your point. I find it interesting because it seems to get to
the heart of how the open source process tried to create a engine that
sums up the skills and reputations of individuals into results that are
better than the parts, results that have higher reputations than the
individuals could probably create on their own.
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. If I post a stupid, rude, lame, illegal, embarrassing thing
to the mailing list there is little doubt that it was me who takes the
responsibility for that. It is my reputation that suffers.
The reputation of the list, and in turn the PMC that owns and manages
that list suffers only by association. In a list with enough
contributors that association will be limited.
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
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
Re: Wiki - we have a problem :)
Posted by Costin Manolache <co...@apache.org>.
On Fri, 31 Jan 2003, Dirk-Willem van Gulik wrote:
> On Fri, 31 Jan 2003, Costin Manolache wrote:
>
> > Are we now going to have similar "oversight" over the mailing lists and
> > archives ? If someone posts a pointer to warez or porn on one of the lists
> > - are we going to have to remove it from archives ?
>
> We have, in my opinion, sufficient oversight on the mailing list already:
>
> -> Mailing list are clearly assigned to specific commiter groups
> or pmcs; who is responsible is clear.
> ...
> This is quite in contrast to the -current- wiki site; where we lack clear
> mapping of sections to PMC's or commiter groups, where we have yet no
> clear indication that any and all changes are actively followed by the
> majority of the committers in that section and no clear scoping.
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. The PMC ( afaik ) can't take it back or remove it from the
archives ( maybe our archives - but I doubt we do that ). The fact
that we read the spam or just delete it ( which is what I do ) is
unrelated.
The wiki has the benefit (?) that bad content can be removed - by _anyone_
who happens to read it ( no only the PMC or committers ).
Fact is that wiki allows _more_ policing than mailing lists ( anyone who
reads a page can modify it and remove offending content - not just
the small number of PMC members ).
As I said, I have no problem with having more structure in Wiki - like
separate wikis for each PMC and some conventions on layout that would
allow easy navigation and tracking.
The solution I would like: a hiearchical layout on the wiki, with the
first levels restricted to PMC and projects. Each topic in wiki will have to
follow a pattern like: JakartaTomcatMyTomcatTopic.
If a topic doesn't start with one of the approved prefixes - it will
be rejected. We just need a map of prefixes to mailing lists, and
each project ( or subproject ) should get a prefix if it provies a list.
( JakartaTomcat -> tomcat-dev@, etc ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by "O'brien, Tim" <to...@transolutions.net>.
> > Oversight of content relating to a specific PMC should be the
repsonsibility
> > of said PMC.
>
> That is one view. There may be others.
I understand, and I don't mean to silence discussion at all. Just trying to
offer a very concrete proposal.
> > It is not clear that PMCs like [Web Service] have any Wiki content as
> > of yet.
>
> FWIW, they do.
Thank you, I stand corrected. Let's consider HTTP and APR.
> > Therefore, I propose a hierarchy of Wikis.
>
> Actually, I think that the topology is better viewed as a (potentially
> heterogeneous) network of federated wikis rather than a
> hierarchy. :-)
That also sounds very good, "The Apache Federation of Wikis". Maybe we can
shorten that to "The Federation" - what's next uniforms :-) You are right,
"hierarchy" makes it sound like one Wiki is better than another wiki.
Federation is more in tune with the concept of cooperation and
collaboration.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Sat, 1 Feb 2003, Noel J. Bergman wrote:
> > I hope we don't tear down the current one for a bit, make sure the PMC
> > owned ones are a functional replacement.
>
> I understand your concern about data loss, and share it. See my comment
> about starting the new ones as clones of the current one. And no need to
> take down the old one (maybe make it read-only because of oversight
> concerns?) until the PMCs say that they're done.
Well - I am sure that the PMC's can be extra vigilant ;-)
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Thinking about it some more. I guess my concern is less about the data
> and more about the people. I'm most concerned about pulling the rug
> out from under people having fun before their a place they can move
> their fun to.
I'm sure we can make the migration work. :-)
We wouldn't remove any content until after the new Wiki are in place, along
with the interwiki setup. Then we'd go to the old Wiki and insert #REDIRECT
directives to point to our new Wiki.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we've got a proposed solution - hierarchy
Posted by Ben Hyde <bh...@pobox.com>.
Noel J. Bergman wrote:
>> I hope we don't tear down the current one for a bit, make sure the PMC
>> owned ones are a functional replacement.
>
> I understand your concern about data loss, and share it. See my
> comment
> about starting the new ones as clones of the current one. And no need
> to
> take down the old one (maybe make it read-only because of oversight
> concerns?) until the PMCs say that they're done.
Thinking about it some more. I guess my concern is less about the data
and more about the people. I'm most concerned about pulling the rug
out from under people having fun before their a place they can move
their fun to.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I hope we don't tear down the current one for a bit, make sure the PMC
> owned ones are a functional replacement.
I understand your concern about data loss, and share it. See my comment
about starting the new ones as clones of the current one. And no need to
take down the old one (maybe make it read-only because of oversight
concerns?) until the PMCs say that they're done.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we've got a proposed solution - hierarchy
Posted by Ben Hyde <bh...@pobox.com>.
> My understanding ... The current Wiki, not being
> under any PMC oversight, would go away.
I hope we don't tear down the current one for a bit, make sure the PMC
owned ones are a functional replacement. Put some markings on the
current one. Move content, leave interlinks. Try to nudge people over
to those, etc. I'd be reluctant to rush to garbage collect. If one's
lucky then no toes need get stepped on, just a transition to - what
appears to me to be - a better model. - ben
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Dirk-Willem van Gulik:
> Noel J. Bergman wrote:
> > The three WikiAdmins are neither official nor representatives of a
proper
> > oversight body. The most logical group would be those who are
responsible
> > for the site module, and I don't believe that they want it.
> Well - the PMC's could each volunteer one wiki admin; just like we now
> have mailing list moderator volunteers - and delegate the task to them.
I don't mean for the per-PMC Wiki oversight. I was refering to his
suggestion that the three current WikiAdmins would continue to monitor the
current Wiki after the per-PMC Wiki would be installed.
My understanding is that according to the per-PMC Wiki policy, unless a PMC
wants oversight of a Wiki, it won't exist. The current Wiki, not being
under any PMC oversight, would go away.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, Noel J. Bergman wrote:
> The three WikiAdmins are neither official nor representatives of a proper
> oversight body. The most logical group would be those who are responsible
> for the site module, and I don't believe that they want it.
Well - the PMC's could each volunteer one wiki admin; just like we now
have mailing list moderator volunteers - and delegate the task to them.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we've got a proposed solution - hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Oversight of content relating to a specific PMC should be the
repsonsibility
> of said PMC.
That is one view. There may be others. I believe that there is interest in
having a consensus on policy first, and then a solution. Not too many
people have spoken up one way or another on that issue.
> It is not clear that PMCs like [Web Service] have any Wiki content
> as of yet.
FWIW, they do.
> Therefore, I propose a hierarchy of Wikis.
Actually, I think that the topology is better viewed as a (potentially
heterogeneous) network of federated wikis rather than a hierarchy. :-)
> The ApacheWiki will remain with it's 3
> official WikiAdmins
The three WikiAdmins are neither official nor representatives of a proper
oversight body. The most logical group would be those who are responsible
for the site module, and I don't believe that they want it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
CLARIFICATION: RE: Wiki - we've got a proposed solution - hierarchy
Posted by "O'brien, Tim" <to...@transolutions.net>.
I hope no one thought that I meant that only PMC members can change Wiki
content. My proposal still involves the public being able to change Wiki,
just centralizing the oversight.
--------
Tim O'Brien
> -----Original Message-----
> From: O'brien, Tim [mailto:tobrien@transolutions.net]
> Sent: Friday, January 31, 2003 6:01 PM
> To: community@apache.org
> Subject: Wiki - we've got a proposed solution - hierarchy
>
>
> -- related to community
>
> Community@ archives are available on Eyebrowse, and for
> someone not involved in those debates they record a several
> pretty important discussions. I won't mention any names, but
> I think it is time to prove that this list is "more than a
> big filibuster". Maybe in the process we can bring some
> people back to the community@ list through action not words.
> Please come back.
>
> Why would anyone ever think that a discussion of ASF policy
> on Instant Messaging is something not to make visible?
> Eyebrowse archives solve these problems -- I only hope that
> lists not currently archived aren't keeping good discourse
> secret. ( ACTUALLY, now that I think about it, the Instant
> Messaging policy discussion is an example of "highly ironic
> secrecy" . Take a read, and think about that:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@
> apache.org&msg
> No=1104 )
>
> -- a SOLUTION for WIKI
>
> NOTE: I feel terrible about making this proposal, as I wasn't
> involved in setting Wiki up, and if the proposal is accepted,
> it will mean real work for "somebody else". It might be
> possible for me to soon rejoin infrastructure and volunteer
> to lend a hand, but we'll see about that.
>
> Oversight of content relating to a specific PMC should be the
> repsonsibility of said PMC. It is clear that PMCs like
> Jakarta and James want a Wiki. It is not clear that PMCs
> like HTTP Server or Web Service have any Wiki content as of
> yet. ( DISCLAIMER: I don't speak for any PMCs, I am not a
> member of any PMC. I am observing the page HomePage. ) Say,
> that PMCs are made responsible for policing content, this
> would require someone from the HTTP PMC to become a
> RecentChanges watcher EVEN THOUGH her PMC has zero content on
> the ApacheWiki.
>
> Therefore, I propose a hierarchy of Wikis. Every Wiki has a
> set of dedicated WikiAdmins who enforce strict definitions of
> scope. The ApacheWiki will remain with it's 3 official
> WikiAdmins, and a separate instance of UseModWiki or SubWiki
> will be installed for each PMC which opts to create a Wiki.
> PMCs are accountable to the Board, and making PMCs
> responsible for Wiki content will "close the accountability
> loop". This would also centralize oversight for each PMC,
> (for example) an Avalon UseMod or SubWiki instance can be set
> up, and individuals responsible for enforcing scope and
> content regulations will be able to check a wiki specific
> RecentChanges page for only Avalon. This would also allow for an
> opportunity to experiment with different Wiki technologies -
> much like different PMCs have different websites. Allowing
> for heterogenous technologies, will also make it easier for
> PMCs to experiment with different patches to UseMod, SubWiki,
> PhpWiki, Twiki, etc..
>
> A PMC can choose not to have a Wiki. In this case, if an
> individual attempts to post content related to that PMC, it
> will be the responsibility of the ApacheWiki admins to remove
> the content and inform the PMC in question.
>
> --------
> Tim O'Brien
>
>
> > -----Original Message-----
> > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org]
> > Sent: Friday, January 31, 2003 4:28 PM
> > To: community@apache.org
> > Subject: Re: Wiki - we have a problem :)
> >
> >
> >
> >
> > On Fri, 31 Jan 2003, Costin Manolache wrote:
> >
> > > Are we now going to have similar "oversight" over the
> mailing lists
> > > and archives ? If someone posts a pointer to warez or porn
> > on one of
> > > the lists
> > > - are we going to have to remove it from archives ?
> >
> > We have, in my opinion, sufficient oversight on the mailing
> > list already:
> >
> > -> Mailing list are clearly assigned to specific commiter groups
> > or pmcs; who is responsible is clear.
> >
> > -> Most, if not all, of the committers and PMC members are
> > subscribed to the mailing list and are clearly reading
> > their mail.
> >
> > -> We have moderation in place, and developer lists generally have
> > clear and well defined scopes which are visibly policed.
> >
> > -> We see active policing of totally off topic data.
> >
> > This is quite in contrast to the -current- wiki site; where
> > we lack clear mapping of sections to PMC's or commiter
> > groups, where we have yet no clear indication that any and
> > all changes are actively followed by the majority of the
> > committers in that section and no clear scoping.
> >
> > Dw
> >
> >
> >
> ---------------------------------------------------------------------
> > 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
Wiki - we've got a proposed solution - hierarchy
Posted by "O'brien, Tim" <to...@transolutions.net>.
-- related to community
Community@ archives are available on Eyebrowse, and for someone not involved
in those debates they record a several pretty important discussions. I
won't mention any names, but I think it is time to prove that this list is
"more than a big filibuster". Maybe in the process we can bring some people
back to the community@ list through action not words. Please come back.
Why would anyone ever think that a discussion of ASF policy on Instant
Messaging is something not to make visible? Eyebrowse archives solve these
problems -- I only hope that lists not currently archived aren't keeping
good discourse secret. ( ACTUALLY, now that I think about it, the Instant
Messaging policy discussion is an example of "highly ironic secrecy" . Take
a read, and think about that:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msg
No=1104 )
-- a SOLUTION for WIKI
NOTE: I feel terrible about making this proposal, as I wasn't involved in
setting Wiki up, and if the proposal is accepted, it will mean real work for
"somebody else". It might be possible for me to soon rejoin infrastructure
and volunteer to lend a hand, but we'll see about that.
Oversight of content relating to a specific PMC should be the repsonsibility
of said PMC. It is clear that PMCs like Jakarta and James want a Wiki. It
is not clear that PMCs like HTTP Server or Web Service have any Wiki content
as of yet. ( DISCLAIMER: I don't speak for any PMCs, I am not a member of
any PMC. I am observing the page HomePage. ) Say, that PMCs are made
responsible for policing content, this would require someone from the HTTP
PMC to become a RecentChanges watcher EVEN THOUGH her PMC has zero content
on the ApacheWiki.
Therefore, I propose a hierarchy of Wikis. Every Wiki has a set of
dedicated WikiAdmins who enforce strict definitions of scope. The
ApacheWiki will remain with it's 3 official WikiAdmins, and a separate
instance of UseModWiki or SubWiki will be installed for each PMC which opts
to create a Wiki. PMCs are accountable to the Board, and making PMCs
responsible for Wiki content will "close the accountability loop". This
would also centralize oversight for each PMC, (for example) an Avalon UseMod
or SubWiki instance can be set up, and individuals responsible for enforcing
scope and content regulations will be able to check a wiki specific
RecentChanges page for only Avalon. This would also allow for an
opportunity to experiment with different Wiki technologies - much like
different PMCs have different websites. Allowing for heterogenous
technologies, will also make it easier for PMCs to experiment with different
patches to UseMod, SubWiki, PhpWiki, Twiki, etc..
A PMC can choose not to have a Wiki. In this case, if an individual
attempts to post content related to that PMC, it will be the responsibility
of the ApacheWiki admins to remove the content and inform the PMC in
question.
--------
Tim O'Brien
> -----Original Message-----
> From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org]
> Sent: Friday, January 31, 2003 4:28 PM
> To: community@apache.org
> Subject: Re: Wiki - we have a problem :)
>
>
>
>
> On Fri, 31 Jan 2003, Costin Manolache wrote:
>
> > Are we now going to have similar "oversight" over the mailing lists
> > and archives ? If someone posts a pointer to warez or porn
> on one of
> > the lists
> > - are we going to have to remove it from archives ?
>
> We have, in my opinion, sufficient oversight on the mailing
> list already:
>
> -> Mailing list are clearly assigned to specific commiter groups
> or pmcs; who is responsible is clear.
>
> -> Most, if not all, of the committers and PMC members are
> subscribed to the mailing list and are clearly reading
> their mail.
>
> -> We have moderation in place, and developer lists generally have
> clear and well defined scopes which are visibly policed.
>
> -> We see active policing of totally off topic data.
>
> This is quite in contrast to the -current- wiki site; where
> we lack clear mapping of sections to PMC's or commiter
> groups, where we have yet no clear indication that any and
> all changes are actively followed by the majority of the
> committers in that section and no clear scoping.
>
> Dw
>
>
> ---------------------------------------------------------------------
> 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
Re: Wiki - we have a problem :)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, Costin Manolache wrote:
> Are we now going to have similar "oversight" over the mailing lists and
> archives ? If someone posts a pointer to warez or porn on one of the lists
> - are we going to have to remove it from archives ?
We have, in my opinion, sufficient oversight on the mailing list already:
-> Mailing list are clearly assigned to specific commiter groups
or pmcs; who is responsible is clear.
-> Most, if not all, of the committers and PMC members are
subscribed to the mailing list and are clearly reading
their mail.
-> We have moderation in place, and developer lists generally have
clear and well defined scopes which are visibly policed.
-> We see active policing of totally off topic data.
This is quite in contrast to the -current- wiki site; where we lack clear
mapping of sections to PMC's or commiter groups, where we have yet no
clear indication that any and all changes are actively followed by the
majority of the committers in that section and no clear scoping.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we have a problem :)
Posted by Costin Manolache <co...@apache.org>.
Are we now going to have similar "oversight" over the mailing lists and
archives ? If someone posts a pointer to warez or porn on one of the lists
- are we going to have to remove it from archives ?
Sorry, but I fail to see the difference between wiki and the mailing
lists. Both are open to anyone to post - with the slight requirement
to provide a valid email address - if people don't use news gateway
( that can be added to wiki as well ). The information that is
posted on mailing lists is archived and available on the web just like
wiki.
IMO the problem is that wiki is treated in the same way with the CVS
or the web site. It should be treated as a mailing list with public
archives.
I am more concerned with the potential that someone who disagrees with
the content of the page would remove it - but again this abuse can
be resolved if we require a valid mailing address ( and we can restore
the page )
On the other side - I have no problem with having one ( or several ) Wiki
per PMC or subproject, and mirroring the postings in the wiki to a mailing
list.
Costin
On Fri, 31 Jan 2003, Dirk-Willem van Gulik wrote:
>
> Folks,
>
> I am seeing this weeking discussion reaching conclusions of sorts. However
> there is still a significant problem with oversight.
>
> What I mean here is -not- the ASF cultural thing of having things
> validated by your peers; but the oversight of the type that the ASF as a
> US incorperated is supposed to maintain.
>
> In this role's I am not as much concerned with pages going up which say
> 'Thou venomed swag-bellied skainsmate!' or other types of respect lacking
> community interaction; but specificaly of the type which gets us in
> real-live(tm) trouble; warez, child-porn, list of license keys, etc.
>
> So unless I hear this group establishing some very clear policy with
> respect to WiKi's I will propose to the board that they go and instruct
> the infrastructure@ folsk as follows:
>
> -> No Wiki(s) will be ran under ASF auspicien unless there
>
> -> is a PMC or similar body who duly provides oversight
> to any abuse.
>
> -> and the infrastructure@ pmc has validated that whatever
> access control, metrics and what not are appropriate and
> that each resource can clearly have an 'owner'.
>
> Note that I did not add things such as acceptable use policies or
> charters. I leave that to the PMC.
>
> Though I personally would certainly encourage PMC's wanting a PMC to think
> about that; as 'scope' helps to foster quality discussion. Though simply
> saying that use should be on topic or in line with the mission/goal (which
> usually is firmly embedded in the resolution which created the PMC in the
> first place) helps.
>
> Note that this is what is effectively happening on the push based mailing
> list; moderation, warning being send to pwersons going off topic and other
> non appropriate postings, and a community sense of 'scope'.
>
> I'd appreciate feedback to solve the 'NOW' problem (not getting sued by
> the scientology church or abetting (US) crime) - and to help me ask the
> board for the right thing. We can solve the 'real' issue later.
>
> Dw
>
>
> ---------------------------------------------------------------------
> 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
RE: Wiki - we have a problem :)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, O'brien, Tim wrote:
> Rules are rules. Maybe as a general rule, if a discussion doesn't need
> secrecy, it should be help on community@, since community is now archived in
> a public place. I believe this is called a "Sunshine policy"
Aye - that is a rule w're trying to introduce. Infrastructure@ is not
secret; and we may well end up archiving it - but it is about unix
sysadmin things; not about setting policy.
> I understand your concerns. I raised these issues with infrastructure@ back
> during the "Action not words" discussion. I'll try to echo it back, if I
> have misunderstood, please correct me. As a user of ASF software, I rely on
Thanks - that is valuable input; and this is the right place (or as good
as we have such a place)..
> ASF standards being set very high, I was playing devil's advocate with Mr.
> Oliver when I raised these issues back in December. He was convincing at
> the time, but, again, you've got some valid concerns.
> >From what I gather, you are not necessarily opposed to Wiki as a general
> "idea" - you just want to see it modified slightly to match the merit-based
> and project-centric work of the foundation. In other words, giving a
> non-committer the ability to use Wiki is not a problem as long as there is
Not a problem ---> no I think it is -great- to have that ability!
> some effective oversight by Wiki administrators. Let me summarize.
> Issues:
>
> 1. Scope/Goals of the Wiki - fostering quality discussion
> 2. Enforcement/Moderation of the Wiki
> 3. Accountability Mechanism
>
> NOW concern about liability:
>
> 1. Does unmoderated public posting affect the corporate shield? Does the
> ASF have any responsibility to limit access in order to protect the
> foundation as a larger corporate entity?
>
> ---- reponses
>
> * To your NOW concern about liablility, that is a valid one.
>
> Most importantly, it might be a good idea to put a disclaimer into the
> footer area of the Wiki sometime today. I believe that this would solve an
> immediate need while other methods are investigated. I only assume that ASF
> has some relationship with a lawyer, and it might make some sense to get a
> lawyer to write a good disclaimer.
>
> I believe one of your previous messages on community@ had an interesting
> idea:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msg
> No=1166 ( only now, can you refer to past community messages, thank you
> people! ). You mention that it would be better to require people to have
> some sort of "identity". In other words, you want people to have some "skin
> in the game". This seems reasonable, if you think that Wiki activity is a
> clear and present danger which could expose the foundation to legal action,
> then it is only sensible that this be fixed before any work goes forward.
>
> This is a *real* concern, ASF is a corporation of Delaware. I'M NOT A
> LAWYER, but ASF corporate status is a huge part of why people can do what
> they do here. ASF provides a corporate umbrella which limits liability - if
> you provide assistance to ASF, you can't get sued, only the assets of the
> Corporation are on the table. That's a good thing, if it is true that some
> bozo could post illegal content and ruin the ASF, then you've got a point.
>
> On the other hand, because ASF hosts the Eyebrowse archive, any individual
> may send an anonymous message to a mailing list license key and this message
> is almost instantly published as a web page via Eyebrowse. From that
> perspective, our email lists are simply another avenue for site content
> creation. The only difference is that one must have a valid email address
> in order to subscribe to a mailing list - this "gets to skin in the game".
And - unlike a WiKi page; an email is 'pushed' to a very large community;
and it is less likely that an issue is missed (or that anyone can easily
'deny' not having seen it) than it is with a WiKi page.
> Again, get a lawyer to write a good disclaimer, and let's get some
> regulations written up.
>
> * To your issues
>
> 1. Scope/Goals of the Wiki - fostering quality discussion
>
> Let's develop a formal proposal and codify this. Here's a start
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheWikiScopeAndGoals - the
> content about blogs and personal views may be a little controversial. I
> think that personal views, criticism of the ASF, are best hosted on other
> wikis. Those Wikis are in the works, and it is only rational that ASF have
> no relationship to those Wikis.
I am traveling right now; and have only email. I'll get back to this when
I am on line again.
> 2. Enforcement/Moderation of the Wiki
>
> There are 3 wiki admins right now. There are a larger number of people who
> watch the recent changes list. I think that a formal proposal should
> include a set of rules and regulations regarding moderation and enforcement.
> It may also be wise to set up a PMC-lite for those people.
>
> 3. Accountability Mechanism
>
> I believe that this relates to your overriding NOW concern, and it would
> help to have some sort of accountability mechanism that is anaolgous to the
> mailing lists. I'm personally neutral on this issue, but if you believe
> that it is a threat to the corporation, than this is a very big deal. I
> think that a well written disclaimer coupled with a strong set of
> enforcement and moderation rules could do the job effectively.
Dw.
> --------
> Tim O'Brien
>
> > -----Original Message-----
> > From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org]
> > Sent: Friday, January 31, 2003 4:41 AM
> > To: community@apache.org
> > Subject: Wiki - we have a problem :)
> >
> >
> >
> > Folks,
> >
> > I am seeing this weeking discussion reaching conclusions of
> > sorts. However there is still a significant problem with oversight.
> >
> > What I mean here is -not- the ASF cultural thing of having
> > things validated by your peers; but the oversight of the type
> > that the ASF as a US incorperated is supposed to maintain.
> >
> > In this role's I am not as much concerned with pages going up
> > which say 'Thou venomed swag-bellied skainsmate!' or other
> > types of respect lacking community interaction; but
> > specificaly of the type which gets us in
> > real-live(tm) trouble; warez, child-porn, list of license keys, etc.
> >
> > So unless I hear this group establishing some very clear
> > policy with respect to WiKi's I will propose to the board
> > that they go and instruct the infrastructure@ folsk as follows:
> >
> > -> No Wiki(s) will be ran under ASF auspicien unless there
> >
> > -> is a PMC or similar body who duly provides oversight
> > to any abuse.
> >
> > -> and the infrastructure@ pmc has validated that whatever
> > access control, metrics and what not are appropriate and
> > that each resource can clearly have an 'owner'.
> >
> > Note that I did not add things such as acceptable use
> > policies or charters. I leave that to the PMC.
> >
> > Though I personally would certainly encourage PMC's wanting a
> > PMC to think about that; as 'scope' helps to foster quality
> > discussion. Though simply saying that use should be on topic
> > or in line with the mission/goal (which usually is firmly
> > embedded in the resolution which created the PMC in the first
> > place) helps.
> >
> > Note that this is what is effectively happening on the push
> > based mailing list; moderation, warning being send to
> > pwersons going off topic and other non appropriate postings,
> > and a community sense of 'scope'.
> >
> > I'd appreciate feedback to solve the 'NOW' problem (not
> > getting sued by the scientology church or abetting (US)
> > crime) - and to help me ask the board for the right thing. We
> > can solve the 'real' issue later.
> >
> > Dw
> >
> >
> > ---------------------------------------------------------------------
> > 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
RE: Wiki - we have a problem :)
Posted by "O'brien, Tim" <to...@transolutions.net>.
Dirk,
I can't comment about what is happening on infrastructure@. I was the
impetus for closing the list, and shortly thereafter I unsubscribed from it.
Rules are rules. Maybe as a general rule, if a discussion doesn't need
secrecy, it should be help on community@, since community is now archived in
a public place. I believe this is called a "Sunshine policy"
---- your concerns
I understand your concerns. I raised these issues with infrastructure@ back
during the "Action not words" discussion. I'll try to echo it back, if I
have misunderstood, please correct me. As a user of ASF software, I rely on
ASF standards being set very high, I was playing devil's advocate with Mr.
Oliver when I raised these issues back in December. He was convincing at
the time, but, again, you've got some valid concerns.
>From what I gather, you are not necessarily opposed to Wiki as a general
"idea" - you just want to see it modified slightly to match the merit-based
and project-centric work of the foundation. In other words, giving a
non-committer the ability to use Wiki is not a problem as long as there is
some effective oversight by Wiki administrators. Let me summarize.
Issues:
1. Scope/Goals of the Wiki - fostering quality discussion
2. Enforcement/Moderation of the Wiki
3. Accountability Mechanism
NOW concern about liability:
1. Does unmoderated public posting affect the corporate shield? Does the
ASF have any responsibility to limit access in order to protect the
foundation as a larger corporate entity?
---- reponses
* To your NOW concern about liablility, that is a valid one.
Most importantly, it might be a good idea to put a disclaimer into the
footer area of the Wiki sometime today. I believe that this would solve an
immediate need while other methods are investigated. I only assume that ASF
has some relationship with a lawyer, and it might make some sense to get a
lawyer to write a good disclaimer.
I believe one of your previous messages on community@ had an interesting
idea:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msg
No=1166 ( only now, can you refer to past community messages, thank you
people! ). You mention that it would be better to require people to have
some sort of "identity". In other words, you want people to have some "skin
in the game". This seems reasonable, if you think that Wiki activity is a
clear and present danger which could expose the foundation to legal action,
then it is only sensible that this be fixed before any work goes forward.
This is a *real* concern, ASF is a corporation of Delaware. I'M NOT A
LAWYER, but ASF corporate status is a huge part of why people can do what
they do here. ASF provides a corporate umbrella which limits liability - if
you provide assistance to ASF, you can't get sued, only the assets of the
Corporation are on the table. That's a good thing, if it is true that some
bozo could post illegal content and ruin the ASF, then you've got a point.
On the other hand, because ASF hosts the Eyebrowse archive, any individual
may send an anonymous message to a mailing list license key and this message
is almost instantly published as a web page via Eyebrowse. From that
perspective, our email lists are simply another avenue for site content
creation. The only difference is that one must have a valid email address
in order to subscribe to a mailing list - this "gets to skin in the game".
Again, get a lawyer to write a good disclaimer, and let's get some
regulations written up.
* To your issues
1. Scope/Goals of the Wiki - fostering quality discussion
Let's develop a formal proposal and codify this. Here's a start
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheWikiScopeAndGoals - the
content about blogs and personal views may be a little controversial. I
think that personal views, criticism of the ASF, are best hosted on other
wikis. Those Wikis are in the works, and it is only rational that ASF have
no relationship to those Wikis.
2. Enforcement/Moderation of the Wiki
There are 3 wiki admins right now. There are a larger number of people who
watch the recent changes list. I think that a formal proposal should
include a set of rules and regulations regarding moderation and enforcement.
It may also be wise to set up a PMC-lite for those people.
3. Accountability Mechanism
I believe that this relates to your overriding NOW concern, and it would
help to have some sort of accountability mechanism that is anaolgous to the
mailing lists. I'm personally neutral on this issue, but if you believe
that it is a threat to the corporation, than this is a very big deal. I
think that a well written disclaimer coupled with a strong set of
enforcement and moderation rules could do the job effectively.
--------
Tim O'Brien
> -----Original Message-----
> From: Dirk-Willem van Gulik [mailto:dirkx@webweaving.org]
> Sent: Friday, January 31, 2003 4:41 AM
> To: community@apache.org
> Subject: Wiki - we have a problem :)
>
>
>
> Folks,
>
> I am seeing this weeking discussion reaching conclusions of
> sorts. However there is still a significant problem with oversight.
>
> What I mean here is -not- the ASF cultural thing of having
> things validated by your peers; but the oversight of the type
> that the ASF as a US incorperated is supposed to maintain.
>
> In this role's I am not as much concerned with pages going up
> which say 'Thou venomed swag-bellied skainsmate!' or other
> types of respect lacking community interaction; but
> specificaly of the type which gets us in
> real-live(tm) trouble; warez, child-porn, list of license keys, etc.
>
> So unless I hear this group establishing some very clear
> policy with respect to WiKi's I will propose to the board
> that they go and instruct the infrastructure@ folsk as follows:
>
> -> No Wiki(s) will be ran under ASF auspicien unless there
>
> -> is a PMC or similar body who duly provides oversight
> to any abuse.
>
> -> and the infrastructure@ pmc has validated that whatever
> access control, metrics and what not are appropriate and
> that each resource can clearly have an 'owner'.
>
> Note that I did not add things such as acceptable use
> policies or charters. I leave that to the PMC.
>
> Though I personally would certainly encourage PMC's wanting a
> PMC to think about that; as 'scope' helps to foster quality
> discussion. Though simply saying that use should be on topic
> or in line with the mission/goal (which usually is firmly
> embedded in the resolution which created the PMC in the first
> place) helps.
>
> Note that this is what is effectively happening on the push
> based mailing list; moderation, warning being send to
> pwersons going off topic and other non appropriate postings,
> and a community sense of 'scope'.
>
> I'd appreciate feedback to solve the 'NOW' problem (not
> getting sued by the scientology church or abetting (US)
> crime) - and to help me ask the board for the right thing. We
> can solve the 'real' issue later.
>
> Dw
>
>
> ---------------------------------------------------------------------
> 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
RE: Wiki - we have a problem :)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, Justin Erenkrantz wrote:
> > for violations of the above content rules. That group, for now,
> > could be a sub-group under the auspices of the infrastructure PMC.
>
> I'd rather not see the infrastructure committee (or any subset
> thereof) have to make the determiniation on what is proper or not.
> Nor, should they be tasked with removal of improper content. We'd
> just get seen as big bad bullies.
That is propably NOT going to happen. Infrastructure@ operates on the
level of scripts, file descriptors, threads, accounts, disk space on spool
var's - and is not a publishing policy setting or executing element.
Infrastructure@ will be happy to help write automated script to zap any
10Gyte divx upload, or perhaps even a virus scanner and help create a
moderation system; but both the spec's and the volunteers to operate it
will not only come from elsewhere, but will also be supervised by a PMC or
group concerned with 'content'. I.e. the coding projects.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, Noel J. Bergman wrote:
> I agree. But the message, as posted, didn't deal with improper content.
Correct. Though I can *well* understand PMC's which clearly keep the
message within their own Scope. As that gives a very fair and clear
policing guideline.
> The issue it raised was simply about oversight from a corporate liability
> perspective, essentially guarding against illegal behavior, and that is what
> I responded to in my reply. I mentioned my observation that it was a
> relatively weak standard for oversight. If more oversight is necessary, a
> different set of issues comes up.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin,
> The wikidiffs@ list received 77 emails yesterday. That's a *lot* of
> traffic for a small group to handle reliably. I certainly can't keep
> up with that.
Understood. One problem is that changes aren't merged. I probably do a
half dozen minor Wiki updates before I finish with an edit. I'd prefer that
diffs for oversight were only generated after pages settled. Obviously,
that requires a code change, and I'm not going to touch that code.
That is something to consider mentioning to Greg for SubWiki. :-) Even
with the oversight approach that we both agree upon, this could be an issue.
Wiki edits are likely to be made iteratively, whereas when I submit code to
the CVS, the edits are already merged. Imagine if we had to follow commits
made directly from emacs on C-X C-S! Ouch. :-)
> And, that's with only minimal activity on the wiki. I don't think a
> centralized group of oversight scales for something the entire ASF
> would use.
> I think the oversight belongs with the people are
> responsible for the content.
> I'd rather not see the infrastructure committee (or any subset
> thereof) have to make the determiniation on what is proper or not.
> I'd much prefer PMCs being responsible for sections of the wiki that
> their projects are using.
I agree. But the message, as posted, didn't deal with improper content.
The issue it raised was simply about oversight from a corporate liability
perspective, essentially guarding against illegal behavior, and that is what
I responded to in my reply. I mentioned my observation that it was a
relatively weak standard for oversight. If more oversight is necessary, a
different set of issues comes up.
I didn't pick infrastructure to do the work. I mentioned a group under the
auspices of infrastructure, since infrastructure is the only group that
spans the organization. I certainly didn't mean that the work would be done
by you, Brian, Manoj, Pier, et al.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by Justin Erenkrantz <je...@apache.org>.
--On Friday, January 31, 2003 10:26 AM -0500 "Noel J. Bergman"
<no...@devtech.com> wrote:
> This is a weaker oversight requirement than ensuring that
> information is accurate, or that more subtle content concerns are
> managed. If setup properly, scanning diffs to see that there
> aren't warez, porn, license keys, etc., shouldn't take very long.
> We're talking about < 30 changed pages per day on average.
The wikidiffs@ list received 77 emails yesterday. That's a *lot* of
traffic for a small group to handle reliably. I certainly can't keep
up with that.
And, that's with only minimal activity on the wiki. I don't think a
centralized group of oversight scales for something the entire ASF
would use. I think the oversight belongs with the people are
responsible for the content. As projects promote the use of the
wiki, the project is responsible for sharing the oversight burden.
> To do the above does not require any structural changes. It simply
> requires that some group be established that watches wiki changes
> for violations of the above content rules. That group, for now,
> could be a sub-group under the auspices of the infrastructure PMC.
I'd rather not see the infrastructure committee (or any subset
thereof) have to make the determiniation on what is proper or not.
Nor, should they be tasked with removal of improper content. We'd
just get seen as big bad bullies.
> Is that level of oversight sufficient, or do we need for each page
> to be under the oversight of a project PMC related to that content?
> The later introduces a whole different set of issues.
I'd much prefer PMCs being responsible for sections of the wiki that
their projects are using. And, if the PMC is responsible for general
oversight, they also get content oversight for free. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 31 Jan 2003, Noel J. Bergman wrote:
> > -> is a PMC or similar body who duly provides oversight
> > to any abuse.
>
> This is a weaker oversight requirement than ensuring that information is
> accurate, or that more subtle content concerns are managed.
Correct - I am after what would make this do-able for the board, and for
infrastructure@ to provide without risk.
I would expect PMC's to be more; and I could well imagine that PMCs -want-
do do more to preserve that peer reviewed quality which is (in my personal
opinion) of paramount importance :-)
But right now I'd settle for the 'NOW' problem :-)
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> What I mean here is -not- the ASF cultural thing of having things
> validated by your peers; but the oversight of the type that the
> ASF as a US incorperated is supposed to maintain.
> specificaly of the type which gets us in real-live(tm) trouble;
> warez, child-porn, list of license keys, etc.
> -> is a PMC or similar body who duly provides oversight
> to any abuse.
This is a weaker oversight requirement than ensuring that information is
accurate, or that more subtle content concerns are managed. If setup
properly, scanning diffs to see that there aren't warez, porn, license keys,
etc., shouldn't take very long. We're talking about < 30 changed pages per
day on average.
To do the above does not require any structural changes. It simply requires
that some group be established that watches wiki changes for violations of
the above content rules. That group, for now, could be a sub-group under
the auspices of the infrastructure PMC.
Is that level of oversight sufficient, or do we need for each page to be
under the oversight of a project PMC related to that content? The later
introduces a whole different set of issues.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by "O'brien, Tim" <to...@transolutions.net>.
> ...some useful
> patches, including one to require people to set their
> preferences before they can post to the Wiki.
Very simple patch, doesn't address true authentication, but it adds another
hurdle into the process...
http://www.usemod.com/cgi-bin/wiki.pl?WikiPatches/RequireAUserName
--------
Tim O'Brien
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Ben,
There may be some minor twists, but I didn't say it would be hard. :-) And
I am going to stay as far away from that code as possible. Tim O'brien,
though, already has some useful patches, including one to require people to
set their preferences before they can post to the Wiki.
To start, I think that we'd want to clone the current Wiki, on the grounds
that it will be easier for those of us who have data in it to delete the
extraneous pages than for Pier to figure out what each of us wants.
--- Noel
-----Original Message-----
From: Ben Hyde [mailto:bhyde@pobox.com]
Sent: Saturday, February 01, 2003 16:46
To: community@apache.org
Subject: Re: Wiki - we have a problem :)
On Saturday, February 1, 2003, at 02:10 PM, Noel J. Bergman wrote:
> a solution using the current Wiki code, I imagine that it would look
> something like:
>
> http://james.apache.org/wiki/
> http://jakarta.apache.org/wiki/
> http://avalon.apache.org/wiki/
> http://xml.apache.org/wiki
> http://incubator.apache.org/wiki
I'll note that the entire behavior of the wiki.pl script hangs by the
thread of this line:
$DataDir = ...;
If you modify that so it looks up the data dir based on the
$ENV{DOCUMENT_ROOT} or some other environment variable then the
provisioning of another PMC's wiki can pretty minimal.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Wiki - we have a problem :)
Posted by Ben Hyde <bh...@pobox.com>.
On Saturday, February 1, 2003, at 02:10 PM, Noel J. Bergman wrote:
> a solution using the current Wiki code, I imagine that it would look
> something like:
>
> http://james.apache.org/wiki/
> http://jakarta.apache.org/wiki/
> http://avalon.apache.org/wiki/
> http://xml.apache.org/wiki
> http://incubator.apache.org/wiki
I'll note that the entire behavior of the wiki.pl script hangs by the
thread
of this line:
$DataDir = ...;
If you modify that so it looks up the data dir based on the
$ENV{DOCUMENT_ROOT} or some other environment variable then the
provisioning of another PMC's wiki can pretty minimal.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Wiki - we have a problem :)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Now that it appears that a consensus is brewing, I'm finally posting this
message in public
---------------------------
There appears to be a consensus for a Wiki per-PMC approach until some other
Wiki technology might provide some other segmentation schema for oversight.
The purpose is to ensure that all content is overseen by some PMC. With the
current Wiki, there is no clear designation, no clear mechanism for
notifying the right people of changes to content they oversee, and there are
pages that aren't overseen by any PMC.
If the infrastructure team is willing to prepare a per-PMC Wiki structure as
a solution using the current Wiki code, I imagine that it would look
something like:
http://james.apache.org/wiki/
http://jakarta.apache.org/wiki/
http://avalon.apache.org/wiki/
http://xml.apache.org/wiki
http://incubator.apache.org/wiki
With appropriate redirects to nagoya, if that is where the Wiki will
continug living for the present. This also implies that if the Cocoon PMC
were ensuring proper oversight they could redirect
http://cocoon.apache.org/wiki to http://wiki.cocoondev.org.
We will need interWiki links to support such things as:
AvalonWiki:IoC
JamesWiki:MailetAPI
etc., and could use an interWiki link to send people to the usemodWiki
sandbox to play, rather than play on our server(s); the same might be true
of some other pages.
I don't see this as a shift in policy, simply a change in implementation to
address the need that at the ASF content requires oversight. Any content
engine must support, at a minimum, two related features in that area:
1) Associate content with the appropriate PMC
2) Allow change notification via e-mail
Note that I did not say *how* either of those things must work. With the
current Wiki, the per-PMC Wiki approach seems to be the best way to meet
those requirements.
I propose that the canonical URL for normal page access be /wiki/page,
regardless of which Wiki is deployed. As a technical matter, and also in
terms of planning for change, I believe that with a minor change to the perl
code, and use of mod_rewrite, we can hide the Wiki implementation in the
URL. One would to do this would be something like:
On daedalus: RewriteRule ^/wiki/(.*)$
http://nagoya.apache.org/<PMC>-wiki/$1 [R]
On nagoya: RewriteRule ^/<PMC>-wiki/(.*)$ /<PMC>-wiki/apachewiki.cgi?$1
If we did a proxy instead of a redirect:
RewriteRule ^/wiki/(.*)$
http://nagoya.apache.org/<PMC>-wiki/apachewiki.cgi?$1 [P]
ProxyPassReverse /wiki/ http://nagoya.apache.org/<PMC>-wiki/
we could make it seamless, but that would put more I/O load on daedalus.
SubWiki would be easy to handle. We wouldn't need a rewrite on nagoya at
all (even assuming that nagoya would be the host). JSPWiki (Cocoon), on the
other hand, makes it a bit trickier, because they use URLs like:
/Wiki.jsp?page=$1
/Edit.jsp?page=$1
/<Action>.jsp?page=$1
But that is easy enough to handle, because of the predicate that the only
URL that we care to preserve for bookmarks is the normal page reference.
In any event, the last portion of this message is something that can be
worked out on infrastructure, if the overall policy is adopted.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org