Job tags versus reading

[GoogleCodeExporter]

As of 6.2, reading a job you're tagged on removes the tag.  This seems to be in 
accordance with documentation, but it creates workflow problems:

Very often we get tagged on jobs, take a look, realize it's more complex than 
we can solve in the next 5 minutes, and so don't respond.  Unfortunately, the 
tag is already removed, so we have to either retag, remember to revisit (haha 
yeah right), or drop it on the floor (which is what most people do).

I propose that tags should stick until removed, perhaps with a specific 
+job/ack nnn or +job/acktag nnn.

Reading a job should trigger any necessary auditing but elave the tag. Tag 
removal should require specific action.  Removing tags on writing to a job 
(e.g. with +job/mail or +job/add) seems reasonable.

> Is this a new command or change to an existing one?

Yes, both; a proposal for tag acknowledgement command and change to +job * to 
not eat tags.

> If a new command, write suggested syntax and describe what the command does:

+job/acktag * - acknowledge that you have read a job and have no input, so the 
tag should be removed.

> Have you coded this?  If so, please attach a patch.

This should probably be discussed and semantics agreed upon prior to coding.

Original issue reported on code.google.com by lasht...@gmail.com on 7 Feb 2011 at 10:11

[GoogleCodeExporter]

Even if we don't completely change the way +job * works, it might be a good 
idea to at least make this per-user configurable.  Completely changing what 
people are used to like this without any sort of backwards compatibility at all 
was a painful thing for most of my users.  It'd be nice to put a middle ground 
back in.

Original comment by kkragenb...@gmail.com on 7 Feb 2011 at 10:14

[GoogleCodeExporter]

Re: comment 1: we have already altered tag behavior (for 6.3) with Issue 128, 
although that was primarily in the case of separating access from tagging.  
However, this is a good time to really nail down what we want for tagging.

Previously tagging looks intended as an access issue, with the "read & remove" 
behavior an unusual add-on.  Without this automatic tag removal, I hardly see 
the need for the /tag command at all.

As of the current code awaiting 6.3, all tagging does is add the job to your 
/mine list.  It doesn't otherwise change your access to the job. 

Once you read a job and realize you want to handle it later, you currently have 
two options.  You can /claim (or /assign=yourname) the job (and it will thus 
appear on your /mine list, even if you don't deal with it for a while), or you 
can /tag it to yourself again (similar to marking it unread).

In my opinion, auto-removal of the tag is preferred, as the cases where you 
want to be re-tagged (without otherwise claiming or assigning the job) will be 
much more rare than the cases where you want to acknowledge a tag.

That said, I'm willing to look at a config option (perhaps player-specific) 
where for an individual player it doesn't remove your tag on reading if you 
have a particular attribute set.  That seems an easy compromise.

Original comment by widdis@gmail.com on 7 Feb 2011 at 10:25

[GoogleCodeExporter]

+job/tag is an action; it puts the red star back-- for everyone ELSE-- even 
though all you've done is half-looked at the job and decided to look at it 
again later.  This makes the red activity star a lot less useful.

Perhaps our workflow should be changed;  currently we tag people onto a job to 
get them to look at it and add comments, even though the job is "owned" by 
someone else.  This could be handled instead by /assigning the job around, but 
it is very slow and tedious to do this if many people are needed to sign off on 
a job and the ordering doesn't matter.

Original comment by lasht...@gmail.com on 7 Feb 2011 at 10:43

[GoogleCodeExporter]

Yeah, I don't think a workflow change is a good idea.  The best compromise is 
the per-player setting, IMO.  Let's just go with that, and call it goodenuf. 
That will allow for configurability without sacrificing usability for any of 
the use cases we deal with.

Original comment by kkragenb...@gmail.com on 7 Feb 2011 at 10:49

[GoogleCodeExporter]

Re: comment 3:  +job/tag isn't associated with the red star. 

Also you can tag a job for yourself and it only adds YOU to the list of 
existing tagged people.

Can you be very specific in how you currently use tagging, and why other 
solutions than tagging don't work?

Original comment by widdis@gmail.com on 7 Feb 2011 at 11:02

[GoogleCodeExporter]

Team Leader (think Faction-specific Staffer) owns a job. they are working on a 
job. But they want input from the rest of their team on the job.  So they tag 
everyone on their team.  But it turns out that the job requires a lot of 
research, so Faction Admin A reads then job, then is untagged. If they tag 
themselves again to remind themselves it will show as new activity to everyone 
else. If they just leave it, they may forget to look at it later when they have 
more time.

Original comment by kkragenb...@gmail.com on 7 Feb 2011 at 11:20

[GoogleCodeExporter]

Oooooooh, I see the problem.  Since tagging a job generates a "hidden" comment 
it ends up showing new for everyone.

+job/tag should *not* trigger the new activity indicator.  That should be 
considered a bug and be fixed. 

Original comment by widdis@gmail.com on 7 Feb 2011 at 11:23

[GoogleCodeExporter]

Except it's new activity. That's NOT a bug.  No more than /assign triggers the 
new activity indicators.  It's a feature, in my opinion.

I really do think the only change needed for this is the per-user customizable 
behaviour on reading jobs that are tagged to you.

Original comment by kkragenb...@gmail.com on 7 Feb 2011 at 11:25

[GoogleCodeExporter]

Done in r392.

Original comment by widdis@gmail.com on 13 Feb 2011 at 12:02

• Changed state: Fixed
• Added labels: Type-Enhancement, Priority-Medium, Usability, Milestone-Release6.3, Plat-All