Moving this conversation here.
Dan Randow wrote:
> Engaging new group members is a big challenge for Admins. Right
> now they send out invites and have almost no idea of what happens to
> them. The admin want to know whether to start posting as if the new
> member/s are there.
Sure -- so what's the difference between an existing invited member and
a new invited member here? If the member hasn't accepted the invitation,
then they're not going to receive posts, verified addresses or not.
> If it's an existing site member, you don't even see them in the current
> manage members.
Yes, known issue. I have already added existing invited members to the
new page.
> She or he wants to know whether or when to phone or
> email people to help them.
What are those decisions based on? That's what I'm most curious about.
What is the information that will enable them to decide? Bear in mind
that as we don't know *why* a user has no verified email addresses, we
can't automatically say, based on that, that they're a brand-new user.
Hi Alice,
Thanks for working on this!
The types of invited users that I can think of are these.
1 invited new user
2 invited site member with verified address
When a new user accepts an invitation, their address is automatically
verified, so you can not have a new user with no verified address.
If the admin invites a new user to join two groups, when they accept the
first invitation, their status in the second group changes from 1 to 2.
The system should not allow the administrator to invite a site member,
if they do not have a verified address, as they would not receive an
invitation email.
However, in theory, the admin could use invite a user with an existing
account, but no verified email address, using one of their broken email
addresses.
I agree with your earlier suggestion that both of the groups of invited
members can be labelled "Invited Member".
Perhaps there is a difference tho. With a new user, the group admin
should see the email address that they sent the invite to, as they may
recognise it as broken. If the invitee was picked from a list of
site-members, their email address should be hidden.
We should keep in mind that an existing user could be a member of a
different site, where the inviter has no view permission. It may be a
breach of privacy to even show that the user has an existing account.
The inviter should be able to remind the invitee about the invitation,
and have some idea of how the system will do the reminding.
The status of people who have been invited to join a group, but have not
accepted, is complicated. In this message I hope to clarify what is going on
with invitations, verification, and what the administrators' tasks are. I will
take a system-centric view of the tasks, to make the code easier to follow.
From the system side of things, there are three issues that need to be
addressed: ensuring email addresses are correct, associating the address with a
person, and ensuring that the person wants to receive email from a group.
The main issue, which Dan touched on, is that a new email address could be
wrong. With GroupServer it is a big thing if an address is wrong, because then
it is hard to access your profile. GroupServer profiles can contain quite a bit
of data and can be associated with multiple email addresses, so they are more
important than a simple address-and-name profile that some mailing-list
software provides. In addition, Richard's bounce-detection code ensures that
most email addresses are working, as it marks addresses that continually bounce
as unverified.
The second issue is ensuring all profiles have at least one working address,
and ensuring that address is only associated with one profile. With GroupSever
profiles can have multiple addresses, so this step is also more complicated
than with many systems.
Finally, only people that want to receive email from a group should receive
email from a group. This is both a good idea, and the law in many places, as it
prevents GroupServer being used for spamming. (For this discussion, I will
consider any unwanted email as spam.)
The verification step during sign up — when the new group member is stopped
until the email address is verified — looks after all the above issues, and is
a lot easier to understand than invitations.
1. The address could be wrong, which is why the person can correct
it during the verification step.
2. It ensures that the profile has one working address by
preventing the new group member from continuing until they have
responded to the verification email.
3. When the address is verified it also marks the email address as
active, so the person can receive email from the group he or she
is signing up for.
With these things in mind, lets look at invitations: inviting existing users,
inviting new users, and sending an invitation to a new user who already has an
invitation.
When a person with an existing profile, and a working email, address accepts an
invitation he or she is only opting-in to receive email from a group, as the
other two issues have been dealt with. A person with an existing profile can be
invited using all three new-member interfaces:
* Add new group member,
* Create members in bulk (by CSV), and
* Invite site member.
A person who has not acted on an invitation *probably* has just not around to
it. This is why we allow invitations to be resent, as a reminder. I hypothesise
that if a person with an existing profile does not want to accept an invitation
then he or she is more likely to reject the invitation than do nothing. I
cannot recall any reports of this part of the system causing many problems.
(There are still improvements to be made, but they are not pressing.)
An administrator can create a new profile for a new group member. When this
happens an invitation is sent out, just like with existing users. However, the
new member may not respond to the invitation for three reasons that I can think
of.
* The new group member may not have forgotten to respond, so we
allow the invitation to be resent as a reminder.
* The new email address could be wrong. The administrator should be
able to fix it and resend the invitation.
* Finally, the person who receives the invitation may not want to
join the group. In this case I suspect that the person is likely
to do *nothing*, rather than reject the invite. Unfortunately
doing nothing looks a lot like an address that does not work. In
this case the administrator may want to contact the person and
“warm them up” to the group some more.
Inviting someone who already has an invitation, but has no verified email
address, is not well handled by GroupServer. It is not a major problem (despite
Dan hitting it with <http://dataversity.org.nz/>) and it is quite complex. I
suggest we should do nothing for now.
Is everything clear as mud?
One additional scenario is a now unverified user due to bouncing e-mail not
getting manual verification requests because the admin can't tell that person
has a bouncing address.
Having a "Bouncing" list and an "Invited" separate from the main list and
publicly stated membership numbers would be ideal. A select all and either
reset to non-bouncing (yahoogroups does this) or remove from group would be
handy.
Also, another scenario that happens is that at some in-person event someone
will say, I used to get the forum and they ask for help to get back on. It is
likely that their e-mail address changed. Every one of our groups has a handful
of repeat names on the member lists. Having a way for a group admin to add an
e-mail, merge accts (site admin only), or generate an invite to a new address
telling someone how to login with their previous e-mail to easily update with
their new address would be handy.
On a related Manage Members note, the biggest time consumer is getting to the
member listing.
For group/site admins I'd like to recommend:
1. A manage icon that would appear next to every display name
2. A simple search box in the main admin menu page when you can type in either
an e-mail address, full or partial display name, a first name, or last name or
userID to then call up that person.
The most frequent task I'd add for group admins is:
1. Set E-mail Delivery Options - We would help our users get to digest everyday
... if we have to manually reply to someone who can't figure out our self-help
instructions, we might as well just do it for them
The most useful option I'd add for site admins is:
1. Site-wide freeze on that account - don't let the addresses on the account
post anywhere, prevent user login, and optionally remove from all groups or
suspend e-mail delivery. We would use this for spammers or those
extra-ordinarily suspended.
Great to see movement on this area ... definitely an aspect that determines
whether people will host groups using this tool.
Steven Clift
On Tue, 2009-07-28 at 01:12 +1200, <email obscured> wrote:
> 1. A manage icon that would appear next to every display name
>
> 2. A simple search box in the main admin menu page when you can type in
either an e-mail address, full or partial display name, a first name, or last
name or userID to then call up that person.
Agreed, I think both of those would be very useful. I'm pretty sure we
have something similar to 2 already implemented for a specific customer
use case .
I wonder if we should have some kind of in-context management to prevent
page switching for simple admin tasks.
> The most frequent task I'd add for group admins is:
>
> 1. Set E-mail Delivery Options - We would help our users get to digest
everyday ... if we have to manually reply to someone who can't figure out our
self-help instructions, we might as well just do it for them
>
> The most useful option I'd add for site admins is:
>
> 1. Site-wide freeze on that account - don't let the addresses on the account
post
> anywhere, prevent user login, and optionally remove from all groups or
suspend e-mail
> delivery. We would use this for spammers or those extra-ordinarily suspended.
That would be useful I agree, particularly in the larger sites.
> Great to see movement on this area ... definitely an aspect that determines
whether people will host groups using this tool.
Agreed. Thanks for the input Steve.
Thanks for your comments, Steve.
One client of ours has the ability to search the members of their sites by
name, email address and some identifiers. We are slowly learning what does and
does not work for them as they use the system. For example, the search box is
actually at the top of the profile page, rather than on a seperate page,
because it makes it easier to go from one account to another. Unfortunately,
the system is currently tailored to the client's specific needs and we had not
had the resources to make it work for a generic GroupServer installation.
However, the ZMI-side scripts that ship with GroupServer can be used to search
for someone by name, user-identifier and email address.
Currently administrators can change email address and profile information of
the site-members. They need to have the "Manage properties" permission in the
contacts folder. With this permission the links to change a member's profile,
email address and image will appear in the context-menu on the member's profile
page. The only down side is that all the pages are written from a normal
member's point of view, rather than from the admin's view — so they refer to
“your email address” for example.
The problem with members who do not have *any* working address is a known one
<http://groupserver.org/r/topic/6Y14i0ZsRPNAwteyggYDwH>. The security controls
around this are not trivial, and the system will take some time to create and
test.
Alice is making excellent progress with her rewrite of the Manage Members page.
One of the many things that she is improving is the display of the status of
the group members. After the rewrite I hope that it will be easier to find the
group members that do not have working email addresses, and to send them
address-verification email messages.
The frequency of different administrator tasks seems to differ wildly from
group to group. Small groups seem to need less administrator intervention than
large groups. Regardless, changing the email settings of a group member would
be quite useful for many people.
I concur with you, Steve, and Richard that large public sites would benefit
from being able to suspend accounts.
Hi Alice,
What should happen when an invited member of a group is withdrawn? Take the
case shown in the screen-shot below. The user “Test Admin Join 80”¹ has been
invited to join the group “Table Team 4”.² Currently the Manage Members page
* Shows the member,
* Shows that the member is invited, and
* Allows the member to be removed.
I suppose if an administrator withdraws an invitation the system should be mark
the invitation as withdrawn. I am wondering how to do this. To keep a good
record of what happened I could add a couple of columns to the
"user_group_member_invitation" table to note when an invitation was withdrawn
and who withdrew the invitation. I would need to tweak the queries
appropriately, but that is no biggie.
On a UI level, I can think of three changes: a notification is needed, a new
error page is needed, and I can see a tweak to the Manage Members UI.
First, the person who was invited should get YAN³ saying that the invitation
has been withdrawn. What the notification should say is a good question, and
not one I am ready to answer. I suppose the message could be editable, but how
to do that with the existing Manage Members UI would require way too much
thought and effort this late in the Spaghettieis development process.
(Especially as we are talking about a rare case.)
In addition to the notification, the "rsvp" redirector should send the member
to a “Invitation Withdrawn” page if the invitation link is followed. This is
simple enough if the invitation is marked as withdrawn, rather than deleted.
Finally, rather than saying “☐ Remove Test Admin Join 80 from the group” could
the Manage Members say the following for invited members?
☐ Withdraw the invitation sent to Test Admin Join 80
That would more accurately say what will happen. I *presume* that the code for
removing invited members is quite different anyway ☺
Would the above changes work for you, Alice? I am happy to work on the
invitation table, the error page, and the related queries. Could you alter the
Manage Members page? I am happy to alter it if you are busy with other stuff.
*Footnotes*
1. Yes, I have been conducting a few tests, hence
“Test Admin Join 80”.
2. I am sorry for the cognitive dissonance caused to
Alice, Dan and Richard by showing a group for one
client in the skin of another.
3. Yet Another Notification.
The
following file was added to this topic:
Ah. Hmmm. Yes.
Back in the mists of time, I think having the "Remove Member" option available
for Invited Members was based on the following case:
"the person who receives the invitation may not
want to join the group. In this case I suspect
that the person is likely to do *nothing*, rather
than reject the invite."¹
For that situation, I didn't consider notifying the member would be a
necessity, as we are presuming that this is what they want to happen anyway.
> I *presume* that the code for removing invited
> members is quite different anyway
Yeah... no. Again, it was just a matter of getting them off the membership
list.
However, you are of course right, and the system should record what has
happened, and notify the invited member. (At the very least, a change from the
regular "You have been removed from the group" would probably be a good idea.)
Thank you for catching it, and for offering to work on the invitation side of
things. I will happily work on the MM side, changing the check box label and
the code that is called.
¹ http://groupserver.org/r/post/3LR6GaS2ixwOHXB3Kdbgc0
Thanks Alice!
I agree that an invited member should be silently removed from a group.
Both you and former-me make a good point: more email is a bad thing to
send someone who does not want to be in a group. With you continuing
your sterling work with the Manage Members page, I will sort out the
database and invitation side of things ☺
Thanks for looking at withdrawing an invitation, Michael. I am not that
sure it is likely to be rare. If an admin invites people, and the
invitees do not respond to the invitation, they may wish to remove the
invitees, to make the members list more tidy.
I am happy with the wording "remove [the member] from [the group]", for
an invited member.
On another note, and with an apology for raising this somewhat late in
the piece, why do we use "Elect to have no Participation Coach"?, rather
than something a little less formal like say "Choose to have no
Participation Coach"?
On 07/29/2010 04:36 AM, Dan Randow wrote:
> I am happy with the wording "remove [the member] from [the group]", for
> an invited member.
The problem with that is that an invited user isn't actually a full
member of the group until they accept the invitation. I've added the
handling for withdrawing an invitation, and used the "Withdraw the
invitation..." wording.
> On another note, and with an apology for raising this somewhat late in
> the piece, why do we use "Elect to have no Participation Coach"?, rather
> than something a little less formal like say "Choose to have no
> Participation Coach"?
I was never very happy with the labelling there. I've since changed it
so that the radio button label is H3 size, thereby allowing me to do
away with the actual H3, and changed the label to "Have no Participation
Coach." The label wording is a small change, so further suggestions are
welcome if they come in quick.
Now that we have rebuilt the Manage Members page, we are in a strong
position to look at the functionality of that page.
There are still various known problems with Manage Members, most of
which are to do with helping people to join groups.
I have listed the changes that are required to the Manage Members page
on <https://projects.iopen.net/groupserver/ticket/253>.
The two main changes are:
1 Re-sending invitations and verification requests.
2 Viewing the history of changes to an email address.
I request your input on this.
Currently, the review of manage members is scheduled for Lemon Ice,
which means it should be completed by early December. We may review that.
Resending an invitation should be tractable. For resending one invitation we
can link from Manage Members to a Resend Invitation a page. The page would
allow the administrator to write another invitation message, and send it to the
invited member. This will solve the most common issue, in most groups, helping
the most people, most of the time.
There is still a question about what to do with the mass-invites. However, in
this case re-processing the same CSV file will resend all the invitations. It
is a hidden feature, but it will work.
