Public feedback discussions

[michellemerrill]

Thanks everyone for your help and patience as we continue to work through how we want to give greater transparency to the feedback you have been giving in this repository and elsewhere. As @isaacs said (#1967), we love the feedback that we get and the ability to discuss early plans with y’all, and want to figure out a way to improve this. Rather than use issues - we are currently looking at expanding the use of discussions in the github/feedback repository. We do this already for some feature areas like GitHub for Mobile, Discussions, and for the lucky folks who are in the Codespaces beta. It’s been working well for those topics so far. Once we’ve decided to work on a related idea we’ll add it to the GitHub public roadmap so that you can track progress.

Given the format change, I’m thinking we start fresh rather than migrate existing issues here. Over time, we may bring over some of the most discussed issues manually but I’m thinking they will naturally come up there. We added a General category for anything that doesn’t fit in the current set of existing, feature-specific categories. On that note, be on the lookout for a few more feature-specific categories to added in the coming weeks.

None of this is set in stone, keen to see what works. So please let me know what you think in the comments below. Otherwise, I look forward to seeing you over in our feedback discussions space.

[TPS]

Quick responses inline below:

Rather than use issues - we are currently looking at expanding the use of discussions in the github/feedback repository.

Much better idea than https:munity/.

Once we’ve decided to work on a related idea we’ll add it to the GitHub public roadmap so that you can track progress.

Thank you! 🙇🏾‍♂️

Given the format change, I’m thinking we start fresh rather than migrate existing issues here. Over time, we may bring over some of the most discussed issues manually but I’m thinking they will naturally come up there.

This wouldn't be acceptable, I expect. If y'all had caught this repo in its infancy, that probably would be ok, but there's many years of emotion (frustration, primarily, but also anger, resignation, hopelessness, &c) & good ideas recorded here that should be better acknowledged than throwing it all out & expecting folks to re-request — that's the kind of thought process that would spawn an issue here!

We added a General category for anything that doesn’t fit in the current set of existing, feature-specific categories. On that note, be on the lookout for a few more feature-specific categories to added in the coming weeks.

An excellent start!

None of this is set in stone, keen to see what works. So please let me know what you think in the comments below. Otherwise, I look forward to seeing you over in our feedback discussions space.

@ALL Please do respond!

[NightMachinery]

https:munity/ 's major pain point is that if one gets a response at all, it's usually from a human bot who just parrots a prerecorded response and doesn't give any actual support. Otherwise, Discourse is not that worse than Github Issues.

[TPS]

@NightMachinary Discourse is only bad in the GitHub context, because it acts/feels bolted-on (cuz it is), but is just fine for general purpose things (if actually staffed appropriately). Discussions is much more GitHub-like & integrated better for technical aspects.

[michellemerrill]

This wouldn't be acceptable, I expect. If y'all had caught this repo in its infancy, that probably would be ok, but there's many years of emotion (frustration, primarily, but anger, resignation, hopelessness, &c) & good ideas recorded here that should be better acknowledged than throwing it all out & expecting folks to re-request — that's the kind of thought process that would spawn an issue here!

@TPS (and all who might read 😄 ) First, thanks for the input here and keep it coming! Migrating issues from here over to discussions is certainly not out of the question, but in order to act with some speed, we opted to start with the opening of a general category.

On a related note, I am curious about your thoughts on migration qualifiers?

[Levi-Lesches]

Also, quick note to everyone, while adding 👍 to issues works here, make sure to take advantage of the upvote feature in the new GitHub Discussions.

[TPS]

Again, inline responses below.
@ALL, any wrong/inappropriate assumptions I make, please comment to correct.

Migrating issues from here over to discussions is certainly not out of the question

We appreciate it! 🙇🏾‍♂️

but in order to act with some speed, we opted to start with the opening of a general category.

Gotta start somewhere. We'd be ok with baby steps, I'd think, just as long as progress keeps noticeably coming.

On a related note, I am curious about your thoughts on migration qualifiers?

I tried both Googling & querying Wolfram Alpha on "migration qualifiers" & came up nil (imho) on relevant definitions. What do you mean? My thoughts are currently 😖😕😵.

[shenlebantongying]

Why cannot you guys analyze this repo first and deal with some very hot topics that keep reoccurring year after year?

Just click sort and pick the most commented open issues.

A feedback place is a good problem solver, but a bunch of problems is already there:

For example:

• Disable contribution graph https:/isaacs/github/issues?q=is%3Aissue+label%3Acontributions-graph+
• Follow organization
• Mark any merge request as merged (so that maintainer can manually committed patch or fix)
• etc.

If you guys don't dislike some of them, make a FAQ list that explicitly says No.

[michellemerrill]

I tried both Googling & querying Wolfram Alpha on "migration qualifiers" & came up nil (imho) on relevant definitions. What do you mean? My thoughts are currently 😖😕😵.

Qualifiers term was shorthand for a list of determinants for what migrates over (ie. meeting a certain upvote threshold).

[waldyrious]

Why cannot you guys analyze this repo first and deal with some very hot topics that keep reoccurring year after year?

I agree with this sentiment. IMO, expecting the community to do the work of recreating the issues in the new platform, voting on them, and adding the relevant nuances as comments, all over again (which is a LOT of work, as @TPS eloquently described above), without at least making an effort to address the top issues here, is not a graceful way to make a transition from this repo. If that's the way things will go, I think it would be more accurate to describe the new feedback system as a start from scratch, rather than than a continuation of this one.

[TPS]

Why cannot you guys analyze this repo first and deal with some very hot topics that keep reoccurring year after year?

@Levi-Lesches had a fantastic idea for these "migration qualifiers":

In the spirit of "moving issues from one place to another", would it be a good idea for someone on the GH team to write a bot that moves issues to the new discussions? In #1985 they say they wanted to open it before doing that, so I think now would be a good time.

To avoid overflowing the new repo, the bot could only copy issues with more than a certain threshold of 👍, avoid copying "+1" comments, etc.

[TPS]

Also, previously, I'd been triaging the pinned issues via the most 👍ed opened issues.

[TPS]

@michellemerrill Would you mind making an introduction/invitation to reply over @ #6, which is, after all, our canonical issue for exactly this meta discussion?

[TPS]

An idea re: an add'l qualifier: # of issue or repo crosslinks should definitely be added to the weighting, similar to Google's PageRank algorithm.

[Levi-Lesches]

Can we PLEASE add something about this to the readme? I keep responding to people who are annoyed that GitHub hasn't heard them yet (generic "GitHub should do X if they want customers" or "GitHub is making people angry by not having Y" comments). A simple link to the official repo at the top of the readme would do.

And, imo, we should close the ability to create new issues (if possible) or have a bot that auto-responds with a message. If the new official repo is not enough, then we can open this again but people are voicing their opinions in the wrong direction here.

[TPS]

Can we PLEASE add something about this to the readme?… A simple link to the official repo at the top of the readme would do.

If a PR is made, I'd be completely for it.

And, imo, we should close the ability to create new issues (if possible) or have a bot that auto-responds with a message. If the new official repo is not enough, then we can open this again but people are voicing their opinions in the wrong direction here.

An issue template is the best the collaborators could do, I fear. A PR for that, too, would be appreciated.

[Levi-Lesches]

Done. @TPS can you archive this repo? That should make GitHub show a warning and won't let anyone open new issues/etc

[Levi-Lesches]

as this could compromise the quality of ~1,400 issues

I meant to move gradually, if sheer volume is currently a blocker. We've had conversation about which issues should be migrated, but I think it's fair to say that any issue with >500 👍 and recent activity should go; it's the other ones that may need more treatment. So, let's move those first, then go into more obscure issues as you see fit.

[aspiers]

@Levi Lesches commented on July 2, 2021 12:16 AM:

as this could compromise the quality of ~1,400 issues

I meant to move gradually, if sheer volume is currently a blocker.

Ah, I see. I had assumed (and hoped) that the migration would be automated, otherwise how could it be done reliably? But maybe I'm wrong.

We've had conversation about which issues should be migrated, but I think it's fair to say that any issue with >500 👍 and recent activity should go; it's the other ones that may need more treatment. So, let's move those first, then go into more obscure issues as you see fit.

Right. Unfortunately, it seems users are already taking the migration into their own hands, which is entirely understandable and unsurprising but could cause problems if we don't address it quickly. For example community/community#4477 is a copy of the description at the top of #867, which on the surface is a perfectly natural and helpful thing to submit, but it has the unfortunate side effect of totally obscuring #959, which is where all the helpful discussion on that topic has occurred so far. This would most likely lead to a whole bunch of newcomers rehashing much of the same discussions which have already happened - effectively taking several steps backwards. This is exactly the problem about which concerns were expressed by @TPS, by myself, and probably by a few others too, so I hope we can nip it in the bud sooner rather than later.

[aspiers]

I wonder, would it help to create a label to track which isaacs issues already have a sister issue in https:/github/feedback/discussions? @michellemerrill Any thoughts on this?

[Levi-Lesches]

I have a bit of experience writing GitHub bots -- I haven't done any cross-repo work (especially because of permissions levels) but I'd be happy to help if that's needed. The way I see it:

• pick an issue that should be transferred
• choose the comments that should be transferred
  • anything with over a threshold number of upvotes
  • the most recent 5-10
  • Exlcuding "+1" or "bump" comments)
• Open a new discussion with a link to the original discussion here
• Insert the above comments (@mention the authors too)
• repeat a thousand more times

@michellemerrill, if you don't have code yet, I can start working on it. Or if you do, let me know if you want any help. I agree with @aspiers here, speed is key.

Also, once we do this, it's relatively trivial to close new discussions on github/feedback and link to the "canonical" one.

[aspiers]

@aspiers commented on July 2, 2021 10:30 PM:

I wonder, would it help to create a label to track which isaacs issues already have a sister issue in https:/github/feedback/discussions? @michellemerrill Any thoughts on this?

@TPS Would be great to get your thoughts on this idea too.

[TPS]

@aspiers commented on July 2, 2021 10:30 PM:

I wonder, would it help to create a label to track which isaacs issues already have a sister issue in https:/github/feedback/discussions? @michellemerrill Any thoughts on this?

@TPS Would be great to get your thoughts on this idea too.

@aspiers Sorry, missed your invite to respond. 🙇🏾‍♂️

I'd happily make a tag & start applying it everyplace such has happened.

@michellemerrill Do you have a preference what tag precisely (perhaps something like Upvote at GitHub Feedback? Are tags able to embed a link to that discussion directly?) should be used, as to not foul up whatever migration/automation processes are in-development?

[aspiers]

@himu243 commented on July 21, 2021 6:45 AM:

Hi All, I'm not able to see the comments added by reviewer on a Pull Request created neither on Conversation Tab nor on File Changes Tab. Can anyone tell me what can be the reason for it?

Hi @himu243, this is not the right place to ask those kinds of questions as it has nothing to do with this particular issue. Please see #998 which may be the cause of your problem, otherwise you could try starting a discussion in https:/github/feedback/discussions.

[aspiers]

@TPS commented on July 10, 2021 12:05 PM:

@aspiers Sorry, missed your invite to respond. 🙇🏾‍♂️

No worries ;-)

I'd happily make a tag & start applying it everyplace such has happened.

@michellemerrill Do you have a preference what tag precisely (perhaps something like Upvote at GitHub Feedback?

Maybe filed in GitHub Feedback?

Are tags able to embed a link to that discussion directly?

I'm fairly sure they're not able to do that, but ICBW of course.

[TPS]

Maybe Filed in GitHub Feedback?

I like this, but also wanted to explicitly request the upvote, not just following/👍🏾 like here or elseplace.

Are tags able to embed a link to that discussion directly?

I'm fairly sure they're not able to do that, but ICBW of course.

I'm asking for this new functionality as part of the migration effort.

[Levi-Lesches]

@TPS labels are just strings that are reused. If you were to somehow embed links into them, they would be unique, and the repo would have as many different labels as it does issues. I think you can just close the issue, apply the label, and comment the link

[aspiers]

@TPS commented on July 21, 2021 12:12 PM:

Maybe Filed in GitHub Feedback?

I like this, but also wanted to explicitly request the upvote, not just following/👍🏾 like here or elseplace.

Upvotes are certainly helpful, but I'm not sure the text of the label is the right place to do it. Apart from anything else, it's hard to imagine label text which is both succint and clear that it's a request to upvote rather than a statement that it has already been upvoted.

However what we can do is attach a description to the label which explains its meaning, and requests an upvote. This description appears as a tooltip when hovering over the label in the web UI.

Are tags able to embed a link to that discussion directly?

I'm fairly sure they're not able to do that, but ICBW of course.

I'm asking for this new functionality as part of the migration effort.

I suspect that GitHub would say "just use the label description field".

[TPS]

This description appears as a tooltip when hovering over the label in the web UI.

& so is basically useless in most common scenarios, e.g., when reader doesn't perform a non-obvious action or is on mobile. Something more explicit is needed.

[TPS]

but in order to act with some speed, we opted to start with the opening of a general category.

Gotta start somewhere. We'd be ok with baby steps, I'd think, just as long as progress keeps noticeably coming.

@michellemerrill I tried https:/github/roadmap/projects/1?card_filter_query=migrat (as suggested in your OP here), but I don't see any way to publicly track migration actions by y'all. Did I miss something? Users are evidently taking to GitHub/feedback swimmingly, but issue/discussion fragmentation (as predicted above) is an enormous challenge due to so many duplicates, so I 🙏🏾🙇🏾‍♂️ that your efforts are working to keep ahead of them.

[aspiers]

@michellemerrill I agree with @TPS 100% - would be fantastic to have an update here, thanks!

[aspiers]

@TPS commented on July 21, 2021 12:12 PM:

Maybe Filed in GitHub Feedback?

I like this, but also wanted to explicitly request the upvote, not just following/👍🏾 like here or elseplace.

Upon further thought, I see two (admittedly minor) issues with explicitly requesting users to upvote issues:

1. It could create an unnatural bias of votes in favour of issues which are already both in this repo and GitHub Feedback, to the detriment of issues which are either a) only in this repo or b) only in GitHub Feedback.
2. As a more general principle, I'm not sure this repo should be in the business of asking anyone to vote or otherwise lobby on specific issues, as traditionally it has been a neutral place with no agenda other than surfacing issues with GitHub so that they can be discussed and workarounds / resolutions sought. Maybe the only obvious exception is for "meta" issues such as Convince github to create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary) #6, where we have obviously encouraged users to do whatever they can to encourage GitHub to do a better job of listening to its user community.

That's just my personal take though, certainly would understand if others see it differently.

Either way, we really need a label right now, so I've created a new github/feedback label which has a description explaining that it's for both:

1. issues which have also been filed in https:/github/feedback
2. meta-issues about the migration

We can continue bike-shedding about better names for the label if there's an appetite to do that; I have no problem renaming it if we can come up with something better, but let's create a separate issue for it to avoid polluting these other migration meta-issues.

[TPS]

1. It could create an unnatural bias of votes in favour of issues which are already both in this repo and GitHub Feedback, to the detriment of issues which are either a) only in this repo or b) only in GitHub Feedback.

Do remember that it seems to GitHub's eventual plan to deprecate this repo (& Dear GitHub, &c) in favor of GitHub/feedback, so a bias in favor of that is critically needed.

Either way, we really need a label right now, so I've created a new github/feedback label which has a description explaining that it's for both:

Thank you! 🙇🏾‍♂️

I am concerned re: not getting any update from @michellemerrill, &c, on behalf of GitHub, in that I'm 🙏🏾 that they haven't lost interest in migration, as GitHub/feedback seems to going well.

[aspiers]

@TPS commented on August 25, 2021 6:22 PM:

1. It could create an unnatural bias of votes in favour of issues which are already both in this repo and GitHub Feedback, to the detriment of issues which are either a) only in this repo or b) only in GitHub Feedback.

Do remember that it seems to GitHub's eventual plan to deprecate this repo (& Dear GitHub, &c) in favor of GitHub/feedback, so a bias in favor of that is critically needed.

Yes but that's not the bias I'm referring to. I'm concerned with a bias towards issues solely because they happen to be in both places rather than in one. If that happens then the migration process is unfairly skewing attention towards certain issues for reasons totally unrelated to the popularity / importance of those issues.

[aspiers]

I am concerned re: not getting any update from @michellemerrill, &c, on behalf of GitHub, in that I'm 🙏🏾 that they haven't lost interest in migration, as GitHub/feedback seems to going well.

Likewise :-( I wonder if @isaacs himself would be able to help find out what's going on here.

[michellemerrill]

Hey @TPS @aspiers 👋🏼 thanks for the ping here! I am way, way overdue in giving y'all an update. For sure, no interest lost in migration or developing the framework for migration. Admittedly the work has slowed on my end, largely due to workload constraints over the summer months.

A couple of thoughts on next steps -- not in any particular order:

• We introduced an auto-notifier when new issues are opened that encourages redirects to feedback/discussions. The next step here would be disabling new issues on this repo.
• Of the 1.4k issues open, I suspect there is yet some duplication…and some stale …and some that need to be closed because the work is complete. It will likely take the help of many eyes to review these issues as a final scrub to ensure we have a good collection for migration.
• Migration framework — the BIG question, what qualifies for migration. Next steps here (still) include developing priority scoring-- but even beyond this is preparing GitHub/feedback for categorization, etc. as well as the how-to of migrating (recognizing on both of these fronts, there has already been a healthy discussion here).

[aspiers]

No worries @michellemerrill, great to hear from you and that the migration is still on the cards!

@Michelle Merrill commented on August 26, 2021 11:24 PM:

A couple of thoughts on next steps -- not in any particular order:

• We introduced an auto-notifier when new issues are opened that encourages redirects to feedback/discussions. The next step here would be disabling new issues on this repo.

Sounds good.

• Of the 1.4k issues open, I suspect there is yet some duplication…and some stale …and some that need to be closed because the work is complete. It will likely take the help of many eyes to review these issues as a final scrub to ensure we have a good collection for migration.

I think this repo has been pretty well curated so I'm hopeful there isn't too much duplication, and generally issues get closed if they are resolved (e.g. by an update from GitHub).

• Migration framework — the BIG question, what qualifies for migration. Next steps here (still) include developing priority scoring-- but even beyond this is preparing GitHub/feedback for categorization, etc. as well as the how-to of migrating (recognizing on both of these fronts, there has already been a healthy discussion here).

Right.

While I'm generally in favour of the migration, I do want to stress how strongly I believe it should not compromise any of the key strengths this repository has exhibited until now. I have previously listed which pitfalls absolutely need avoiding, but in particular I want to highlight the last item of that list: that some element of community curation should remain.

The whole point of creating this repository in the first place was that the official channels provided by GitHub at the time (a long time ago) simply weren't good enough. Clearly GitHub has improved by light years since then, and I'm genuinely optimistic that https:/github/feedback/discussions can be a good replacement. But if any serious deficiencies emerge which the community is powerless to correct (e.g. as mentioned in that list, high numbers of duplicate topics, low signal-to-noise ratios, discussions frequently veering off topic or having poor classification / discoverability), then probably we will just want to carry on using this repo, or (even worse) create another alternative to the official offering. And any such fragmentation is clearly counterproductive.

No matter how well GitHub invests in this area, it's obvious from the numbers alone that it will never be able to scale to compete with what its enormous community can offer in terms of supporting each other. So I think it's really important that this migration is treated more as a "making the isaacs/github repo official" exercise rather than a "GitHub taking back control of its lists of known issues" exercise. Hope that makes sense.

[isaacs]

Update: #2035 (comment)