Re: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
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
RE: Wiki - we have a problem :)
...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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
