An open question is how the community should provide feedback. Trello provides a decent example of how to do it well [1], but GitHub feels like a black box. I've been on GitHub since 2008 and I have been paying every month for years, but other than emailing support I have no idea how to vote for a feature request.
My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other people with the same frustration [2], but we have no idea how to get that on GitHub's roadmap.
An open question is how the community should provide feedback.
Perhaps if Github used their own issues system to gather feedback on Github itself, they'd more rapidly improve it. I'm sure they'd feel a lot of these pain points in a far sharper, more visceral way if they were subjected to them daily.
Yes it is fairly bizarre that Github don't dogfood the issues function. I'm sure they have an internal system that they prefer, but even that internal system could have a public interface. Also, if the internal system is superior then its superior features could be added to the public system so that we could all benefit.
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.
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.
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.
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.
> 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?
Users can use those buttons to +1 or -1, and any comments that contain nothing but an emoji (like `:+1:`) are automatically converted to emoji awards, as we call them.
> My personal pet peeve is not being able to mark a public repo as 'deprecated'.
What I came up to work around this is:
- Create an org named <YOUR-USERNAME>-deprecated
- Move the projects to the organization
- Set the avatar of the organization to your avatar, with desaturated colors (purely cosmetic, optional)
I watch the project and did not see "UNMAINTAINED", cause i scroll automatically on github projects down to the readme.
I search and then i see it in the title.
Better would be an Option in Github to set a project to unmaintained or deprecated, with an optional link to the new project (if some exist).
Github could then change the background color from white to an other color or add a border around the page, so that it is really obvious that this project es EOL.
Have a look at the trending erlang repositories[0]. You will always find, near the top, basho/rebar. However, the subject on this reads:
ATTENTION: Please find the canonical repository here:
The same advice is in the README.
What this tells you is that enough people are not only using this repository, which was last updated in August 2014 with a change to the README directing people at the new source, but people are giving it stars this week such that it shows up as "trending" higher than the correct repository.
> I normally put a big "[DEPRECATED]" notice at the beginning of the README.
Aye. Some folks in the discussion linked to by krschultz complain that "People sometimes don't read the README and -thus- don't notice deprecation warnings.". To them I ask: "What makes you think that those sorts of people will notice anything less than an overlay that prevents them from interacting with the Github UI for that particular repo?".
One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.
> One concern would be around tools that fetch from github automatically.
Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right?
> ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings]
I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?
Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches https://example.org/pkg/foo?go-get=1. So coordination between go and github could implement something for deprecated repositories without changing anything in git.
Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) [0]
> ...coordination between go and github could implement something for deprecated repositories without changing anything in git.
A couple of things:
* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.
* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)
* Frankly, having a well-known file in your Git repo that contains meaningful tags seems far more compatible than changing git, or altering the $BUILD_TOOL<->GitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)
I am not your grand parent poster but I fully agree with you and I'd go further than that.
The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Facebook/Uber.
So, I heartily agree that vendor lock-in is bad. [0] However, git doesn't handle mailing lists, or issue trackers, or hands-off repo push access control, or.... So, if you're going to do more than just serving git repos, you're almost certainly going to have to do these things yourself, and you very well might end up doing them in a way that differs from how everyone else is doing them.
I mean, as long as you can get complete exports of the data in the important non-git bits, who cares, right?
Agree. I've had literary thousands of libs/tools/apps dependencies in one of my projects that was built using automatic tools (Bitbake + Yocto). It's simply impractical to go through all these README's manually, so a tool to detect depreciated projects is a must in such situations. Of course, one could implement some tool to scan all README files for keywords ('DEPRECIATED', 'UNMAINTAINABLE' etc.), but that's just a workaround and I'd like a proper, reliable way to do that.
What if the maintainer never marks the library as deprecated? What if they're just hit by a bus?
I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many. Whoever decided it was OK to depend on that library should be able to follow it closely enough to say when it cannot be depended on.
"What if the maintainer never marks the library as deprecated? What if they're just hit by a bus?"
There are a lot of "if's" and many things might go wrong -- there's almost never 100% guarantee, but every mean that makes end product more reliable is a good idea.
"I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many."
Such number of dependencies is common when building custom Kernel/OS + application. Also, I've never mentioned direct dependencies, some are just tools to build tools. It wasn't event that big of a project -- a relatively small (~150 Mb) custom OS with Qt application for an embedded device.
I've had pretty good success with feature requests in Github – but I agree that it at least _feels_ like it depends on who is replying to you (or even what state of mind they're in; copy paste responses has been had).
Anyway, a good example of a successful feature request – shared since it might help others in their quest for success – included me attempting to reduce the problem, scoping it and suggesting a solution. If you can find examples of this problem over multiple open source repositories (in my case nodejs) it seems to contribute to it getting fixed.
My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other people with the same frustration [2], but we have no idea how to get that on GitHub's roadmap.
[1] http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144