Job Workflow and/or subordinate jobs

[GoogleCodeExporter]

Have you ever had a job that you were primarily responsible for, and you
needed to hold off on it pending someone else doing something?

Many issue tracking systems allow you to specify a "next-action", meaning
that while this job is still yours, you can't do anything until someone
else completes a related task or sub-task.

Assuming we have Job 100, a coding project to that requires a policy file
to be written to define its scope, I propose:

+job/next 100/Project News=We need to define the policy for what this
project is doing.

This command will do the following:
 #1) It will lock 100 from editing, and set its escalation to NEXT. 
 #2) On the job list, jobs escalated to NEXT appear plain-gray-- as opposed
to green/yellow/red.
 #3) A new job will be created in the NEXT bucket, 101, with the title of
'Project News', and the initial comment of 'We need to define...etc'. 
 #4) The new job will inherit the escalation of the original job.
 #5) If you +job/approve 101=msg or +job/deny 101=msg, that message will be
added into job 100 indicating that the sub-job was complete.
 #6) When the sub-job is complete, the parent will be unlocked.

Like, dislike?

Original issue reported on code.google.com by apt.shan...@gmail.com on 23 Oct 2007 at 9:07

[GoogleCodeExporter]

I'm not sure if I like this method. At point point Anomaly and I discussed 
adding
support for 'threaded' jobs. IE, with the situation above you would just 
created a
job like '+job/create files/Projects New=We need to creates news files for 
projects
news to explain that ......' Then you would just +'job/link it to the main job 
and it
would appear as a sub job. We figured that would happen in two ways. One, it 
would be
directly under the main job in the jobs list, but marked/indented. Two, in the 
main
job's header it would say 'Linked Jobs: 396' and in the linked job's header it 
would
say 'Main Job: 100'. 

If we could implement this, it would be more flexible. Instead of one Next job, 
you
could create a main job for something complex and then link in 20 jobs to it. 

Original comment by grey...@gmail.com on 23 Oct 2007 at 2:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

... Okay, none of that may have been clear. Re-doing comment! I shouldn't try 
to make
sense 2 minute after I wake up :)

Basically, the +job/link feature you talk about adds more complexity of use for 
no
benefit that I can see; and it lacks some of the core/fundamental things that 
make
+job/next useful. The automatic feeding of information in and out of these 
sub-jobs. 

It's just too much of a burden on the users; I honestly have a hard enough time
getting users to use a LOT of Jobs features because the interface effectiveness 
is
too complicated for them. When +job/sumset came out, I was @whee. Now I have to 
write
custom code to more easily manage setting of data on jobs. 

I'm looking at this from a use-case situation; how it would be used in real 
life, and
how to make it as seemless and easy as possible for the users while allowing 
maximum
flexibility. 

My use cases are situations like: "I, as code wiz, am stuck on completing this 
task
until Build wiz creates and approves something, Theme wiz writes the policy 
spec, or
Bob over there finishes testing." I am stuck and need to farm out some effort.

Now, if that first part is always, "I, as code wiz, am stuck..." then I'd say 
sure,
lets go for the /link. But if it says "I, as build wiz, am stuck..." or some of 
our
even less technical staff, then I can't expect them to go through very much 
extra
effort. 

To solve the use-case above, I need:
 #1) A very simple and effectively intuitive way to create a new job that is
associated with the last, including the means to set an initial comment. 
(+job/next
100/Title For Subjob=Body)
 #2) Assign this to another person (+job/assign 100=Bob)
 #3) Clearly indicate on +jobs that I am in a "stuck" position, so that anyone who
looks at 100 knows this, and if they read 100 they see why (The comment for 
"Body"
would also be put in the parent job), and so it not being worked on is clearly
understood.
 #4) Clearly indicate to Bob that this task assigned to them is associated with
another job, and that when it is closed it will free me up to finish my task.
 #5) When Bob closes his job, it needs to seemlessly inform me that I can now
continue work. Expecting me to keep up and remember the Staff Job Tracker 
doesn't
work. Having me as the source and then receiving an @mail VERY much doesn't 
work-- if
I have to type @mail as staff, something is wrong :) Ergo, the /approve or /deny
message needs to be add its closure message into the final job and (if its the 
last
/next), unlock it.

This isn't about creating "Sub jobs" as much as it is creating a very, very 
common
workflow in issue trackers that is incredibly useful to use in regular, day to 
day
life. I actually don't see the purpose of having one meta-job and 20 sub-jobs; 
at
that point it sounds like it's just a bucket. 

Expecting the initiator to +job/link, and then the worker to close their job 
then
inform me in mine, is just too much of a burden for no benefit that I can see-- 
but
perhaps you have a use-case I'm not thinking of? 

This is about a situation that comes up a lot, if I have Job 100, but I need 
someone
else to do something? As it stands I /assign it to them, they add comments and
discussion, and when they're done-- my 100 is contaminated by details that, 
while
tangentially connected, are of no use to 100's real discussion. Its a waste of
information. All I need to know is "I need X.." and then "... X has been done" 
in there. 

The next-action is a sub job in a way, though, and I do like how you talk about
displaying it indented over a bit; it makes #3 and #4 a lot easier. 

Original comment by apt.shan...@gmail.com on 23 Oct 2007 at 4:15

[GoogleCodeExporter]

I've been contemplating a workflow solution for the system for some time (as 
Grey 
said, we discussed it a few years ago), however, my primary contention with it 
is 
that nobody knows your game's workflow better than yourself. Establishing a 
process 
that works isn't difficult, but establishing on that is universal for all games 
is, 
frankly, impossible.

I'm not going to reject the idea outright, because it's an idea I keep 
returning to, 
but finding a method that is useful for the largest number of games has been 
difficult.

I'm interested in hearing any ideas regarding this particular issue.

Original comment by Fleety...@gmail.com on 24 Oct 2007 at 1:06

[GoogleCodeExporter]

I'm not sure I see the connection between workflow and next-actions.

Workflow for an issue tracker can't be universal, of course, but has to just be 
a
system allowing semi-automated progression of a task through several stages; 
moving
the task, reassigning the task, changing its status (escalation?), etc... 
There's a
number of straightforward ways one could be integrated into Jobs. It's always a
framework, though, never an answer.

We use workflow at work in our issue tracker, and I've implemented a generic 
workflow
system into our own product-- it's not really that complicated. You have to 
create a
generic sort of framework of stages and actions and triggers, but... 

However, I'm not talking about workflow here. At least, not any kind of 
workflow I've
ever seen before.

A next-action is a very specific sort of thing; the feature is meant simply to 
say,
"I have this task that I need to do, but I can not do anything on it, as the 
ball is
now in Jane's court. The thing Jane has to do may be simple or complicated so 
needs
tracking on its own, but when she's done I need to be updated on her status."

Original comment by apt.shan...@gmail.com on 24 Oct 2007 at 2:50

[GoogleCodeExporter]

Just to be clear: I'm not asking anyone to implement this. I intend on doing 
so. The
purpose of this issue is more, "Do you want it?" and "Do you have a better idea 
of
how to architect it?" The latter would have to solve my needs seemlessly, but if
there's a way to do so and also allow some concerns of others, great. 

If you don't want it, that's fine :) All that means is I won't be updating 
unless
Jobs has some incredible new feature that makes re-doing it/re-porting it worth 
the
effort, which is no biggie. :) 

Original comment by apt.shan...@gmail.com on 24 Oct 2007 at 2:58

[GoogleCodeExporter]

Liking and workflow are highly related, but you're right, they're two different 
issues. Inbred cousins, at best. :)

I keyed off your paragraph in your previous post: "This isn't about creating 
"Sub 
jobs" as much as it is creating a very, very common workflow in issue trackers 
that 
is incredibly useful to use in regular, day to day life."

I'd rather use +job/next for an actual workflow model, IE, it moves the job to 
the 
next step in the workflow list.

Let's call it +job/link.

I don't like all the job renaming, and I'm not for the the concept of having a 
NEXT 
bucket (too many people would require access to it, when a NEXT job could be a 
sensitive thing that not everyone needs to see). Having the job indented below 
it 
would require massive sorting of the lists, unless we turned the job into a 
dynamic 
bucket (Grey, reference +parents on Anomaly, where children are indented below 
its 
parent) where jobs are stored inside other jobs, but then we would REALLY need 
to 
rewrite the locate code (reference #1140 @ Anomaly, @teleport into it, and type 
+orgs). The way the #1140 list has to be constructed is a nightmare, and would 
likely violate some function invocation limits for a jobs system of any 
considerable 
size. Finding the job is even nastier than list gathering.

The ideal, then, would be the disliked (by me, anyhow) renaming/naming scheme. 
I 
don't think that they should appear directly below the master job (again, 
sorting 
issues). I think they should be created like a normal job and placed at the 
bottom 
of the list. The master should not be renamed. It should be flagged as a Master 
invisibly by the system. It can still be fuxx0red with, but it cannot be 
closed/deleted/completed/approved/denied until all of its children have been 
completed. A command like '+jobs/links <#>' could list all linked jobs, and we 
can 
create a new column for the main display to show whether it is a master job or 
a 
linked job.

Any thoughts?

Original comment by Fleety...@gmail.com on 26 Oct 2007 at 3:29

[GoogleCodeExporter]

I'd actually +job/adv(ance) and +job/rev(erse) for workflow, personally.

The NEXT bucket was, in effect, an implementation detail when I was doing this 
just
as a hack; it was the simplest way to get the communication back, by using APR 
hooks
on that bucket.

I don't understand what you mean by "job renaming", this is the first I've 
heard of it.

Indenting can be done in a very, very straight-forward way, VERY efficiently, 
without
adding more then a couple function invocations per job in the common case where 
a job
is not a master. If someone is tight enough on the FIL where 2x<Total Jobs> of
additional function invocations is a problem, chances are high it'll be a 
problem
anyways. No big sort or searches are necessary. I like the idea of indenting so 
very
much that I'll show you a sample implementation when I get into this-- and if 
you
still feel it's too expensive, it can be removed from the distro.

As for +job/link? I dislike it strongly, because it doesn't say to me "creates 
a new
job". I have an idea on that, however: what if +job/link is to meant to link an
already existent job to a master, and add a +job/spawn command to spawn off a 
new job
and link it w/ a single command?

The one implementation detail I'm not clear on is, lacking a NEXT bucket, how 
best to
hook /approve, /deny, /complete, and /delete into the next action system. It 
seems
I'd have to make each of the command next/link aware-- which is why I went with 
the
NEXT bucket hack, as I could make just the bucket aware. :) I don't want to 
modify
every single command if I can avoid it. Perhaps a modification to %va/TRIG_ADD? 
Have
it call TRIG_LINK with all the necessary details so the link can write the 
commit
message over if it wants/needs to, depending on %3.

Original comment by apt.shan...@gmail.com on 26 Oct 2007 at 3:51

[GoogleCodeExporter]

Original comment by grey...@gmail.com on 29 Oct 2007 at 4:25

• Added labels: Milestone-Release5.3

[GoogleCodeExporter]

Removing milestone information as this discussion does not appear to have 
concluded
with any consensus.  Definitely room for a future feature linking jobs if a 
common
scheme can be decided on.

Original comment by widdis@gmail.com on 19 Dec 2009 at 1:57

• Changed state: New
• Removed labels: Milestone-Release5.3

[GoogleCodeExporter]

I think that this could actually be performed by SET hooks if the behavior is
required.

&HOOK_SET <bucket/parent>=Is STATUS=0? Does job already have a NEXT_JOB attr?
Fail if no. Succeed if yes, and TRIG_CREATE a new job with all the necessary
back-linking to the old job, and title it accordingly, attaching name emphasis
referencing the prev job.

It might require a custom TRIG_CREATE (modified from the old), but that, too, is
not tough for a game to implement if this behavior is needed.

I also think it is more useful as a plugin - the usefulness potential seems low 
because we already have the capability - it seems to me to be a workflow issue 
and not a jobs issue.

Workflow solution:
If work is stalled, you should set the job to ON HOLD, assign it to
whomever is next in line, and add a comment that they need to do X. When they 
do X,
they add a comment saying X has been done. They remove their name from 
assignment 
and set the status back to whatever it was before.

It's kind of the whole idea behind +jobs in general. I'm not being sarcastic, 
here,
so please do not misconstrue what I'm saying. The original idea behind jobs was 
to
have one issue associated to one job, to allow for accountability without much
hassle tracking back through the issueand if a single job is split 20 different
times, then imagine that accountability backtrack, and figuring out what 
happened
and when. It also keeps staffers from having to worry about 'what jobs go with
what', which would allow for more issues to potentially fall through the cracks.

I am not in favor of this as proposed.

Original comment by Fleety...@gmail.com on 12 Jan 2010 at 8:13

[GoogleCodeExporter]

I concur that a separate, optional plugin would work well. "Here's one possible 
way
to do job workflow."

Original comment by widdis@gmail.com on 12 Jan 2010 at 10:36

[GoogleCodeExporter]

Having just finished doing a workflow issue for RL (what's that) I had an idea 
on how
this could be implemented realatively easily and intuitively.  

My idea: use +job/assign to assign a workflow:  in particular, the command 
would take
a list of players (or jgroups), which would be processed left-to-right.  Say, 
for
example, a player application was submitted to the APPS bucket.  It would be 
reviewed
by, in order, a member of theme staff and then a member of rp staff.  You could
assign apps by default (through parentage or hooks) an assignment of "+THEME 
+RP" (or
the appropriate dbrefs).

It would show up on "mine" (altered to read first() of the attribute) for the 
+THEME
staff until they finished it.  The /complete and /approve commands could check 
the
status of ASSIGNED_TO.  If words() > 1, it would alert that they aren't the 
final
step and suggest +job/next, which would move first() to a WAS_ASSIGNED 
attribute, and
changed ASSIGNED_TO to rest() -- in this case, it's now assigned to +RP staff.  
When
+RP approves it, words() is 1, indicating the final step of approval, behavior 
would
be similar to what it is now.    

Moving backwards could be done with the +job/prev command, bumping it back down
(using WAS_ASSIGNED to append to front of the list).  

Editing the assignment could be done with /assignbefore, or /assignafter, or 
some
other similar feature.  (But more likely automatically with hooks.)

Benefits of this system: 
- minimal change from existing code, makes automatic workflow implementation 
possible
within a single job.
- generic behavior which any game could use
- keeps things in appropriate buckets (could have a HOOK_NXT which moves 
buckets if
needed)
- does not rule out other workflow options such as subjobs.  Can be used alone 
or in
conjunction with other methods.

That said, I also like the suggestion in comment 11 about using the ON HOLD 
status in
conjunction with an attribute referencing another job(s).  Have a 
+job/prerequisite
command which assigns a job as a prerequisite (or some shorter synonym).  If 
that
attribute is not empty, the job is automatically ON HOLD.  When those 
prerequisite
job(s) are completed, the software could check for any on-hold jobs with those 
jobs
in their NEXT_JOB attribute.  

Ideally both systems could be employed:  assigned_to as a linear sequence 
approval
system, and on hold/subordinate job as a "any order prerequisite, but I need 
all this
stuff done first" system.

Neither specifies a workflow. Both give game owners more flexibility in creating
workflow and could be built on top of the existing system without too much 
overhead.

(The question of how to display workflows is a separate manner!)

Original comment by widdis@gmail.com on 21 Jan 2010 at 11:16

[GoogleCodeExporter]

Original comment by widdis@gmail.com on 20 Aug 2010 at 6:17

• Changed title: Job Workflow and/or subordinate jobs