Comment by krschultz
10 years ago
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.
[1] http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144
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.
21 replies →
But then they'd be spammed with useless +1 comments
+1
2 replies →
> 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)
https://github.com/coreh-deprecated
I normally put a big "[DEPRECATED]" notice at the beginning of the README. This normally doesn't go unnoticed.
Another good example is harthur's "[UNMAINTAINED]" [1]
[1] https://github.com/harthur/brain
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:
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.
There has to be something wrong with the deprecation process if this happens. [0]https://github.com/trending?l=erlang
> 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.
9 replies →
My primary use case would be searching projects and filtering out deprecated ones.
Someone came up with http://unmaintained.tech/ for exactly this reason. You can add a badge to your README.
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.