On Thu, Jun 20, 2019 at 02:15 PM, Andy W wrote:

I believe this is referring to the member's activity log.  If you look in there, there is no reference to being added.

Ah, I see. Yes, it certainly seems like it should be there, too. Sorry for being slow on the uptake.

Bruce

Same with display name. Does not seem fixed. :-(
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Way back, I suggested a "flying lawnmower" analogy. The discussion has ranged so widely, I'm not sure what this is, but I will go back and say that a simple implementation may be useful for some groups. This is what I think has been proposed:

• An owner/moderator option for an entire group.
• Owner/moderator would have access to email addresses, but not members would not.
• Members would have the same options as now: no-email, special only, digest, full email.
• On the web or in reflected emails, the address of the originator would not appear. Instead a "no-reply" dummy address would be inserted. My guess is that this would not be difficult to implement.
• No "Private" button on web replies.
• An official recorded "handle" would not be strictly necessary; members can always put their chosen handle in the body of the message, on the other hand a "Display name" that could be left blank would be okay.

The effect of this implementation would not be a strictly anonymous group since the owner/moderator would know the member's identity, or at least email address, but identities and private access would not be shared among the members. I can see a value for this type of group. The health group example is a good one. However, I have to point out that it is easy to set up a web site, with something like WordPress, that would have these characteristics, so I don't have a crying need for a groups.io implementation. But I have no objection either, especially if it brings in a few premium groups.
Best, Marv (his handle)

I see the thread I replied to is old, lengthy and became argumentative so thought it best to start fresh.
I’ve just spent several days working with others to set up a health-oriented education/discussion/support group only to realize that the email feeds don’t scrub individuals’ email addresses. Otherwise the functionality is exactly what we need.  
If addresses can’t be scrubbed from the email feeds, then a no-email option would work well. Most similar (health) groups are web based only and people often join for short periods of time for information and support then move on - there’s no need for them to have access to everyone else’s address. Many of these users are not sophisticated enough to set up an alternate email or even realize they could be exposed. If two unknowingly related people join the.same medical condition group, they might not want each other to know for personal, work related or legal reasons. Comments were made in the earlier thread that a web only option or scrubbing email addresses would be “exclusionary”.  What is “exclusionary” is that not allowing email privacy excludes people with medical conditions from participating in an educational science and experience based support group on groups.io. 
It can’t be that difficult to provide code to have the system allow  email replies without posting addresses (to take care of those who can’t/won’t read on the web) and to have “reply to sender” or PM’s not showing the recipient’s name - giving the recipient the opportunity to reply directly and reveal their address only if they wish to. 
I totally get those who read a post and want to contact the poster directly for whatever reason. But there are situations when it can be wise to allow it to be the recipient’s choice to respond or not when someone has reached out to them and not have their email end up in the sender’s contact list. (Do you accept every Facebook friend request.)
When unwanted PM is received and is reported, a Moderator/owner can ban the sender. But I have seen someone come in despite moderation and scrape email addresses from digests then use these to mount an ongoing advertising campaign. If this were to occur with a health related group (not to say web-only is immune to break ins) it could be problematic with possible legal implications. 
While I understand that groups.io might not be able to be all things to all people, making these what appear to be fairly easy changes would open groups.io to a additional genre of user groups (which anyone is free *not* to join) without affecting any current functionality. 

Thank you.

Patti in AZ

On Thu, Jun 20, 2019 at 06:21 PM, Mark Fletcher wrote:

This particular mild PITA has now been fixed. :-)

If I click in the email address header, it's still sorted in reverse alpha to start with.

Andy

Yay! Thanks, Mark. 😊

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Exactly right. The member activity log is explicitly the issue here.

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Bruce,

On Thu, Jun 20, 2019 at 07:12 PM, Bruce Bowman wrote:

I just checked our group's activity log and each Direct Add

I believe this is referring to the member's activity log.  If you look in there, there is no reference to being added.

Andy

On Sun, Jun 16, 2019 at 03:19 PM, J_Catlady wrote:

I can't remember whether this came up before: since moderator actions on a membership of having approved or rejected a membership are included in the member's activity history, it seems an anomaly that having been direct added is not included as well.

J -- I just checked our group's activity log and each Direct Add creates an entry along these lines:

"Moderator name <email address> added [new member's email address] with message "This email signifies that you have been added to the collaboration site for the Indiana Astronomical Society at groups.io. IAS-INDY is a etc...

It doesn't say "direct added," but it does say "added." The same thing happens when Direct Adding someone to a subgroup...with or without a corresponding Member Notice.

Just struggling a little to understand the scope of the proposal.

Regards,
Bruce

Behind J Catlady’s suggestion 100%. 
I’ve just spent several days working with others to set up a health-oriented education/discussion/support group only to realize that the email feeds don’t scrub individuals’ email addresses. Otherwise the functionality is exactly what we need.  
If addresses can’t be scrubbed from the email feeds, then a no-email option would work well. Most similar (health) groups are web based only and people often join for short periods of time for information and support then move on - there’s no need for them to have access to everyone else’s address. Many of these users are not sophisticated enough to set up an alternate email or even realize they could be exposed.
As far as display name, an individual can determine how revealing or detached from their identity it is.  I’m sure there are nefarious people out there with nothing better to do than to put screen names into their browser search and match them up with real people - well, many NSA but I don’t think they’ll bother with my group.  But I seem to be hearing “anonymity” and “privacy” being thought of as one and the same here. While “privacy” is often/usually a subset of security “anonymity” is not.

This is a bit late. As a general principle, I think hashtags are a good feature, but for some groups, they are an unnecessary complication and best not used.

When one of my groups moved to groups.io, I tried to promote the value of hashtags and a few people used them for a while, but within a few weeks, they all quit and I quit promoting them. As a result, hashtag counts show up on the home page, but they are deceptive since none have been used for a couple years. I suggest that you set up a rolling window, i.e. only show counts for the past 12 months or whatever threshold seems appropriate.

Sorry for chiming in so late.
Best, Marv

That makes sense, Mark.  I bet it is email client driven. Being able to change the reply-to default helps so, if a subscriber does want to reply-all (to the group), they then have to scroll to that link at the bottom of the message.

Would it be easier/more sensible to build the notify/don't notify choice into both "reject" and "delete" though?  I'm not sure how many others might value that but it only makes sense if the group is using the two for two different, pragmatic, purposes aside from notification.

Thank you!
Barry

Hi Gerald,

Thanks for the question.  There are two things related to the suggestion of considering a "without notification" option for both delete and reject.  On the tracking piece, we're finding that we use reject when some type of group rule or norm has been violated, typically on content or tone or whatever.  Alternatively, we'll use delete if a more administrative or technical issues, such as when the commenter mistakenly replies to the group when they intended to reply to an individual commenter.  Separate and related to that, allowing for auto-notification or no-notification (different from whether an owner/mod chooses to write a reply message), seems like it would just be more compressive in allowing group leaders to handle the full gamut of possible situations most effectively and efficiently.

Finally, aside from allowing that choice for both reject and delete, I do think better if the default top fields on emails sent to group members were more literal, descriptive and consistent with what most are familiar with from normal email.  That was my #1 below in the original post.

Barry

Barry,

I don't understand what nuance you are trying to track. The way I see it, there are only two possible cases, not three, or four. The difference between Rejecting and Deleting is only whether or not you want to bother to reply to the submitter.

--
Gerald