Provide a mechanism for users to say thanks or provide positive feedback on features. #10327

@DHowett commented on GitHub (Sep 10, 2020):

Thanks for the kind words 😄 The team always loves getting feedback, be it kudos or bug reports, so I very much appreciate your suggestion.

@cinnamon-msft Is there somewhere we can collect things like this? I don't necessarily want to make another place that people might file bugs (which we're prone to missing), but it might be nice to aggregate some of these things.

@DHowett commented on GitHub (Sep 10, 2020): Thanks for the kind words :smile: The team always loves getting feedback, be it kudos or bug reports, so I very much appreciate your suggestion. @cinnamon-msft Is there somewhere we can collect things like this? I don't necessarily want to make another place that people might file bugs (which we're prone to missing), but it might be nice to aggregate some of these things.

claunia commented

@cinnamon-msft commented on GitHub (Sep 16, 2020):

I'm hesitant to add another item to the dropdown list inside the app. However, we could pin a "positivity" issue to the top of the issues list, so clicking the Feedback button would still bring you to it.

@cinnamon-msft commented on GitHub (Sep 16, 2020): I'm hesitant to add another item to the dropdown list inside the app. However, we could pin a "positivity" issue to the top of the issues list, so clicking the Feedback button would still bring you to it.

claunia commented

@WSLUser commented on GitHub (Sep 16, 2020):

What about doing what the WSL team did and add a Discussion tab to the repo?

@WSLUser commented on GitHub (Sep 16, 2020): What about doing what the WSL team did and add a Discussion tab to the repo?

claunia commented

@ghost commented on GitHub (Nov 11, 2020):

GitHub Discussions is a beta feature. But I think the Terminal team can request early access.

@ghost commented on GitHub (Nov 11, 2020): GitHub Discussions is a beta feature. But I think the Terminal team can request early access.

claunia commented

@WSLUser commented on GitHub (Nov 11, 2020):

Again WSL repo has it. So Terminal can too

@WSLUser commented on GitHub (Nov 11, 2020): Again WSL repo has it. So Terminal can too

claunia commented

@DHowett commented on GitHub (Nov 11, 2020):

Well, since you mentioned WSL. I'm not sure that this is representative of the kind of content we'd want on our discussions page:

That's just a separate bug tracker that looks like a forum but is still just as filled with bug reports as the actual bug tracker.

@DHowett commented on GitHub (Nov 11, 2020): Well, since you mentioned WSL. I'm not sure that this is representative of the kind of content we'd want on our discussions page: ![image](https://user-images.githubusercontent.com/189190/98864185-5a726f80-241e-11eb-9db9-04271f3000ed.png) That's just a separate bug tracker that looks like a forum but is still just as filled with bug reports as the _actual bug tracker_.

claunia commented

@WSLUser commented on GitHub (Nov 12, 2020):

Yeah I noticed they migrated some issues to the discussions (looks like any issue that had been issued the discussion tag). I'm sure we can lay some ground rules on what should and shouldn't be placed in Discussions tab. One of the discussions can be dedicated to resolving the specific issue here.

@WSLUser commented on GitHub (Nov 12, 2020): Yeah I noticed they migrated some issues to the discussions (looks like any issue that had been issued the discussion tag). I'm sure we can lay some ground rules on what should and shouldn't be placed in Discussions tab. One of the discussions can be dedicated to resolving the specific issue here.

claunia commented

@ghost commented on GitHub (Nov 24, 2020):

They are not really bugs but they are questions like in Stack Overflow

@ghost commented on GitHub (Nov 24, 2020): They are not really bugs but they are questions like in Stack Overflow

claunia commented

@Don-Vito commented on GitHub (Nov 24, 2020):

I agree with Dustin that having an open discussion page might fork the issue tracker.

Do we believe the tools for discussions and answering questions that we have today are not good enough for the target audience? I personally feel they are OK (after all I am managing a discussion with you right now).

Going back to the original idea, as a new member of community (and a veteran user of Terminal 😊) I personally miss a way to express my opinion. And when I want to provide a feedback:

I don't really want to discuss with the entire community on how terribly wrong I am to not appreciate some default or animation.
I also don't want to learn that there is a duplicate discussion from 5 years ago that is idle for the last year (that I wouldn't find even with Azure AI).

When I have an idea and want to hear back I open an issue here.

So what I need is a way to provide the following one-way messages:

Feedback for features that exist
Voting for big changes that are planned to affect my experience by default, like default features, changes in look-n-feel, installation, etc. E.g., I wish we had a poll for MRU vs InOrder tabs to understand what should be a default for new installations.

@Don-Vito commented on GitHub (Nov 24, 2020): I agree with Dustin that having an open discussion page might fork the issue tracker. Do we believe the tools for discussions and answering questions that we have today are not good enough for the target audience? I personally feel they are OK (after all I am managing a discussion with you right now). Going back to the original idea, as a new member of community (and a veteran user of Terminal :blush:) I personally miss a way to express my opinion. And when I want to provide a feedback: 1. I don't really want to discuss with the entire community on how terribly wrong I am to not appreciate some default or animation. 2. I also don't want to learn that there is a duplicate discussion from 5 years ago that is idle for the last year (that I wouldn't find even with Azure AI). When I have an idea and want to hear back I open an issue here. So what I need is a way to provide the following one-way messages: 1. Feedback for features that exist 2. Voting for big changes that are planned to affect my experience by default, like default features, changes in look-n-feel, installation, etc. E.g., I wish we had a poll for MRU vs InOrder tabs to understand what should be a default for new installations.

claunia commented

@ghost commented on GitHub (Nov 24, 2020):

Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it.

@ghost commented on GitHub (Nov 24, 2020): Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it.

claunia commented

@Don-Vito commented on GitHub (Nov 24, 2020):

Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it.

IMHO this approach will work as long as you have several dozens of such discussions. Afterwards we will have pages and we will still need to do the same search we have today.. unless I am missing something 😊

@Don-Vito commented on GitHub (Nov 24, 2020): > > > Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it. IMHO this approach will work as long as you have several dozens of such discussions. Afterwards we will have pages and we will still need to do the same search we have today.. unless I am missing something :blush:

claunia commented

@ghost commented on GitHub (Nov 24, 2020):

Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it.

IMHO this approach will work as long as you have several dozens of such discussions. Afterwards we will have pages and we will still need to do the same search we have today.. unless I am missing something 😊

Why do you think Stack Overflow is better than Issues for asking questions/finding answers? Same thing essentially 😊

@ghost commented on GitHub (Nov 24, 2020): > > Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it. > > IMHO this approach will work as long as you have several dozens of such discussions. Afterwards we will have pages and we will still need to do the same search we have today.. unless I am missing something 😊 Why do you think Stack Overflow is better than Issues for asking questions/finding answers? Same thing essentially 😊

claunia commented

@Don-Vito commented on GitHub (Nov 24, 2020):

Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it.

IMHO this approach will work as long as you have several dozens of such discussions. Afterwards we will have pages and we will still need to do the same search we have today.. unless I am missing something 😊

Why do you think Stack Overflow is better than Issues for asking questions/finding answers? Same thing essentially 😊

Mostly because Google search provides you a preview 😝
In many cases there is not another choice as product / tracker / community are closed (or "hating")

But yeah, in many cases it works and better searchable. However the question is does it justify the a risk for splitting the tracker?
And if we do feel strong about it, than probably it should be StackOverflow 😄

@Don-Vito commented on GitHub (Nov 24, 2020): > > > > > Look at most of issues with Issue-Question label, most of them are closed after they are answered. People who have the same question might not check the closed issues. But with Discussions, you can find both the questions and answers easily because their is no "closing" or "reopening". People just find it when they search for it. > > > > > > IMHO this approach will work as long as you have several dozens of such discussions. Afterwards we will have pages and we will still need to do the same search we have today.. unless I am missing something 😊 > > Why do you think Stack Overflow is better than Issues for asking questions/finding answers? Same thing essentially 😊 1. Mostly because Google search provides you a preview 😝 2. In many cases there is not another choice as product / tracker / community are closed (or "hating") But yeah, in many cases it works and better searchable. However the question is does it justify the a risk for splitting the tracker? And if we do feel strong about it, than probably it should be StackOverflow :smile:

claunia commented

@ghost commented on GitHub (Nov 24, 2020):

In many cases there is not another choice as product / tracker / community are closed (or "hating")

You can restrict commenting to collaborators as you could do with Issues

However the question is does it justify the a risk for splitting the tracker?

It is not a bug tracker

probably it should be StackOverflow 😄

I don't mind it being Stack Overflow or Reddit or whatever

@ghost commented on GitHub (Nov 24, 2020): > In many cases there is not another choice as product / tracker / community are closed (or "hating") You *can* restrict commenting to collaborators as you could do with Issues > However the question is does it justify the a risk for splitting the tracker? It is *not* a bug tracker > probably it should be StackOverflow 😄 I don't mind it being Stack Overflow or Reddit or whatever

claunia commented

@Don-Vito commented on GitHub (Nov 24, 2020):

You can restrict commenting to collaborators as you could do with Issues

What I meant is that sometimes people ask in StackOverflow because they don't feel comfortable to ask the community.. that in some projects is not really nice with "noobs"

@Don-Vito commented on GitHub (Nov 24, 2020): > > You _can_ restrict commenting to collaborators as you could do with Issues > What I meant is that sometimes people ask in StackOverflow because they don't feel comfortable to ask the community.. that in some projects is not really nice with "noobs"

claunia commented

@ghost commented on GitHub (Nov 24, 2020):

You can restrict commenting to collaborators as you could do with Issues

What I meant is that sometimes people ask in StackOverflow because they don't feel comfortable to ask the community.. that in some projects is not really nice with "noobs"

Valid concern. But let's see what the core team thinks about our discussions so far.

@ghost commented on GitHub (Nov 24, 2020): > > You _can_ restrict commenting to collaborators as you could do with Issues > > What I meant is that sometimes people ask in StackOverflow because they don't feel comfortable to ask the community.. that in some projects is not really nice with "noobs" Valid concern. But let's see what the core team thinks about our discussions so far.

claunia commented

@just1a-person commented on GitHub (Dec 11, 2020):

UPDATE: GitHub Discussions can now be enabled in the Repository Settings

@Don-Vito No one from the team seems to be interested in our conversation 😄

@just1a-person commented on GitHub (Dec 11, 2020): UPDATE: GitHub Discussions can now be enabled in the Repository Settings @Don-Vito No one from the team seems to be interested in our conversation 😄

claunia commented

@zadjii-msft commented on GitHub (Dec 11, 2020):

I'm sorry, I just don't think I see the value in Discussions. To me, it looks like another fragmented place for people to ask duplicate questions. I honestly really doubt that the people who can't search the one giant list of everything will be able to figure out searching in both locations. It raises questions like "what's an issue vs discussion?". It creates another list of things that we'll have to ensure to triage regularly, instead of having all the answers in one place.

Maybe a discussion is an issue. Then we need to convert the discussion back to an issue - how does that work? How are the comments maintained?

It also creates two different UX's for communicating on GH - right now in an issue, everything is in one list. With discussions, there's top level comments, and those can have replies. I guarantee you that people will reply to other top-level comments in their own top-level comment.

IDK, this just doesn't seem valuable to me.

@zadjii-msft commented on GitHub (Dec 11, 2020): I'm sorry, I just don't think I see the value in Discussions. To me, it looks like another fragmented place for people to ask duplicate questions. I honestly really doubt that the people who can't search the _one giant list of everything_ will be able to figure out searching in _both_ locations. It raises questions like "what's an issue vs discussion?". It creates another list of things that we'll have to ensure to triage regularly, instead of having all the answers in one place. Maybe a discussion _is_ an issue. Then we need to convert the discussion back to an issue - how does _that_ work? How are the comments maintained? It also creates two different UX's for communicating on GH - right now in an issue, everything is in one list. With discussions, there's top level comments, and those can have replies. I guarantee you that people will reply to other top-level comments _in their own top-level comment_. IDK, this just doesn't seem valuable to me.

claunia commented

@just1a-person commented on GitHub (Dec 11, 2020):

@zadjii-msft If you feel that way, we can consider other alternative solutions for this issue

@just1a-person commented on GitHub (Dec 11, 2020): @zadjii-msft If you feel that way, we can consider other alternative solutions for *this* issue

claunia commented

@NeilMacMullen commented on GitHub (Dec 11, 2020):

This topic seems to have drifted quite a bit. The original suggestion was simply to provide an low-friction way for users to express +positive+ feedback. It's clearly inappropriate to raise a github issue for that purpose since those tend to be associated with problems or change-requests. FWIW I don't think there's a lot of added value in allowing discussion around positive comments either - I just thought it would be nice for the development team to see that people appreciated the product.

@NeilMacMullen commented on GitHub (Dec 11, 2020): This topic seems to have drifted quite a bit. The _original_ suggestion was simply to provide an low-friction way for users to express +positive+ feedback. It's clearly inappropriate to raise a github issue for that purpose since those tend to be associated with problems or change-requests. FWIW I don't think there's a lot of added value in allowing discussion around positive comments either - I just thought it would be nice for the development team to see that people appreciated the product.

claunia commented

@just1a-person commented on GitHub (Dec 11, 2020):

How about one issue thread created just for this and people can drop in their positive feedback into it?

@just1a-person commented on GitHub (Dec 11, 2020): How about *one* issue thread created just for this and people can drop in their positive feedback into it?

claunia commented

@NeilMacMullen commented on GitHub (Dec 11, 2020):

Let me put it this way ... :-)

"As a user of the terminal I would like to be able to quickly offer positive comments about the product instead of being forced to raise a scary looking bug-report when I click on the Feedback menu item"

@NeilMacMullen commented on GitHub (Dec 11, 2020): Let me put it this way ... :-) "_As a user_ of the terminal I would like to be able to quickly offer positive comments about the product instead of being forced to raise a scary looking **bug-report** when I click on the Feedback menu item"

claunia commented

@just1a-person commented on GitHub (Dec 12, 2020):

Do you remember the issue options config PR that I did. We can add an option like "General Feedback" that links to an issue thread like I mentioned before.

When they click on feedback, they will be dropped into https://github.com/microsoft/terminal/issues/new/choose where they will find this option

@just1a-person commented on GitHub (Dec 12, 2020): Do you remember the issue options config PR that I did. We can add an option like "General Feedback" that links to an issue thread like I mentioned before. When they click on feedback, they will be dropped into https://github.com/microsoft/terminal/issues/new/choose where they will find this option

claunia commented

@just1a-person commented on GitHub (Jan 10, 2021):

Hey wait! Isn't Feedback Hub the best place for the original ask?

@just1a-person commented on GitHub (Jan 10, 2021): Hey wait! Isn't Feedback Hub the best place for the original ask?

claunia commented