Convince github to create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary)

[isaacs]

Just what the title says.

I want to post issues for github.com on github.com, and discuss them with other github users, so that's why this repo exists. But it shouldn't exist. Github should take this over, and make it a thing.

This is valuable for all the same reasons why public issues forums on open source projects and other websites are valuable: it allows users to discuss and refine a use case that they're trying to get help with, allows us to help each other, and then when githubbers respond, it is clear that it's an issue that's being worked on and planned, so we don't feel ignored or neglected.

Of course, people often email support@github.com with issues about their credit cards, usernames, ssh keys, and other things that might contain private info. So it would take some care to help ensure that doesn't happen. Perhaps it would be worthwhile to add a feature to github issues that filters out likely private information, like anything matching /{[0-9]{4} ?){4}/ or whatnot could be replaced with XXXX XXXX XXXX XXXX.

[tekkub]

I just wanted to drop a quick reply so you'd know that we have noticed what you've created here. In the past we've dabbled with a number of different public forums and issue trackers, but for various reasons have migrated to providing only direct private support to users. We hope that anyone who stumbles upon this repo know that they can contact us directly with any issues or suggestions they have. We welcome any and all feedback.

That being said, I hope you understand that we may not keep a very close eye on this tracker as it is not an officially sanctioned place for GitHub feedback. You've put together a very nice README that communicates your intent and that you're not associated with GitHub in any way, but the repo name itself may breed confusion among users who never see that README. I'd like to suggest you rename the repo to something like suggestions-for-github to help clear up that ambiguity.

Love and octocats,
--tek

[isaacs]

In the past we've dabbled with a number of different public forums and issue trackers, but for various reasons have migrated to providing only direct private support to users.

Sure. I've heard that before, numerous times, from you and other GitHubbers in our private email conversations.

And I think that is 100% the wrong decision for your users.

1. Since creating this repository, two of my issues have been addressed through creative ideas of other GitHub users. There is simply no way that could have happened without a public conversation. I would think that GitHub would care about this, not just "notice" it.
2. There's no way for me to keep track of the issues that I send to GitHub. That is, I actually forget that I've sent a feature request, bug report, or annoying UI glitch to you guys. That's really why I set up this repository, so that I can track my own requests. When I privately report an issue to GitHub, I don't get even so much as a tracking ID to refer to in subsequent conversations. The helpdesk at a typical airline, telecom, or insurance company does this better.
3. There is no visibility into the opinions of other GitHub users of a suggestion. If I suggest something that most users would be super annoyed by, well, you might know that, but I probably never will. Since starting this repository, I've gotten a lot of feedback from other GitHub users about my own suggestions, which I never would have known otherwise. In at least one case, another GitHub user strongly disagreed with my point of view, and it was a very enlightening conversation.
4. There is zero visibility into the opinions of GitHub about my suggestions, even! When I suggested (via email) that GitHub needs to use a public issue tracker in the way that your users use public issue trackers, I was told that GitHubbers "use the shit out of" Issues. However, the whole point of a public issue tracker is that it adds visibility into the software maintenance process. Feedback is public, and users interact with one another. GitHub doesn't do this with github.com, so no matter how much shit is used out of Issues, it's not being used on your actual product in the ways that your product's users are using your product on their products.

The fact that you can only say "various reasons" for not providing a public support forum is part of the problem. GitHub is a crucial part of the open source software community, but is run in an even more closed-door fashion than Microsoft or Oracle. Suggestions are taken under advisement, processed through an internal cadre of product managers and user experience experts, and software developers, and then handed down to the users in releases that bear no direct connection to the initial request.

we may not keep a very close eye on this tracker as it is not an officially sanctioned place for GitHub feedback.

I don't expect anyone at GitHub to keep a close eye on this tracker. But, if you're smart, and care, you will see that it's a good idea to pay attention to the ways in which your frustrated users go out of their way to make their feedback as useful as possible.

I have not seen any compelling reasons for not having a public issue tracker for GitHub. I haven't even seen any evidence that GitHub actually accepts that there would be any value to this, or any interest in addressing the potential pitfalls! Do you have any new information about why public issue tracking is so verboten for GitHub, other than the reasons cited in this issue?

[tjfontaine]

I can see GitHub feeling concerned about sensitive information being leaked in a public issue tracker, as it happens public repositories care about that #37

Maybe GitHub is also concerned about the flood from trolls as people pile on complaining about their issue not getting the love they want, public repositories also care about that #38

[chadwhitacre]

Sent the following to support@github.com:

Greetings,

First, please allow me to apologize. I pulled a stunt today where I created a "github.com" repo and added all members of the GitHub organization on GitHub as collaborators. It was wrong of me to spam you all, and I apologize.

The context for my mistake was a conversation I was having with @holman and others on Twitter, and I was hoping we could pick up that conversation here on support@github.com. I'm given to understand that this email channel is Very Important to the way GitHub functions, and is backed by a finely-tuned internal application (maybe this?).

What I'm struggling with is the mismatch between how support works for open-source projects and how support works for GitHub itself. I don't like emailing support@ with issues because it's not public. I can't point other people to the conversation, I can't find out who else shares my problems, and I can't find out how others work around them. It's just not social.

Tweeting @githubhelp is public and social but it isn't a good tool for anything more than the simplest issues.

I learned today of another unofficial GitHub repo, isaacs/github, that is a month older than mine and has 50+ issues in it. I've nipped mine in the bud and started filing issues there instead.

One thought that occurs to me is that maybe an email bridge could be written that proxies messages back and forth between isaacs/github and support@github.com. A hack, and after my misfire this afternoon I'd better not move forward on it without your approval.

What's the state of the internal conversation around this issue? What can I do to help?

chad

---

Chad Whitacre, Founder, Gittip
https://www.gittip.com/
https://twitter.com/whit537
chad@zetaweb.com
+1-412-925-4220 (cell)

[chadwhitacre]

I just went back and actually read this thread. Um, +1. 💃

[chadwhitacre]

Response from @nuclearsandwich:

Hi Chad,

The reason we handle issues on a one-on-one basis is because unlike an open source project, the individuals reporting bugs to GitHub.com can't check the source. So if two people report the same symptoms, it's not always a sure bet the issues are related. Where workarounds are suggested by staff, they are likely temporary measures tailored to a specific situation and the last thing we want is a permanent thread online where a GitHubber tells someone they need to pet the monkey while walking the dog or their cake won't bake because of a bug with the oven. Only to fix that bug and have everyone complain for the next three years because they thought they had to pet the monkey while walking the dog in order to get cake because that's what it said to do in the one thread they found.

The issue comes down to something I refer to as canonical sources of truth. Right now GitHub.com has three, GitHub.com itself, help.github.com, and GitHub Support. These three things are always kept up to date with the latest information about GitHub.com. Before we ship new changes, we have to make sure our sources of truth will be updated with them. Updating GitHub.com is straightforward enough since you can ship your feature or fix as well other changes necessitated by it all at once. Updating the help articles involves contributing new documentation or making sure that screenshots have current visuals for GitHub and keeping support up to date usually happens via Campfire chat or an internal issue.

Adding any kind of official community Issues repository would add a fourth source of truth and one that is far more difficult for us to maintain effectively. Heroku ran into the same issue some time ago and they made the decision to retire their mailing list, after some push back, they instead decided to hand it off to the community so that no Heroku employees are dedicated to moderating the list. They had very similar reasons for doing so that we have for keeping issues routed through our tools: It was too difficult to manage the mailing list as a canonical source of truth and moving from a conversation in a public mailing list to a private thread in a support tool was creating lots of repeat questions and frustrating experiences for Heroku's users and staff alike.

If you want to talk about issues or problems you have with GitHub with other GitHub users, you don't need our permission to do so. Talk about stuff and have ideas, maybe even make some of them a reality using the GitHub API. We can't be active in every user forum, even though we may stop by from time to time and lurk. So when that community discussion becomes so exciting that you want to share it with us, it's time to drop us a line at support@github.com

With regard to your proposed email bridge, please don't do that. You have complete freedom to do whatever with the replies you get from GitHub, though automating that might come back to haunt you the next time you forget your password after a few drinks, but creating a public bridge would give people the impression that whatever issue list you're using for this proxy was an official way to contact GitHub which would not be the case at all.

This, along with the reasons explained by Zach and Tekkub which you've seen previously, is why we handle Support at GitHub the way we do.

Cheers,
Steven!

[chadwhitacre]

Thanks for the response. Do I have your permission to share this publicly?

Chad,

If you would like, you're welcome to do so. Thanks for asking. I would ask you to remember that this is a conversation between yourself and GitHub and that choosing to share our replies doesn't mean this will become a conversation we continue to have in public. It is more like a source code drop than an open source conversation.

Cheers,
Steven!

[isaacs]

@nuclearsandwich I'm all too familiar with this problem! You realize that open source projects face this as well, right? That's precisely why we've asked for the ability to close issue threads.

I asked for this via support@ and have repeatedly discussed with GitHubbers on Twitter and tried to explain why this is extremely problematic for npm and Node in particular. People see an error code, google for an issue, and comment on something that was posted before literally every single line of the program was rewritten, adding their info to the pile. Users don't check the source before reporting an issue, basically ever. It causes exactly the problem you're describing.

Allow me to list the reasons I've heard for GitHub not using a public support forum:

1. Users sometimes post private data to public forums, and there'd be no way to correct that. private issues or pull requests for public repositories #37
2. People pile onto different issues with surface similarities, and it's difficult to direct them elsewhere. disable further commenting on an issue or pull request #38
3. GitHub doesn't want to make promises about what fixes will be made to the product. (I don't have an issue for that, because I don't think that's a justifiable problem; it's just laziness and poor customer support.)
4. GitHub's internal tracker has more features. (Can't really evaluate this one. I assume it MUST be better than Issues, since people use it who can actually fix it, and Issues is riddled with problems.)

These are all just reasons to not use Issues in the first place, which apply equally to your users problems! This is why I publicly chastised GitHub in the past of not dogfooding Issues, only to be told that GitHub "uses the shit out of Issues", because some GitHubbers contribute to open source projects.

However, organizationally, you don't actually expose yourself to the problems that your users are facing every day with your product, because you're not using your product the way that your users are. This is what we call the Quality Death Spiral. You're not using your inadequate product, because it is inadequate, and so you never notice or fix its inadequacies.

Frankly, the excuses I've seen for not having a public support forum of any sort, all boil down to "GitHub doesn't care about open source maintainers". You face the same problems we face, but rather than fix them, you're deciding to just not use your product. Some of your most active users are going out of their way to provide SOME kind of feedback in a public way, because we all actually know that, even despite all the problems with GitHub Issues, doing it in public is the right thing to do, and we're repeatedly told by GitHub employees that we're a nuisance, and wasting our time.

The sad thing about this is that no one at GitHub seems to see that any of this is a problem.

I'd be much happier with GitHub if you could just come right out and say that your paying customers are not your priority, and you're only interested in big enterprise sales. At least that would be believable.

[chadwhitacre]

@isaacs Whoa! That kind of frustration is unlikely to actually move the ball down the field, imo. Let's give GitHub the benefit of the doubt: They're supporting 3+ million users with only ~180 people. They've got all kinds of scale issues that I for one don't have the experience to imagine. Scaling that quickly while maintaining quality is surely a challenge, and imposing constraints in order to keep things manageable is surely understandable.

That said, GitHub does walk a fine line between propriety and open-source, and I think this issue gets to the heart of the matter. It's an even bigger challenge to figure out how to do open customer support for 3+ million people. No-one has figured that out yet, though if anyone is up to the challenge, surely it's GitHub. I think that's the framing that's going to move us forward here, albeit more slowly than we might like.

I think our best bet is to keep trying to raise this issue for public debate, engage those GitHubbers that resonate with this concern, and figure out a way forward together. The alternatives I can imagine—passive-aggressively cross-posting to support@github.com anyway, or bailing in favor of GitLab—are rather less satisfying.

[chadwhitacre]

Hey @adamstac @pengwynn, wanna do a @thechangelog show re: #6? :-)

https://twitter.com/whit537/status/353321249969160192

[chadwhitacre]

No go on @thechangelog.

[adamstac]

I mentioned on Twitter that our M.O. is to cover the positive impacts to
software development and open source and the people making them happen.

However, a conversation with @pengwynn and team on support at GitHub.
That's different.

On Friday, July 5, 2013, Chad Whitacre wrote:

No go on @thechangelog https://github.com/TheChangelog.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-20547032
.

Sent from Mobile

[chadwhitacre]

@adamstac Right, thanks for weighing in. :-)

Honestly, I think GitHub is too far along to alter course here. I plan to continue using this repo to track my own issues with GitHub together with others, but I don't really expect to budge GitHub's commitment to closed support and I'm not interested in adopting the role of an activist on this issue. Instead, I hope to explore "open support" and how to scale it to millions of users over on Gittip.

[adamstac]

I feel you, and that's why I don't think the topic is a fit on The
Changelog. Thanks for thinking of us though!

On Friday, July 5, 2013, Chad Whitacre wrote:

@adamstac https://github.com/adamstac Right, thanks for weighing in. :-)

Honestly, I think GitHub is too far along to alter course here. I plan to
continue using this repo to track my own issues with GitHub together with
others, but I don't really expect to budge GitHub's commitment to closed
support and I'm not interested in adopting the role of an activist on this
issue. Instead, I hope to explore "open support" and how to scale it to
millions of users over on Gittip https://www.gittip.com/.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-20547388
.

Sent from Mobile

[tjfontaine]

I think it would be prudent for GitHub to have a summit with @isaacs and other leads from projects with popular repositories on GitHub. The point is for projects truly "using the shit out of issues" it feels like the "issues with issues" conversation just enters a black hole.

Meanwhile outwardly their development focus has been more on iterating over the UI and developing their social network, while continuing to ignore the existing workflow problems that really are a point of frustration for projects.

I do appreciate they've been paying down technical debt on the disastrous backend design decisions they made initially--everyone is happy that the file server(s) aren't falling over consistently.

[Utumno]

Actually I spent around half an hour googling for the github tracker - only to go through this and realize there is no such a thing as a github tracker. A shame - there should at least be a feature request tracker for the reasons outlined in this thread.
+1 for your initiative

[patcon]

👍

Seems like the wicked problem of solving integration of public issue tracking and private employee conversations is worth solving.

GitHub has a badass, full-featured API, so I figure some sort of solution must be possible. Maybe a bridge between a public and private issue queue, in which comments are synced, but a certain keyword (#private?) in the private issue tracker results in that comment not syncing?

But then again, I don't understand GitHub's internal processes, so I can imagine this wouldn't be robust enough :(

[catdadcode]

I'm glad the staff has chimed in here but searching for "github issue tracker" is a nightmare because everyone uses github as their issue tracker for their repos!

I searched forever to get here only to be disappointed :(

It really is a shame that this is not a thing.

[rlidwka]

This message was displayed when I moved to https://github.com/contact from here.

Now I'm considering what's happening here, and thinking that this message must be right. Laughing out loud.

ps: +1 to this issue of course

[juniorplenty]

Just adding this as an example, for features at least:

http://help.hipchat.com/forums/138883-suggestions-ideas

[foxbunny]

FWIW, BitBucket has had a public bug tracker for as long as I can remember, and they actually discuss and solve issues there. Not always in a very friendly way, but still, it's better than a private one-on-one.

[reedstrm]

An example of another public-participatory web company: trello.com They dogfood their boards for the trello.com and the mobile apps as well: https://trello.com/b/nC8QJJoZ/trello-development

This is admittedly a 'read only' interface to their dev process: feature requests and bug submissions still go through email or bug submission forms, so there's a triage step. Perhaps that's what Issues needs: a way to make the public view of the issues on a repo only 'accepted' or 'confirmed' issues, while members of the repo can confirm/reject other, submitted issues. Github.com could experiment then with pushing vetted results from emails out to such a repo/Issues instance.

Their at 5 million users, BTW.

[stuartpb]

I'm just CCing all my (non-personal) support@ issues to this repo, and telling folks like @jdalton about this when they mention issues they have with GitHub (jdalton mentioned an issue where Github isn't reflecting garbage-collected repository sizes).

Hopefully we can make using this repo to discuss public issues with GitHub common enough that it eventually changes @tekkub's mind and gets adopted by GitHub proper as a matter of course.

[AnneTheAgile]

+1 I naively assumed since Github is 'the' way to have great feedback and openness that they would belove their dogfood. Rats. Ty for a place to track questions and issues.

[stuartpb]

What's most ironic is, from emails I've received regarding issues I've reported, it would appear that GitHub is actually using JIRA (at github.atlassian.net) to track issues on at least some projects (specifically github-linguist/linguist#917).

[AnneTheAgile]

Public Jira would also be quite acceptable! Other projects use that.

[waldyrious]

I think a bump is warranted in light of the recent news! 😄

[stuartpb]

I think that's an extremely solid point, given that the owner of this repo is primarily known for his work at npm, which has just effectively become part of GitHub itself.

[TPS]

It seems that https://GitHub.com/github/roadmap is closer to what the community expects from GitHub than https://GitHub.Community. But every single issue is locked to GitHub collaborators only, so effectively read-only to everyone else!

[clarkbw]

The community site has githubbers working through it to organize and track things. That's the best place for requesting a feature right now as it gets funneled back to the right product team internally.

The roadmap allows us to publicly commit to work we're doing but isn't designed for discussions or requests.

[TPS]

@clarkbw Thanks for the clarification. Still, that .Community site doesn't quite feel like GitHub — it doesn't seem organized toward handling issues as we users are used to here — but simply seems like general chat boards.

[clarkbw]

Yeah. It's a discourse board so it has some different community features. Biggest difference is that the support team is monitoring it, here it's mostly me and a few others.

[kenorb]

See: https://github.com/github/docs/discussions

[TPS]

@clarkbw Thanks for the clarification. Still, that .Community site doesn't quite feel like GitHub — it doesn't seem organized toward handling issues as we users are used to here — but simply seems like general chat boards.

@clarkbw https://github.com/github/feedback does feel like GitHub. Wouldn't it better to shift toward that generally (I realize it's currently limited to 4 beta products) instead of the awkward GitHub.Community Discourse site?

[TPS]

Some big official changes are coming, per #1967!

[TPS]

Major official announcement @ #1985! Please chime in there!

[michellemerrill]

👋🏼 everyone! I recognize the desire to have issues from this repo migrate to our public Discussions #1985. Though we've given this some thought over the last few weeks, I'd welcome your ideas and insights specifically regarding: Migration Qualifiers = a list of determinants for what migrates over. Some thoughts to get the ball rolling:

• upvote/emoji thresholds // weighting by top votes (❤️, 👍🏼)
• recency // is there / should there be any bias for recent activity
• assortment of topics // how to weight product areas (actions vs. issues...so on)
• what else? what's are the important things to consider here?

[aspiers]

Another collaborator here, chiming in late. I'm delighted to see that GitHub is finally attempting to tackle this, and that you're reaching out proactively to the community and working with us to do it in the right way. It's funny to hear that @isaacs works for you these days too!

I wholeheartedly endorse a migration - the "start from scratch" idea would not work at all. I'm a bit concerned by the risks of a partial migration based on qualifiers, but it could work, assuming that:

• it remains crystal clear which issues have migrated and which haven't, so that no single topic is fragmented into two places - this is very important!
• no important info is lost (see below) - also very important!
• the list of migration qualifiers is good.

On the last point, I think you already have a pretty good list of qualifiers... but actually they're technically just sorting criteria rather than qualifiers; you also need to specify thresholds somehow, and decide and explain how they would be combined. For example, does an issue need at least a certain number of reactions and activity after a certain date in order to be migrated? What percentage of issues do you expect to migrate? Will you set a maximum number and then adjust thresholds accordingly? What do you expect to happen to the ones left behind?

Anyway, certainly the weighting by reactions is going to yield good results. Please take into account all emojis though, not just 👍 or ❤️. I'm not sure whether recency bias makes sense, as a lack of updates often doesn't mean the problem has gone away, but rather that no progress has been made - although in the latter case one would expect to see a steady stream of new reactions coming in at least.

@TPS's suggestion of using the number of crosslinks as a metric sounds good to me.

Other thoughts (not around qualifiers):

• For any issue which is migrated, there needs to be bi-directional links between the old and new. The old should be closed with a comment pointing to the new, but also a link added to the old original issue description, so there are links from both the bottom and the top of the old issue to the new discussion.
• Please make sure the migration preserves labels as much as possible when migrating. We have put quite a bit of effort into categorising issues using these labels (e.g. see [meta] clean up and document labels in this issue tracker #1549), so it would be a shame if those classifications were lost.
• Can the migration also accurately preserve historical discussions, including authorship, timestamps, reactions etc.?
• Don't forget that a lot of valuable historical discussion and info is contained within closed issues in this tracker. Cross-links to non-migrated issues should be preserved.
• Framing a tracker as "Discussions" suggests an unwritten social contract that it is OK for discussions to veer off topic. Maybe that's helpful for some use cases, but off-topic tangents should be kept to a minimum when tracking actual issues (e.g. bugs) with GitHub. The fact that this (isaacs) tracker is an issue tracker makes it fairly clear that comments in an issue should stay on topic for that issue. I'm a bit worried that a move to GitHub Discussions, which looks much more like a chat forum, could result in lower signal-to-noise ratio. It would be great if there was some strategy for ensuring that doesn't happen.
• There needs to be the standard mechanism for discouraging filing of duplicates, like the one Discourse implements, e.g. "Hey! It looks like you are about to start a discussion which may overlap with one which already exists. Check out this list of similar looking topics before submitting yours!"
• Some element of community curation should remain. For example currently here I can fix typos / formatting errors in an issue submitted by someone else, and I can add labels etc. @TPS and others have been similarly granted extra curation powers by virtue of their hard work on this tracker. GitHub would benefit from harnessing this extra positive energy rather than accidentally blocking it as a side effect of the migration :-)

[waldyrious]

Framing a tracker as "Discussions" suggests an unwritten social contract that it is OK for discussions to veer off topic. (...) I'm a bit worried that a move to GitHub Discussions, which looks much more like a chat forum, could result in lower signal-to-noise ratio. It would be great if there was some strategy for ensuring that doesn't happen.

Thanks for putting that into words. I totally agree — I've been struggling with this exact anxiety but hadn't pinpointed it yet.

"Can the migration also accurately preserve historical discussions, including authorship, timestamps, reactions etc.?

Important point indeed. I'm worried that this won't be the case, and frankly I've felt that reading conversations migrated non-seamlessly between different places to be quite jarring (e.g. always having to look at a note at the top or the bottom of each comment to figure out who authored it, rather than relying on the usual location of the comment author name and profile icon).

EDIT: the second issue is not an problem with the existing functionality to convert issues to discussions, as @TPS points out below.

[TPS]

Just a note: Converting issues to discussions is already implemented. Assuming that's what's done & IIUC, it's mostly a matter of which 1s when.

[waldyrious]

D'oh! I totally forgot about that 😅 Sorry for the noise!

[aspiers]

Is it though? That mechanism looks like converting within a repo, whereas what we are discussing involves migration of issues from a user repo to discussions in a repo in another organisation.

[TPS]

Much of the work seems done w/ the issue → discussion conversion. Once this repo itself changes owners (isaacs/GitHub → GitHub/isaacs — why not?), I can't imagine it'd be too much harder to move those to GitHub/feedback, especially as it'd be staff doing it, not us poor souls trying to navigate, e.g., permissions, &c.

[TPS]

Another important concern: These issues are heavily crosslinked all over GitHub & indeed all over the 'Net. Those links need to stay working. (I just had a non-related issue moved between repos in an org, & an important link to it broke outright, so I had to fix manually. That certainly wouldn't be acceptable here!)

A general question: If any issue/discussion/whatever is moved, its number (like this is issue #6) & URL seems retired (not reused, &c), & then 404s. Why aren't these being used as pointers/redirects/301s to wherever these issues end up as an automatic part of the move process? Is that something that'd cause widespread chaos?

[aspiers]

@TPS commented on June 19, 2021 3:07 AM:

Much of the work seems done w/ the issue → discussion conversion.

It is? I guess I must have missed the news on that - where was it announced?

Once this repo itself changes owners (isaacs/GitHub → GitHub/isaacs — why not?),

Has it been agreed and confirmed by GitHub that this repo will definitely change ownership? Again, if so I must have missed the announcement. I haven't seen any message in this issue or in #1985 about any news since @michellemerrill kindly asked for feedback on a migration plan (qualifiers etc.) Would be really helpful if any status updates are communicated widely, as this will affect many people.

[TPS]

As of #2035, this is announced as solved via https://github.com/github/feedback/discussions/.