Closed GoogleCodeExporter closed 9 years ago
What if we changed the behaviour of +job/tag somewhat? +job/tag currently
allows you
to tag multiple people and when they are tagged in a job, that job shows up in
their
+jobs lists.
So let's say we dropped the +job/tag feature of having the tag removed when a
comment
is added as the first step. Second modifed the jobs list or added a marked to
clearly
denote that a job was tagged (as right now you only know this by looking).
Third,
show the tag list in the job header. Fourth, add a command for configuring tag
groups. IE, a game could create a tag group called code with the four coders
listed.
Fifth, allow jobs to be assigned to a tag group.
I think this would build on the code already in place and, if done, could avoid
the
whole need to create a PC.
Original comment by grey...@gmail.com
on 22 Oct 2007 at 11:06
I had forgotten tags existed; that would all work, I think.
However, the "command for configuring tag groups" would need to be settable as
an
function. I don't want to have to manage +job lists independently of other
system
lists, I'd rather be able to call isstaff(%#,execstaff) or some such then
constantly
add/remove people from these lists.
(I have no idea what you mean by 'having the tag removed when a comment is
added as
the first step' -- huh?)
#5 is basically the most essential. Using the tag machinery seems more
complicated
then just modifying the joblist and /assign command; but I can see some use. If
only
to allow groups to contain players.
Original comment by apt.shan...@gmail.com
on 22 Oct 2007 at 11:20
If I tag a job for someone, the tag is removed when they do a +job/add.
Original comment by grey...@gmail.com
on 22 Oct 2007 at 11:31
Original comment by grey...@gmail.com
on 29 Oct 2007 at 4:24
I've been musing over potential implementations for this. I see two key
requests:
groups for "Assigned-to", and more clearly designating tagged jobs. Regarding
the
five points in comment 1:
1. I'm not in favor of removing an expected behavior of tagging. Seems that
tagging
should be a temporary "read this" thing, whereas the assigned-to would ensure
that a
job automatically shows up on appropriate groups' +jobs/mine somewhat
permanently.
2. Currently we have a * denoting new activity. We could have a + symbol in its
place to represent tagged, and update the legend in the footer appropriately.
3. Easy to add tagged somewhere in job header.
4 & 5. Tags seem similar to buckets. In theory the same set of commands for
+buckets
could also be used for +assignlists. Given the need to associate each
assignlist
with multiple things (description, function of players assigned, additional
players
in group) it seems an object (similar to the bucket objects) would be
appropriate.
If so, the question arises where to put these objects. %va holds jobs and %vc
holds
buckets. Currently %vb is empty...
So, idea would be to store an object inside %vb whose name is the assignment
group
name, uses a speechlock for regular members of the group, and who can have
additional
members assigned with an /access command.
Thoughts?
Original comment by widdis@gmail.com
on 22 Dec 2009 at 3:39
If we're going to go with the assignlists (which I think is a fine idea), let's
also
make sure we can +job/assign and +job/tag to them. Additionally, assigning to
an
assignlist should require some sort of indicator, like +job/assign 123=+staff,
and
+job/tag 123=+apps loki grey. The + would denote 'this is distinctly an
assignlist',
and should not only make finding the list easier, but remove the potential for
namespace conflict with player names.
I DON'T think we need to add a + for tags in the jobs list, but adding the list
of
tags to the job header is a good idea.
I also am not in favor of removing the expected behaviour of tagging.
Original comment by kkragenb...@gmail.com
on 22 Dec 2009 at 2:05
I like the + indicator on lists. Matches @malias concept and makes matching
names vs.
lists easy. Will add to /assign and /tag (and might as well /source and /query
for
completeness?)
Adding to jobs header is trivial.
But how else (if not + for *) could we denote in the jobs list that a job has
been
tagged for you, essentially a "read this and reply" alert like those little red
flags
in MS Outlook?
Original comment by widdis@gmail.com
on 22 Dec 2009 at 4:20
I don't think we need a way to note it in the jobs list. Tagged jobs already
show up
in +jobs/mine. That's where most people should be looking for things
assigned/tagged
to them.
Original comment by kkragenb...@gmail.com
on 22 Dec 2009 at 10:31
Working on a possible implementation of this (called jgroups for the moment),
very
similar to the existing bucket code. What it does:
- creates an object (similar to bucket) stored in %vb with name matching list,
desc,
and an ISMEMBER attribute: a boolean function which defaults to
t(member(v(memberlist),%0)
- deleting list destroys said object
- +jgroup/member *=* toggles memberhip of players in memberlist. If ISMEMBER is
replaced by another function call (e.g., isstaff(%#,execstaff) as in comment 2)
then
this would be meaningless.
- +jgroups lists the contents of %vb by name and desc.
Advantages:
- boolean ISMEMBER is useful for determining whether to display in +jobs/mine
- presence of an object makes it easy to check names/lists of groups/etc.
- can copy bucket code and have similar behavior :)
Disadvantages:
- If user overrides the ISMEMBER behavior it'd be annoying to detect in order to
display appropriate message for adding new members. Would like a cleaner way of
detecting that.
- There are a few times it will be useful/required to get a list of all members
of a
jgroup. (1) Unlike the bucket/info, a list of only connected players is
probably not
sufficient. (2) For +job/tag with a list it needs to tag them individually so
they
can be removed individually. (3) There's the potential of having to @mail them.
This
is difficult to do without a search() (which differs between servers). I don't
see
anyway around this without directly accessing memberlist (and not permitting the
"override" from comment 2).
Thoughts? Other ideas?
Original comment by widdis@gmail.com
on 28 Dec 2009 at 5:17
First draft at this uploaded as r202. Thoughts in comment 9 still apply.
Decision
point needed on +job/tag behavior:
Should +job/tag add the dbref of the jgroup to the tag list? This is easily
done
when tagging, but requires more complex code to remove the jgroup when any of
the
members read it.
Or, should +job/tag add dbrefs of individuals to the tag list (shortcut to
+job/tag
<each member's name>). This avoids having to change other tag code. But
requires
getting a list of all members of the jgroup... easily done if it's the
memberlist,
but harder to do (search all players and filter by ismember) if using the
general
version mentioned in comment 9.
Original comment by widdis@gmail.com
on 11 Jan 2010 at 6:53
OK... as of r207, I went ahead and implemented the second option of comment 10:
when
+job/tag or +job/untag is used, the jgroup (+apps, etc.) is simply expanded
into its
list of members.
So say +apps contains members Alice, Bob, and Carol. "+job/tag +apps Bob Dave"
will
do the same as "+job/tag Alice Bob Carol Bob Dave" (the duplicates will be
removed by
setunion).
With this implementation of tagging, all the other code for tags is already up
to
date, including headers, etc.
I think this implementation is mostly complete. Review/comments welcome.
Original comment by widdis@gmail.com
on 12 Jan 2010 at 7:28
Reviewing comments, the following is still todo:
1. add something in the header listing who's tagged on the job. Perhaps a
special
"This is tagged for you" if %# is tagged.
2. do similar expansion of +jgroup names for /source and /query that was done
for
/tag and /untag. Might not be used much, but makes sense that anytime a list of
names is acceptable a jgroup should also be.
3. Potentially add a +jgroup/info command that lists all members of the jgroup.
4. Scour the code for everywhere ASSIGNED_TO is used and make sure it can
handle the
list.
Original comment by widdis@gmail.com
on 12 Jan 2010 at 7:44
I like the idea of making it simply an expansion. Also, using this for /query
and
/source is actually an EXCELLENT idea; I can think of dozens of uses for that
in my
regular usage of the jobs code.
+jgroup/info = bonus good idea. Please do that one.
Original comment by kkragenb...@gmail.com
on 12 Jan 2010 at 8:23
[deleted comment]
I am not in favor of this type of implementation - it is what buckets are
supposed
to be for - but I can see the potential for usefulness across a wide range of
systems. There's enough potential to warrant its inclusion so I'm not going
to reject the idea or try to argue anyone out of the change. That is pretty much
why I've been quiet on this issue. I'm against it, but I'll bite my NO
ASSUMPTIONS
dev philosophy bullet and accept the change with pride. :)
Besides, one game I work at wanted something similar, so I've seen the behavior
in the wild. In their implementation, they use an object named 'ALL' or 'STORY',
but there's no list associated with it. It's the staffer's responsibility to
look
at what they see tagged for these objs (it only works in assign, IIRC). This
has the
drawback of limiting the 'group' system, but has the benefit of reducing the
the amount of complicated interactions with other commands, like the coding
ballet
you are presently performing. (It's a Good Ballet, don't get me wrong.)
That said, the implementation and ideas that widdis has come up with are
excellent. +jgroups as a name is a good name for it, I can't think of anything
else to call it without adding excessive carpal tunel.
C12.1: This is a good idea. It should only display if tagging is present. A
'tagging is present' check is already on the footer. If C12.1 is implemented,
the footer stuff should be removed.
C12.2: I'm not sure if Kevin thought you were talking about turning this into
a plugin. If so, then I vote no; it has extremely useful potential in the
default
rollout. If not, I too like the idea of /source and /query. Is there any where
else
that it could be implemented?
C12.3: Very important for keeping track of the lists.
C12.4: Even more important. :)
My own points:
1. Needs to be reconciled with the BLETTER behavior and the <code>_ACCESS stuff,
both of which are in the bletter.txt document. I can do the fixes if need be,
neither are difficult.
2. Nope, can't think of anything else. Looks good, so far.
Original comment by Fleety...@gmail.com
on 12 Jan 2010 at 7:01
(As a side note, the term 'buckets' comes from the AS400 ticketing system in
use by
MCI/Worldcom during the late 90's/early 00's, upon which Jobs is inspired. A
bucket
was a department's responsibility - everyone in that dept was supposed to read
it if
it was open in their bucket, which is sort of why I'm against the ideas of
'groups'
in general - we technically already have them, and incorrect usage is what is
necessitating this change. However, it still has potential use, even if people
are
Doing It Wrong.) ;)
Original comment by Fleety...@gmail.com
on 12 Jan 2010 at 7:35
I was initially kinda with Fleety419 on the idea as applied to assign (vs.
buckets).
When responsibility is shared, nobody's responsible. :) But hey, it was requested
and it's not too hard to implement.
But there's a subtle difference between buckets I'm responsible for and buckets
I'd
like to look at jut for info, and this change makes that distinction possible.
For
example, say on my game I'm responsible for the "BUILD" and "CODE" buckets and
interested in a hodgepodge of other buckets, but not "responsible". How do I
get a
list of jobs that I am really, no-kidding, on the hook for tracking?
Currently, I'd have to type three commands: +jobs/list code, +jobs/list build,
and
+jobs/mine.
With +jobs/select my task is shorter: +jobs/select bucket=code | bucket=build
| mine
With jgroups, if I'm a member of +coders and +builders, and &ASSIGNED_TO is set
on
those buckets by default (either on bucket which is inherited, or hooked to add
conventionally), then a simple +jobs/mine automatically pulls up the same list
(except those jobs another coder or builder has claimed).
So +jobs with monitored buckets shows my "interest" but +jobs/mine (with the
whole
bucket in "mine" except what's specifically not mine) shows my responsibility.
Separately, I think the "list" concept as employed in /tag and /untag (and soon
others) is very useful addition in that it's simply a "macro" but the remainder
of
jobs behavior remains the same. Things like "all admin read and acknowledge
this" can
be handled with +job/tag +admin or somesuch rather than having to individually
add
admin names.
Original comment by widdis@gmail.com
on 12 Jan 2010 at 9:34
Ok, r211 implements Comment 12 points 2, 3, and 4.
Need the bletter updates and review of header/footer id of tagging to see if we
want
to keep it or change it.
Original comment by widdis@gmail.com
on 13 Jan 2010 at 1:25
Bletter updates in. Will create new issue for tag header/footer changes as
those are
actually independent of this issue.
Original comment by widdis@gmail.com
on 13 Jan 2010 at 7:59
Original issue reported on code.google.com by
apt.shan...@gmail.com
on 22 Oct 2007 at 10:22