On 03 Jan 2020 11:09, Samuel Murray wrote:

Yes, that bothers me too.  But a little-known secret is that you can get to https://groups.io/groups very easily by simply clicking on the "Groups.io" logo in the top left of the screen.

I must eat my words. The logo link is even less intuitive than that. It sometimes take you to whatever page you visted previously, e.g. Feed, Your Groups, Topics, etc.

Samuel

On 02 Jan 2020 22:36, Christos G. Psarras wrote:

It would be helpful to vertically-enlarge the "Your Groups" pull-down menu to account for screen Y-size and allow for more viewable groups and less scrolling.

Yes, that bothers me too. But a little-known secret is that you can get to https://groups.io/groups very easily by simply clicking on the "Groups.io" logo in the top left of the screen.

I know it's a bit odd that clicking the web site logo does not take you to the web site's main page (as one would expect), but to a page listing your subscriptions, but fortunately for us, that's the way it is.

(In addition, sorry for maybe hijacking the thread, the groups in the pull-down menu aren't in any logical order, whereas the groups on the Your Groups page are alphabetical, with owned groups at the top.)

Samuel

--
Larry Marks

 
It would be helpful to vertically-enlarge the "Your Groups" pull-down menu to account for screen Y-size and allow for more viewable groups and less scrolling:


 
Right now it's always the same height (not big enough IMO) regardless of the screen's vertical-size, so there is scrolling that much of it can be avoided if the menu's vertical size/height was bigger.

Thanks and Cheers,
Christos

Exactly, so the adjective is either superfluous or confusing, depending on who is using it. It serves no purpose. 😊

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

>>>On Thu, Jan 2, 2020 at 07:51 AM, J_Catlady wrote:

“potential”<<<

LOL, I’m not that presumptuous to be certain enough that a “potential” bug, is an “actual” bug. 

On Thu, Jan 2, 2020 at 08:39 AM, Duane wrote:

and "member_notes"

Drat, faulty memory.  Should be "moderator_notes".

Duane

While playing with various things the last few days, relative to some questions that have been asked recently, I realized that it would be beneficial to have some additional information included when using the Download button on the Members page.  In this case, it would specifically be the "id", "user_id", and "member_notes" that are included in the export (JSON) file.  Ideally, all of the information contained in the export could be included in the download, but that might be stretching it a bit.

Thanks,
Duane

For an email address, you could use the term bugreport.

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

Bug reports in the bug forum could be required to be tagged from a set of defined hashtags that relate to specific features, plus an #other tag. That would help.

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

Hashtag, email address, whatever. It’s the qualifier “potential” that’s the problem. 

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

On Wed, Jan 1, 2020 at 11:11 AM, J_Catlady wrote:

I have not been receiving the standard acknowledgement of any bugs I've sent to the support address

I posted in another thread how it would be useful to have a "bug" group. The reason being, I was interested in following their reporting and which ones were being addressed. I had no idea that bugs sent to Support were ever acknowledged. As a newbie to GIO bug reporting, I thought it was normal for Support emails to vanished into a black hole of sorts. Nice to know that isn't how it used to be. 
 
--
Sandi Dickenson
ASG Volunteers Group.

Hello

I have tested whether a user can join a subgroup directly after responding to an invite, and yes: he can. However, if a user tries to join a subgroup directly via e-mail, Groups.io sends out conflicting responses and does subscribe the user to the subgroup.

1. In a test, a user (i.e. me) tried to subscribe to my test group's subgroup directly, via e-mail (not via invite).
2. Groups.io replied (from the subgroup), telling the person to "reply" to confirm the subscription (to the subgroup).  The reply from Groups.io mentioned the subgroup specifically and not the main group at all.
3. After the user replied to the message, the moderator received a message from Groups.io that the test user wants to join the *main* group (not the subgroup).
4. After the moderator approved the membership, the test user is a member of the main group, but not of the subgroup.
5. After a few minutes, the test user received a welcome message from the *main* group, and the moderator received confirmation that the test user joined the main group.
6. The test user is still not subscribed to the subgroup, and (presumably) has to try to join the subgroup a second time.

Samuel

Hello

In a test, a user who accepted an invitation to a subgroup is told to use the plus-style address for posting to the subgroup (see image attached).  This is not ideal.  I suspect the template for that page just needs to be updated.

Samuel

[By the way, posting to the plus-style address works fine, although when the reply is received again, it comes from the subdomain-style address, which would mean that users would then end up with two different addresses in their e-mail program's address book.]

>>>On Wed, Jan 1, 2020 at 04:37 PM, J_Catlady wrote:

useful only if bugs are easily identifiable there by subject lines, and there again you fall prey to possible widespread misuse in not identifying bugs properly, etc.<<<

Ok I can buy into the benefit of a bug-specific forum. (BUT good luck with the above caveat.)  Arrrgh. 

>>>

potential-bug@“ could differentiate general support vs bug reporting.

I don't think a hashtag like that will be effective.<<<

On Wed, Jan 1, 2020 at 12:56 PM, Ken Kloeber wrote:

potential-bug@“ could differentiate general support vs bug reporting.

I don't think a hashtag like that will be effective. You'll get a plethora of people using it identically to #bug, either sometimes or all the time, either because most bugs *are* still potential until they're confirmed (either by the reporting user or others), and/or because they don't know the difference between "general support" and "bug reporting," etc. etc. etc. It will be a complete mish-mosh. 

a forum to browse bugs MIGHT be helpful, but (hopefully) anything posted/searched/browsed for on there would be moot (the bug was subsequently corrected/addressed so the bug will no longer exist

I think a bugs forum might be very helpful so that you could check whether a bug you notice has already been reported and not repeat it (and/or you could add details to the thread when you find a bug you've also experienced; but I think it would be useful only if bugs are easily identifiable there by subject lines, and there again you fall prey to possible widespread misuse in not identifying bugs properly, etc. I don't think anything in a bugs forum would be "moot." First, bugs take awhile to get fixed around here; second, a fixed bug should not be removed from the system, but marked "fixed", so that people still experiencing it can report that it's not really fixed.

Regarding the prioritization of feature suggestions based on user payment rather than suggestion quality, we agree.
 
--
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

Ok, so for one, “potential-bug@“ could differentiate general support vs bug reporting.  I do agree a forum to browse bugs MIGHT be helpful, but (hopefully) anything posted/searched/browsed for on there would be moot (the bug was subsequently corrected/addressed so the bug will no longer exist.)

doesn't your point of first running an issue thru GMF makes my point? - a high percentage of suspected bugs would/should get sorted out there (yes, no, maybe from experienced users) and then mark would be bothered with reports of only the true bugs that get filtered/confirmed via GMF (to support@ or whatever.)  For instance - the wiki sidebar issue, sorted out in 4 GMF posts (‘er messages) and confirmed an apparent bug.  GMF seems to have a pretty broad function (maybe wider than Shal intended?!?) and has confirmed a lot of “oddities” I’ll call them - not necessarily bugs that must get addressed. 

On another’s point of paid- vs freeloader-suggested features -
I presume there’s nothing preventing Mark from prioritizing all suggestions any way he desires - he knows which are generated from paid groups.  But having them all discussed on one spot certainly has obvious benefit.  Hopefully the priority would be toward those that carry the greatest improvement overall but that’s mark’s choice whether to play toward paid suggestions.  Another option (certainly not suggesting this) is two sets of coding.  Features added and available to only paid groups, but I truly believe that is, overall, detrimental in most if not every respect. 

>>>On Mon, Dec 30, 2019 at 10:22 AM, Sandi D wrote:

On Wed, Jan 1, 2020 at 04:19 PM, J_Catlady wrote:

and allow only moderators to create hashtags. 
 

Have you been reading my mind? :)

This will be in my proposal to Mark as it would result in a much smaller and tidier library of hashtags in beta.

Chris