Posts in GroupServer Development

Manage Members Page From: Dan Randow Date: Jul 29 02:36 UTC Short link

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"?
    

Participation Coach Role From: Michael JasonSmith Date: Jul 28 23:45 UTC Short link

There are many hard and soft roles (to use Steve's term) in a group. I went
through the roles that have code *defined* to support them, and I came up with
the following list of hard roles¹

    * Site administrators,
    * Group administrators²,
    * Moderators,
    * Moderated members,
    * Blocked members,
    * Posting members in announcement groups,
    * Invited members, and
    * Normal members.

However, I can see a use for soft roles, such as a participation coach. A
person may be a local expert on a topic, or have a senior role in an
organisation. An owner is another social role, but an odd one because the owner
may not even be a member of the group, and it may not even be a single person!
I will ignore the owner because it is so odd.

I have a two-fold idea: show roles more widely, and allow social roles to be
defined.

A person's roles should be shown on a post. This will provide more context to
the post. For example a post by me to this group could be headed up

  From:   Michael JasonSmith — Group Administrator

(Not all roles should be shown, but we can discuss that later.)

The second part of my idea is to allow generic social roles to be defined
within the group context. For example, in this group Richard may be given the
role “System Architect” to give some context to his posts — which, lets face
it, should have more gravitas than my ramblings.

I have written a ticket that encompasses both my ideas
<https://projects.iopen.net/groupserver/ticket/437>.

*Footnotes*

1. The list of hard roles is mostly the work of
   Alice, who wrote the Manage Members code that
   I used to compile the list!

2. What we call a “group administrator” is *mostly*
   a matter of skinning.
    

Participation Coach Role From: Dan Randow Date: Jul 28 04:55 UTC Short link

For as long as I can remember, GroupServer has supported a role called
Participation Coach in a group. This is primarily a social role, and has
been technically almost identical to a regular group member. This role
has many names, but I think of it as a "go to" person for the group.

What I can't remember is any particular reason for the role to exist. In
almost all cases, a group has only one group admin, who is by default,
the "go to" person for that group. In groups with multiple admins, they
could all perform the function of the "go to" person.

We have a proposal to remove this role.
   https://projects.iopen.net/groupserver/ticket/411

Currently, the group properties include the "owner" of the group. I
think this remains an important thing to declare, as it tells the group
members and others (in public and priovate groups) who has convened the
group, and therefore has a key interest in its functioning, and the
power to decommission it.

What do you think of this?
    

Dan

--

Dan Randow
Chief Wrangler
OnlineGroups.Net
ph +64-3-377-5377 +64-27-431-4928
Kenton Chmbrs, 190 Hereford St
PO Box 739, Christchurch, 8140
Aotearoa (New Zealand)
http://onlinegroups.net
http://groupserver.org
http://twitter.com/danrandow
skype: vonrandow

Manage Members Page From: Michael JasonSmith Date: Jul 26 22:57 UTC Short link

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 ☺
    

Manage Members Page From: Michael JasonSmith Date: Jul 26 05:41 UTC Short link

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:

manage-members-invite.png (image/png, 69KB)

Inviting New Users to Join a Group From: Michael JasonSmith Date: Jul 13 07:00 UTC Short link

I am about to work on getting the Sundae release of GroupServer out the door
<http://groupserver.org/r/topic/6IwIFaOtTpvenJlPJ6LOW4>. However, once that is
done I will be getting back onto Invitations. Below is the the Testing document
for invitations, in HTML form. I have tried to link it to the tickets that
exist for the problems with invitations.
    

Join and Leave Log From: Steven Clift Date: Jul 09 11:43 UTC Short link

This will be a good change.

We have lots of folks who think the only way to stop the e-mail is to
unsubscribe completely.

You might consider text at top like:

"Please confirm that you seek to leave (unsubscribe) XYZ group. Or select the
delivery option to participate with less email."

I am thinking of the person who posts a few times each year and subs/unsubs
whenever they want to post.

Text might not be needed or a [?] explaining that under these settings they can
still post which is why they might want to remain a member.

Mixed thoughts.
    

Join and Leave Log From: Dan Randow Date: Jul 09 00:52 UTC Short link

Alice,

> The plan is to have an adapter that figures out all the group admins
> for a group. We can use that in combination with a variant of our
> comma_comma_and utility (comma_comma_or?) to display the list of
> admins directly.

Perfect.

> I can't think of a reason why someone
> who was thinking of leaving a group would instead *increase* the
> amount of email they got from the group, so I have left it off.

Doh! Well spotted.

> the more appropriate place is as part of the label for the "Leave"
> option. There, we can at least get rid of the first IF above. And as
> a bonus, the page becomes even shorter.

Excellent. Love it.
    

Dan

Join and Leave Log From: Alice Murphy Date: Jul 08 14:29 UTC Short link

After a good chat with Dan and Michael today, we came up with the
following improvements to the initial mock-up:

   1. Introduce the options with more concise text: "Want less email?"
   2. Reverse the order in which the options are displayed, so that
      they are, from top to bottom, in order of least email to most.
   3. Ensure that "Leave" is the default option, as Michael recommended.

This led me to wonder if there's any point in including "One email per
post" as an option at all. I can't think of a reason why someone who was
thinking of leaving a group would instead *increase* the amount of email
they got from the group, so I have left it off.

We also discussed the rejoining text, and decided that it required
further thought. After more pondering, I've concluded that it is the
timing of the text that was causing the difficulties — it comes after
the user has said they want to leave the group, but before that action
has been taken. In that position, we need to communicate that:

   IF the leave action is taken (a hypothetical situation)
   AND the user later wishes to rejoin (another hypothetical situation)
   THEN certain other actions will need to be taken

It's just too awkward and quickly becomes too wordy. I think that the
more appropriate place is as part of the label for the "Leave" option.
There, we can at least get rid of the first IF above. And as a bonus,
the page becomes even shorter. My suggestions for the three labels are:

   Secret
     Leave {the group} (to rejoin, you must be invited by {the group
    administrator})

   Private
     Leave {the group} (to rejoin, you can apply to {the group
     administrator} at any time)

   Public
     Leave {the group} (you can rejoin at any time)

Latest mock-up attached. Again, suggestions for further refinements welcome.
    

The following file was added to this topic:

leave-page-v2.png (image/png, 19KB)

Join and Leave Log From: Dan Randow Date: Jul 08 08:18 UTC Short link

If we do drop the idea of having one admin as "go to" person, then this:

> *Secret* {The group administrator} must be invite you to rejoin the
> group.

would not float. We'd have to say "the group administrator" and link to
a list.