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. 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 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.
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.
Joerg
-- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
