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