Date   

moderated Re: Feature request/enhancement -- Enlarge the vertical size of the "Your Groups" pull-down menu #suggestion

Samuel Murrayy
 

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


moderated Re: Feature request/enhancement -- Enlarge the vertical size of the "Your Groups" pull-down menu #suggestion

Samuel Murrayy
 

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


moderated Re: The Groups.io Beta Group - Digest #668

Laurence Marks
 

At IBM, the response to a bug report where the product didn't perform to user expectations was "Working as Designed," often abbreviated to "WAD."

No matter what you do, you're always going to have that situation.

Larry

--
Larry Marks


moderated Feature request/enhancement -- Enlarge the vertical size of the "Your Groups" pull-down menu #suggestion

 

 
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


moderated Re: The Groups.io Beta Group - Digest #668

KWKloeber
 


>>> superfluous or confusing<<<

If you think in a logical linear fashion, not at all. 

A bug isn’t confirmed until Mark receives the email and verifies it’s a bug (or is not.)

The prefix (ie, qualifier) “bug”report@ is technically incorrect because no one knows when submitting it that’s it’s a bug (vs potential) until it’s verified to be as such by Mark. 
Someone could think,  “I don’t know whether it’s a true bug or user error, or machine/browser error, so I better not use that address.”

(Subsequent silence on this doesn’t indicate agreement with left coast logic.  LOL)



On Jan 2, 2020, at 2:25 PM, main@beta.groups.io <digestnoreply@groups.io> wrote:

superfluous or confusing


moderated Re: Feature requests/Canny after two weeks

 

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


On Jan 2, 2020, at 11:21 AM, Ken Kloeber via Groups.Io <KWKloeber@...> wrote:

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

--
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: Feature requests/Canny after two weeks

KWKloeber
 

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


moderated Re: Members Download information #suggestion

Duane
 

On Thu, Jan 2, 2020 at 08:39 AM, Duane wrote:
and "member_notes"
Drat, faulty memory.  Should be "moderator_notes".

Duane


moderated Members Download information #suggestion

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


moderated Re: Feature requests/Canny after two weeks

 

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


On Jan 2, 2020, at 4:51 AM, J_Catlady via Groups.Io <j.olivia.catlady@...> wrote:

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


On Jan 2, 2020, at 1:32 AM, Ken Kloeber via Groups.Io <KWKloeber@...> wrote:

>>>
potential-bug@“ could differentiate general support vs bug reporting.
I don't think a hashtag like that will be effective.<<<

In response to Sandi’s comment about both bugs and support questions addressed to <support@>, <potential-bug@> (or whatever@) would be an address specifically for bugs. 
i.e., @ being common for an email address, not for a (#) hashtag. 
Focus LOL. 



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


--
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: Feature requests/Canny after two weeks

 

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.


On Jan 2, 2020, at 1:38 AM, Ken Kloeber via Groups.Io <KWKloeber@...> wrote:

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

--
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: Feature requests/Canny after two weeks

 

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


On Jan 2, 2020, at 1:32 AM, Ken Kloeber via Groups.Io <KWKloeber@...> wrote:

>>>
potential-bug@“ could differentiate general support vs bug reporting.
I don't think a hashtag like that will be effective.<<<

In response to Sandi’s comment about both bugs and support questions addressed to <support@>, <potential-bug@> (or whatever@) would be an address specifically for bugs. 
i.e., @ being common for an email address, not for a (#) hashtag. 
Focus LOL. 



--
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: Bugs sent to support not generating acknowledgements #Bug about bugs #bug

Sandi D <sandi.asgtechie@...>
 

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.


moderated Joining subgroup via e-mail directly only subscribes user to main group #bug

Samuel Murrayy
 

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


moderated After accepting invite to subgroup, Groups.io tells user to use plus-style address to post #bug

Samuel Murrayy
 

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


moderated Re: Feature requests/Canny after two weeks

KWKloeber
 

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


moderated Re: Feature requests/Canny after two weeks

KWKloeber
 

>>>
potential-bug@“ could differentiate general support vs bug reporting.
I don't think a hashtag like that will be effective.<<<

In response to Sandi’s comment about both bugs and support questions addressed to <support@>, <potential-bug@> (or whatever@) would be an address specifically for bugs. 
i.e., @ being common for an email address, not for a (#) hashtag. 
Focus LOL. 



moderated Re: Feature requests/Canny after two weeks

 

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


moderated Re: Feature requests/Canny after two weeks

KWKloeber
 

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 Mon, Dec 30, 2019 at 01:14 AM, Ken Kloeber wrote:
As far as bugs, aren’t we SUPPOSED TO use “support@“?
Experienced users may know to email Support for bugs but the concept of emailing Support, in general, is a recognized way to ask for help and not specifically for reporting bugs.

As a newbie, I found it extremely difficult to determine if an action (or non action) was a bug or if it was user behaviour or lack of behavior. In one instance, it was complex enough to require 18 GMF posts over 5 days and even then, when "fixed", Shal recommended that I report the behavior to Support so that Mark could determine if a mechanism had failed. However, by then, I no longer had the problem. Thinking it was a Support issue, I had not captured screen shots that I would have if I was reporting a Bug issue. 

I suppose what I am saying is it is very helpful to have a dedicated bug area discussion (or email address) in addition to the feature area discussion.

I can live with known bugs that don't cause havoc and I see no reason to email support if someone else has done so and provided enough data to render a solution. It's helpful to me if I am aware of a known bug. I used to be a software beta tester so I am familiar with reporting relavent data but I see no need to repeatedly report the same data. I would find a bug discussion area interesting and helpful. 

Support to me, is when a user is stumped and needs help to figure out how to do something. Experienced users can generally determine if it's user behaviour or a bug. I have found GMF to be my Support. 

I think of Features as independent of bugs and support but they do often have a relationship with both. For example, when Support responds with a "work around" perhaps a new Feature could offer a direct approach. When known buggy behavior is the result of a certain action, then a new Feature could eliminate the need to use an action known to result in the annoying behavior.

--
Sandi Dickenson
ASG Volunteers Group.<<<

 

 

 


moderated Re: Feature requests/Canny after two weeks

Chris Jones
 

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

5681 - 5700 of 28898