Date   

moderated New Groups.io Help Center now online #misc

West Coast Compañeros Staff
 

A new, centralized Groups.io Help Center is accessible online at https://groups.io/helpcenter. The Groups.io Members Manual (for all of us who use Groups.io's services) and the Groups.io Owners Manual (for owners and moderators of groups) are each available as a PDF download and as a single long, continuous web page. The Groups.io FAQ (Frequently Asked Questions) is also available in both formats.

This new documentation has been professionally assembled and edited by technical writer Nina Eppes under the direction of, and with help from, Mark Fletcher, the proprietor of Groups.io. Members of the beta docs subgroup have also contributed helpful critiques and suggestions for improvement.

Robert R.



moderated Re: Site updates #changelog

John Wirtz SF
 

Not wishing to teach old dinosaurs new tricks, as an ex Technical Information Manager in the rail industry, it is absolutely vital to apply version control to the user manual to capture updates.

I suggest the following control measures:
1 - Put the version control box at the beginning of the document
2 - Make sure version ,date and author is included upon every modification

Designations for versions:
Original version (current version).  v1, v2, v3, etc  These are published documents made available to all users.

Draft Versions: v1.1, v1.2, 1.3 , etc.  These version could be held in the docs folder on the beta site for review and comment.
Once draft version is approved for publication this invokes an up-reving of the main users document. 

Keep an maintain Change Log  or alternatively, use a revision system like the one provided in M/S Word to track changes.  Please note, the change log does not detail the detail of the change but merely records the location of the change.  i.e. page no and paragraph.

I would be happy to assist with this process if necessary.

Regards

John 
 


moderated Re: Site updates #changelog

Andy Wedge
 

On Mon, Apr 6, 2020 at 03:05 PM, Bruce Bowman wrote:
the big "Top Hashtags" buttons tend to dominate the layout. In turn, the current hashtag layout is difficult to tap/navigate on mobile devices.
Given that we currently have different layouts and default settings for mobile devices (the calendar display is an easy example) I don't think that should be a big hurdle to overcome.

If we had some stats on how many visits there had been to different areas of our groups (basically the options on the left side menu) then we may be able to see gauge the impact of a change. If nobody visits a group home page, for example, then whether the hashtag buttons are large, small or not displayed is somewhat mute.

Andy


moderated Re: Member Data Improvements request #suggestion

John Wirtz SF
 

In suggesting certain facilities to improve subscriber management, I wasn't prompting a debate on how group owners and moderators run their own groups.
Ultimately, as a group owner, I accept responsibility for the content of messages posted to my group.  This an important commitment as the owners of "Groups.io" cannot monitor every message posted and would be quickly and publicly taken to task if things got out of hand.   

The minimum requirements for joining our group are based on twenty years of experience and witnessing some appalling behaviour on other groups.  Our successive groups (egroups and then Yahoo) have been mostly free for unpleasantness and that is due to the fact that I can identify the subscriber, and call him/her to order when things go wrong.
I'd stress that this arrangement is reciprocal and anyone wishing to contact me can do so and that;s right down to a phone cal if the situation requires it.
I know plenty of forum.group owners who run a mile when things go wrong, no contact, unanswered emails, etc.  As we say here, that's not cricket.

The option I suggest are to assist member management and to be in a position to ave a limited degree of control over those siubscribers.

There absolutely no suggestion that "my rules" become "group.io" rules.

Let's keep this thread on topic, the technical aspects and perhaps the "groups.io" own company policies. 
On the the hand, if you feel strongly about my rules, you are welcome to contact me direct to open a discussion about my rationale.  My email address is john@...

Regards





John Wirtz

SFSS Group 


moderated Database Row - allow table editors to see/change database row owner #suggestion

jay@...
 

For database table editors, allow the easy viewing, as a column, the row owner. Also, allow the assigning of a row owner for any given row to a member.

This would help sites where members need to register/list items/credentials/capabilities/trainings, etc. A table editor can bootstrap the creation of a table row and then assign ownership to a new member for future updates.

Also, this feature would allow table editors (presumably moderators and above) to audit the ownership of rows and to know who has and who has not created rows.


moderated Re: Member Data Improvements request #suggestion

Bob Bellizzi
 

On Wed, Apr 8, 2020 at 03:39 AM, John Wirtz SF wrote:
This paranoia has to be reined in, some questions are asked for purely practical reasons and not in the basis of discrimination.
I agree that some groups, like yours, may need more security to prevent bad actors from joining; that's what Restricted Groups are all about. 

  • Don't allow anyone to just subscribe and automatically become a member
  • Set up a join form with the questions you require answers for
  • Vet the form and check out key tokens, prior to allowing someone to be direct subscribed.
  • Only use direct subscribe.
That's exactly what we do for our group.  We use an online form and vet it.
But  if it's that important, you need a website for a front end and for forms, etc.
And you need a Premium group to direct subscribe.
In fact, I would suggest that your suggestion only be implemented on Premium and above groups if the fields are optional and can have text names defined by the owner.

Much of what I gather you want to do  seems to fit an online store front better than a group.
We have both to enhance the expeience.
 
--

Bob Bellizzi


moderated Re: Member Data Improvements request #suggestion

Duane
 

On Wed, Apr 8, 2020 at 02:18 AM, John Wirtz SF wrote:
un-defined fields could cause problems as they would be likely contain incompatible data from group to group, i.e. numbers, text, etc.
Yes, in many cases that could be a problem, but if these were all text fields, it would be consistent.

Duane


moderated Re: Member Data Improvements request #suggestion

 

What you are requesting sounds a bit like mandatory “registration” - like firearms registration information, license registration information, etc.
There are many, many groups here which do not require anything more than an email address to subscribe. The purpose of a lot of groups is discussion and sharing, not reaching out to a customer base. 

If this kind of registration is important to you, then set up a database and require members to fill out the information you are requesting in the database within x number of days of joining and boot them out if they fail to comply. 

Members in the groups I am involved with would revolt if this sort of information were made mandatory. 


Patti


moderated Re: Member Data Improvements request #suggestion

John Pearce
 

Our group would not want any of this as mandatory.  Many members wish to remain anonymous for varying reasons.  Much of this is due to the public's mistrust of privacy concerns..  In this age of gender identification you might find it difficult to accommodate all of them.

John


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!

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@...> wrote:

Christopher,

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@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
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@...>







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

 

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 .

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

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

Bärbel Stephenson
 

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@...> wrote:

Christopher,

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@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
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@...>







moderated Re: Member Data Improvements request #suggestion

John Wirtz SF
 

Christopher,

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@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
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@...>


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

 

 

.

 

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:

Desirable additional fields would be

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.

Thanks,
Duane


moderated Re: Member Data Improvements request #suggestion

Christopher Warrington
 

On 2020-04-07 at 9:49:03 AM, John Wirtz SF <john@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
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@...>


moderated Re: Member Data Improvements request #suggestion

Duane
 

On Tue, Apr 7, 2020 at 11:57 AM, John Wirtz SF wrote:
Desirable additional fields would be
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.

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
Owner SFSS Group

 


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”).


Patti