Live data from Hacker News

Dear GitHub

github.com

181–190 of 491 posts

Re: Dear GitHub

#181

I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developi…

It's a momentum thing I think. A big part of the Github platform mirrors a social media platform. When you meet a developer, you check out what they're up to on Github just like you might check on a friend's status on Facebook. Like Twitter, it's a way to get your name out there. Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to t…

> Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.

There are multiple ways to go around this, OpenID, Mozilla Persona, or any third-party authenticator.

> The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.

I see this more of an additional reason for big projects to move away from Github. It gives unwarranted legitimacy to everything on the platform.

Re: Dear GitHub

#182
post #8

Being a maintainer on a project with some minor community on GitHub is such a garbage experience. It’s pretty neat as a general user, but at least you get the impression with BitBucket that they prioritize productivity and project management. And the task system hasn't received any significant updates since their inception - which is a shame, because tasks are an awesome invention, they just have to be implemented aw…

I wonder if the whole "managerless culture" is to blame and is unfixable? (In other words, why hasn't SOMEONE had this thought about issues in N years? One is they deem it not a problem, another could be that they think to optimize for the filer, and the maintainer doesn't matter, or... there's no organization at all?) There could be (theoretically) no one to make anyone do anything, and perhaps the issue tracker is…

I like the theory of the flat-office culture or philosophy affecting this.

Then again, it could be the kind of anarchic Libertarian or laissez-faire bent that we see with reddit that makes it exceedingly different to grant special permissions and privileges, especially across subreddits/issues/users/orgs. Or maybe user experience just doesn't matter for today's start-ups; maybe we've passed the Overton window for start-ups deciding it's not worth caring about their users.

A lot of the time, I feel like more of a user+ than a(n) (super)admin on my own repos. I might as well have the permissions and tools to ruin my own project - in the name of pure unadulterated freedom if for no other reason.

The dashboard and notification system have always been POS, too, so it might just be that everything that basically isn't tethered to a GUI is on the bottom of the totem pole.

Re: Dear GitHub

#183
I know they've only recently released new permissions for organisations, but they're still extremely lacking. As far as I can see, there's no way of setting permissions at a group level.

As an example of how this would be used, we have a Github team within our organisation which is used for non-technical people to post bugs. These people have no reason to be able to see or push code to the repository, they only need to be able to create issues. This applies to every repository in the organisation. As far as I can see, and without manually adding every single repository to the team, there's no way of setting global permissions permissions for a team. This seems like a major oversight to me.

Re: Dear GitHub

#184

Hi Adam, Addy, Andreas, Ariya, Forbes, James, Henry, John-David, Juriy , Ken, Nicholas, Pascal, Sam, Sindre, My name is Jono and I started as Director of Community back in November at GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in. Firstly, thanks for your feedback. I think it is essential that GitHub always has a good sense of not just what works well for our users, but also where the pa…

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…

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.

Re: Dear GitHub

#185
post #142

This first request is the anti-thesis of GitHub's simple approach: >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. Every checkbox, text-field and dropdown…

> Every checkbox, text-field and dropdown you add to a page adds cognitive overhead to the process

I do concur, but there should be at least some of them. One shouldn't have to hope that people will be kind enough to submit proper issues, the platform should force them somehow to do so. I think, if a study of github issues was made, we'd see that about first five messages on a given issue would be those of maintainers craving for more input. What is the output of dmesg, how is your configuration, what is the output of the process, can you run it with the verbose flag on... A bit of cognitive overload is good, so that who submit bugs are those who take the burden of doing so.

Re: Dear GitHub

#186

Do the undersigned send any money to github? It might be better to phrase your demand in the form of a question, "how much can we pay you to do this work for us?"

So most of the above replies seem to be a threat. Give us free stuffs. You have a nice website there, be a shame if anything happened to it.....

Seems like the Tony Soprano way of doing things.

Re: Dear GitHub

#187

Hi Adam, Addy, Andreas, Ariya, Forbes, James, Henry, John-David, Juriy , Ken, Nicholas, Pascal, Sam, Sindre, My name is Jono and I started as Director of Community back in November at GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in. Firstly, thanks for your feedback. I think it is essential that GitHub always has a good sense of not just what works well for our users, but also where the pa…

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…

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.

Re: Dear GitHub

#188
Distributed revision control users whining about centralized repository lacking features.

Ummm ... anybody getting the irony here?

And, from a GitHub business perspective, why do I hear Lily Tomlin: "We don't care. We don't have to."

Everybody anointed GitHub as "the chosen one" over strenuous objections from some of us that creating another monopoly for open source projects is a bad idea.

Pardon me for enjoying some Schadenfreude now that GitHub leveraged the open-source adoption into corporate contracts and now doesn't have to give two shits about open source folks.

Lily Tomlin's Phone Company Sketch: https://www.youtube.com/watch?v=CHgUN_95UAw

Re: Dear GitHub

#189

My experience with Github support is terrible, if not one of the worst, I once had an issue and contacted their support and it took them 1 month to respond to me (literally) I was really surprised by that.

I contacted them dozens of times in 4 years and never had to wait more than a day. I guess you’ve been unlucky that time.

Re: Dear GitHub

#190

Earlier quoted context omitted.

Google Code has primarily been used for Chromium's issue tracker, but they have a star system for exactly this reason. You can sort something by stars, but it's bad etiquette there for a user to comment +1 rather than just star.

Yep. The problem is that some users are not aware of the conventions, and often you see on the Android Google Code repo "+1" or something along the lines of "Google plz fix this". This becomes heavily apparent when someone posts an Android issue directly onto the Android subreddit. I suspect the same could happen with GitHub issues. When you see others posting "+1", then others follow the same practice.

It seems to me that it would be a good idea to have a special-case that turns a comment where the only content is "+1" into a star request instead.
Post reply on HN