[whups] whups mods... and a reference to Due Date

[Gary Weinreb]

Quoting "Robert E. Coyle" <robertecoyle@hotmail.com>:
> 
> From: "Gary Weinreb" <gweinreb@rocksolidsystems.com>
> 
> > > <Snip interesting use case>
> 
> Ahh.. that actually makes sense - it seems that you do just have a lot of
> similar types.  I presume that this:
> 
> From: "Mike Baptiste" <mike@msbnetworks.net>
> 
> > If I follow you correctly here - why not use the Type version feature
> > instead?  So you creaet modules for the various project types (radio, CD,
> > etc) and then create versions in each type for 2 min, 4min, etc.
> 
> While very interesting, isn't applicable because versions are associated with
> modules, and you're using the module field to track clients, not the type of
> audio production (is that right?)

Right.  I use Module = Client, State = Phase, Ticket = Project. 
> 
> When you copy the type to the new one, do you alter it in any way at all
> (other
> than the name)?  If not, it just seems to me that there should be an easier
> way
> of representing this - I just haven't thought of it yet...

Well, I'm still setting it up and experimenting.  The "Projects" portion
of my implementation is still in development, though the Webmail/Calendaring is
in production.  

In short, the answer to your question is Yes, the Type is altered other than
it's name.  Let me try and explain where I was going with this.  Basically, I
halted development after having my last set of diffs "rejected", not strictly
because of that, moreso due to other reasons, but I would very much prefer to be
working on a course of development which is in the interest of the Horde
project, for obvious reasons, and this concept apparently requires further
discussion and/or consideration.  No problem.  Better now than later <g>...

I don't actually "copy" a type to another, I "merge" sets of States or
Priorities (which are stored in "template" Types), into a given "target" Type,
probably, but not exclusively, at it's time of inception.  "Merging" means
testing for existence of the State/Priority in the "target" Type and creating it
if not already there.  

My "Priorities" are staying fairly stable conceptually, and are consistent
across all Types so I do a fairly straight "merge" of them initially from a
"Base template" and leave them alone.  Incidentally, I (and my client loves the
concept) use colors as the Priorities (Green - normal, Yellow - caution,
Orange - warning, Red - critical, Blue - exemplary), and eventually I plan to
color-code the various Listings (ala Categories) to reflect the Priority without
the textual overhead.  (BTW, I've received no feedback on this idea from this
list, and would like some, before I proceed to code something else which no
others want...)
 
For example, Client XYZ may produce a seasonal (quarterly) CD, in which they
always have my client do the "CD-Production".  Sometimes they provide the
graphics files for the cover, ready to print, sometimes they have my Client do
it in-house ("CD-Cover Design"), sometimes their CD is for archival purposes
only, sometimes it is for packaging and sale ("CD-Duplication").  Sometimes they
provide tape, sometimes my client goes to their location and records them
("Audio Recording, remote"), sometimes they come into the studio ("Audio
Recording, Studio")...  

Anyway, let's say I create "template" Types for "CD-Cover Design", "Audio
Recording, Remote", "Audio Recording, Studio", "CD-Production", and
"CD-Duplication".  They each contain several "States", detailing the various
phases encompassed by that Type.  The "template" Types may have some duplicate
States amongst them, for example, both "CD-Production" and "CD-Duplication" may
have "CD Mastering" as a State, though it will occur at the "end" of
"Production" and at the "beginning" of "Duplication".  All of these template
Types will have "Admin, Preliminary", and "Admin, Followup" States, because any
one Type could be utilized as a  template for a stand-alone project Type...  

With my changes, I can "merge" in any or all of the template Types I want to
incorporate into a new Type, and end up with a Type that contains all of the
States that this particular project requires, with no duplicate States.  I can
then fine-tune, adding or deleting individual States as required for this
specific Type.  I should point out that though I might already have a "CD -
Production" Type, it may not be appropriate for Client XYZ, as they may have
special needs, or special pricing, or so on, and require their own specific Type
for this Project.  Now, if I do the same Project again for the same Client in 6
months, I'll already have a Type set up for them, and only require a new Version
and a new Ticket (Project)...   

When the Client calls in and requests a project, they will stipulate the
requirements, and at that point, we want to set up the Project.  Some
requirements will be the same for all of their projects, such as who to notify,
and when, regarding proofing, etc.  These would be good preferences to store
with the Module, but be able to override at the instance (Ticket) level.  They
may want to see various quotes, including different combinations of Types, which
could easily be different Versions.  The "Quoting" process may cycle through
several iterations, so there may need to be "Quote", "Quote Submitted", "Quote
Revision", "Approved", and "Scheduled" and/or "Active" States on the whole
project, which might be merged in through a "Quote" template Type.  The whole
Project, as distinct Versions, may all be abandoned, or one Version will be
"Accepted" and eventually move into an "Active" State.  I'm not crazy about the
New, Assigned, etc. groupings of States, because of this.  i.e. A project may be
Assigned, but still not be in "Production", because it is still being sold...

Anyway, my Client charges Client XYZ different amounts, and different labor and
facilities resources are scheduled, based on the Types, and thus the States,
involved in the project, but we want to manage the "project" as a contiguous,
sometimes parallel "workflow", not as several separate projects which only
aggregate in Billing.  That is currently what is expected to happen, and it
often fails...

Currently, my last stab at it, (which lost momentum on ya'll's "rejection")
involved creating a new type on the fly if one didn't exist with the components
(States) required, and merging in the "States" from the appropriate "template"
Types, to create a Type with the appropriate workflow.
 
Ideally, we would "Create Ticket (Project)", select "Module/Client", create a new
"Version" on the fly, or multiple Versions if we're offering several different
Quotes, and then be able to select several Types as "Tickets", some of which
would exist concurrently, some of which would follow one another sequentially,
all of which would then flow together towards Resolution.

The principal of having Types which can "nest" (or, I believe "roll-up" in MS
Project terminology) inside other Types is very powerful for creating workflow
dependencies.

<SNIP>
 
> Yes - workflow is the current direction for whups.  Did you see my previous
> mail
> about implementing state transitions for workflow?  I'd be interested to hear
> how
> it fits with the way you're currently using whups.
> 

Well, the way I'm currently USING whups is as a platform to develop a workflow
app from... so, I'm excited that you are involving yourself in the same.  Having
seen your name in many if not all of the whups files I've messed around in, I
can only assume that you know a lot more about what you're doing in there than I
do...<g>...

I do have quite a bit of experience (20+ years) designing and implementing
software applications in the real world though, so perhaps I can contribute
something worthwhile conceptually while learning the Horde framework...

State Transitions are a key to much of what I see as the implementation of
whups as a powerful workflow management system.  What happens when a Ticket
enters or exits a State.  I would like to see "triggers" (events) fire when a
State is entered, and when a State is exited, so that conditions can be tested,
and other events caused to occur.  I think the mechanism that you suggested in
your posting of Nov. 20, Workflow, is right on track with what I was thinking. 
I am looking for a method of encapsulating actions and their subjects into
conditional triggers to be tested upon the entry and exit of States, and
Priorities, too, for that matter...  Your Attributes additions are an excellent
part of this, as well.  

It seems that we need a mechanism for structuring a syntax for testing
conditions and storing the tests, as well as actions and action-subjects, and
then, as you and Chuck have mentioned, serializing this as data...

The current thread regarding Due Date relates to this, BTW.  One of the default
tests of a State should be how long the current Ticket has been in that State,
or perhaps, if it is being run by a cron job, how long a Ticket has been in a
given State, tested against an expected value.  Too much time, and any number of
events should occur, a notification (perhaps of Administrative or Supervisory
group of personnel) or a Priority change...  This can fit into many popular
management perspectives on performance measurement, though there are certainly
arguments which illustrate that measuring performance and managing against the
results can have adverse effects on quality...

My point is that it seems that the Due Date should not be on the Ticket, per se,
but upon it's duration in a particular State...

Regards,
GaryGary Weinreb
RockSolid Systems, LLC


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/