Topics

moderated Feature requests/Canny after two weeks


 

I just want to register my support for this proposal to use Beta as you
describe and drop Canny. It has the added advantage that anyone on Beta who
happens to spot a problem with a proposal can draw attention to it, whereas on
Canny access is restricted so fewer eyes are looking for possible snags.

Jim Fisher

On 26 Dec 2019 at 9:02, Mark Fletcher wrote:

Hi All,

So, it seems that some people are using Canny to submit feature requests
and that it can be a useful tool for doing so. I do see a few drawbacks:

- There are still a bunch of posts to beta that would be more appropriate
instead as Canny feature requests.
- There is no notification of new posts to Canny on beta. So it can be
difficult to know when new things are posted to Canny.
- People who don't run premium groups cannot post to Canny.

I can address the second issue with a custom email summary sent to beta on
a regular basis, but that will require some development effort on my part.
My main problem with Canny is with the first issue; people will still post
feature requests on beta, and the discussion about those feature requests
will still happen on beta.

I thought of another way we could address this, using just the beta
group and hashtags. We could use a designated hashtag for feature requests
(and maybe another for bugs). That would make it easy to address the first
issue above; if someone posts a feature request without the correct
hashtag, I can just add it. To view all feature requests, just filter on
the hashtag. The one main thing that doesn't provide is the ability to sort by
popularity (ie likes). However, I could add something like that to the search
results page (he says without thinking it through completely).

(Also, I would add 'status' hashtags, like #closed, #planned, etc)

What do you think? I'm willing to continue using Canny if you all think
it's a good solution. Or we could switch to something like my proposal. Or
something else if someone has a better idea.

Thanks,
Mark (still on vacation)



--
http://jimellame.tumblr.com - My thoughts on freedom (needs updating)
http://jimella.wordpress.com - political snippets, especially economic policy
http://jimella.livejournal.com - misc. snippets, some political, some not
Forget Google! I search with https://duckduckgo.com which doesn't spy on you


 

Mark,
I like your idea.

Susan B

On Dec 28, 2019, at 6:09 PM, Jim Fisher <@jimella> wrote:

I just want to register my support for this proposal to use Beta as you
describe and drop Canny. It has the added advantage that anyone on Beta who
happens to spot a problem with a proposal can draw attention to it, whereas on
Canny access is restricted so fewer eyes are looking for possible snags.

Jim Fisher

On 26 Dec 2019 at 9:02, Mark Fletcher wrote:

Hi All,

So, it seems that some people are using Canny to submit feature requests
and that it can be a useful tool for doing so. I do see a few drawbacks:

- There are still a bunch of posts to beta that would be more appropriate
instead as Canny feature requests.
- There is no notification of new posts to Canny on beta. So it can be
difficult to know when new things are posted to Canny.
- People who don't run premium groups cannot post to Canny.

I can address the second issue with a custom email summary sent to beta on
a regular basis, but that will require some development effort on my part.
My main problem with Canny is with the first issue; people will still post
feature requests on beta, and the discussion about those feature requests
will still happen on beta.

I thought of another way we could address this, using just the beta
group and hashtags. We could use a designated hashtag for feature requests
(and maybe another for bugs). That would make it easy to address the first
issue above; if someone posts a feature request without the correct
hashtag, I can just add it. To view all feature requests, just filter on
the hashtag. The one main thing that doesn't provide is the ability to sort by
popularity (ie likes). However, I could add something like that to the search
results page (he says without thinking it through completely).

(Also, I would add 'status' hashtags, like #closed, #planned, etc)

What do you think? I'm willing to continue using Canny if you all think
it's a good solution. Or we could switch to something like my proposal. Or
something else if someone has a better idea.

Thanks,
Mark (still on vacation)



--
http://jimellame.tumblr.com - My thoughts on freedom (needs updating)
http://jimella.wordpress.com - political snippets, especially economic policy
http://jimella.livejournal.com - misc. snippets, some political, some not
Forget Google! I search with https://duckduckgo.com which doesn't spy on you






 

I've been around here for a while now; just about two weeks shy of five years if beta's records are correct. I've learned a lot and I occasionally throw a comment into a discussion. Some days it doesn't get thrown back! And yes, I'm one of those people who pay for Premium groups. Right now three of them, but I hope to convert one back to regular in another year or so. I also have a few regular groups that are not real active. I try not to pester support, as they have enough to do already. Beta and GMF have handled 95% of my needs quite simply and effectively.

I haven't looked at Canny. It's just one more thing I haven't had time for. I try to keep up with beta, and generally do well enough, although I often get in at the end of discussions. What's important here for me is that I DO routinely read beta. And I try to browse all the beta posts, because I know that thread drift will often obscure a good idea.

If I find what I think might be a bug, I bring it to GMF first. If I get feedback that there's a reason for something, I like to know first before bothering Mark with it. For me, GMF acts as that filter. And I'd prefer that enhancements be discussed here in beta rather than Canny - because I know I won't make it there.

I don't use hashtags, but could use them here, I guess, if I have to, I suppose, eventually. Having a menu of primary hashtags would help that, or a responder to my few original posts could add a hashtag.

As for GMF, it is what it is. Don't screw around with renaming it and confuse the thousands who come looking for assistance. The worst thing you can do to a successful business is rename it. As for Group Help - sorry, never heard of it before this. And knowing the knowledge base that's on GMF, I'll keep going there - AND coming here.

Dano


KWKloeber
 

On Thu, Dec 26, 2019 at 12:03 PM, Mark Fletcher wrote:
What do you think?
i think any method that eliminates, or separates, unpaid groups from contributing feature requests is both inefficient and harmful to the desired end result.  Are requests from paid groups “better” / “more valid” than from unpaid?  Besides, the added overhead having to deal with two paths seems inefficient.  No reason not to use one group for both paid/unpaid requests.  As far as bugs, aren’t we SUPPOSED TO use “support@“?

why the need to clog up a forum for those?
I find #s to be not much more than a P.I.T.A. (though can go with any flow.). But if there’s truly some need to differentiate/separate why not a (should b) group beta-feature requests and a group beta-bugs?


 

On Sun, Dec 29, 2019 at 10:14 PM, Ken Kloeber wrote:
Are requests from paid groups “better” / “more valid” than from unpaid?
That is a very good point and one that occurred to me as well. There can be owners of unpaid groups who've been around a long time and are very familiar with the product and capable of making extremely valuable suggestions based on a deep knowledge and understanding of what is and isn't already there. And on the other hand there can be owners of paid groups (especially for the first year after the yahoo rescue) who are totally new to groups.io and will tend to make less informed suggestions, at least for awhile. And everything in between. There is no correlation between having a premium group and being capable, for whatever reason, of making really useful suggestions.
 
--
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


txercoupemuseum.org
 


I think we need to consider some simple facts.  Between group hosting providers NONE seems to have a monopoly on MOST popular “features”.  

Paid group funds pay ALL Groups.io bills and are the sole source of associated salaries/profits.  That means paid groups FINANCIALLY SUPPORT the presence and operational expenses of all unpaid groups at present.

Of all the ideas thrown on the wall before Mark by unsung geniuses, VERY VERY FEW “stick”.  In the majority of cases there is already some way to accomplish almost anything truly necessary with the many tools presently available.  Related efforts of unpaid volunteers do NOT mean that these good people consider their considerable contribution(s) without value.  

People today live in a society so affluent that few perceive the very real difference between a “want” and a “need”.  Because there are NO unpaid group dollars, is it not obvious that feature requests from paid groups ARE “more valid” when apportioning clearly finite resources.    

Every “feature request” is indistinguishable from a complaint about the existing product to either resolve or ignore.  It is entirely appropriate that practical "feature requests" from PAID groups of reasonable size receive priority.   

Perhaps a forum could be established specifically for unpaid groups where their genuine unmet “needs” could be identified and debated SEPARATELY.  If ANY were to result in a specific and collectively agreed “scope of work” to present to Mark, I’m sure he could and would estimate funding necessary to make it happen.  Just as at the post office, faster service costs more.

This would quickly separate the “wheat” from the “chaff”.  We don’t go to the grocery store or the car dealership to convince those there how deserving we are.  We go out into the world and trade our time in some form for money to exchange for what we need AND can afford.
I suggest this path to be the most reasonable and practical “equity” possible between the two types of groups.  

In each case, such “new features” as thus emerge CAN then made available to one and all (or not), as deemed appropriate by management.   

Best!

WRB

— 
 


On Thu, Dec 26, 2019 at 12:03 PM, Mark Fletcher wrote:
What do you think?


 

On Mon, Dec 30, 2019 at 12:45 AM, txercoupemuseum.org wrote:
Every “feature request” is indistinguishable from a complaint about the existing product to either resolve or ignore.  It is entirely appropriate that practical "feature requests" from PAID groups of reasonable size receive priority.  
For little individual desires, for help/support, and possibly for bug fixing, then yes, I agree that people with premium groups should have priority. But as an owner of a premium group, I think I can legitimately say that I disagree that I and my paying fellow groups should get priority in having our feature suggestions implemented or considered (I am purposely calling them suggestions, not requests). I, and I know that some others here as well, frequently make comments and suggestions based on wanting groups.io to be a good product, not only because we want some particular feature for our own particular groups. Go figure. 
 
--
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


kr402
 

someone making a suggestion is simply that someone making a suggestion,
regardless of the type of group they are in.



txercoupemuseum.org
 

I respect your expressed opinions and would hope to deserve inclusion among those described in your last sentence.  But we must not let any "pursuit of perfection” blind us to how very good the existing “product” already is.  

There ARE circumstances necessitating financial discrimination.  When Yahoo went into meltdown, the leader of Groups.io quickly understood he couldn’t continue “business as before”.  He acted in a timely manner to secure the funding necessary to successfully ride that tiger.  His organization is unarguably more capable and better “positioned” for the long run as a direct result of his competence.  

Those who take the time to frame and submit a specific “suggestion” may or may not be aware that their perspective is seldom the same as the Groups.io people whose burden it is to glean from what is said precisely what is actually meant; and how difficult (expensive, in a coding sense) this will be to achieve.  The average quality of “suggestions" decreases as overall quantity (and the labor expended dealing with them) increases. 

Reading Donald Rumsfeld enlightened me that (with apologies to any inaccuracy): “There are things we know and things we don’t know.  But there are also things we don’t know we know and things we don’t know we don’t know.”  In such context, yes, most of us “throw our dice” in relative ignorance with the very best of intention(s). 

In the end, whatever is “requested” or “suggested” is ultimately acted upon in some manner or ignored.  It is either “approved” or it is not.  The words used do not change the reality.  

WRB

— 

On Dec 30, 2019, at 3:04 AM, J_Catlady <j.olivia.catlady@...> wrote:

On Mon, Dec 30, 2019 at 12:45 AM, txercoupemuseum.org wrote:
Every “feature request” is indistinguishable from a complaint about the existing product to either resolve or ignore.  It is entirely appropriate that practical "feature requests" from PAID groups of reasonable size receive priority.  
For little individual desires, for help/support, and possibly for bug fixing, then yes, I agree that people with premium groups should have priority. But as an owner of a premium group, I think I can legitimately say that I disagree that I and my paying fellow groups should get priority in having our feature suggestions implemented or considered (I am purposely calling them suggestions, not requests). I, and I know that some others here as well, frequently make comments and suggestions based on wanting groups.io to be a good product, not only because we want some particular feature for our own particular groups. Go figure. 
 
--
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



Sandi D
 

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.


 

On Mon, Dec 30, 2019 at 02:46 AM, txercoupemuseum.org wrote:
When Yahoo went into meltdown, the leader of Groups.io quickly understood he couldn’t continue “business as before”.  He acted in a timely manner to secure the funding necessary
And I actually was one of the first to advocate for that at the time. The fact that Mark needs - and highly deserves - to make a living, and a good one, does not really bear on this except possibly as a marketing issue, in that he can advertise that paying for premium comes with the priority for feature requests. Prioritizing feature suggestions from paid users, and bumping suggestions from non-paying users lower down on the basis of the user, not their suggestion, does not necessarily create a better overall product.
 
--
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


Marv Waschke
 

Canny is a nice interface, but, for me, it makes keeping up with groups.io more difficult because it is yet another thing to monitor. Using hashtags in beta to separate new feature requests, bugs, etc. may be a convenience for Mark when he is planning his work agenda. If he finds them useful, I'm in favor.
Best, Marv


Samuel Murrayy
 

On Thu, Dec 26, 2019 at 06:03 PM, Mark Fletcher wrote:
- People who don't run premium groups cannot post to Canny.
This is an odd restriction.  I understand that you might want to give people who pay money some kind of priority attention w.r.t. feature requests, but generally feature requests should be evaluated on their individual merits, and people who don't pay can also have some good ideas (and be able to formulate it properly).

I thought of another way we could address this, using just the beta group and hashtags.
How hashtags work and the fact that they can/should be used, may be clear for you and for people who regularly frequent group where hashtags are being used, but if you want to rely on hashtags alone to separate bug reports from feature requests and from support requests, you're going to be only partly successful.  On the other hand, I agree with what others have said: many bug reports are actually feature requests, and vice versa, so it's useful to deal with both types of tickets in a single system (not in e.g. two separate mailing lists, unless there is a feature whereby a thread can be "moved" to another mailing list).

Is there a reason why you don't have two subgroups, RFE@beta and BUG@beta, where people can post feature requests and bug reports?  People will still post feature requests and bug reports to the main group, but a lot of RFEs and bug reports will end up in the right place, and you can hope that such posts will be better formulated, too.  I think that sometimes if people know that they're posting to a bug-report specific list, they'll formulate their bug reports better, whereas if they post to a general discussion group, they tend to let their fingers wander along with their thoughts.

If someone posts a feature request without the correct hashtag, I can just add it.
I thought that hashtags only "work" if they are applied to the first post of a topic.  Wouldn't this mean that you would have to turn beta into a moderated group, so that you can add hashtags before the messages go out?  Or are you (and moderators in general) able to add hashtags to posts after they've been posted?

Samuel


Chris Jones
 

On Wed, Jan 1, 2020 at 01:03 PM, Samuel Murray wrote:
I thought that hashtags only "work" if they are applied to the first post of a topic.  Wouldn't this mean that you would have to turn beta into a moderated group, so that you can add hashtags before the messages go out?
Members can add hashtags when they start a topic. However, at present the library of hashtags is (IMHO) a complete mess that is badly in need of rationalisation; if you don't believe me go and look at it.

I am working towards putting a semi - finite proposal to Mark, probably within the next day or two. As it will be proposed via beta I daresay it might trigger one or two howls of protest but that's a risk I am prepared to take.

Watch this space... although I might make it a new topic.

Chris


Dave Sergeant
 

And hashtags also only really work for viewing on the web. Email
recipients may gain some advantage but the threaded views in email
clients largely make them superfluous - if only people would use the
threading features of their email clients of course, many do not (and
hashtags won't help them either).

Although hashtags are occasionally used in the groups I own they are
few and far between. Most people just don't know what they are about
(myself included...).

Dave

On 1 Jan 2020 at 5:03, Samuel Murray wrote:

I thought that hashtags only "work" if they are applied to the first
post of a topic.  Wouldn't this mean that you would have to turn beta
into a moderated group, so that you can add hashtags before the messages
go out?  Or are you (and moderators in general) able to add hashtags to
posts after they've been posted?

http://davesergeant.com


 

On Wed, Jan 1, 2020 at 05:03 AM, Samuel Murray wrote:
I thought that hashtags only "work" if they are applied to the first post of a topic.  Wouldn't this mean that you would have to turn beta into a moderated group, so that you can add hashtags before the messages go out?
You could use the MF feature ("moderate the first message of every topic this member starts"), but you would have to apply it to every member, and that is practical only if you make MF a group option, which it currently is not (I've requested it on Canny). Another option would be to require that every topic include at least one hashtag (this is already a group option) and allow only moderators to create hashtags. 
 
--
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


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


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

 

 

 


 

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


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.