Kenny,
This pattern looks like the one currently used by the mail moderators for apache lists, and as such it's familiarity is probably a benefit.
Exactly. I would exactly mimic the behavior that moderators are used to.
While James is easily capable of supporting much richer functionality, the problem occurs when you try to figure out how you can use the extremely minimal information that is guaranteed to be passed back in the headers of a reply.
TBH disentangling conflicting approve/reject messages is always going to require a people-centric solution as it is a symptom of a people problem (conflicting opinions in the team). As with revision control the software can only go so far and it needs to be supported by having a communicative team with agreed and shared goals.
very well said. The workflow system should *NOT* turn into a communication media (like some people do over issue tracking software, for example), but as a more efficient (think asynchronous) way to do approuvals.
So, instead of having to log into a web site, see the list of changes and approuve each one of them, you just have to go thru your email and decide to reply or not.
One useful addition might be to accept the first command and reject all subsequent ones with a message to the effect that the change has already been approved/rejected, it would then fall to the commiters to discuss and resolve the conflict through a more collaborative channel.
Seems like a good idea to me.
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
