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.
> 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.
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.
