Date   

moderated Log "joined chat" #suggestion

 

As far as I can tell, "joined chat" is not logged in either the member or the group activity log. Seems like it should be.
--
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


moderated Pending message approval fails without explanation #bug

Andy Wedge
 

Hi,

I'm raising this as a bug and I think there are potentially two issues here:

We have a member who posted a message to our Committee subgroup and for some reason, also copied the email to an address that gets forwarded to the same group via an integration. The copy of the message sent direct to the group was sent to other members and the copy sent via the integration has been held pending approval (part of our moderation process).  A recipient and member of the same group then replied to all and so now we have the two messages showing on the subgroup archive, and two messages pending approval.

Seeing the pending messages and not realising they has also been posted directly to the subgroup I tried to approve them.  There is no warning message to say that approval has failed but the messages stay as pending. I could probably delete them but have left them for now as evidence of this issue.

In addition, the member who posted the original message received the following response from Groups.io:




This was very confusing for our member as it indicates that he is not a member of our Committee subgroup when he is.

Regards,
Andy


moderated Re: #bug Gio iCal feed errors making GCal mad #bug #fixed

Dave Huseby <dhuseby@...>
 

Hi Mark,

Thank you so much for your quick response to my bug report. It looks like the issue has been completely fixed but I'm following up with members of our community to confirm that it is. Thank you again, this is wonderful.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


On Mon, Mar 23, 2020 at 1:33 PM Mark Fletcher <markf@corp.groups.io> wrote:
Hello,

On Fri, Mar 20, 2020 at 6:01 PM Dave Huseby <dhuseby@...> wrote:

The Hyperledger community uses Groups.io for all of our mailing lists and community managed calendars. We like to use the .ics feeds from groups.io to populate a GCal plugin on our Confluence wiki. We're finding that GCal fails to render all of the events in the feed. I ran our iCal feed through an ics validator and found tons of errors:


The issue was with a duplicate 'RRULE:' for events that repeated yearly. I've fixed it and that ICS file is now readable in GCal.

Thanks,
Mark 


moderated Re: Edit a wiki page, make no change, then Save is logged as a change and an identical revision is created #bug

 

There is yet another bug (and these are separate): the addition and deletion of spaces within a line are not detected/shown by Compare evisions. For example, if the original line is
let's have a virtual block party
and it is edited to
let's       have a virtual block party
then Compare Revisions does not show the change and simply displays the original.

Therefore, when Compare Revisions shows no changes (no green text), it's possible that either (1) no change was made yet a revision was created anyway (as I first reported), or (2) the spacing was changed. For completeness's sake I have to say that of course there may be other bugs involving changes that don't show up, but I'm guessing those two are the extent of it.

For awhile, I had just one group, wherein the wiki was strictly controlled and only mods could change the pages. So these bugs never became apparent to me. But now that I have another group, wherein everyone can change wiki pages (and in fact is encouraged to do so), these wiki bugs are problematic (including the previously reported one of not controlling simultaneous editing).

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


moderated Re: Edit a wiki page, make no change, then Save is logged as a change and an identical revision is created #bug

 

Mental typo, it's recorded as "updated wiki page." But you know what I meant. :-)
--
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


moderated Edit a wiki page, make no change, then Save is logged as a change and an identical revision is created #bug

 

I don't know what the standard for wiki revision logs is, but the situation here is that if someone clicks Edit Page, makes no changes, and clicks Save Page, their activity is recorded as "edited wiki page" and a new revision is created that's identical to the prior one. This is a PITA when you try to determine what changes someone has made and can't find the green-highlighted text - because there isn't any. It seems to me that if no changes are made, nothing should be recorded - no log entry that they edited and no new (but identical) revision.
--
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


moderated Re: Guidelines available to non-members via the help address even if GG are private #bug #fixed

 

Hello,

This should be fixed now.

Thanks,
Mark

On Tue, Mar 24, 2020 at 11:21 AM J_Catlady <j.olivia.catlady@...> wrote:
On Tue, Mar 24, 2020 at 11:10 AM, Mark Irving wrote:
Preferably both.
Agreed.

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


moderated Re: Guidelines available to non-members via the help address even if GG are private #bug #fixed

 

On Tue, Mar 24, 2020 at 11:10 AM, Mark Irving wrote:
Preferably both.
Agreed.

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


moderated Re: Guidelines available to non-members via the help address even if GG are private #bug #fixed

Mark Irving
 

Preferably both. The private guidelines should be refused to anyone who tries the GROUP+guidelines@... address and is not a member, even when this address is not advertised in the automated help message.

  - Mark (not that Mark, a lesser Mark).


moderated Guidelines available to non-members via the help address even if GG are private #bug #fixed

 

Setup: group with private Group Guidelines.
Situation: Non-member sends message to the help address, gets back instructions that include sending email to group+guidelines address. Non-member sends email to that address and receives a copy of the group guidelines via email, which they should not be privy to.
Best solution IMO: the automated help message does not include instructions for getting the guidelines if the person is a non-member and the guidelines are private.
Alternate solution: keep help message the same but if a non-member sends a message to the guidelines address send back an error message ("this group's guidelines are only available to group members" yada yada).
--
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


moderated Re: #bug Gio iCal feed errors making GCal mad #bug #fixed

 

Hello,

On Fri, Mar 20, 2020 at 6:01 PM Dave Huseby <dhuseby@...> wrote:

The Hyperledger community uses Groups.io for all of our mailing lists and community managed calendars. We like to use the .ics feeds from groups.io to populate a GCal plugin on our Confluence wiki. We're finding that GCal fails to render all of the events in the feed. I ran our iCal feed through an ics validator and found tons of errors:


The issue was with a duplicate 'RRULE:' for events that repeated yearly. I've fixed it and that ICS file is now readable in GCal.

Thanks,
Mark 


moderated Re: Solving the overload issue (Selecting specific messages into two batches - Individual email vs. Full featured digest delivery) #suggestion

 

Homayon,

My responses below should not be taken as a disagreement with your suggestion, rather they are advice on what you can do with the system today. There are multiple approaches, but discussion of existing features is really off topic for beta, so I invite you to ask in GMF if you want more detail.
https://groups.io/g/GroupManagersForum

Unfortunately again and again members leave because they feel flooded
by a part of those mails containing rather little information - while
other msg's are very valuable
This has been an issue in one of my groups, GMF, as well. My general recommendation is that members feeling flooded should check out the Advanced Preferences section of their Subscription page on the group.
https://groups.io/g/GroupManagersForum/wiki/Help-Mock-up#Advanced-Preferences

So are group is loosing many members, they feel flooded with useless
mails. That shouldn't be.
I've added advice about the use of Advanced Preferences to GMF's Goodbye member notice, inviting them to rejoin if they wish, or simply monitor the group's messages on the web without joining (GMF has public messages).

1. The messages which contain "important medical information" which
should then be delivered instantly to all members and...
I agree with the moderator that using Special Notices seems like a good fit for this use case.

Another would be the use of a subgroup, with the primary group reserved for important moderator posts only (Announcement-Only Group). But that is a Premium feature so may not work for you.

Now you could say those members should choose themselves, if they want
a full featured digest or individual email delivery, but try to
explain that to some 460 mailing list dummies ...
You can use the Default Sub Settings tab in your group's Settings page to make the default subscription Email Delivery be digest or daily summary. That won't change any existing members, but new members would start out the setting you choose. You could also choose for them a Message Selection option other than "All Messages".

Shal


moderated Main subgroup screen sort columns, sort by sub-group #suggestion

Roland Roberts
 

I'm still new to groups.io and getting up-to-speed on managing our group.

Our groups are really sort of hierarchical and, while groups.io doesn't directly support that, having the ability to sort the subgroups membership list by the subgroup would make it pretty easy to manage that. As an example, almost everyone who is in our organization is part of an announcement-only sub-group. Except for those who are part of a "friends" group who get their own special announcements only. If I could sort by the "friends" sub-group, I could quickly check that they are not part of the general "announcement" group.

roland


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

KWKloeber
 

A HARD lockout, not a warning. Folks/ignorant/inattentive/malicious can and will ignore warnings. And the downside is that it‘s not detrimental to THEM, but to everyone else.

But in addition to it being hard, the lockout should also (like an online banking session) time out (with a huge warning) so that no one user could inadvertently lock the wiki page “forever.”  Wiki edits should also get plunked into a Draft location so that time-outs are saved.



Ken
 
Sent from my phone


moderated Repeating Calendar Event updating #suggestion

Michael Pavan
 

When updating a repeating Calendar Event,
the confirmation window "Edit Recurring Event" asks:

| Would you like to change only this event or all events in the series?
|
| "Only This Event" All other events in the series will remain the same.
| "All Events" All events in the series will be changed.

If one clicks on "All Events" that changes all past occurrences, as well as the current and future ones.
This is usually not accurate.
The past is history, and should not be changed.

There should be a way to update only the current and future occurrences.

Please add "This and Future Events" as an option.

[Mod note: Removed the #bug hashtag]


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

 

There are many reasons I decided against a database for this. I won't list them here.
So it's not the issue.
Also, we are almost all done getting the bulk of the neighbor info into the list and we ourselves will seldom run into this synchronicity problem again. I do think something needs to be done about this for the sake of other groups and other use cases.
Thanks.

On Sun, Mar 22, 2020 at 6:20 AM Duane <txpigeon@...> wrote:
On Sun, Mar 22, 2020 at 01:45 AM, J_Catlady wrote:
It became very real tonight after asking neighbors to input their info
It seems to me that a database/table might be a better choice for this situation, depending on how much information is being added.  I did a quick test this morning and it's possible for one person to be editing their row while another is editing theirs and both are fine, no mingling.  The only time there will be a conflict is if a moderator is making a change while the row owner is also editing.  This results in the "last save wins" scenario.

Duane


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


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

Duane
 

On Sun, Mar 22, 2020 at 01:45 AM, J_Catlady wrote:
It became very real tonight after asking neighbors to input their info
It seems to me that a database/table might be a better choice for this situation, depending on how much information is being added.  I did a quick test this morning and it's possible for one person to be editing their row while another is editing theirs and both are fine, no mingling.  The only time there will be a conflict is if a moderator is making a change while the row owner is also editing.  This results in the "last save wins" scenario.

Duane


moderated Re: Solving the overload issue (Selecting specific messages into two batches - Individual email vs. Full featured digest delivery) #suggestion

Homayon Reinhardt Chaudhry
 

Hi Ronaldo
Insisting on netiquette didn't work. They stumbled already over this unknown English term 'Netiquette'. "Nétiquette - c'est quoi là, de la censure? Je m'en fous..."
Segmenting messages into different batches and assign those to different ways of delivery would be a "solution possible".
But we can wait in these days, it's not urgent. Let's concentrate on really important issues. When the whole pandemic is hopefully over, lets look into it again. Until then we use the method recommended by Patti and you people stay all well.
Ciao
Homayon




-----Ursprüngliche Nachricht-----
Von: main@beta.groups.io [mailto:main@beta.groups.io] Im Auftrag von ro-esp
Gesendet: Samstag, 21. März 2020 00:29
An: main@beta.groups.io
Betreff: Re: [beta] Solving the overload issue (Selecting specific messages into two batches - Individual email vs. Full featured digest delivery) #suggestion

On Thu, Mar 19, 2020 at 08:09 PM, Homayon Reinhardt Chaudhry wrote:

Dear all

Our medical group
Unfortunately again and again members leave because they feel flooded
by a part of those mails containing rather little information
I'm not sure why you think there should be a technical solution, nor even whether one is possible. The way I do it is by insisting on netiquette ( unfortunately http://www.learn.to/quote doesn't work anymore), and by clearly stating in the group-description that "me too"-messages, "thank you"-messages and seasonal greetings are not allowed.

groetjes, Ronaldo


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

 

Duane/Shal,

That's funny. I read the prior thread you posted and see that I was actively involved in it, even though no group of mine was using a wiki then. For me it was all hypothetical at that point. It became very real tonight after asking neighbors to input their info, and some of them went to a lot of effort to do it, and the result was an unholy mess lol.

Maybe it's time to finally do something about this.


On Sat, Mar 21, 2020 at 10:25 PM Duane <txpigeon@...> wrote:
On Sat, Mar 21, 2020 at 11:03 PM, J_Catlady wrote:
It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
Yeah, that's been around for awhile, https://beta.groups.io/g/main/topic/4993391  It even made it to the Trello page about 3 years ago, https://trello.com/c/4MNUkqic/283

Duane


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


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

 

J wrote:

When you compare revisions, you see, one after the other, people
wiping out each other's additions, shown by their being crossed out in
the compare.

It would be nice if this could be controlled.
This sounds familiar...
https://beta.groups.io/g/main/topic/4993391

One way to control this might be to use a warning system (soft locking) similar to the "claim" of a moderator to a pending message. The Wiki is a simpler case because there is no email interaction to handle. The first member to Edit a given Wiki page would "claim" it, causing any other member to see a warning banner if he/she also Edits that page.

One thing to consider is whether this should be a hard lock - preventing any other members from editing the page until the first member Saves or Discards his/her edit. The downside of a hard lock is that the page could end up locked indefinitely if there is no way to "break" the first member's claim.

In my own opinion, an "Are you sure?" type of soft lock would be adequate: warning the user of the other edit in progress but still allowing the judgement call to break an apparently "stale" claim.

Our neighborhood/block group has been having group members going into
the name/address directory for the block and adding their info, while
simultaneously someone else is doing the same thing, ...
Instead of locking, I'd actually prefer to control this by way of an automatic merge function; merging in the concurrent edits in the manner of a distributed version control system (DVCS) like Fossil. For use cases like J's (which I think are common) the various member's edits would (most likely) be non-overlapping spans of text, making it possible to automatically merge the changes without conflict.

Of course merge conflicts are a pain to handle; the challenge for implementing this method for the Wiki would be finding a way to signal the presence of a conflict and a means for manual resolution. A typical approach is to include both versions of the conflicting span with some markup to delimit each version of the span. That leaves it possible for someone editing the page later to resolve the conflict by editing that part of the text down to a single "correct" version.

Groups.io could encourage manual resolution of any merge conflict by providing a notification to both of the members involved in the conflicting edits. Maybe also the group moderators.

Shal