Hi,

I represent the River City Gems charitable organization (www.rivercitygems.org and rivercitygems.groups.io) and we have been using groups.io for a number of years. We currently have the Premium membership. Just a little background. We are a private social group that hosts various social events and we provide a community forum so that all our members can communicate. We also use groups.io subgroup to organize and plan events with a subset of our community that volunteers. This is an all volunteer organization. The current email based system has served us well but most of our younger users only have a mobile device and they find the email interface a little cumbersome and antiquated. We are trying to find another tool to replace groups.io but then I stumbled on this group discussing a mobile app version of groups.io. I have not yet got my hands on it to test it but I hope that changes soon. We have been evaluating other tools and think we may have found something but we have to give up some features in groups.io that we like. Specifically the ability to have folders in the storage area, private storage for each subgroup and the integrated calendar function. A groups.io mobile app would probably solve our problem if we can wait for it and afford it.

I've read through some of the pricing discussion but there doesn't seem to be a good summary so I'll just ask here.

I've got a board meeting on the 18th to review some of the new applications so I'm looking for pricing and availability of the groups.io mobile app. I'm looking for something to take to the board meeting so share. Would the mobile app be included in the premium version for all users? If not, is there someone who can summarize the current options on the table? When would the app be released to general public? 

Hugs,

Joanie

J,

-Is the group owner supposed, or is groups.io going, to maintain a
wait list?

Neither.

Well, actually Groups.io but not in the way you're thinking.

-What about restricted groups with a questionnaire - are people
requesting admission supposed to complete the questionnaire knowing
they won't be admitted immediately, or perhaps not even knowing at
first?

Yes.

In my proposal the processing of pending members proceeds as normal, with the addition of telling the group moderator (in the pending email and in the Pending Approval tab of the Members list) of whether this applicant would need a group-sponsored slot, and if so how many such slots are available.

If a slot is not needed (the applicant has a paid account), or if one is needed and the moderator elects to apply one to this applicant, then approval proceeds as normal and the applicant becomes a member.

If a slot is needed and the group doesn't have any available, or the moderator elects not to apply one to this applicant, then approval makes this applicant an "inactive" member (that special status in my answer to Mark). Similar to NC status, the member cannot participate in the group (not even reading or receiving messages).

Like NC status this can be corrected after the fact. The member can correct it by paying for his/her account or a moderator can correct it by applying a sponsored slot to this member.

-Is the 14-day pending member limit (before deletion) going to be
removed?

With my scheme that needn't change: there's no new reason to hold someone in the Pending list; approve them with the knowledge that they may stay indefinitely inactive.

-In general, how and at what point, would or should requesting members
be notified that the group is temporarily full?

I'll have to think about whether the number of available sponsored slots should be shown in the group's home page and/or their directory listing. That would in some sense be friendly towards people with no means or desire to pay for their account, but it might lead to predatory behavior (over-subscribing to groups with available slots "just in case" or as a means of costing the group a valuable resource).

On the whole I'm inclined to say that the applicant finds out when they are Approved, and either become an active or inactive member. If the applicant is rejected then the question of available slots is moot, and they needn't have been informed sooner

-How, and this is not a technical issue, but how are group owners
supposed to figure out whom to remove (and how to inform them) if and
when a "more desirable" person requests admission?

Much of the heartache with this issue is reduced in my proposal, because you can inactivate a member to free a slot rather than removing them. Inactivation can and should be associated with a Member Notice by which the group says whatever they think needs to be said about the circumstances. But the key here is that the inactivation can be cured easily by the member or the moderator without all the overhead of removing them and having them re-apply.

-"Try before you buy" also sounds very tricky. How many people will be
allowed in on that basis? How would it be kept track of (in case
someone tries to repeatedly try), and other issues...

That's handled entirely by Groups.io. From the point of view of the group such people appear as paid accounts (no need to use up a slot). When their trial expires they go on Inactive status.

That event would be logged to the group's Activity page, and a group moderator can choose to receive a notice (like a "left group" notice). I don't know if it needs a separate control or just rolled into the moderator's subscription control for Members notices.

Shal

Mark,

* Groups have a set number of "free member slots". Someone filling
one of these slots does not have to pay anything to Groups.io.

The number of included subscriptions (based on plan type) plus the additional per member fee slots purchased by the group I would refer to as "sponsored" subscriptions. The intent is to emphasize that those two types of subscription are equivalent: a limited resource that the group purchased through the base plan payment plus the per member payment. The group itself is sponsoring these members.

* Once the free member slots are filled up, someone wishing to be a
new member of the group would have to pay a yearly fee to Groups.io.

I'd like to have a different word than "paid" for these subscriptions, to avoid confusion with subscription slots purchased by the group. Possibly "sustaining" members. Maybe "at large" members, because they can join any* group (not just those with available "sponsored" slots).

*Any group that will have them - I'm not suggesting that they can bypass the approval process of Restricted membership groups.

* Are there any problems with this idea/reasons to not implement it?

I don't see any show-stoppers.

* Does there need to be a |try before you buy| period where someone
could subscribe to a group for 14 days (let's say) before having to
become a paid member?

That would likely make sense. Usually one doesn't know how well a group works for you without seeing the content and possibly interacting with other members.

At the end of the period perhaps put the subscription in a special inactive* status (rather than unsubscribing it). The status would operate like NC, Bouncing and Bounced in that the account would not be allowed to receive or post by email, nor use the group's web features. But unlike those, this would be a subscription status, not an account status (that is, the account could still participate in groups where it is sponsored).

*This inactive status is not to be confused with WRB's concept of actively posting versus passively listening (inactive, or lurking) members. Maybe I need a better word than "inactive" but I haven't thought of it yet.

The member can correct inactive status (or preferably preempt it) by paying for their account. The group owner could correct (or preempt) the inactive status by sponsoring the member.

One potential downside for Groups.io in this is that a "free trial" subscription may be all some users need. I'm thinking of "freecycle" style groups or help groups where once the transaction is complete or the help obtained the user may have no further interest in the group. Maybe that's ok, maybe it isn't.

* In Samuel's proposal, there's potentially a lot of member
management that has to be done by the owners and I wonder if we
reduce/simplify that?

I think the idea of an inactive membership (one that is neither sponsored by the group nor a paid account) provides a way create very easy management. If a group wants to free up a sponsored slot there can be a button/action to un-sponsor a subscription - which puts it into inactive status until corrected by the member choosing to pay for their subscription (or the group reversing its decision). This avoids a lot of the downsides of unsubscribing the member.

Group owners who want to actively manage their sponsorships will likely want the types of subscription metrics some have already been asking for. Things like most recent post, # of posts in the last year, etc.

Ideally this is something owners would not have to think about.

For groups owners who don't want to actively manage their sponsorships
I think simple mechanisms and suitable defaults can be devised that will produce reasonable results. The fundamental thing the owners must decide is which plan and how many sponsored members (if any, above the number included in the plan). After that it is a matter of choosing to actively manage the sponsorships or not.

Shal

On Sun, Jan 10, 2021 at 07:56 PM, Christos G. Psarras wrote:

Duane tested the actual notice-generation event part, and it results in notices sent out after the event has transpired; a 0-min reminder's notice came 5 minutes after the event

Actually, I set a -5 minute reminder which came after the event start.  Sorry I wasn't more clear on that.

Duane

Hi Mark,

This is a combination of two separate but related issues in the Reminders section of the Event Add/Edit screen.

Please refer to this topic: https://groups.io/g/Group_Help/topic/events_calendar_reminders/79560226

The bug part; the "minutes before" duration textbox and/or underlying code allows the user to add/edit and save a Reminder with zero or negative values as the "minutes before" duration, no check or validation is done.  Duane tested the actual notice-generation event part, and it results in notices sent out after the event has transpired; a 0-min reminder's notice came 5 minutes after the event (the 5 must be significant because that's the default textbox display value when one adds a new reminder).  These are non-desired results.

The suggestion part; as you'll note in the above linked topic, the current Reminder frame's element layout can foster some ambiguity/fuzziness on adding/editing Reminders for Calendar-inexperienced folk (myself included at first look at it), coupled with thin/insufficient/unclear user-manual Calendar how-to info.  From a screen POV, my suggestion would be to rearrange the elements a bit or add some visible separator/delimiter, something to make absolutely clear the checkbox is not related whatsoever to the button above it or the AddReminder process, maybe something like in the attached.  Or alternatively maybe leave as is but change the checkbox to say "Send Reminder" instead of "Send Notice"?  Not sure which tweak(s) would work the best, but some tweak would help to make things crystal-clear. 

Cheers,
Christos

On Sun, Jan 10, 2021 at 01:46 PM, SP4149 wrote:

They generate considerable message traffic and image storage and will be impacted by the Jan18th price increases.

The existing group(s) should not be impacted at all by the upcoming changes, unless or until they decide to upgrade, per Mark's announcement - https://beta.groups.io/g/main/message/27191.

Duane

I belong to several Online Swap Meets that are Basic (Free) lists on groups.io
They generate considerable message traffic and image storage and will be impacted by the Jan18th price increases.
Some of these lists are large (2000+ members) that are being subsidized by the paid lists.
Retailers and manufacturers are on these lists as they provide free advertising and free web sales postings.
For Sale listings can be compact; one email listing 100 items for sale, or wasteful, a separate listing for each for sale item.
Frequently the Digest  will list only for sale items from one seller, sometimes over multiple Digest messages.

These lists have the resources to upgrade to Premium at the current $220/year but will not have the resources to upgrade in a week to over $1100/year
for Premium.  For now they are happy to be grandfathered as they are using all their Free image storage.

WE have a pricing plan that will take effect in a week; introducing a new fee per subscriber plan and also promulgating target list sizes.
The pricing plan should also state what pre-existing pricing structures will be grandfathered and for how long.
For example :

• Free lists under 100 members remain free for next ten years
• Free lists under 500 members remain free for five years
• Free list under 1,000 members remain free for three years
• Free lists over 1,000 members remain free for two years

And there should be a NEW, separate pricing plan for Online swap meets hosted by groups.io lists.
Perhaps:

• Free swap meets under 100 members remain free for next ten years
• Free swap meets under 500 members remain free for five years
• Free swap meets under 1,000 members remain free for three years
• Free swap meets over 1,000 members remain free for two years

Grandfathered provisions need a definite expiration date if the costs of groups.io lists are to be shared equitably.
And accordingly list owners facing a Premium upgrade in three years can plan ahead
And list owners of High Cost/volume Online Swap Meets can plan ahead as well.

ken

I respectfully but emphatically disagree.  Incessant criticism without suggestion(s) for improvement is a waste of everyone’s time.  

The logic supporting your absolute pronouncement here is not clear to me.

Ultimately, while no one wants this, the point may be reached when FREE cannot be continued: the choice then becomes pay or lose... as I've mentioned before, in this situation, there is no good option, only a choice of bad or worse...

Note: members are members of Groups.io, having a relationship with it separate from, but combining, their membership of groups. Groups.io 'knows', and 'acts on', both that X is a member of group Y, and that group Y has X as a member, as required.

My thoughts on 'message to users' for (and so 'members view' of) Samuel's proposal (as I understand, and would intend it implemented - in bullet point form - would need revision before sending out):

• Groups.io costs money - someone has to pay. The current model, of free memberships, with payment by (some) group owners is unsustainable.
• There is a consequent need for members to contribute, so we (groups.io) invite you to take out a 'Contributing Member' subscription ($? p.a.), to help ensure the continuance, growth and developement of Groups.io. We hope you feel it worth it....
• 'Contributing Members' will benefit from unlimited groups memberships; also possible future additional features may only be available to 'Contributing Members'  
• In the future, some groups will only have a limited number of spaces available for non-contributing members.
• There is no requirement to become a 'Contributing Member': you may continue as a free member, with your current group memberships and features unchanged (including use of web interface).
• But you may not able to join additional groups (if they do not have 'free' spaces available), or take advantage of new features.

Notes:

• People will continue to be able join as free members (though with an invitation to become a 'Contributing Member')
• Invitations to become a 'Contributing Member' can/should be sent periodically...
• When someone wishes to join a 'full' group (no free spaces), they should (perhaps) be invited to become a 'Contributing Member' for the purpose, on a 30(?) day provisional/trial basis.
• For a 'full' restricted group, the ability of group owner to add an additional 'free' space must be considered: possibly the process should be an additional response to 'can I join?' - 'yes, if you become a 'Contributing Member'; or an initial request take it on 'trial' basis (cancellable on rejection).  Process may differ, depending on whether additional 'free' spaces are bought by the block (50? 100?), or individually.
• If a group is full, with public archive, etc., then someone with free membership will still be able to read the archive, etc.: just be unable to join, and post, etc, as a member,

Jeremy

On Sun, Jan 10, 2021 at 11:30 AM, Scott Chase wrote:

My Grandfathered FREE Basic Group would no longer be freely accessible, if there is ANY form of a user account fee suddenly being charged by Groups.io every year.

I don't believe that's true.  I think Mark would have some sort of setting at the group level to determine if a site membership would be required.  A new group would have a limited number of free members, but any paid members wouldn't count against that limit.  A grandfathered group would basically have unlimited free members.  There are certainly a lot of details like this that would need to be accounted for, but I don't think it will be that much of a change, if any, for existing groups.  Only existing groups that upgrade may be presented with a limit that they'll need to keep in mind.

Duane

Quite so!
GROUPS are Grandfathered.
Not members.
Groups are members of IO.

Memebers of a group are members oilf a group and not members of IO.

SOME outfits for say, $500, give a member lifetime total all-inclusive benefits.

But that's not been suggested and would be a unique tier... for a member... not for a Group.

BillSF9c

My Grandfathered FREE Basic Group would no longer be freely accessible, if there is ANY form of a user account fee suddenly being charged by Groups.io every year. My FREE Group would be placed behind a traditional Paywall at that point. Someone even remotely interested in joining my group may be required to become a subscriber of Groups.io in order to access my Group's previously-free content.

Nobody on the internet is going to even remotely have the impression that my Group's content is free, if they must now pay for a Groups.io account. I would not have been initially interested in Groups.io, and subsequently paid $220 to transfer my little Yahoo group to Groups.io in the first place, if there was going to be ANY kind of user Paywall put in front of my group at some point. I don't think most people will join my Group anymore if Groups.io becomes a Premium service with a Paywall. That's not what I signed up for and paid a transfer fee for.

But, I do support adding a Donation button to me grandfathered free group. And I would encourage my members to use it.

Scott

On Sun, Jan 10, 2021 at 12:22 AM, J_Catlady wrote:

My interpretation is that the grandfathering would immediately cease to be in effect because the new proposal affects all group members. Even if a group itself is grandfathered in, members may have to start paying to join other groups. Nobody who created a groups.io account thought that was going to happen.

While I agree that many people who created groups at Groups.io had thought that things would always be the same for them and for everyone else that they recommended Groups.io to, and many such people were disappointed to discover that Groups.io changed in ways that no longer match the recommendations that they had made to their friends, and that the advantages of Groups.io that they had originally mentioned to their group members to convince them to move to Groups.io are no longer available... while I agree with all of that, the fact is that "grandfathering" relates to groups only.

I deduce from your comments here and in other mails that you thought that "grandfathering" means that members of a grandfathered group will always have the same rights/abilities in all other groups that they have in the grandfathered group.  But the way I understand "grandfathering", the group (i.e. the group structure, not the collection of individual members) continues with the same rights/abilities as before, and its members have the same rights/abilities in that group that they had before.  Grandfathering does not mean that all existing members of a grandfathered group can continue to use the rest of Groups.io as if it's still 2018.

(I do sympathize with owners and members of grandfathered groups.  When Mark's new payment plan goes into effect, if a member of a grandfathered group tries to create a new group, he'll get a very unpleasant surprise when he discovers that Groups.io is no longer the free platform that he had thought it was when he joined the first group.  We all have stories about how we heartily recommended Groups.io to friends, and then we were forced to retract it when conditions became less favourable.)

To the question of how my suggestion would affect grandfathered groups: one thing that Mark could do is to convert the "unlimited membership numbers" facility of grandfathered groups to "unlimited free-member slots", and nothing else would need change for grandfathered groups to become compatible with the suggested payment system.

I keep getting drawn back in, so I’ll just say it one last time and then mute this topic so I’m not tempted: my feeling is that any structure wherein members pay instead of just owners violates the promised grandfathering because it affects virtually everything, is messy and complicated in nearly any form, changes the whole model of what we are doing here, and (as someone else mentioned) creates weird inequities. That’s it, that’s my own personal position, it may not be other people’s, and I won’t respond to comments contradicting it. I have to say that least this thread provided a welcome diversion from the rest of what’s going on.

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

Yes, I understand that. Again, not what I’m talking about.

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

Nobody was promised that those things would be grandfathered, either.
 

You mean, grandfathered forever and ever? 

If yes, Mark's message promises (to me at least) that, as has been customary so far, groups created before this necessary (Jan-2021) plan change will stay legacy "forever" [or at the very least until there is the absolute need for change due to a sustainability or emergency situation]; an explicit promise in other words that grandfathered/legacy groups will stay as such as for as long as he can help it.  (Mark please correct me if I understood/extrapolated wrong)

To me that is as good as grandfathered forever.io can get; it's the same promise we have gotten every time so far there has been something grandfathered, and so far it has been forever, hopefully it will stay like that forever.  It would be nice but it's unreasonable to expect Mark to promise forever-and-ever; if one thinks about it, grandfathering things is a perk to us from Mark, done at his discretion because it's affordable/sustainable, so far.  Things can change with no control over them.

Cheers,
Christos

My group deals with loads of databases, by this I mean I have to deal with loads of databases. I would LOVE to have the buttons at the top. Deleting a database is onerous, especially when I have several dozen to do at once, like when we are getting ready for our next semester of classes and I need to delete all the previous databases. Eliminating the scrolling would be helpful. I just now learned about the shortcut to get to the bottom of my screen, how many others aren't aware of this? 

On Sat, Jan 9, 2021 at 07:31 PM, Christos G. Psarras wrote:

Not to argue,

Haha! :-)
 
--
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