Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 18054 invoked from network); 25 Oct 2003 10:14:28 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 25 Oct 2003 10:14:28 -0000 Received: (qmail 55408 invoked by uid 500); 25 Oct 2003 10:13:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 55366 invoked by uid 500); 25 Oct 2003 10:13:56 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 55353 invoked from network); 25 Oct 2003 10:13:56 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 25 Oct 2003 10:13:56 -0000 Received: (qmail 25195 invoked from network); 25 Oct 2003 10:14:06 -0000 Received: from unknown (HELO apache.org) (stefano@212.254.251.104) by pulse.betaversion.org with SMTP; 25 Oct 2003 10:14:06 -0000 Date: Sat, 25 Oct 2003 12:14:26 +0200 Subject: Re: [proposal] Doco Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Stefano Mazzocchi To: dev@cocoon.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: <3F992FBC.2050005@outerthought.org> Message-Id: <0369AC65-06D4-11D8-B33B-000393D2CB02@apache.org> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Friday, Oct 24, 2003, at 15:57 Europe/Rome, Steven Noels wrote: > Stefano Mazzocchi wrote: > >> In the entire history of the wiki, we had only a few cases of severe >> vandalism on our wiki. > > Please don't over-generalize, Stefano. We have weekly 'annoyances' on > the Cocoon Wiki ATM, but some people happen to clean them up sooner > rather than later. I know the Wiki appears to be running smoothly, but > it requires energy and handholding at times - these times even that > much that I'm still hunting for some free moment to move it to moof. > Ditto with moderation: I have at the very least 20 spam mails and > viruses awaiting me in my moderation inbox (from all Cocoon lists) on > a daily basis, some days more. I'm sorry, I didn't make myself clear with the above: my point was not that a document management system doesn't need work to operate (being a wiki or something more complex doesn't matter), but that since the "severe" vandalism (that vandalism that would be "embarassing" for us in front of our public and in front of the ASF board/members/infrastructure) frequency is very low, the "error prone"-ness of the system (as was implied) has to be normalized with that severity frequency. I mean: if you get "look mom, I can modify an apache site" on cocoon.apache.org because somebody wrongly hit reply instead of reply-to-all, then nobody does anything for 24 hours and the above gets published is not a big deal. Different would be to have "f**k [insert your favorite public figure here]" or child pornography passing thru the system, but in order to happen, the chain of events that should happen are: 1) somebody does that kind of vandalism (so far, happened only a few times) 2) a moderator sends "reply-to" instead of "reply-to-all" and *NO OTHER MODERATOR* does anything (the probability of this event is, IMO, already rare, redundancy of moderation should also reduce errors) 3) the change is approved, approuval email is sent back to the moderators list and nobody goes to the backend of the system to revert the changes for 24 hours (again, pretty unlikely that I would receive an email that says "this change was accepted by "blah" see the diff inside" and I would just sit and watch... the 24 hour period should be enough to get at least one other moderator see it... keep in mind that moderators don't need to be necessarely committers) It is not impossible that such a chain of events happen. But it is not so prone to errors as it might seem at first sight. [well, at least that's my impression, practice might prove me dead wrong] > > That workflow is designed to prevent the vandalist acts but > > without slowing down the creative process. > > We definitely need some form of oversight. The current 'mass push' to > a mailing list appears to be working quite well IMHO. We need "pre-emptive oversight" if we want to have the slight chance of having the ASF infrastructure team allow us to use such a system in practice. -- Stefano.