cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [proposal] Doco
Date Fri, 24 Oct 2003 22:37:16 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.

I agree.  _Great_ proposal.

>> 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. 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? Are the committers registered with 
> specific mail addresses? What happens if the preferred address changes?

I agree that the accept=Reply, reject=Reply To All feels a little hacky 
but I also see there's not a lot of great options.  Would subject line = 
approve/reject be a better compromise?  Maybe the default line could 
have "accept" and no subject would mean "reject".  So reply would mean 
accept and delete the subject and reply would mean reject?

At the end of the day, I'd live with any of the proposals on the table. 
  The overall system is such a big step forward that I'd rather pick 
anything that works technically and just go with it for now.  It's not a 
large group of people to communicate with to change the system later.

> 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 think Stefano has a good point on this - you can process offline and 
"commit" when you next synch mail.

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

Again, does anyone really think the choice of this method should delay 
forward progress at all?


View raw message