cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [proposal] Doco
Date Fri, 24 Oct 2003 13:47:13 GMT
Joerg Heinicke wrote:

> Stefano wrote
> 
>>>       c) the email will have "reply-to" set to the "allow" action and 
>>> a continuation ID. and will have the CC: header set to "reject" with 
>>> the continuation ID. So, by "replying" to the email
>>>       d) by hitting "reply", the workflow will approuve the changes
>>>       e) by hitting "reply to all", the workflow will reject them 
>>> with no further action
> 
> 
> Kenny Smith wrote:
> 
>> Hi Stefano,
>>
>> I think the overall concept for this project is pretty cool and very 
>> well thought out.
>>
>> The one part that stands out to me as a weak link is the "reply" vs. 
>> "reply to all" mechanism. It seems prone to human errors and to things 
>> like vacation messages. How would conflicts be handled (one person 
>> rejects and one approves)?
>>
>> At the very least, I would provide a mechanism that allows changes to 
>> be just as easily revoked as they were approved so that late that one 
>> night when someone accidentally hits "reply to all" instead of "reply" 
>> that they can easily fix it.
> 
> 
> I can only join. Email workflow is bad in general, but additionally the 
> above system is to much error prone. 

I has worked for the apache group since 1995. Yes, there are occasional 
mistakes and some message gets moderated thru even if it shouldn't, but 
compared to the traffic we get this is really nothing.

> 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 even this I don't 
> like much. What about authorization? 

only "doc committers" are subscribed.

> Are the committers registered with 
> specific mail addresses? 

of course, how else?

> What happens if the preferred address changes?

they tell us and we change the address.

keep in mind that most of them are committers anyway, they will have an 
@apache.org address that will never change.

> 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.

> > This is still much easier than the current workflow with applying a 
> patch, committing to CVS, and so on, but less error prone than the above 
> approach.

In the entire history of the wiki, we had only a few cases of severe 
vandalism on our wiki. That workflow is designed to prevent the 
vandalist acts but without slowing down the creative process.

-- 
Stefano.



Mime
View raw message