Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 25118 invoked from network); 26 Oct 2003 00:58:47 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 26 Oct 2003 00:58:47 -0000 Received: (qmail 91642 invoked by uid 500); 26 Oct 2003 00:58:27 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 91599 invoked by uid 500); 26 Oct 2003 00:58:27 -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 91571 invoked from network); 26 Oct 2003 00:58:26 -0000 Received: from unknown (HELO sati.virbus.de) (145.253.246.81) by daedalus.apache.org with SMTP; 26 Oct 2003 00:58:26 -0000 Received: from sati.virbus.de (localhost [127.0.0.1]) by localhost (SMTP Server) with ESMTP id BEDF4166AAB for ; Sun, 26 Oct 2003 02:58:34 +0200 (MEST) Received: from virbus.de (Bd49a.b.pppool.de [213.7.212.154]) by sati.virbus.de (SMTP Server) with ESMTP id EB6CA1669A6 for ; Sun, 26 Oct 2003 02:58:33 +0200 (MEST) Message-ID: <3F9B1C5D.90000@virbus.de> Date: Sun, 26 Oct 2003 02:59:09 +0200 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-gb, en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [proposal] Doco References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 26.10.2003 01:49, Stefano Mazzocchi wrote: > >>>> We should at least use the body with an explicite "accept" and >>>> "reject" in it. This can't be done by accident, while it can happen >>>> for sending a mail. >> >> >> But why not at least explicite "accept"/"reject" in the subject or the >> body of a mail? > > > saves you a couple of seconds per email. the easier the job, the more > people will do it. > > more than errors, I'm concerned to people not moderating things thru. > >>>> I would like to see a little application, where a link in the mail >>>> points directly to the resource. The committer has to login and >>>> accept or reject the change. So conflict situations can also be much >>>> better handled and reverting changes should also be easier to be >>>> implemented. >>> >>> I dislike this, it stops me from doing auditing offline. >> >> >> Is offline/online still an issue? > > > It is for me. I want a system that works for me, does not force me to > work for the system. > >> Furthermore we only talk about minutes if not seconds per day: the >> mails are sent, you can read offline and decide whether to accept or >> reject,, go online, click on the link in the mail, login, click >> "accept" or "reject", finished. Even on the wiki not more than ten >> pages change per day. We are many more committers. > > > suppose that I'm online and reading email. > > your solution requires me to: move my hand on the mouse, click on the > link [this opens the browser that will automatically fill the login page > with my login/password], click login, approuve the change, go back to my > email client. > > my solution requires two keystrokes > > your solution is easy enough, but I'm way more lazy than you can > possibly imagine... I know me and I know that many fellow cocooners are > as lazy as I am, this means that I will end up avoiding doing > moderation, or forgetting altogether. > > this will result in a few people doing the moderation task only, > increasing by orders of magnitude the errorprone-ness of the system and > decreasing fault-tollerance by reducing distribution of laber and > redundancy. > > I say we try my lazy ass solution first and then, in case we find > problems with it, we change. > > deal? Man, you must really be lazy ;-) So, yes, let's try your solution first. Joerg