25 ms·

GitHub responds to Dear GitHub letter

763 points by joshmanders 11y ago

chris_wot 11y ago
That took a long long time for them to respond. It's day 29 now. In fact, they could have communicated something after even a week - probably something similar to what they have actually written, only more 'We're looking at your list and we'll try to get back to you as soon as possible'. Where is Jono Bacon in all of this? edit: OK, I feel kind of bad for mentioning Jono because I've watched him do awesome things over the years. I've sent him an email out of the blue asking him to respond - hopefully he gets it.
- petetnt 11y ago
  They did sort of respond on the initial HN thread though. Commenting means committing and if you do the wrong decision in haste, you might screwed up in the process (as an individual or a company). Is 29 days too long? Maybe. They do address the slowness on the commit too and they provided a timeline.
  - chris_wot 11y ago
    Oh, I'm glad they did respond :-) In fact, I actually think that if they hadn't responded they would be seeing an exodus of projects. Given that the issues being highlighted in that letter are long standing though, I don't think it would have been hasty to say that they appreciate the feedback and they are reviewing. It's great of course that they responded on HN. But the fact that they only responded on HN and had no way of responding on their own site is... a bit embarrassing actually! At least I sort of feel that they should feel that way. I actually pay for their lowest monthly tier as my needs are very limited. I largely like GitHub and will stick with them, but they just have to do something about their community engagement. If they don't, then someone is going to eat their lunch! edit: kind of surprised at how some are responding to my comment - what did I say that was so wrong? I'm genuinely curious - it's not just me saying and thinking this, after all!
    - deleted 11y ago
      [deleted]
    - deleted 11y ago
      [deleted]
- joshmanders 11y ago
  I agree with you, and when Jono made his post on the original Hacker News thread, I immediately followed him on twitter and even CC'd him on tweets that had people talking about things hoping that he'd respond to them, at least post a public post outside of the HN thread saying that they're working on things... But he was more worried about promoting the community leadership summit. Kind of sad honestly. Not very good community leadership by ignoring your own community to promote a community leadership conference.
  - chris_wot 11y ago
    To be fair, he was flying into linux.conf.au all the way in Geelong - that's a long flight. It could well have been that he's recovering - I notice that his last blog post was February 1st. And of course I'm kicking myself that I missed the conference entirely. Sigh. Next year I guess.
    - jonobacon 11y ago
      You are not kidding about the long flight. I wish someone could move Australia a little closer to California. :-) Hope to see you at linux.conf.au next year, chris_wot! :-)
      - chris_wot 11y ago
        Thanks Jono :-)
- dmethvin 11y ago
  I have to assume he's been told not to speak about details until the executives came up with a plan. If that is the case, GitHub management is really making his job a living hell. Why have someone whose job it is to work with the community if everything has to be micro-managed by higher-ups?
- jonobacon 11y ago
  My apologies for the lack of public responsiveness. Thanks, chris_wot, for jumpstarting the discussion. As outlined in Brandon's post linked here, we have been taking some time to really delve into the core of these issues and explore what the best solutions are. This has involved some internal discussion as well as reaching out to various parts of our community to gather feedback and perspectives. We take these concerns really seriously and want to ensure we can explore the best long and short-term solutions. As you can probably understand, we want to have some of our ducks in a row before sharing some next steps. Rest assured that even though there has not been much publicly shared yet, we are definitely exploring ways to address these issues.
- deleted 11y ago
  [deleted]
eibrahim 11y ago
Wow, It took them 29 days to say "we hear you stay tuned"
- drinchev 11y ago
  Some other companies usually don't reply at all. E.g. Apple, Microsoft, etc.
  - giancarlostoro 11y ago
    It's really sad though when you consider gitlab answered a while back.
  - chris_wot 11y ago
    And have suffered for it in the past (though Apple, less so, it is true).
    - pluma 11y ago
      But Apple has a reputation of not saying anything outside of the big releases and for the most part didn't have to be responsive because the periodic hype usually drowned out any criticism. GitHub on the other hand largely owes its reputation to how it is perceived by open source communities. Their perceived value is based less on the quality of their product(s) and more on being the place all open source projects live (moreso than even SourceForge ever was -- even companies like Google and Microsoft have moved their open source projects to GitHub simply because that's where developers expect open source projects to live). Apple can get by largely on marketing and the perceived quality of their products. GitHub relies on open source projects, even if they don't make any money of them directly. Hosting open source projects is just an advertising expense. If the majority of noteworthy open source projects left GitHub (especially if they left to the same platform, e.g. GitLab.com or BitBucket) their reputation as "the place where open source projects live" would evaporate and they'd have to fight the same friction for new users as their competitors. Additionally they'd probably become less interesting for third-party integrations as they can no longer serve as a cheap showcase for those products/services. This would again harm their appeal to paid users.
bhouston 11y ago
Brutal delay in responding to their most important constituent? What the hell? This wasn't a minor user's feature request, it was an open letter signed by a ton of major open source leaders. If I was an investor in GitHub I would fire the CEO.
- bryanlarsen 11y ago
  That's the problem. GitHub brass thinks their most important constituent is the people paying thousands of dollars to buy GitHub Enterprise. The only reason they have the enterprise customers is because they got popular with open source first. However, at this point their enterprise popularity may be big enough that success there is self-sustaining -- enterprises make decisions based more on what other enterprises do rather than on what open source and small companies do. That being said, I bet that enterprises are screaming about Issues too. Enterprise loves their custom fields.
  - ageofwant 11y ago
    Enterprises use JIRA and various github plugins, works a treat and keeps PM types happy. This is about OSS projects that are to small for JIRA/Bugzilla, but have outgrown the limited github issue tracker.
  - x1024 11y ago
    You say that, but much has changed in the past 10 years. If it truly were "up to enterprises", we wouldn't be using Git in the first place.
    - deleted 11y ago
      [deleted]
  - mietek 11y ago
    > The only reason they have the enterprise customers is because they got popular with open source first. I have absolutely no idea how GitHub could have lost sight of this simple fact.
sotojuan 11y ago
I'll be more optimistic and be happy they replied and very interested in what they have in store. They say "next week" and it's Friday so it won't take that long.
punnerud 11y ago
"Issues haven't gotten much attention from GitHub these past few years and that was a mistake, but we've never stopped thinking about or caring about you and your communities." A lot of thinking but no action. Github, what have you been up to these years??
- oldmanjay 11y ago
  Keeping a gigantic software application running, mainly. The ease of your role as a bystander and critic in no way reflects the work they have to do to keep the system up.
- acdha 11y ago
  You can see a list by scrolling through: https://github.com/blog https://github.com/blog One of the more obvious things is that running a huge, popular app is non-trivial, particularly if your users do things which get e.g. governments to attack your site.
tacos 11y ago
I wish more companies would take more time to respond to these sorts of situations. Perhaps this was excessive (I see conflicting reports of where they responded and when). But... Let things cool off, take a hard look at things internally, get the stakeholders committed to actual change, then provide an update. I'm far more likely to believe that then even a perfectly executed PR play. I've watched even the most pathological and idiotic tech people get good at those the past 10 years. Beware people with good haircuts who say nothing and only appear during times of trouble.
- sangnoir 11y ago
  > Let things cool off, take a hard look at things internally, get the stakeholders committed to actual change, then provide an update. This is not an update - this is "we're looking into it", which should precede the internal soul-searching and actual change. They should have released this the moment they decided they were going to look into it - to outsiders, that moment seemed to be 29 days after the open letter was published.
Siecje 11y ago
I wonder if this has more to do with ESLint[1] than the letter. [1]:https://github.com/eslint/eslint/issues/5205 https://github.com/eslint/eslint/issues/5205
- jglovier 11y ago
  Nope. We'd been working on our response ever since Dear GitHub was published. It just took a little time because we wanted to think long and hard about our response - beyond just the words we used to respond – and actually consider how we are interacting with the community, and where we can make demonstrable improvements. It is just coincidence that the ESLint thread happened this week, and our response came out today.
  - chris_wot 11y ago
    You really should consider telling those who filed the letter that you were at least working on it. Did you expect them to know?!?
    - eric_h 11y ago
      Someone, not the GP, did: https://news.ycombinator.com/item?id=10905338 https://news.ycombinator.com/item?id=10905338
    - stronglikedan 11y ago
      Did they who filed the letter ask? If they asked and didn't get a reply to the effect of "we're working on it", then I can see your point. If they didn't ask, well then that's on them. I not finding any stories about them asking about what's going on and not receiving a reply, so I'll assume the latter, since I'm sure the former would have been posted about.
      - chris_wot 11y ago
        Who, precisely, were they meant to ask? Perhaps you should reread that letter: However, many of us are frustrated. Those of us who run some of the most popular projects on GitHub feel completely ignored by you. We’ve gone through the only support channel that you have given us either to receive an empty response or even no response at all. We have no visibility into what has happened with our requests, or whether GitHub is working on them.
progx 11y ago
Thank you GitHub, to know that you need 29 days to reply, let my OpenSource GitHub Project look not soooo bad. :-)
- r3bl 11y ago
  It took GitHub's support exactly 82 days to respond to my issue[1]. In the end, I literally had to ask a GitHub employee on his AMA to look up what the hell is going on. [1] https://blog.r3bl.me/en/worst-support-experience-ever/ https://blog.r3bl.me/en/worst-support-experience-ever/
miseg 11y ago
That's a great question on the page by EGreg: > I wonder if GitHub itself can use its own issues system for prioritizing feature requests and bugs :-)
ageofwant 11y ago
Great, but please resist the urge and goading to build another JIRA in github. The second best thing about github is its simplicity.
- ivl 11y ago
  I don't thin something that size would be warranted. But, letting users customize Issues, and PR/merge rules, and splitting off another section for requests would be beautiful.
- steveklabnik 11y ago
  This is exactly my fear as well. I really, really like how simple GitHub issues are. While I have some very minor quibbles, I'm also afraid that change here will end up being worse, not better.
- joshrowley 11y ago
  In an ideal world, the Issues team would develop and support a plugin ecosystem for the tracker. Users can customize and add the features they see fit and even create their own custom plugins. Allows flexibility and power for those who want it while keeping the core simple and clean
  - tomschlick 11y ago
    This is the best idea. While some features like +1s and contributing guidelines should be baked in, other features like extra fields, requiring people to sign a disclosure, etc would be best left to plugins that can hook into issues much like CI services hook into pull requests.
mirashii 11y ago
Now, if only we could get a movement behind a "merge" button that does fast-forward only commits.
- jquast 11y ago
  or squash
- zanny 11y ago
  I know that gitlab has it as a project option!
- scrollaway 11y ago
  Agreed, and here's a git alias I made for the occasion: merge-pr = "!f() { git fetch $1 $2; git branch _FETCH_HEAD FETCH_HEAD && git rebase HEAD _FETCH_HEAD && git checkout master && git merge --ff-only _FETCH_HEAD; git branch -d _FETCH_HEAD; }; f" Syntax: `git merge-pr <remote> <branch>`. You can copypaste url + branch from github's UI above the merge button. Note: This merges only to master, no way to specify another merge target. Feel free to suggest improvements.
  - danielsamuels 11y ago
    I have these for merging a PR into develop and master respectively. Usage is `git pr <#>` pr = "!f() { git checkout develop && git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1 && git rebase -i origin/develop && git checkout develop && git merge - && git push; }; f" prm = "!f() { git checkout master && git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1 && git rebase -i origin/master && git checkout master && git merge - && git push; }; f"
    - scrollaway 11y ago
      I remember trying and failing to get exactly that working. I'll give yours a shot, thanks!
  - cletusw 11y ago
greggman 11y ago
I don't have any giant opens source projects so I guess I don't get bothered by the +1s and cries for help. Chromium gets those on their non-github issues. So does Firefox. I'm guessing WebKit does too. My biggest issue, which I guess is a non-issue for most others?, is I hate when reviewing a PR that every single line comment generates a message/email. Maybe it's because I'm used to Rietveld but my normal workflow is to start reading the patch and adding comments. I might have made 10 separate line comments before I get to a part of the patch that invalidates all those comments. Therefore I don't want them sent until I'm ready. I want to be able to make line comments across all files in the PR and only when I'm ready, send them as one coherent message. As it is now, AFAICT, the only way to do this is to write line comments in some other file on my computer and then later manually find the lines again in github and add them one at a time. Rietveld also lets you respond to line comments inline and mark them as "done". is there anything for github that does the same? Maybe one of their offline tools?
- jsight 11y ago
  Excellent idea... some notion of a review session would be nice.
- chris_wot 11y ago
  Gerrit does this as well.
- mconley 11y ago
  Review Board works with GitHub and allows you to publish your review when you're ready.
- spankalee 11y ago
  Just continue to use Reitveld :)
- masklinn 11y ago
  > My biggest issue, which I guess is a non-issue for most others?, is I hate when reviewing a PR that every single line comment generates a message/email. > is there anything for github that does the same? Maybe one of their offline tools? Nope. Even the API doesn't allow this, you can only create one "review comment" at a time and no matter how fast you create them (or if you carefully create all of them over a persistent connection) each and every one of them will generate one notification and one outbound mail. That went pretty well the first time I tried to get a linter to annotate a PR. The annotation worked, but I discovered some people's mailboxes can not handle getting 50 mails from the same source in a fraction of a second (and oddly enough people are not fond of getting 50 one-line emails from the same place). (I asked github support about it, they confirmed the only workaround is to not use inline comments)
rafael-rinaldi 11y ago
I would love to know what the reasonable approach would be ideal from the people talking bad things about GitHub. If they responded to issues right away people would complain too. It's not easy to come up with a solid plan for new features and improvements, specially in a company this big (that has a lot going on as we all know). What? You think they're going to get that list of complaints and start smashing some code? That letter is not even 1 month old. I can kinda understand the frustration but keep in mind that there's a lot of other things to handle, it's more complicated than that. In the meantime if you're really struggling, there are other great options available out there like BitBucket and GitLab.
- chris_wot 11y ago
  Then they might have grown too quickly then. At this point, is really not that hard to move to GitLab.
- merpnderp 11y ago
  A reasonable approach? When I'm in doubt, I just go with the truth. They could have said "Hey, we hear you, we're starting a group to figure out how best to resolve your issues." or "Hey, we've already been working on this, we'll get back to you in a couple of months." Or even a "Hey, we get you aren't completely happy, but we just don't have the time to address your concerns right no, but when we can, we will." Any of those would have been better than perfect silence followed with, we'll see what we can do.
  - rafael-rinaldi 11y ago
    Well, they just published a down to earth response didn't they? Some companies don't even respond at all. As I said, I can understand the frustration but they seem to be working on it. Give them some time or use other tools if you can't wait.
- forgottenpass 11y ago
  I would love to know what the reasonable approach would be ideal from the people talking bad things about GitHub. Treat their software development savvy usebase as stakeholders in their ongoing project rather than unwashed masses consuming a loss leader? A mutually-agreeable reasonable approach probably doesn't exist. Limited visibility into the project may be considered exposing too much of the business for GitHub's tastes. So it will continue to be a one-way relationship, with all the baggage that comes with a one-way relationship (incl "talking bad things").
tptacek 11y ago
From reading the comments on this thread, one could get the impression that HN Github users would have been happier had Github not responded at all.
- chris_wot 11y ago
  That's an odd impression for you to have gotten!
- beachstartup 11y ago
  once the troll is fed the appetizers, it demands the main course.
- striking 11y ago
  I think some people are miffed that it took them almost a month to just respond to the letter. Maybe you don't care as much about certain software, but some people are really passionate about it. Perhaps HNers would have appreciated some more substantive action by now, rather than just a response.
  - tptacek 11y ago
    I'm confused by what these people are asking for. Should Github acquire a time machine? If so, instead of asking for an earlier response to this later, maybe they could just do things differently from the beginning so the letter was never necessary!
    - striking 11y ago
      Being flippant is really unhelpful, and kind of insulting. People really care about software. Instead of just responding to us now with a letter that's totally sparse on details, what if GitHub gave us an idea of what they're actually going to do? "We're sorry" is really annoying to hear almost a month after the fact.
      - cortesoft 11y ago
VeejayRampay 11y ago
Reading the reactions to their addressing the complaints, I really don't envy the folks at Github. A lot of folks in the "Yeah that's nice but what about X/Y/Z" range (and same here on HN). There's simply no winning.
- ohitsdom 11y ago
  It'd be a little easier to identify key requests if they implemented voting to solve the "+1" comments, as identified in the "Dear Github" letter.
- dreamdu5t 11y ago
  Yes and no. Some feature requests were years old and hugely popular. For example, displaying tab-spaces code (such as Go) properly was something that took years to implement, despite the enormous feature request thread and extremely simple implementation. It became obvious github had dedicated zero resources to building new features the community had longed-for
elliotpage 11y ago
I just hope they also add new features centering around depreciation of repos and the ability to add a "THIS IS NO LONGER BEING MAINTAINED" flag or an equivalent. Finding a repo that appears to solve my problems only to find a mass of issues and an absent maintainer is a pretty big time sink, for both me and likely the maintainer too!
- Blahah 11y ago
  It's pretty easy right now to just change the header of the README, and/or the project description to indicate deprecation. What added benefit would making it a feature provide?
  - RichieAHB 11y ago
    It requires the maintainer to do this. Often if the maintainer isn't maintaining the codebase then they won't be updating the readme either.
    - Karunamon 11y ago
      Wouldn't it be up to the maintainer to toggle the "no longer maintained" flag? Sometimes a project that hasn't seen commits in a long time isn't orphaned, but just doesn't need changes...
- deleted 11y ago
  [deleted]
  - deleted 11y ago
    [deleted]
    - deleted 11y ago
      [deleted]
- mattcantstop 11y ago
  I usually look at the "Pulse" part of the repo page. That tells me how often it has activity and if it is an active repo.
rogerbinns 11y ago
I complain every 6 months about their "releases" page - eg this one for my project https://github.com/rogerbinns/apsw/releases https://github.com/rogerbinns/apsw/releases They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. But the repository is in a maintainer state, so the "Source Code" isn't useful to an end user because various tools need to be run (eg building help, automake/autoconf, dependencies). The people mislead by Github due to this "Source Code" contact me, not github. Every six months for several years, I send the email explaining how this doesn't serve anyone's interest, how it hurts, and that I am happy with any solution (eg don't auto add, change the name to make it clear, be able to label an existing file as the "Source Code" etc). I get the usual response of understanding and sympathy, and vague suggestion that it may be addressed. Three years and counting ...
- deleted 11y ago
  [deleted]
- wnevets 11y ago
  >They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. I fall for this everytime I go to use that link.
  - danielweber 11y ago
    The people who dogfood Github, by using it every day, know how to get around places. The people who is it once every week or two, like me, get lost each time. It's always a hunt when I want to figure out how to do something, even if I know I've done it before.
    - haberman 11y ago
      Totally agree. A few examples for me: - From a "pull request / files" view like this (https://github.com/google/protobuf/pull/1191/files https://github.com/google/protobuf/pull/1191/files), when I want to view a whole file, I always want to click on the filename. But the filename isn't a link: you have to look at the right side and click the button that is generically named "View" (View what?). - At the top level of a repo (ie https://github.com/google/protobuf https://github.com/google/protobuf), you can click "X commits" to view the list of commits. But when you go into a subdirectory (ie. https://github.com/google/protobuf/tree/master/benchmarks https://github.com/google/protobuf/tree/master/benchmarks) the "commits" link disappears, and to view the commits in that directory you have to look on the right side instead for a button that says "History". - continuing from my last point, if you view an individual file, (ie. https://github.com/google/protobuf/blob/master/benchmarks/ProtoBench.java https://github.com/google/protobuf/blob/master/benchmarks/Pr...), the "History" link is in yet another place! So between the top level, a subdirectory, and a file, the link to view history is in three different places. I don't follow these links quite often enough that it becomes automatic, so it slows me down every time.
donretag 11y ago
So tempted to add a +1 comment... (This is a joke, please do not do it)
shadowmint 11y ago
Can't wait to see what actually tangible outcome this will have. I think that's far more interesting than that they took 29 days to respond; ok, they did. Deal with it. They have responded now. What's important is what happens next. A public issue tracker? A rust style RFC process? (https://github.com/rust-lang/rfcs https://github.com/rust-lang/rfcs) Just please, whatever you do, do it fast, and stop people from doing what babel did and migrating to phabricator. :P
smoyer 11y ago
Since they only offered a "receipt" for the original letter, why did it take two months? They could have put this response out the same day the "Dear GitHub" letter was posted.
gerbilly 11y ago
And the first response to their letter was a: :+1:
Etheryte 11y ago
What's the point of "we're going to reply next week" post on a Friday? Just make a statement next week.
chappi42 11y ago
Quite nice answer. - Googled for some background and stumbled upon the following: [Danilo Campos, has been known to tweet similarly strong views about diversity. Campos joined in August]: "don't think we'll succeed teaching white, male middle managers empathie and compassion anytime soon so let's limit their scope of damage" Such a rubbish. I think GitHub has their priorities / focus wrong. - Glad I'm using Gitlab.
- robalfonso 11y ago
  A couple of thoughts come up, I'm not a white guy and I'm offended by that guys statement, its prejudiced and I'd be embarrassed if that came out of my mouth. Second if a company is going to trade on being a meritocracy, then be a meritocracy. Why have a diversity council, why be concerned over a bunch of "white guys" and what they can't learn. If they are the best at what they do and if github considers good management traits include compassion and empathy, then whats it matter what color they are the best people would rise up regardless. This is just prejudice plain and simple.
  - hga 11y ago
    Second if a company is going to trade on being a meritocracy.... They haven't for some time: https://www.google.com/search?q=github+meritocracy+rug https://www.google.com/search?q=github+meritocracy+rug
    - kuschku 11y ago
      What GitHub did is the worst possible response. We women get worse education, so the solution is to lower hiring standards for us? Seriously? Lobby for better women education, sponsor groups and events engaging in that, but don't hire less qualified people just for their genitals or their skin color.
      - hga 11y ago
        Except that, in all but the most intangible possible metrics, at least in the US women officially get better educations, as measured by graduation rates, grades, and sanctions including most especially medical interventions (for ADD), for both K-12 and college. And in the former most of their teachers are women.
redsymbol 11y ago
To any githubbers reading this: A lot of people posting here are being unreasonable, demanding, and childish. Recognize that for what it is, don't let it affect you, and just continue moving forward based on the constructive part of the feedback.
- dominotw 11y ago
  thanks coach.
- hueving 11y ago
  Yes, continue to ignore feedback from the community and enjoy your market lead because once you have that users will never leave for another product.
  - deleted 11y ago
    [deleted]
- dreamdu5t 11y ago
  Yeah.. Poor github. I'm playing a tiny violin made of hundreds of millions of dollars.
- searine 11y ago
  >A lot of people posting here are being unreasonable, demanding, and childish. Yes, please ignore all reasonable expectations for communication and go back inside the hugbox.
- Karunamon 11y ago
  I see frankly none of those things here. I see annoyance that it takes a month to respond to a frickin' letter, and I see many opportunities for improvement. A smart organization will focus on that, rather than weak tone arguments.
deleted 11y ago
[deleted]
dreamdu5t 11y ago
Remember it took years just to get them to properly display code that uses tabs (and we still didn't get a simple ui setting).
lhnz 11y ago
If they take 29 days to respond to this, I wonder how long they might take to respond to the fairly shocking allegations within the recent Business Insider article [0]? In fact I wonder if this response was ever going to happen on its own? Perhaps the cause of the response was their recent string of bad press - dear github, business insider, eslint, etc. It strikes me as strange that a company that has so many people focused on community and social impact doesn't have time to talk to its users. I hope they manage to sort themselves out as it's getting embarrassing. [0] https://news.ycombinator.com/item?id=11049067 https://news.ycombinator.com/item?id=11049067
- zzleeper 11y ago
  Maybe the overhauling meant they had no resources to respond? i.e. everyone was busy hiring?
- the_mitsuhiko 11y ago
  Why do they have to respond at all to that article? I fail to see how that article is relevant for anyone who has projects on GitHub.
  - lhnz 11y ago
    They're not being forced into responding. But it was unsettling to hear an anonymous source say they were avoiding interviews on racial grounds. That sounds illegal if it's true - and even if it's not true, surely it's something you should be open about? People care about fairness.
ptio 11y ago
GitHub should consider "open sourcing" GitHub itself so the community can submit PRs and RFPs.
- BinaryIdiot 11y ago
  But if they did that it might hurt their enterprise, non-SaaS, offering considering people could then install it on their own.
  - ptio 11y ago
    True, but that's GitLab's business strategy anyway.
programminggeek 11y ago
TLDR; We've been busy making piles of money in Enterprise land and forgot that we acquire customers via FOSS. Oops.
lcfcjs 11y ago
yeah moan moan over something you use for free, you ungrateful git
shade23 11y ago
this would be a better link : https://github.com/bkeepers/dear-github https://github.com/bkeepers/dear-github
devonoel 11y ago
Github is a large bloated organization that's slow to move, more news at 6. I don't see how it should shock anyone that its taken Github 29 days to respond. Github can't move at the speed of say, an open source project with a hand full of contributors. They're a company of 100s of people. And the larger an organization is, the harder it gets to make a decision about anything, because more people have to agree. In this case, they have to agree about how to respond to open criticism while saving PR face, which is a difficult task. I'm fairly confident that the stink this whole Dear Github thing has raised will result in positive changes of some kind, but let's be real, Github is still just a corporation that faces a lot of the same problems other corporations face. They're probably scrambling to get a whole bunch of people to agree on what it is they should do.
aledalgrande 11y ago
Well, even if quality is declining I wouldn't know where else to go for now. Gerrit doesn't cut it and neither does Bitbucket. Guess we will see.
jcoffland 11y ago
Next we need to figure out how to light this same fire under Docker. In someways they're even worse. They often close issues because they won't be addressed in the next release. I've tried to explain that this is exactly the case where you want to leave an issue open. They said they would think about that but still leave issues they don't want to work on right now closed.
nv-vn 11y ago
Ironic that most of the replies were '+1's
thejameskyle 11y ago
Some of the responses here are kinda obnoxious. I helped kickstart the original letter and I'm very happy about this response. GitHub more than anything has been a blackbox, and this was a very notable first step towards opening up. It should be encouraged, not shut down. Privately (and some publicly), in the past few days, a lot of major open source projects were discussing a coordinated move away from GitHub. This likely puts that all on hold, but we'll see what changes GitHub makes and how people want to respond to it. Again, I'm very happy about this response, as should everyone in this thread. We'll see in the coming weeks what it really means though.
- jcoffland 11y ago
  I'm not sure it puts anything on hold. Some real action might.
- bovermyer 11y ago
  Where would those projects move to? There's no real alternative to GitHub, at least none that combines the social side of it with the Gittiness of it. That I know of, anyway.
  - scrollaway 11y ago
    Gitlab is a worthy alternative. It's only missing critical mass, which gives Github the upper hand in considerations such as "all my foss contributions are on there in one place and that's what companies look at when they offer me a job". Hey, sytse - I know you're reading this. Have you guys thought about a way of including, in gitlab profiles, user info from Github in a non-intrusive way?
    - zyxley 11y ago
      > It's only missing critical mass As somebody who loves Gitlab... no, what it's missing is Github's reputation of lasting uptime reliability. If they get it to the point where people trust it to always be up to the same extent as Github, the rest will follow.
enknamel 11y ago
This is rather a nonresponse. It basically says GitHub read the letter. It makes no promises, proposes no solutions and no timeline. After working in gaming for years we would post responses just like this all the time and get something scheduled 6 months to a year out knowing that just responding with general affirmations would placate customers without having to do actually fix anything.
lutorm 11y ago
The fact that this discussion is being made by committing to a README.md file seems to point to a serious lack of tools for interaction...
trengrj 11y ago
Not sure why they did this on a Friday. I know the standard PR playbook says to release bad news on Friday but I wouldn't call a response to this bad news.
SFjulie1 11y ago
I complain every day more about how we organize our works and need the insanely complex git to collaborate because we have insane ways of producing code. An industry that requires increased insane level of complexity for simple task to "progress" amaze me at failing to get the problem is not in the tools. I can guarantee that for 10 weeks work with "old" technologies (python + whatever static HTML server) I can make a one size fits all website for all restaurant that can be customized without security holes. Make it in a free license so that people make money with my second creation ... on purpose. And we would all win. All the economy from having something simple and well thought. But I can't do it. I am not an influent trend maker so no one will bet a kopek on my business. And you know, these tools cognitive load on the brain, is a load that should be spent on business problems, where cost efficiency matters. Where operational expenses are better kept low whatever the initial investment is. The fact we all use at least git (+ a ticket tracker) that are heavyweight, should tell us that we are dangerously inflating the cost of building software. Hence, contradicting our very primary reason to be : which is to diminish operational expenses the most we can. And we still have not proven anything about how much money this increased expenses due to complexity finally create value anywhere... In decreased price, decreased incidents, higher quality, better jobs, better economical growth ... saved lives...business values true SLA (and not the one measured by the editors/operators)... So, well, github may not be the problem.
avitzurel 11y ago
I think a lot of the disappointed comments are understandable here. (obnoxious or not). I know I personally expected one of either to happen 1. Github responds in 2-3 days with the EXACT response they made. 2. Github responds in 1-2 weeks with a concrete plans that addresses at least some of the concerns the original letter addressed. They basically did the bad combination of both. One of the things that frustrates me the most about companies responding to feedback is "We have it planned" and "we don't have an exact timeline". More than anything I really dislike the "stay tuned". I don't want to stay tuned, you should either tell me when to expect it or I will tune out (and I think that's what most people think). To me, this is a non-response. I like Github, I use it every day. I don't have any plans to move away from Github. If I had a project that I felt wasn't fit for Github, this response would not change anything for me, I would still likely research for alternatives.
camhenlin 11y ago
Has anyone else made the decision to switch due to github's internal racism and sexism rather than technical reasons? That's my biggest reason for looking at alternatives lately (although I haven't made the move yet, but plan to as soon as I have some spare time)
- Revisor 11y ago
  We haven't switched an existing project, but we're looking around for a place for a new library we're going to publish in a few weeks. It will most probably be on Assembla or Gitlab.
barely_stubbell 11y ago
What I want, more than anything, is to search on commit hashes.
alexandrerond 11y ago
Oh wow, that's all they have to say after weeks? Funny enough Gitlab responded in hours. Opportunistic or not, that is why people are taking it seriously.
erikb 11y ago
Businesses are ridiculously slow. What I can tell you about a business that is a blackbox to you which will surprise you: It's a blackbox to them as well. They just don't know how to manage so many people and ideas. And the sad part is most managers don't. So I don't think it will change. The solution would be to educate the manager about how to find out what's not working and how to resolve such problems, or switch the manager with one that is willing to constantly work on getting things to work instead of just keeping the head above the water. It's a really hard problem though, since as an employee you don't gain much by resolving true systematic problems, and you even may lose some value with your coworkers by changing their daily processes that they are used to so well. It's really something that must come from the top, but if there is nobody to do that then it won't happen.
quadrangle 11y ago
Right, this is typical for proprietary software. Everyone has to beg and petition and then if a company isn't awful, they'll respond and do something. Meanwhile, you still can't adapt things to your needs or submit pull requests or otherwise do what you could with free/libre/open tools. And if GitHub does a good job addressing these requests, it will encourage everyone to stay with GitHub… where we're still helpless serfs. If we all demand software freedom, then we won't be so helpless in the future with whatever issues come up.

763 points by joshmanders 11y ago

That took a long long time for them to respond. It's day 29 now. In fact, they could have communicated something after even a week - probably something similar to what they have actually written, only more 'We're looking at your list and we'll try to get back to you as soon as possible'. Where is Jono Bacon in all of this? edit: OK, I feel kind of bad for mentioning Jono because I've watched him do awesome things over the years. I've sent him an email out of the blue asking him to respond - hopefully he gets it.

petetnt 11y ago
They did sort of respond on the initial HN thread though. Commenting means committing and if you do the wrong decision in haste, you might screwed up in the process (as an individual or a company). Is 29 days too long? Maybe. They do address the slowness on the commit too and they provided a timeline.
- chris_wot 11y ago
  Oh, I'm glad they did respond :-) In fact, I actually think that if they hadn't responded they would be seeing an exodus of projects. Given that the issues being highlighted in that letter are long standing though, I don't think it would have been hasty to say that they appreciate the feedback and they are reviewing. It's great of course that they responded on HN. But the fact that they only responded on HN and had no way of responding on their own site is... a bit embarrassing actually! At least I sort of feel that they should feel that way. I actually pay for their lowest monthly tier as my needs are very limited. I largely like GitHub and will stick with them, but they just have to do something about their community engagement. If they don't, then someone is going to eat their lunch! edit: kind of surprised at how some are responding to my comment - what did I say that was so wrong? I'm genuinely curious - it's not just me saying and thinking this, after all!
  - deleted 11y ago
    [deleted]
  - deleted 11y ago
    [deleted]
joshmanders 11y ago
I agree with you, and when Jono made his post on the original Hacker News thread, I immediately followed him on twitter and even CC'd him on tweets that had people talking about things hoping that he'd respond to them, at least post a public post outside of the HN thread saying that they're working on things... But he was more worried about promoting the community leadership summit. Kind of sad honestly. Not very good community leadership by ignoring your own community to promote a community leadership conference.
- chris_wot 11y ago
  To be fair, he was flying into linux.conf.au all the way in Geelong - that's a long flight. It could well have been that he's recovering - I notice that his last blog post was February 1st. And of course I'm kicking myself that I missed the conference entirely. Sigh. Next year I guess.
  - jonobacon 11y ago
    You are not kidding about the long flight. I wish someone could move Australia a little closer to California. :-) Hope to see you at linux.conf.au next year, chris_wot! :-)
    - chris_wot 11y ago
      Thanks Jono :-)
dmethvin 11y ago
I have to assume he's been told not to speak about details until the executives came up with a plan. If that is the case, GitHub management is really making his job a living hell. Why have someone whose job it is to work with the community if everything has to be micro-managed by higher-ups?
jonobacon 11y ago
My apologies for the lack of public responsiveness. Thanks, chris_wot, for jumpstarting the discussion. As outlined in Brandon's post linked here, we have been taking some time to really delve into the core of these issues and explore what the best solutions are. This has involved some internal discussion as well as reaching out to various parts of our community to gather feedback and perspectives. We take these concerns really seriously and want to ensure we can explore the best long and short-term solutions. As you can probably understand, we want to have some of our ducks in a row before sharing some next steps. Rest assured that even though there has not been much publicly shared yet, we are definitely exploring ways to address these issues.
deleted 11y ago
[deleted]

eibrahim 11y ago

Wow, It took them 29 days to say "we hear you stay tuned"

drinchev 11y ago
Some other companies usually don't reply at all. E.g. Apple, Microsoft, etc.
- giancarlostoro 11y ago
  It's really sad though when you consider gitlab answered a while back.
- chris_wot 11y ago
  And have suffered for it in the past (though Apple, less so, it is true).
  - pluma 11y ago
    But Apple has a reputation of not saying anything outside of the big releases and for the most part didn't have to be responsive because the periodic hype usually drowned out any criticism. GitHub on the other hand largely owes its reputation to how it is perceived by open source communities. Their perceived value is based less on the quality of their product(s) and more on being the place all open source projects live (moreso than even SourceForge ever was -- even companies like Google and Microsoft have moved their open source projects to GitHub simply because that's where developers expect open source projects to live). Apple can get by largely on marketing and the perceived quality of their products. GitHub relies on open source projects, even if they don't make any money of them directly. Hosting open source projects is just an advertising expense. If the majority of noteworthy open source projects left GitHub (especially if they left to the same platform, e.g. GitLab.com or BitBucket) their reputation as "the place where open source projects live" would evaporate and they'd have to fight the same friction for new users as their competitors. Additionally they'd probably become less interesting for third-party integrations as they can no longer serve as a cheap showcase for those products/services. This would again harm their appeal to paid users.

bhouston 11y ago

Brutal delay in responding to their most important constituent? What the hell? This wasn't a minor user's feature request, it was an open letter signed by a ton of major open source leaders. If I was an investor in GitHub I would fire the CEO.

bryanlarsen 11y ago
That's the problem. GitHub brass thinks their most important constituent is the people paying thousands of dollars to buy GitHub Enterprise. The only reason they have the enterprise customers is because they got popular with open source first. However, at this point their enterprise popularity may be big enough that success there is self-sustaining -- enterprises make decisions based more on what other enterprises do rather than on what open source and small companies do. That being said, I bet that enterprises are screaming about Issues too. Enterprise loves their custom fields.
- ageofwant 11y ago
  Enterprises use JIRA and various github plugins, works a treat and keeps PM types happy. This is about OSS projects that are to small for JIRA/Bugzilla, but have outgrown the limited github issue tracker.
- x1024 11y ago
  You say that, but much has changed in the past 10 years. If it truly were "up to enterprises", we wouldn't be using Git in the first place.
  - deleted 11y ago
    [deleted]
- mietek 11y ago
  > The only reason they have the enterprise customers is because they got popular with open source first. I have absolutely no idea how GitHub could have lost sight of this simple fact.

sotojuan 11y ago

I'll be more optimistic and be happy they replied and very interested in what they have in store. They say "next week" and it's Friday so it won't take that long.

punnerud 11y ago

"Issues haven't gotten much attention from GitHub these past few years and that was a mistake, but we've never stopped thinking about or caring about you and your communities." A lot of thinking but no action. Github, what have you been up to these years??

oldmanjay 11y ago
Keeping a gigantic software application running, mainly. The ease of your role as a bystander and critic in no way reflects the work they have to do to keep the system up.
acdha 11y ago
You can see a list by scrolling through: https://github.com/blog https://github.com/blog One of the more obvious things is that running a huge, popular app is non-trivial, particularly if your users do things which get e.g. governments to attack your site.

tacos 11y ago

I wish more companies would take more time to respond to these sorts of situations. Perhaps this was excessive (I see conflicting reports of where they responded and when). But... Let things cool off, take a hard look at things internally, get the stakeholders committed to actual change, then provide an update. I'm far more likely to believe that then even a perfectly executed PR play. I've watched even the most pathological and idiotic tech people get good at those the past 10 years. Beware people with good haircuts who say nothing and only appear during times of trouble.

sangnoir 11y ago
> Let things cool off, take a hard look at things internally, get the stakeholders committed to actual change, then provide an update. This is not an update - this is "we're looking into it", which should precede the internal soul-searching and actual change. They should have released this the moment they decided they were going to look into it - to outsiders, that moment seemed to be 29 days after the open letter was published.

Siecje 11y ago

I wonder if this has more to do with ESLint[1] than the letter. [1]:https://github.com/eslint/eslint/issues/5205 https://github.com/eslint/eslint/issues/5205

jglovier 11y ago
Nope. We'd been working on our response ever since Dear GitHub was published. It just took a little time because we wanted to think long and hard about our response - beyond just the words we used to respond – and actually consider how we are interacting with the community, and where we can make demonstrable improvements. It is just coincidence that the ESLint thread happened this week, and our response came out today.
- chris_wot 11y ago
  You really should consider telling those who filed the letter that you were at least working on it. Did you expect them to know?!?
  - eric_h 11y ago
    Someone, not the GP, did: https://news.ycombinator.com/item?id=10905338 https://news.ycombinator.com/item?id=10905338
  - stronglikedan 11y ago
    Did they who filed the letter ask? If they asked and didn't get a reply to the effect of "we're working on it", then I can see your point. If they didn't ask, well then that's on them. I not finding any stories about them asking about what's going on and not receiving a reply, so I'll assume the latter, since I'm sure the former would have been posted about.
    - chris_wot 11y ago
      Who, precisely, were they meant to ask? Perhaps you should reread that letter: However, many of us are frustrated. Those of us who run some of the most popular projects on GitHub feel completely ignored by you. We’ve gone through the only support channel that you have given us either to receive an empty response or even no response at all. We have no visibility into what has happened with our requests, or whether GitHub is working on them.

progx 11y ago

Thank you GitHub, to know that you need 29 days to reply, let my OpenSource GitHub Project look not soooo bad. :-)

r3bl 11y ago
It took GitHub's support exactly 82 days to respond to my issue[1]. In the end, I literally had to ask a GitHub employee on his AMA to look up what the hell is going on. [1] https://blog.r3bl.me/en/worst-support-experience-ever/ https://blog.r3bl.me/en/worst-support-experience-ever/

miseg 11y ago

That's a great question on the page by EGreg: > I wonder if GitHub itself can use its own issues system for prioritizing feature requests and bugs :-)

ageofwant 11y ago

Great, but please resist the urge and goading to build another JIRA in github. The second best thing about github is its simplicity.

ivl 11y ago
I don't thin something that size would be warranted. But, letting users customize Issues, and PR/merge rules, and splitting off another section for requests would be beautiful.
steveklabnik 11y ago
This is exactly my fear as well. I really, really like how simple GitHub issues are. While I have some very minor quibbles, I'm also afraid that change here will end up being worse, not better.
joshrowley 11y ago
In an ideal world, the Issues team would develop and support a plugin ecosystem for the tracker. Users can customize and add the features they see fit and even create their own custom plugins. Allows flexibility and power for those who want it while keeping the core simple and clean
- tomschlick 11y ago
  This is the best idea. While some features like +1s and contributing guidelines should be baked in, other features like extra fields, requiring people to sign a disclosure, etc would be best left to plugins that can hook into issues much like CI services hook into pull requests.

mirashii 11y ago

Now, if only we could get a movement behind a "merge" button that does fast-forward only commits.

jquast 11y ago
or squash
zanny 11y ago
I know that gitlab has it as a project option!
scrollaway 11y ago
Agreed, and here's a git alias I made for the occasion: merge-pr = "!f() { git fetch $1 $2; git branch _FETCH_HEAD FETCH_HEAD && git rebase HEAD _FETCH_HEAD && git checkout master && git merge --ff-only _FETCH_HEAD; git branch -d _FETCH_HEAD; }; f" Syntax: `git merge-pr <remote> <branch>`. You can copypaste url + branch from github's UI above the merge button. Note: This merges only to master, no way to specify another merge target. Feel free to suggest improvements.
- danielsamuels 11y ago
  I have these for merging a PR into develop and master respectively. Usage is `git pr <#>` pr = "!f() { git checkout develop && git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1 && git rebase -i origin/develop && git checkout develop && git merge - && git push; }; f" prm = "!f() { git checkout master && git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1 && git rebase -i origin/master && git checkout master && git merge - && git push; }; f"
  - scrollaway 11y ago
    I remember trying and failing to get exactly that working. I'll give yours a shot, thanks!
- cletusw 11y ago

greggman 11y ago

I don't have any giant opens source projects so I guess I don't get bothered by the +1s and cries for help. Chromium gets those on their non-github issues. So does Firefox. I'm guessing WebKit does too. My biggest issue, which I guess is a non-issue for most others?, is I hate when reviewing a PR that every single line comment generates a message/email. Maybe it's because I'm used to Rietveld but my normal workflow is to start reading the patch and adding comments. I might have made 10 separate line comments before I get to a part of the patch that invalidates all those comments. Therefore I don't want them sent until I'm ready. I want to be able to make line comments across all files in the PR and only when I'm ready, send them as one coherent message. As it is now, AFAICT, the only way to do this is to write line comments in some other file on my computer and then later manually find the lines again in github and add them one at a time. Rietveld also lets you respond to line comments inline and mark them as "done". is there anything for github that does the same? Maybe one of their offline tools?

jsight 11y ago
Excellent idea... some notion of a review session would be nice.
chris_wot 11y ago
Gerrit does this as well.
mconley 11y ago
Review Board works with GitHub and allows you to publish your review when you're ready.
spankalee 11y ago
Just continue to use Reitveld :)
masklinn 11y ago
> My biggest issue, which I guess is a non-issue for most others?, is I hate when reviewing a PR that every single line comment generates a message/email. > is there anything for github that does the same? Maybe one of their offline tools? Nope. Even the API doesn't allow this, you can only create one "review comment" at a time and no matter how fast you create them (or if you carefully create all of them over a persistent connection) each and every one of them will generate one notification and one outbound mail. That went pretty well the first time I tried to get a linter to annotate a PR. The annotation worked, but I discovered some people's mailboxes can not handle getting 50 mails from the same source in a fraction of a second (and oddly enough people are not fond of getting 50 one-line emails from the same place). (I asked github support about it, they confirmed the only workaround is to not use inline comments)

rafael-rinaldi 11y ago

I would love to know what the reasonable approach would be ideal from the people talking bad things about GitHub. If they responded to issues right away people would complain too. It's not easy to come up with a solid plan for new features and improvements, specially in a company this big (that has a lot going on as we all know). What? You think they're going to get that list of complaints and start smashing some code? That letter is not even 1 month old. I can kinda understand the frustration but keep in mind that there's a lot of other things to handle, it's more complicated than that. In the meantime if you're really struggling, there are other great options available out there like BitBucket and GitLab.

chris_wot 11y ago
Then they might have grown too quickly then. At this point, is really not that hard to move to GitLab.
merpnderp 11y ago
A reasonable approach? When I'm in doubt, I just go with the truth. They could have said "Hey, we hear you, we're starting a group to figure out how best to resolve your issues." or "Hey, we've already been working on this, we'll get back to you in a couple of months." Or even a "Hey, we get you aren't completely happy, but we just don't have the time to address your concerns right no, but when we can, we will." Any of those would have been better than perfect silence followed with, we'll see what we can do.
- rafael-rinaldi 11y ago
  Well, they just published a down to earth response didn't they? Some companies don't even respond at all. As I said, I can understand the frustration but they seem to be working on it. Give them some time or use other tools if you can't wait.
forgottenpass 11y ago
I would love to know what the reasonable approach would be ideal from the people talking bad things about GitHub. Treat their software development savvy usebase as stakeholders in their ongoing project rather than unwashed masses consuming a loss leader? A mutually-agreeable reasonable approach probably doesn't exist. Limited visibility into the project may be considered exposing too much of the business for GitHub's tastes. So it will continue to be a one-way relationship, with all the baggage that comes with a one-way relationship (incl "talking bad things").

tptacek 11y ago

From reading the comments on this thread, one could get the impression that HN Github users would have been happier had Github not responded at all.

chris_wot 11y ago
That's an odd impression for you to have gotten!
beachstartup 11y ago
once the troll is fed the appetizers, it demands the main course.
striking 11y ago
I think some people are miffed that it took them almost a month to just respond to the letter. Maybe you don't care as much about certain software, but some people are really passionate about it. Perhaps HNers would have appreciated some more substantive action by now, rather than just a response.
- tptacek 11y ago
  I'm confused by what these people are asking for. Should Github acquire a time machine? If so, instead of asking for an earlier response to this later, maybe they could just do things differently from the beginning so the letter was never necessary!
  - striking 11y ago
    Being flippant is really unhelpful, and kind of insulting. People really care about software. Instead of just responding to us now with a letter that's totally sparse on details, what if GitHub gave us an idea of what they're actually going to do? "We're sorry" is really annoying to hear almost a month after the fact.
    - cortesoft 11y ago

VeejayRampay 11y ago

Reading the reactions to their addressing the complaints, I really don't envy the folks at Github. A lot of folks in the "Yeah that's nice but what about X/Y/Z" range (and same here on HN). There's simply no winning.

ohitsdom 11y ago
It'd be a little easier to identify key requests if they implemented voting to solve the "+1" comments, as identified in the "Dear Github" letter.
dreamdu5t 11y ago
Yes and no. Some feature requests were years old and hugely popular. For example, displaying tab-spaces code (such as Go) properly was something that took years to implement, despite the enormous feature request thread and extremely simple implementation. It became obvious github had dedicated zero resources to building new features the community had longed-for

elliotpage 11y ago

I just hope they also add new features centering around depreciation of repos and the ability to add a "THIS IS NO LONGER BEING MAINTAINED" flag or an equivalent. Finding a repo that appears to solve my problems only to find a mass of issues and an absent maintainer is a pretty big time sink, for both me and likely the maintainer too!

Blahah 11y ago
It's pretty easy right now to just change the header of the README, and/or the project description to indicate deprecation. What added benefit would making it a feature provide?
- RichieAHB 11y ago
  It requires the maintainer to do this. Often if the maintainer isn't maintaining the codebase then they won't be updating the readme either.
  - Karunamon 11y ago
    Wouldn't it be up to the maintainer to toggle the "no longer maintained" flag? Sometimes a project that hasn't seen commits in a long time isn't orphaned, but just doesn't need changes...
deleted 11y ago
[deleted]
- deleted 11y ago
  [deleted]
  - deleted 11y ago
    [deleted]
mattcantstop 11y ago
I usually look at the "Pulse" part of the repo page. That tells me how often it has activity and if it is an active repo.

rogerbinns 11y ago

I complain every 6 months about their "releases" page - eg this one for my project https://github.com/rogerbinns/apsw/releases https://github.com/rogerbinns/apsw/releases They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. But the repository is in a maintainer state, so the "Source Code" isn't useful to an end user because various tools need to be run (eg building help, automake/autoconf, dependencies). The people mislead by Github due to this "Source Code" contact me, not github. Every six months for several years, I send the email explaining how this doesn't serve anyone's interest, how it hurts, and that I am happy with any solution (eg don't auto add, change the name to make it clear, be able to label an existing file as the "Source Code" etc). I get the usual response of understanding and sympathy, and vague suggestion that it may be addressed. Three years and counting ...

deleted 11y ago
[deleted]
wnevets 11y ago
>They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. I fall for this everytime I go to use that link.
- danielweber 11y ago
  The people who dogfood Github, by using it every day, know how to get around places. The people who is it once every week or two, like me, get lost each time. It's always a hunt when I want to figure out how to do something, even if I know I've done it before.
  - haberman 11y ago
    Totally agree. A few examples for me: - From a "pull request / files" view like this (https://github.com/google/protobuf/pull/1191/files https://github.com/google/protobuf/pull/1191/files), when I want to view a whole file, I always want to click on the filename. But the filename isn't a link: you have to look at the right side and click the button that is generically named "View" (View what?). - At the top level of a repo (ie https://github.com/google/protobuf https://github.com/google/protobuf), you can click "X commits" to view the list of commits. But when you go into a subdirectory (ie. https://github.com/google/protobuf/tree/master/benchmarks https://github.com/google/protobuf/tree/master/benchmarks) the "commits" link disappears, and to view the commits in that directory you have to look on the right side instead for a button that says "History". - continuing from my last point, if you view an individual file, (ie. https://github.com/google/protobuf/blob/master/benchmarks/ProtoBench.java https://github.com/google/protobuf/blob/master/benchmarks/Pr...), the "History" link is in yet another place! So between the top level, a subdirectory, and a file, the link to view history is in three different places. I don't follow these links quite often enough that it becomes automatic, so it slows me down every time.

donretag 11y ago

So tempted to add a +1 comment... (This is a joke, please do not do it)

shadowmint 11y ago

Can't wait to see what actually tangible outcome this will have. I think that's far more interesting than that they took 29 days to respond; ok, they did. Deal with it. They have responded now. What's important is what happens next. A public issue tracker? A rust style RFC process? (https://github.com/rust-lang/rfcs https://github.com/rust-lang/rfcs) Just please, whatever you do, do it fast, and stop people from doing what babel did and migrating to phabricator. :P

smoyer 11y ago

Since they only offered a "receipt" for the original letter, why did it take two months? They could have put this response out the same day the "Dear GitHub" letter was posted.

gerbilly 11y ago

And the first response to their letter was a: :+1:

Etheryte 11y ago

What's the point of "we're going to reply next week" post on a Friday? Just make a statement next week.

chappi42 11y ago

Quite nice answer. - Googled for some background and stumbled upon the following: [Danilo Campos, has been known to tweet similarly strong views about diversity. Campos joined in August]: "don't think we'll succeed teaching white, male middle managers empathie and compassion anytime soon so let's limit their scope of damage" Such a rubbish. I think GitHub has their priorities / focus wrong. - Glad I'm using Gitlab.

robalfonso 11y ago
A couple of thoughts come up, I'm not a white guy and I'm offended by that guys statement, its prejudiced and I'd be embarrassed if that came out of my mouth. Second if a company is going to trade on being a meritocracy, then be a meritocracy. Why have a diversity council, why be concerned over a bunch of "white guys" and what they can't learn. If they are the best at what they do and if github considers good management traits include compassion and empathy, then whats it matter what color they are the best people would rise up regardless. This is just prejudice plain and simple.
- hga 11y ago
  Second if a company is going to trade on being a meritocracy.... They haven't for some time: https://www.google.com/search?q=github+meritocracy+rug https://www.google.com/search?q=github+meritocracy+rug
  - kuschku 11y ago
    What GitHub did is the worst possible response. We women get worse education, so the solution is to lower hiring standards for us? Seriously? Lobby for better women education, sponsor groups and events engaging in that, but don't hire less qualified people just for their genitals or their skin color.
    - hga 11y ago
      Except that, in all but the most intangible possible metrics, at least in the US women officially get better educations, as measured by graduation rates, grades, and sanctions including most especially medical interventions (for ADD), for both K-12 and college. And in the former most of their teachers are women.

redsymbol 11y ago

To any githubbers reading this: A lot of people posting here are being unreasonable, demanding, and childish. Recognize that for what it is, don't let it affect you, and just continue moving forward based on the constructive part of the feedback.

dominotw 11y ago
thanks coach.
hueving 11y ago
Yes, continue to ignore feedback from the community and enjoy your market lead because once you have that users will never leave for another product.
- deleted 11y ago
  [deleted]
dreamdu5t 11y ago
Yeah.. Poor github. I'm playing a tiny violin made of hundreds of millions of dollars.
searine 11y ago
>A lot of people posting here are being unreasonable, demanding, and childish. Yes, please ignore all reasonable expectations for communication and go back inside the hugbox.
Karunamon 11y ago
I see frankly none of those things here. I see annoyance that it takes a month to respond to a frickin' letter, and I see many opportunities for improvement. A smart organization will focus on that, rather than weak tone arguments.

deleted 11y ago

[deleted]

dreamdu5t 11y ago

Remember it took years just to get them to properly display code that uses tabs (and we still didn't get a simple ui setting).

lhnz 11y ago

If they take 29 days to respond to this, I wonder how long they might take to respond to the fairly shocking allegations within the recent Business Insider article [0]? In fact I wonder if this response was ever going to happen on its own? Perhaps the cause of the response was their recent string of bad press - dear github, business insider, eslint, etc. It strikes me as strange that a company that has so many people focused on community and social impact doesn't have time to talk to its users. I hope they manage to sort themselves out as it's getting embarrassing. [0] https://news.ycombinator.com/item?id=11049067 https://news.ycombinator.com/item?id=11049067

zzleeper 11y ago
Maybe the overhauling meant they had no resources to respond? i.e. everyone was busy hiring?
the_mitsuhiko 11y ago
Why do they have to respond at all to that article? I fail to see how that article is relevant for anyone who has projects on GitHub.
- lhnz 11y ago
  They're not being forced into responding. But it was unsettling to hear an anonymous source say they were avoiding interviews on racial grounds. That sounds illegal if it's true - and even if it's not true, surely it's something you should be open about? People care about fairness.

ptio 11y ago

GitHub should consider "open sourcing" GitHub itself so the community can submit PRs and RFPs.

BinaryIdiot 11y ago
But if they did that it might hurt their enterprise, non-SaaS, offering considering people could then install it on their own.
- ptio 11y ago
  True, but that's GitLab's business strategy anyway.

programminggeek 11y ago

TLDR; We've been busy making piles of money in Enterprise land and forgot that we acquire customers via FOSS. Oops.

lcfcjs 11y ago

yeah moan moan over something you use for free, you ungrateful git

shade23 11y ago

this would be a better link : https://github.com/bkeepers/dear-github https://github.com/bkeepers/dear-github

devonoel 11y ago

Github is a large bloated organization that's slow to move, more news at 6. I don't see how it should shock anyone that its taken Github 29 days to respond. Github can't move at the speed of say, an open source project with a hand full of contributors. They're a company of 100s of people. And the larger an organization is, the harder it gets to make a decision about anything, because more people have to agree. In this case, they have to agree about how to respond to open criticism while saving PR face, which is a difficult task. I'm fairly confident that the stink this whole Dear Github thing has raised will result in positive changes of some kind, but let's be real, Github is still just a corporation that faces a lot of the same problems other corporations face. They're probably scrambling to get a whole bunch of people to agree on what it is they should do.

aledalgrande 11y ago

Well, even if quality is declining I wouldn't know where else to go for now. Gerrit doesn't cut it and neither does Bitbucket. Guess we will see.

jcoffland 11y ago

Next we need to figure out how to light this same fire under Docker. In someways they're even worse. They often close issues because they won't be addressed in the next release. I've tried to explain that this is exactly the case where you want to leave an issue open. They said they would think about that but still leave issues they don't want to work on right now closed.

nv-vn 11y ago

Ironic that most of the replies were '+1's

thejameskyle 11y ago

Some of the responses here are kinda obnoxious. I helped kickstart the original letter and I'm very happy about this response. GitHub more than anything has been a blackbox, and this was a very notable first step towards opening up. It should be encouraged, not shut down. Privately (and some publicly), in the past few days, a lot of major open source projects were discussing a coordinated move away from GitHub. This likely puts that all on hold, but we'll see what changes GitHub makes and how people want to respond to it. Again, I'm very happy about this response, as should everyone in this thread. We'll see in the coming weeks what it really means though.

jcoffland 11y ago
I'm not sure it puts anything on hold. Some real action might.
bovermyer 11y ago
Where would those projects move to? There's no real alternative to GitHub, at least none that combines the social side of it with the Gittiness of it. That I know of, anyway.
- scrollaway 11y ago
  Gitlab is a worthy alternative. It's only missing critical mass, which gives Github the upper hand in considerations such as "all my foss contributions are on there in one place and that's what companies look at when they offer me a job". Hey, sytse - I know you're reading this. Have you guys thought about a way of including, in gitlab profiles, user info from Github in a non-intrusive way?
  - zyxley 11y ago
    > It's only missing critical mass As somebody who loves Gitlab... no, what it's missing is Github's reputation of lasting uptime reliability. If they get it to the point where people trust it to always be up to the same extent as Github, the rest will follow.

enknamel 11y ago

This is rather a nonresponse. It basically says GitHub read the letter. It makes no promises, proposes no solutions and no timeline. After working in gaming for years we would post responses just like this all the time and get something scheduled 6 months to a year out knowing that just responding with general affirmations would placate customers without having to do actually fix anything.

lutorm 11y ago

The fact that this discussion is being made by committing to a README.md file seems to point to a serious lack of tools for interaction...

trengrj 11y ago

Not sure why they did this on a Friday. I know the standard PR playbook says to release bad news on Friday but I wouldn't call a response to this bad news.

SFjulie1 11y ago

I complain every day more about how we organize our works and need the insanely complex git to collaborate because we have insane ways of producing code. An industry that requires increased insane level of complexity for simple task to "progress" amaze me at failing to get the problem is not in the tools. I can guarantee that for 10 weeks work with "old" technologies (python + whatever static HTML server) I can make a one size fits all website for all restaurant that can be customized without security holes. Make it in a free license so that people make money with my second creation ... on purpose. And we would all win. All the economy from having something simple and well thought. But I can't do it. I am not an influent trend maker so no one will bet a kopek on my business. And you know, these tools cognitive load on the brain, is a load that should be spent on business problems, where cost efficiency matters. Where operational expenses are better kept low whatever the initial investment is. The fact we all use at least git (+ a ticket tracker) that are heavyweight, should tell us that we are dangerously inflating the cost of building software. Hence, contradicting our very primary reason to be : which is to diminish operational expenses the most we can. And we still have not proven anything about how much money this increased expenses due to complexity finally create value anywhere... In decreased price, decreased incidents, higher quality, better jobs, better economical growth ... saved lives...business values true SLA (and not the one measured by the editors/operators)... So, well, github may not be the problem.

avitzurel 11y ago

I think a lot of the disappointed comments are understandable here. (obnoxious or not). I know I personally expected one of either to happen 1. Github responds in 2-3 days with the EXACT response they made. 2. Github responds in 1-2 weeks with a concrete plans that addresses at least some of the concerns the original letter addressed. They basically did the bad combination of both. One of the things that frustrates me the most about companies responding to feedback is "We have it planned" and "we don't have an exact timeline". More than anything I really dislike the "stay tuned". I don't want to stay tuned, you should either tell me when to expect it or I will tune out (and I think that's what most people think). To me, this is a non-response. I like Github, I use it every day. I don't have any plans to move away from Github. If I had a project that I felt wasn't fit for Github, this response would not change anything for me, I would still likely research for alternatives.

camhenlin 11y ago

Has anyone else made the decision to switch due to github's internal racism and sexism rather than technical reasons? That's my biggest reason for looking at alternatives lately (although I haven't made the move yet, but plan to as soon as I have some spare time)

Revisor 11y ago
We haven't switched an existing project, but we're looking around for a place for a new library we're going to publish in a few weeks. It will most probably be on Assembla or Gitlab.

barely_stubbell 11y ago

What I want, more than anything, is to search on commit hashes.

alexandrerond 11y ago

Oh wow, that's all they have to say after weeks? Funny enough Gitlab responded in hours. Opportunistic or not, that is why people are taking it seriously.

erikb 11y ago

Businesses are ridiculously slow. What I can tell you about a business that is a blackbox to you which will surprise you: It's a blackbox to them as well. They just don't know how to manage so many people and ideas. And the sad part is most managers don't. So I don't think it will change. The solution would be to educate the manager about how to find out what's not working and how to resolve such problems, or switch the manager with one that is willing to constantly work on getting things to work instead of just keeping the head above the water. It's a really hard problem though, since as an employee you don't gain much by resolving true systematic problems, and you even may lose some value with your coworkers by changing their daily processes that they are used to so well. It's really something that must come from the top, but if there is nobody to do that then it won't happen.

quadrangle 11y ago

Right, this is typical for proprietary software. Everyone has to beg and petition and then if a company isn't awful, they'll respond and do something. Meanwhile, you still can't adapt things to your needs or submit pull requests or otherwise do what you could with free/libre/open tools. And if GitHub does a good job addressing these requests, it will encourage everyone to stay with GitHub… where we're still helpless serfs. If we all demand software freedom, then we won't be so helpless in the future with whatever issues come up.