For general Groups.io questions, please see the Group Managers Forum and Group_Help groups. Note: those groups are volunteer-led and are not officially run by Groups.io.
moderated
Re: Member Data Improvements request
#suggestion
John Wirtz SF
Gender? Absolutely fine except for when, if you run a residential training event as we do, you allocate a single female to a gents accommodation block!
toggle quoted messageShow quoted text
This paranoia has to be reined in, some questions are asked for purely practical reasons and not in the basis of discrimination. John SFSS group
-----Original Message-----
From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Bärbel Stephenson Sent: 08 April 2020 09:38 To: main@beta.groups.io Subject: Re: [beta] Member Data Improvements request #suggestion People in e.g. Mongolia have a single word as a name, no first or second name, just the one word name. Ever increasing amount of people do not want to be identified by a gender, so title if they do not have a PhD or other such professional title that could also cause an issue for them. Barbara On 8 Apr 2020, at 08:29, John Wirtz SF <john@sorefingers.co.uk> wrote:
|
|
moderated
Re: Member Data Improvements request
#suggestion
John Wirtz SF
Interesting stuff. However, these sites don’t talk about people not having names but rather how different cultures treat names. I’d expect the majority of groups her are pretty conventional in terms of name requirement.
Long Company names is an easy thing, just define the number of characters allowed in a field. It’s not unusual for a text field to accept up to 255 characters I believe. Developers restrict this property with very large databases to save storage and also accelerate searches and indexing.
A lot of this depends on how the subscribers database on group.io is organised and it’s properties are defined.
Regards
John
From: main@beta.groups.io <main@beta.groups.io>
On Behalf Of Jeremy H via groups.io
Sent: 08 April 2020 10:56 To: main@beta.groups.io Subject: Re: [beta] Member Data Improvements request #suggestion
Ah yes - see
https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/ (based on
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ ),
https://blog.jgc.org/2010/06/your-last-name-contains-invalid.html or
https://www.w3.org/International/questions/qa-personal-names. Or the discussion in
https://developers.slashdot.org/story/10/06/17/2347257/falsehoods-programmers-believe-about-names .
|
|
moderated
Re: Member Data Improvements request
#suggestion
Jeremy H
Ah yes - see https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/ (based on https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ ), https://blog.jgc.org/2010/06/your-last-name-contains-invalid.html or https://www.w3.org/International/questions/qa-personal-names. Or the discussion in https://developers.slashdot.org/story/10/06/17/2347257/falsehoods-programmers-believe-about-names .
Or the somebody's struggle with (IIRC) Hawaii DOT - they wanted her full legal name - she said it has 39 letters, your system will only accept 38... So - if a group does have a requirement like this - I would go with Duane's idea of extra, group definable, fields. And a group wanting to make them mandatory will have a group management issue as to how it does so. I think that's the only thing we can reasonably ask Mark to implement.
|
|
moderated
Re: Member Data Improvements request
#suggestion
People in e.g. Mongolia have a single word as a name, no first or second name, just the one word name.
toggle quoted messageShow quoted text
Ever increasing amount of people do not want to be identified by a gender, so title if they do not have a PhD or other such professional title that could also cause an issue for them. Barbara
On 8 Apr 2020, at 08:29, John Wirtz SF <john@sorefingers.co.uk> wrote:
|
|
moderated
Re: Member Data Improvements request
#suggestion
John Wirtz SF
Christopher,
toggle quoted messageShow quoted text
I don't get this. Can you give me instances of a group that has members without names. I stress that should the mandatory option be available - I suggest it as an option - our group would insist on that data. I don't want to deal with people who have something to hide as hey are the most likely to cause trouble down the line under the protection of anonymity. We have run groups since 2001 and I can count less than five trolling type incidents. Cheers John SFSS Group
-----Original Message-----
From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Christopher W. Sent: 08 April 2020 01:00 To: main@beta.groups.io Subject: Re: [beta] Member Data Improvements request #suggestion On 2020-04-07 at 9:49:03 AM, John Wirtz SF <john@sorefingers.co.uk> wrote: Desirable additional fields would be:I don't think that any of these can be mandatory. Not everyone has a title, a first name, or even a last name. -- Christopher W. <lists@cw.codes>
|
|
moderated
Re: Member Data Improvements request
#suggestion
John Wirtz SF
I’m no database developer but un-defined fields could cause problems as they would be likely contain incompatible data from group to group, i.e. numbers, text, etc. Normally, when setting up field properties, it is wise to specify the type of field content.
My rationale is that most people will be happy to supply First and Lastnames along with their email addresses. Anymore then that (addresses etc) become more controversial from a data protection point of view. The “mandatory” is easy,. In the field properties, one can set an option to not a allow a ZERO VALUE. Just needs a toggle to switch it on or off in line with the group owner’s preference.
Anyway, over to the developers….
John
.
From: main@beta.groups.io <main@beta.groups.io>
On Behalf Of Duane
Sent: 07 April 2020 20:26 To: main@beta.groups.io Subject: Re: [beta] Member Data Improvements request #suggestion
On Tue, Apr 7, 2020 at 11:57 AM, John Wirtz SF wrote:
Something that I just thought of. Instead of having dedicated fields added, how about having 5(?) extra fields in the member record that could be used by group management for whatever purpose they want. (It would be up to them to keep
a list of what it represents.) I'm sure there are some groups that would want 30, but 5 seems like a reasonable number and can contain a lot of information if used wisely. That also might make it more likely to be implemented since it could cover a lot of
applications instead of a few specifics. I don't know how difficult it would be to make them mandatory for a group where they're used though.
|
|
moderated
Re: Member Data Improvements request
#suggestion
Christopher Warrington
On 2020-04-07 at 9:49:03 AM, John Wirtz SF <john@sorefingers.co.uk> wrote:
Desirable additional fields would be:I don't think that any of these can be mandatory. Not everyone has a title, a first name, or even a last name. -- Christopher W. <lists@cw.codes>
|
|
moderated
Re: Member Data Improvements request
#suggestion
On Tue, Apr 7, 2020 at 11:57 AM, John Wirtz SF wrote:
Desirable additional fields would beSomething that I just thought of. Instead of having dedicated fields added, how about having 5(?) extra fields in the member record that could be used by group management for whatever purpose they want. (It would be up to them to keep a list of what it represents.) I'm sure there are some groups that would want 30, but 5 seems like a reasonable number and can contain a lot of information if used wisely. That also might make it more likely to be implemented since it could cover a lot of applications instead of a few specifics. I don't know how difficult it would be to make them mandatory for a group where they're used though. Thanks, Duane
|
|
moderated
Member Data Improvements request
#suggestion
John Wirtz SF
Email Distribution Groups – General observations The main purpose of such a group is to enable us to be able to reach all our subscribers (also customers) from a single email address with messages delivered directly to their email client inboxes. Despite popular opinion, Facebook has never been an effective replacement for email groups. We are ex users of “egroups” and “Yahoo Groups” So, why do we favour the use of email groups? Running a small business with limited resources, the group is ideal to send targeted messages to our subscribers, straight to their email client inboxes. Once the site is set up – the manual is a great help – the group needs little maintenance. The most onerous task is subscriber management. Like most small businesses, we have a developed customer database. In an ideal world, I’d like to manage customer group subscriptions to the group from our own database – I am very wary of duplication – and have a dedicated table synced to a MYSQL type table on Groups.io either directly or to the subscriber’s database. Failing that, links between these data sets could exist internally to the group.io between the database section and the subscriber’s database table. The table facility in the database section already exists. The current problem is that the main subscriber’s listing doesn’t carry enough fields against which to filter and search records. Desirable additional fields would be: - Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc) - Firstname (mandatory field) - Lastname (mandatory field) These fields would make searches and filtering a lot easier and by consequence would greatly ease the subscribers maintenance process. Our own policy is to not allow anonymous membership as it is always those who are likely to mis behave thinking they are immune form recognition. At present we are forced to use the “display Name” field to record that information and it cannot be made mandatory. Searches are not instant as we have first and lastname in a single field. I realise it is possible to download a “csv” file but even this requires two steps from the groups site. Once downloaded, one has to split columns and carry out other manipulation before the data is ready for use. As a general comment, I am always a little surprised that after many years of experience of open communications across the internet, social media and forum platforms allow anonymous membership. Concluding, I would like to see improvements in the subscriptions data table – additional fields - and syncing of internal and external data tables. I would add that it’s refreshing to know that one can reach out to those who are empowered to make changes and improve the site. John Wirtz
|
|
moderated
Re: Digest sent before member accepted
#bug
On Mon, Apr 6, 2020 at 7:56 AM Marv Waschke <marv@...> wrote: On April 4, a user requested membership to our restricted, private archive group, received our standard reply asking for more information. Before replying, the as yet non-member received a message digest from the group. They mentioned this in their reply. I approved the request for membership. The logs show the request and acceptance, but no email delivery is recorded. I believe both the delivery of the digest and the absence of a log record of the delivery in the Email Delivery History are defects. The group is trollope.groups.io. The member is EJP. The logs cycled before I was able to look at any possible digest delivery (I've increased the log retention on those logs now). But I went through the code and I don't see how that could have happened. Please let me know if you see something like this again. Thanks, Mark
|
|
moderated
Re: Site updates
#changelog
I could do without both the “active topics” and the ugly hashtag thingy. I get really tired of someone trying to direct what I do and don’t read and engage with. This seems to be happening on a lot of platforms in attempts to be more “social”. For those folks who prefer to be controlling with their group members, enjoy. Just give the rest of us the option to not opt in (and make it an “opt in” rather than an “opt out”).
|
|
moderated
Re: Digest sent before member accepted
#bug
Chris Jones
On Mon, Apr 6, 2020 at 04:05 PM, Marv Waschke wrote:
Could that have affected the digest sending logic?Only time will tell... (Sorry!) Chris
|
|
moderated
Re: Digest sent before member accepted
#bug
I just noticed Duane's comment on Time Zones. The digest was sent across the international date line. Could that have affected the digest sending logic?
Best, Marv
|
|
moderated
Digest sent before member accepted
#bug
On April 4, a user requested membership to our restricted, private archive group, received our standard reply asking for more information. Before replying, the as yet non-member received a message digest from the group. They mentioned this in their reply. I approved the request for membership. The logs show the request and acceptance, but no email delivery is recorded. I believe both the delivery of the digest and the absence of a log record of the delivery in the Email Delivery History are defects. The group is trollope.groups.io. The member is EJP.
Best, Marv Waschke
|
|
moderated
Display member time zone
#suggestion
#done
While I was checking this morning to see if digests were being delivered (based on a question I was looking into), I noticed that some members didn't get one. Then it dawned on me that they aren't in the same time zone as me (used as the group default) so will get theirs later/earlier. In cases like this, it would be really handy if there were a notation in their member record of which TZ they have selected. I wouldn't want to be able to change it, just see it. Maybe next to or just below the Joined date. Due to some areas not having an official abbreviation, showing them in UTC might be best.
Thanks, Duane
|
|
moderated
Re: Site updates
#changelog
On Sun, Apr 5, 2020 at 02:22 PM, William Ellis wrote:
I understand people's reluctance to change something that they "see no value" but for those of us with groups where it would be a plus - why not.IIRC, the main concern expressed with the new homepage wasn't so much the addition of an "Active Topics" div, but that the big "Top Hashtags" buttons tend to dominate the layout. In turn, the current hashtag layout is difficult to tap/navigate on mobile devices. If the new layout was implemented in conjunction with a setting to hide the "Top Hashtags" div entirely, I believe this might go a long way toward resolution of the deadlock. Regards, Bruce
|
|
moderated
Re: Site updates
#changelog
Mark;
How about giving the Admin of a group the right to upgrade the home page? I understand people's reluctance to change something that they "see no value" but for those of us with groups where it would be a plus - why not. I don't know what it is like to do something like letting people select and I am sure it is more work than rolling it out everywhere. We.
|
|
moderated
Re: Site updates
#changelog
On Sat, Apr 4, 2020 at 10:24 AM, Mark Fletcher wrote:
I would still like to roll it out everywhere because I think it's a superior experience.Will it be an option or mandatory? I still have the same reservations about the new page layout as when it was originally announced. Thanks, Duane
|
|
moderated
Re: Site updates
#changelog
On Sat, Apr 4, 2020 at 06:35 PM, Mark Fletcher wrote:
I made a mistake and forgot to remove that from the list before I posted it.If it was just a mistake then no problem. At least we understand the discrepancy between the changelog and what actually changed. Hopefully the changes to the homepage and the Zoom integration can be rolled out shortly. Many thanks, Andy
|
|
moderated
Re: Site updates
#changelog
On Sat, Apr 4, 2020 at 9:27 AM Andy Wedge <andy_wedge@...> wrote: I've seen the previous discussions on the hompage changes and the recent release and rollback of the zoom integration. I am still perplexed by the fact that these changes were included in the changelog when in fact they had not been released. How many of the others in this week's list are like this? (Many snarky responses typed and deleted). I made a mistake and forgot to remove that from the list before I posted it. Mark
|
|