Where are you getting that they don't dogfood the issue tracker? It's a private tracker (private repository) but from what I've seen in the Github blog, they do... it wouldn't make much sense if they didn't.

If they're using it, they're doing so in completely different fashion than everyone else. That is, it's not public for viewing, submitting, commenting, etc. Indeed TFA indicates exactly the sorts of pain points that would be missed by those using the tool in such a radically different way than everyone else. If someone at GH had to wade through all the damn +1's then something would have been done about them years ago.

95% of all my github activity is in private repositories.

Ditto. Maybe 98%. I think that's a big part of the disconnect I'm seeing here in the comments. Those of us that live in private repos are likely pretty happy with how things currently work especially since we're the ones paying to use the service. If it wasn't working well for our teams, we'd find somewhere else to spend our money. That being said, we're certainly the minority when it comes to users on the platform.

I guarantee everyone maintaining a large public project on github has private repos and is paying for the service.

Open source ties in with my work. Every one of my private repos has open source dependencies hosted on github.

Privileging the priorities of my private repos over their public dependencies would be shortsighted.

> Privileging the priorities of my private repos over their public dependencies would be shortsighted

I think that’s Github’s call, but I definitely don’t disagree with you and apologize that I came off that way. Open source projects exposed me to Github and greatly benefit the projects I work on in private repos. I really do want those projects to have an effective platform for growth and stability. I don’t want to water down their needs; I just wanted to offer some balance to the discussion.

My point was simply that this probably isn’t something that is as easy for Github to solve as it may appear on the surface. Any changes they make to the issues system can’t upset the low friction way it works for repos with a modest amount of contributors (and +1’s from clients are appreciated). I hope that positive changes come out of this letter.

If Github were to leave Open Source projects high and dry, they’d lose my business.

>That being said, we're certainly the minority when it comes to users on the platform.

But you're the huge majority of people who give GitHub money. It makes sense not to prioritize the pain points of open-source projects when you lose money by hosting them.

We have the diamond level plan from GitHub and have >260 private repos at my company.

We only chose GitHub because we wanted to host our open source repos there. If they don't prioritize the open-source projects then we have no reason to pick them over BitBucket or something else like that.

That's not how it works. Happy consumers leads to happy enterprise users. They are one and the same.

I only pay Github money to host my private repos because their platform also hosts most of the open source projects I use. If enough of those projects leave for a service that does open source better, I'll be happy to follow them. Otherwise I may as well be using Bitbucket or Gitlab.

We don't pay GitHub precisely because they lack features we can implement in GitLab.

Much of that is due to the OP's requested features that are currently missing. But tbh, it is too late to get us to switch.

> Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.

For instance, is something we basically implemented in our local version of GitLab but aren't sharing because our implementation pulls this from internal docs other people can't use. Our CSRs put issues into GitLab but they tend to forget steps while on the phone with a user.

We wouldn't have bothered if we had something like this when I was evaluating GitLab vs. GitHub.

GitHub pretty please, give us an option to hide our profile from search engines just like Facebook do.

What is the use-case of this?

I have an account that is only for private repos and I don't want that account to appear on search engines for my real name.

I also have a public account that I use for contributing to public projects so it could also help to avoid duplicate accounts in search results.

All accounts should be searchable for username/real name with GitHub's search anyway.

Just curious, why not have just a single account?

Your private repo's and contributions are not made public, so there's no "risk" involved.

I think a lot of companies forced this because for a while the api permissions weren't granular enough when dealing with private repos on organizations. They added the "Third-party application access policy" sometime in the last year or two. I might be wrong though.

Do you feel like your usage is typical?

I would guess that private repos have a much smaller user base, in that that they work for companies where they are trained in specific policies to submit issues and work with the repos. With public repos you're at the mercy of widely differing levels of user experience.

I think you should chill down with all the speculations. I only use it for private repos.

Go look at a project like Rails where you can tell they need it.

> If they're using it, they're doing so in completely different fashion than everyone else. That is, it's not public for viewing, submitting, commenting, etc

Huh? Github isn't opened sourced so how is a different fashion from anyone else using private repos?

Plenty of private projects use a separate, public Github repository for community reporting of issues, and public tracking of those issues.