It's a good sign when the bug reports get smaller and smaller. :) :)
Because of the fact that I am facing the end of semester pressures,
this report is probably not thorough everywhere. If you need any
specific examples, I can provide them on a case by case basis.
1>>> /what when there are no active discussions.
/what
(there are no active discussions)
I would prefer to see how many inactive discussions:
(there are 5 inactive discussions)
2>>> consulting help
Needs an overhaul. Also, I think that "/help consult_cmds" and
"/help consult" are more inherently obvious than "/help cons_cmds"
3>>> /when contains two "Co" events.
C A H R B I I U P P C P J R R P G C
o t e n l n g n u r r e o t v a m o
- - - - - - - - - - - - - - - - - -
defaults to... + + + + + + + + + + + + + + + + + +
I know that the first 'Co' is Connect and the last 'Co' is Consult, but
it can be confusing to some. How about 'Cs' for Consult ?
4>>> /timestamp public
"/time public discussion off" doesnt turn off the timestamping if
the global "/time public on" is set.
5>>> miscellaneous consulting stuff
a) /observe, /unobserve
1) I would like to see notifies when someone decides to observe or
unobserve a client.
*** (22:10) bp is no longer observing Client #1 ***
*** (22:12) bp is now observing Client #1 ***
2) if client is unclaimed.
/unobserve #1
(you were not observing Client #1)
Perhaps the message should state the client is not claimed yet.
3) unclaiming & re-claiming a Client.
the unobserve setting gets reset to observe when the client is
re-claimed. If isolation will stay permanent between unclaiming
& reclaiming, then I feel that unobserving should too. If
I should be the person that reclaim's this client, then obviously,
it should reset to 'observe' for me.
b) transfer notifications.
Currently, if the client is transferred to someone else, the message would
appear as:
*** Client #1 is now being helped by raindog ***
I think I would find it more useful if the notification stated who the client
was being transferred from, as such:
*** bp has transferred Client #1 to raindog ***
or:
*** Client #1 was transferred from bp to raindog ***
c) /signal consult
I can turn the signalling for consult notifications on & off, except
the client entering and leaving is not affected by this setting.
They always beep. I do understand the justification behind making sure
that an entering client is not ignored by consultants if they are
busy elsewhere, but I think that the client leaving should be able to
be turned off, since it isnt as critical.
d) sending to a client that isnt yours or unclaimed.
#1;hi
(Client #1 is being helped by no one)
#1;hi
(Client #1 is being helped by Kenstein)
I think there should also be a "(message not sent)" perhaps..
e) messages from client always beep
As far as I can see, there is no way to turn off the beeps from a client
message. I can have "/signal consult off", and "/signal private off",
but I cant turn the beeps off. I would prefer that the client messages
were grouped into "/signal consult". This is not only useful to the
particular consultant helping the client...for example, I may be in
a late-nite setting where beeps are distracting.. but also to the consultant
who is merely watching. A consultant may start unobserving in order
to turn off the beeps if they cant turn those beeps off manually.
f) timestamping from client messages.
=> (03:49) From Client #1, to bp and watchers:
- hello
There is currently no way to turn off the timestamp in the above messages.
If it was grouped into "/timestamp consult", it would be my method of choice.
6>>> miscellaneous review items
a) synonym for '/review detach'
I think having 'det' as a synonym for 'detach' on /review would
be welcomed by many.
b) consulting: can't review a Client that is long gone.
/review consult user Client_#1
This only works if the Client is actually connected.
But it would be highly useful if one could review a particular client.
/review consult user Client_#1
(could find no match to "Client #1")
(no valid users in user list)
c) No date boundaries in /review
It's hard to tell which day the messages are from when reviewing
a discussion or buffer that's been around for some time.
d) Extraneous message when permitting someone to a discussion.
# *** (21:14) You are now permitted to consult ***
# *** (21:14) Kenstein is now permitted to discussion consult ***
# *** (21:15) You are now permitted to consult ***
# *** (21:15) raindog is now permitted to discussion consult ***
e) /review detach
Some people are getting the
### Peak userload ..... ###
messages in their /review detach buffer. They may be entering lily
for the first time and they are _not_ admins.
/review detach
(Beginning review: Thu Dec 1 21:13:36 1994 EST)
# *** (21:13) Kenstein has entered lilyCore ***
# ### Peak userload 3 at Thu Dec 1 21:13:36 1994 EST ###
(End of review)
f) Space needed before trailing ***'s in moderator notify.
# *** (11:50) You have been made a moderator of discussion admin***
# *** (11:50) You have been made a moderator of discussion consult***
g) Some people are getting Range errors.
/review consult session
(Beginning review of consult: Thu Dec 1 21:14:12 1994 EST)
# *** (21:14) raindog is now permitted to discussion consult ***
# *** (21:14) Kenstein is now permitted to discussion consult ***
# *** (21:14) Kenstein is now a member of consult ***
# *** (21:24) Client #1 has entered consulting with the problem
# "HELP!" ***
# *** (21:24) raindog is now a member of consult ***
# *** Client #1 is now being helped by bp ***
#6:reviewMessage (this == #124), line 18: Range error
... called from #15:showByTime (this == #108), line 26
... called from #2:/review, line 71
... called from #6:do_command (this == #124), line 9
... called from #0:do_command, line 5
(End of traceback)
h) /review discussion detach
/review consult detach
(Beginning review of consult: Fri Nov 18 11:40:04 1994 EST)
# *** (11:40) System Manager is now a member of consult ***
# *** (11:50) bp is now permitted to discussion consult ***
# *** (11:50) bp is now a moderator of consult ***
# *** (11:53) bp is now a member of consult ***
(End of review of consult)
This was done by someone who just entered lily for the first time and was
never detached before. Obviously, the discussion existed before they
entered. It looks to be exactly the same as "/review consult" without the
"detach".
i) Some people still get traceback errors sporadically. Easily
reproducable once it happens to a particular discussion. It seems
to only occur when the "time" parameter is put on /review. A
/review discussion by itself doesnt seem to ever have any problems.
I am completely uncertain why this occurs on some discussions and why
not on others.
/review icu session
(Beginning review of ICU: Thu Dec 1 22:40:31 1994 EST)
# *** (22:40) Discussion ICU, "La la la la la la la la la" has been created by raindog ***
# *** (22:40) bp is now a member of ICU ***
# *** (22:50) Crazy Cub is now a member of ICU ***
#11:splitmsg, line 16: Type mismatch
... called from #6:reviewEmote (this == #124), line 5
... called from #15:showByTime (this == #138), line 24
... called from #2:/review, line 71
... called from #6:do_command (this == #124), line 9
... called from #0:do_command, line 5
(End of traceback)
/review newuser session
(Beginning review of newuser: Wed Dec 7 02:11:25 1994 EST)
# *** (02:11) raindog is no longer a member of newuser ***
#6:reviewMessage (this == #112), line 18: Range error
... called from #15:showByTime (this == #104), line 26
... called from #2:/review, line 71
... called from #6:do_command (this == #112), line 9
... called from #0:do_command, line 5
(End of traceback)
/review consult detach
(Beginning review of consult: Thu Dec 1 22:13:16 1994 EST)
#6:reviewMessage (this == #121), line 18: Range error
... called from #15:showByTime (this == #108), line 26
... called from #2:/review, line 71
... called from #6:do_command (this == #121), line 9
... called from #0:do_command, line 5
(End of traceback)
But, the one time it wasn't easily reproducable was that it
happened to Kenstein & raindog, but not to me.
The only differences were: I was there before them, I am a moderator
of the discussion, and I'm an admin.
They got:
/review consult old
(Beginning review of consult: Fri Nov 18 11:40:04 1994 EST)
# *** (11:40) System Manager is now a member of consult ***
# *** (11:50) bp is now permitted to discussion consult ***
# *** (11:50) bp is now a moderator of consult ***
# *** (11:53) bp is now a member of consult ***
# *** (21:14) raindog is now permitted to discussion consult ***
# *** (21:14) Kenstein is now permitted to discussion consult ***
# *** (21:14) Kenstein is now a member of consult ***
# *** (21:24) Client #1 has entered consulting with the problem
# "HELP" ***
# *** (21:24) raindog is now a member of consult ***
# *** Client #1 is now being helped by bp ***
#6:reviewMessage (this == #121), line 18: Range error
... called from #15:showByTime (this == #108), line 26
... called from #2:/review, line 71
... called from #6:do_command (this == #121), line 9
... called from #0:do_command, line 5
(End of traceback)
j) when someone renames, their messages dont carry the old name.
Let's say I send some messages to a discussion as "bp", then I
rename to "atul" and send some messages to a discussion,
then I rename back to "bp". When I review, the notifications say "bp",
but the messages I sent as "atul" say they were sent as "bp". If I reviewed
when I was "atul", the messages sent by "bp" show up as if they were sent
by "atul". As I said, notifications seem to be unaffected by this behaviour.
7>>> moderated discussions
a) '/ask discussion question' puts the discussion name in the question.
/allow
Question queue for discussion arena
----------------------------------------
raindog asks, "arena Why ask "why ask why"?"
bp asks, "arena I have a question."
(type "/allow arena username" to select a question for answering)
b) creator of discussion needs to be appointed as a speaker.
I would think that the discussion creator would be a speaker by default.
c) can't /allow someone to speak if they haven't asked a question.
/allow arena cub
(Crazy Cub does not have a pending question)
I would think that the question asking procedure is good to filter out
who should speak, but not be the end-all if someone can speak. I should
be able to give the floor to anyone in the discussion.
8>>> general /help improvements
a) '/help moderation' should be listed in default '/help'
b) '/help what' should list the new moderated discussion flag.
c) '/help rules' should be removed since it is applicable to our
RPI production server only.
d) anyone else reading want to improve the rest of /help ? :)
9>>> idling away/idled to death
a) idling away resets your idle time to 0.
b) idling to death is plagued with problems.
10>>> $banner
a) I see no way of nulling the banner unless i'm a programmer. The best
I can do is make it one line.
b) The only way to set the banner is with "$banner"
How about making "banner" a special reserved discussion name when a file is
%export'd with lclient. This way I could do:
%export file banner
and it would work for admins, but not for non-admins.
11>>> What I should not leave out.
Lots of neat stuff has been put in that DOES WORK. Thank you.
-- Atul Jagga <bp@eclipse.its.rpi.edu> <bp@acm.rpi.edu> <bp@mts.rpi.edu>