GitHub responds to Dear GitHub letter(github.com)
github.com
GitHub responds to Dear GitHub letter
https://github.com/dear-github/dear-github/pull/115
349 comments
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.
That I know of, anyway.
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?
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?
Great idea! I created an issue https://gitlab.com/gitlab-org/gitlab-ce/issues/13401
While you are here, I have a question. As far as I can tell neither your service nor Github nor Bitbucket have a way for a user to organize their repositories other than a list.
This gets annoying if one has many unrelated projects.
For instance, I have some chess projects, some math projects, some Warhammer Online projects, and so on. With the linear list approach if I want some semblance of order I need to resort to a kludge like prefixing the names with chess- and math- and WAR- and so on and using sort-by-name.
It would be a lot easier to deal with if I could have a chess folder and math folder and WAR folder and put the appropriate projects there. Even better would be multiple levels of folders, and allowing a project to be in more than one folder at a time.
In the project information, there is a field to enter a list of tags. I tried using that, with the idea that someone who wanted to see all my chess projects, say, could look for all projects I tagged "chess".
Two problems: (1) I could not figure out what these tags actually do other than show up on the project settings page, and (2) I could not find any help on them in the Gitlab documentation because searching for "tags" brings up a bazillion things about Git tags. Maybe these should be called "labels" instead of "tags"?
I see that there is a Groups feature, and I have not yet had a chance to delve into that to see if it can substitute for folders.
This gets annoying if one has many unrelated projects.
For instance, I have some chess projects, some math projects, some Warhammer Online projects, and so on. With the linear list approach if I want some semblance of order I need to resort to a kludge like prefixing the names with chess- and math- and WAR- and so on and using sort-by-name.
It would be a lot easier to deal with if I could have a chess folder and math folder and WAR folder and put the appropriate projects there. Even better would be multiple levels of folders, and allowing a project to be in more than one folder at a time.
In the project information, there is a field to enter a list of tags. I tried using that, with the idea that someone who wanted to see all my chess projects, say, could look for all projects I tagged "chess".
Two problems: (1) I could not figure out what these tags actually do other than show up on the project settings page, and (2) I could not find any help on them in the Gitlab documentation because searching for "tags" brings up a bazillion things about Git tags. Maybe these should be called "labels" instead of "tags"?
I see that there is a Groups feature, and I have not yet had a chance to delve into that to see if it can substitute for folders.
I'm not sure this exactly addresses your issue, but BitBucket very recently released a concept called "projects" for grouping repositories.
https://confluence.atlassian.com/bitbucket/projects-79249795...
Unfortunately, it's only for teams right now, it seems. Additionally, (and this may only be a me concern) you can't include repos in more than one project, like in the case that you have a common framework you build between separate projects. I mentioned this to them (may have even had a support request), but haven't gotten any feedback.
Basically, it's much more rigid that I personally find useful, but it seems like their first step in the right direction.
[Edit] Seems kannonboy said the same thing, but I'll leave my opinions here. Interested to see if anyone else has used it and has any opinions.
https://confluence.atlassian.com/bitbucket/projects-79249795...
Unfortunately, it's only for teams right now, it seems. Additionally, (and this may only be a me concern) you can't include repos in more than one project, like in the case that you have a common framework you build between separate projects. I mentioned this to them (may have even had a support request), but haven't gotten any feedback.
Basically, it's much more rigid that I personally find useful, but it seems like their first step in the right direction.
[Edit] Seems kannonboy said the same thing, but I'll leave my opinions here. Interested to see if anyone else has used it and has any opinions.
There are two things that might be relevant to your request. In GitLab you can star repo's and show that, obviously this would mean only one list. And we would love to see nested groups https://gitlab.com/gitlab-org/gitlab-ce/issues/2772 although this would require you to move the projects under the chess namespace.
It seems like you guys are proceeding down the directories path to solve this issue-is there any reason that semantic tagging wasn't considered? It would appear to be a good fit and might solve the nesting issue, but I could have totally missed some conflicting requirements. (I admit I was flipping through the issue thread fairly quickly)
Our main goal is to solve the 'android repos problem' therefore the nesting was the most natural thing.
Just a small clarification, both Bitbucket Cloud and Server have Projects[1] that allow you to organize related repositories together.
[1]: https://confluence.atlassian.com/bitbucket/projects-79249795...
[1]: https://confluence.atlassian.com/bitbucket/projects-79249795...
Definitely agree. I have a project that has iOS, server, and android reopos and it'd be nice to have there be some notion that they're related, maybe even have issues sharable? Though I guess that could get really messy.
Gitlab groups allow you to group repositories together so you could have a Warhammer online group that holds all those projects.
You can navigate or search to your groups so I think it does what you want.
You can navigate or search to your groups so I think it does what you want.
I was thinking of making exactly this for GitHub. I'm still just doing some research on what would be useful.
Mind if I contact you to ask some questions? It'd be real quick.
Mind if I contact you to ask some questions? It'd be real quick.
wouldn't moving the related repos to an "organization" namespace like "chess" organization help better?
Oh wait! now everyone will have clashes since this would be a global namespace.
Tags do seem like a nicer way to do this now.
Oh wait! now everyone will have clashes since this would be a global namespace.
Tags do seem like a nicer way to do this now.
I didn't realize that GitLab had a central hosted option! I thought it was just a download-and-maintain-yourself type of thing.
We have, and both public and private repositories are free without a collaborator limit. For more information see https://about.gitlab.com/gitlab-com/
Pretty long delay on the email verification email. Very excited to check it out, though!
Sorry to hear that. Please email [email protected] if it doesn't arrive.
Basically, it looks like you pay for support?
Also, do you guys do Mercurial? Or just Git?
Also, do you guys do Mercurial? Or just Git?
Interesting, checking this up.
As of the middle of 2015 GitLab was hosted on a single c3.8xlarge AWS instance in Frankfurt.
See https://about.gitlab.com/2015/03/09/moving-all-your-data/
Perhaps their scaling strategy has improved since then.
See https://about.gitlab.com/2015/03/09/moving-all-your-data/
Perhaps their scaling strategy has improved since then.
For sure, we have 94 servers in checkmk now, a significant portion of which is used to run GitLab.com
> 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.
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.
We're not there yet but uptime is a lot better than two months ago (we can deal with Azure now, PostgreSQL and Redis are HA). But file storage is still a single point of failure, we're looking into moving to Ceph https://gitlab.com/gitlab-com/operations/issues/1
We're focussed right now on making GitLab.com faster. Issues got 3 times faster yesterday https://gitlab.com/gitlab-com/operations/issues/42#note_3670...
We're focussed right now on making GitLab.com faster. Issues got 3 times faster yesterday https://gitlab.com/gitlab-com/operations/issues/42#note_3670...
That's one of the definitions of critical mass. Reputation is built up over time and usage. Gitlab's uptime reliability isn't particularly known or unknown, mostly because, compared to Github, it's not used enough for those issues to come up.
Try talking to a dev, ask them why they use Github instead of Gitlab. Are they going to tell you "Oh I absolutely would use Gitlab but their uptime is such a problem"? Or are they going to tell you their stuff's already on Github? Their friends/coworkers are on Github? Their employers look for their Github profile?
As a sidenote I would totally use MySpace instead of Facebook if not for their notable history of extended downtime...
Try talking to a dev, ask them why they use Github instead of Gitlab. Are they going to tell you "Oh I absolutely would use Gitlab but their uptime is such a problem"? Or are they going to tell you their stuff's already on Github? Their friends/coworkers are on Github? Their employers look for their Github profile?
As a sidenote I would totally use MySpace instead of Facebook if not for their notable history of extended downtime...
I partly agree, but those that have done the research or already use Gitlab know that Gitlab's uptime has been problematic compared to Github's, which is a bigger issue for most companies than the community. As sytse correctly notes below, it's a lot better than it was a few months ago - but the pessimistic/risk-averse way to say that is "as recently as two months ago they were having major uptime issues". I have high hopes for Gitlab and I think they're doing great things, it's always great to see new competition in the space. And I applaud their transparency, it's refreshing! But it'll require some more "burn in" time before I consider it a reliable Github replacement, all questions of critical mass aside.
On the plus side, if the manage to fix their problems at some point people will start trusting them to be up. It is not set in stone that they have worse uptime.
Absolutely, and I do think most of their problems have been fixed. So it's just a matter of time - the longer they are stable, the better their reputation will become.
> Try talking to a dev, ask them why they use Github instead of Gitlab. Are they going to tell you "Oh I absolutely would use Gitlab but their uptime is such a problem"? Or are they going to tell you their stuff's already on Github? Their friends/coworkers are on Github? Their employers look for their Github profile?
Just as an alternative point of view, a shop I knew used self-hosted gitlab in preference to github, because they were in China. That was actually how I learned about gitlab.
Just as an alternative point of view, a shop I knew used self-hosted gitlab in preference to github, because they were in China. That was actually how I learned about gitlab.
FYI - We have been running GitLab internally for over a year, we have not had a single crash or unscheduled down time, not even once. The only few things we had was that prior to about 6 months ago we noticed a lot of regressions after a major upgrade, i.e. small things not working but they weren't show stoppers, I spoke with a few people at GL about it and they were fantastic, they immediately set off a program to improve testing quality and in the last 3 months we've upgraded the day each new release has come out (weekly now I think?) and haven't had any problems that we've noticed.
Just FTR: This was an issue for me too.
(Well, there are quite a few weird UI decisions that also pushed me away, but they're minor in the grand scheme of things.)
EDIT: It wasn't my problem per se, but one of my users who had a problem downloading things for at least "several" hours. As this project isn't very popular to start with that's a comparatively huge loss.
(Well, there are quite a few weird UI decisions that also pushed me away, but they're minor in the grand scheme of things.)
EDIT: It wasn't my problem per se, but one of my users who had a problem downloading things for at least "several" hours. As this project isn't very popular to start with that's a comparatively huge loss.
[deleted]
Critical mass is hugely important, but it can also be surprisingly fickle. I remember when MySpace hit the tipping point and it seemed like Friendster became a ghost town overnight. A few years later when Facebook opened up outside of colleges, MySpace turned into a dead zone.
It's possible for the same thing to happen with GitHub, though Facebook's continued entrenchment is also a signal that it may not.
It's possible for the same thing to happen with GitHub, though Facebook's continued entrenchment is also a signal that it may not.
Facebook is entrenched still, because they deliberately tried to avoid the mistakes that MySpace and Friendster (et al) made. They grew and expanded, changed their feature set to ensure that Facebook had everything your average person needed. GitHub haven't been doing that so much, but hopefully this response is the beginning of a change in that direction
gitlab doesn't have the same appeal to me for browsing projects... at least not on the surface.
the amazing thing about github is that you can go to github.com without signing up and search a multitude of projects and their forks. that's awesome. it's a level playing field.
the amazing thing about github is that you can go to github.com without signing up and search a multitude of projects and their forks. that's awesome. it's a level playing field.
Is this not available to view signed out? https://gitlab.com/explore if not I think that's something Gitlab should make visible to anyone. But the problem here isn't that Gitlab lacks this it's that no one is using it to make the explore page interesting.
https://gitlab.com/explore should be viewable when you're signed out. There are not many projects there yet, but when I just looked I saw that iterm2 moved their issues to GitLab.com https://gitlab.com/gnachman/iterm2
Projects fully on GitLab.com include F-droid and Mailman.
Projects fully on GitLab.com include F-droid and Mailman.
Tested it in private browsing mode and can confirm. The problem then is just the number of high profile projects on Github vs Gitlab.
The "problem" would be the number of high profile projects on GitHub.com vs GitLab.com - a subtle but important difference, I think.
Yeah, I can see it and I don't have a Gitlab account.
I'm curious, what about bitbucket prevents it from being a real alternative to github?
Their pricing model is different, which I think keeps the base feature-set neutered. They try to up-sell you to JIRA and Confluence, which disincentives them from improving the base tools, IMO.
Yes, the pricing model is different with the goal of making Bitbucket affordable for individual developers and small teams, no matter whether they work on public or private projects.
Do we want people to use JIRA? If they require more than simple issue tracking, absolutely. But that doesn't mean that we aren't improving the base tools.
For example, Bitbucket already provides the ability to vote for issues and recently added rendering of the CONTRIBUTING.md file for pull requests (http://blog.bitbucket.org/2016/01/26/pull-request-guidelines...).
Do we want people to use JIRA? If they require more than simple issue tracking, absolutely. But that doesn't mean that we aren't improving the base tools.
For example, Bitbucket already provides the ability to vote for issues and recently added rendering of the CONTRIBUTING.md file for pull requests (http://blog.bitbucket.org/2016/01/26/pull-request-guidelines...).
IMHO it's the code search (which they've been planning for months now)
We haven't been planning it for months, we've been working on it for months. It's a big project to implement search at the scale of Bitbucket.
They often have issues, in my experience. Not bad, but shouldn't be the backbone of every package manager out there.
People are split between:
- GitLab
- Phabricator
- GitHub + Phabricator Maniphest (or alternative)
- GitLab
- Phabricator
- GitHub + Phabricator Maniphest (or alternative)
GitLab and Bitbucket are equally as powerful. I've actually really enjoyed trying out GitLab for the past few days.
Glad to hear you like GitLab!
Thanks! I'm really new to it and I'm using it for basic mirroring for now. But the UI is really enjoyable and I've liked the native mirror support in GitLab.
I do have one issue, but I already reported it here: https://gitlab.com/gitlab-com/support-forum/issues/536
I do have one issue, but I already reported it here: https://gitlab.com/gitlab-com/support-forum/issues/536
SourceForge is probably not worth it now, but it is also worth watching.
It's good if you're looking for malware. Everything else, less so.
It is not good for malware either anymore.
I'm not sure it puts anything on hold. Some real action might.
And yet, look at this blog post from 2 days ago: https://github.com/blog/2110-migrate-your-code-with-the-gith... still offering to migrate your existing SVN or Mercurial repositories to GitHub, without any mention of all the other data that are typical of a software project like issues. Should I migrate my Trac or Bitbucket issues manually to GitHub?
What's the reason behind not allowing issues to be deleted?
Very obnoxious. It's embarrassing to see a community I respect so much acting so childish ...
I complain every 6 months about their "releases" page - eg this one for my project 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 ...
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 ...
> 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.
Huh, if all the files of the repository at that tag aren't the "source code" of that release what is?
Huh, if all the files of the repository at that tag aren't the "source code" of that release what is?
Any reasonably complicated project has some pre-processing that has to be done for a source release. e.g. creating the configure script for autotools repos, or building the documentation. These steps can and should be automated, but github is not providing hooks to perform these automated tasks.
Wouldn't the output of that be the "distribution code" rather than the "source code"?
Do your projects not have a README telling people how to build? Are you targeting a nontechnical or beginner audience?
Do your projects not have a README telling people how to build? Are you targeting a nontechnical or beginner audience?
There's a long history of distributing source code already partially processed, and for decades, this has been what people expected when they download a source tarball. Newer generations were introduced to open source through github and are less familiar with this, but they also are rarely interested in source tarballs — they're interested in either the source code to contribute to (in which case they'll git clone) or in a binary distribution.
Really the main purpose of source distributions is for packagers. Especially when you're creating pkgbuild scripts like for archlinux's AUR or gentoo or slackbuilds or macports or BSD, all the tools needed to build the source code become build-time dependencies for your package, which is annoying for people installing it.
Really the main purpose of source distributions is for packagers. Especially when you're creating pkgbuild scripts like for archlinux's AUR or gentoo or slackbuilds or macports or BSD, all the tools needed to build the source code become build-time dependencies for your package, which is annoying for people installing it.
Not having to add autotools to a BuildRequires is nice, but hardly the end of the world as a package maintainer. I agree though, the contents of the repository at a git tag is not necessarily a source DISTRIBUTION - which is what most people who are compiling your software would want - especially when many of them probably don't know the autotools incantations required to generate the configure script.
We probably need to do away with partially processed source and distribute just the git repo (or a tarball without .git but with info about which git rev it is) and binary packages for end-users.
Gotcha, thanks for the explanation!
Shouldn't the person downloading the source code be expected to run those scripts? And topically those scripts are included in the source.
Github isn't a build server. You shouldn't expect it to perform tasks for you. You should provide a CI server to your users if you want that functionality. I've never heard of downloading "source code" that has been preprocessed. The entire point of the repo is that it IS the source code. If you want it to be preprocessed for users, why even have the original form in the repo?
This is explained in reply to your sibling comment, but the convention on linux for many years is that the source distribution has automake/autotools already run. That way, when you download the source tarball, you know the process is `./configure && make` to make the final binary. The way package maintainers for distributions customize things is (hopefully) by providing flags for configure. The idea is that autotools should only be necessary for developers, not for maintainers.
It is unfortunate, but just create a new branch and run autotools, and mark a release there.
If by "unfortunate" you mean "totally crazy"... I'd rather deal with the occasional person confused by GitHub kids' ignorance of what source tarballs are meant to be that doing such wild and dirty dances in the repository.
TL;DR source code to install from and source code to hack on are often different beasts.
Yeah but those steps should be part of the normal build process. If you have to use weird tools (e.g. autotools) to generate your "real" source code, I'd say the problem is those tools. Also. Seriously. Autotools? In 2016?
Who's going to volunteer porting, say, Wine's 4000 line autotool script[1] to CMake, exactly? You, maybe? (I'm not being sarcastic, if you actually came up with a patch it might be considered...)
[1] http://source.winehq.org/git/wine.git/blob/0f8a0fd4002f9d5d1...
[1] http://source.winehq.org/git/wine.git/blob/0f8a0fd4002f9d5d1...
Autotools? In my Linux?
It's more likely than you think.
It's more likely than you think.
So what would you suggest in lieu of autotools? The only real mature alternative is cmake, and cmake's main advantage is that it is a cross platform build system. Basically that means it works on windows without cygwin or its equivalents.
If you use something other than cmake or autotools, you're going to end up making the lives of packagers more difficult. If they have to change anything, as they usually do, they're going to have to know how the build system works, and they dont necessarily want to deal with whatever new-fangled build system you're using.
Usually projects using cmake distribute their source code with cmake build scripts because they're taking advantage of cmake's cross plaform features, and cmake generates different source distributions for different platforms. But this does place a burden on the user to have cmake installed. There's a good argument to be made that that's no longer much of a burden, after all, it's just one package manager invocation away. But you have to think about who's downloading a source distribution (as opposed to binaries or checking out the repository). They're people who are compiling from source for esoteric platforms, perhaps and embedded system, where a cmake package might not already exist. They're people like me who are writing their own pkgbuild script because they like to keep their system well organized and not have too many useless packages (like cmake) lying around. They are people creating a new linux distribution who haven't yet packaged cmake but want to package your software.
And in terms of software design, cmake isn't very good, at least in the eyes of many people writing unix systems software, which as far as mature open source software projects written in C/C++ go, is a lot. Don't get me wrong, cmake certainly has the cross platform advantage, and if you're making software that you want to compile on windows, you'd be remiss to not at least seriously look into using cmake (not that it's the only option, you could also opt to lean on cross-compiliation from a unix platform to windows, distributing binaries only, or requiring users to install cygwin, which isn't worse than having to install visual studio if you don't already use it).
But if you're not taking advantage of the cross-platform features, I'd say cmake is pretty awful. Precisely because it's cross-platform, cmake rejects the typical design principles of unix software, instead offering a monolithic build system that requires special scripts to be written for any different tools you want to use, or even any complicated dependencies (for example: SDL). This is necessary because cmake needs to establish a consistent internal interface that can work for both the windows and unix tools. As a result, everyone has to learn how to use the monolithic cmake system from the ground up, and those skills won't be useful for anything else.
In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix system, you can figure out autotools faster than you can cmake. And you can really know it, to the extent that you feel confident diving in and messing with its defaults, much sooner than you would with cmake.
But of course, ease of learning isn't the only factor autotools integrates with external tools using their standard interface while cmake demands you essentially write a wrapper for them. Autotools is simply more flexible.
I don't like autotools, for the record, but given the options available, I'd probably choose it over any other build system in almost all the places it's used currently and more.
If you use something other than cmake or autotools, you're going to end up making the lives of packagers more difficult. If they have to change anything, as they usually do, they're going to have to know how the build system works, and they dont necessarily want to deal with whatever new-fangled build system you're using.
Usually projects using cmake distribute their source code with cmake build scripts because they're taking advantage of cmake's cross plaform features, and cmake generates different source distributions for different platforms. But this does place a burden on the user to have cmake installed. There's a good argument to be made that that's no longer much of a burden, after all, it's just one package manager invocation away. But you have to think about who's downloading a source distribution (as opposed to binaries or checking out the repository). They're people who are compiling from source for esoteric platforms, perhaps and embedded system, where a cmake package might not already exist. They're people like me who are writing their own pkgbuild script because they like to keep their system well organized and not have too many useless packages (like cmake) lying around. They are people creating a new linux distribution who haven't yet packaged cmake but want to package your software.
And in terms of software design, cmake isn't very good, at least in the eyes of many people writing unix systems software, which as far as mature open source software projects written in C/C++ go, is a lot. Don't get me wrong, cmake certainly has the cross platform advantage, and if you're making software that you want to compile on windows, you'd be remiss to not at least seriously look into using cmake (not that it's the only option, you could also opt to lean on cross-compiliation from a unix platform to windows, distributing binaries only, or requiring users to install cygwin, which isn't worse than having to install visual studio if you don't already use it).
But if you're not taking advantage of the cross-platform features, I'd say cmake is pretty awful. Precisely because it's cross-platform, cmake rejects the typical design principles of unix software, instead offering a monolithic build system that requires special scripts to be written for any different tools you want to use, or even any complicated dependencies (for example: SDL). This is necessary because cmake needs to establish a consistent internal interface that can work for both the windows and unix tools. As a result, everyone has to learn how to use the monolithic cmake system from the ground up, and those skills won't be useful for anything else.
In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix system, you can figure out autotools faster than you can cmake. And you can really know it, to the extent that you feel confident diving in and messing with its defaults, much sooner than you would with cmake.
But of course, ease of learning isn't the only factor autotools integrates with external tools using their standard interface while cmake demands you essentially write a wrapper for them. Autotools is simply more flexible.
I don't like autotools, for the record, but given the options available, I'd probably choose it over any other build system in almost all the places it's used currently and more.
> In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix system, you can figure out autotools faster than you can cmake. And you can really know it, to the extent that you feel confident diving in and messing with its defaults, much sooner than you would with cmake.
I've been using unix since 1992 and find the entire autotools suite to be almost incomprehensible. The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf. This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those. Eventually I just gave up and used a different package.
Conversely, when I started using cmake (motivated by clion using it as a build system) I was able to get it up and running basically immediately, and 12 months later I appear to have become the cmake guru for my company.
I've been using unix since 1992 and find the entire autotools suite to be almost incomprehensible. The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf. This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those. Eventually I just gave up and used a different package.
Conversely, when I started using cmake (motivated by clion using it as a build system) I was able to get it up and running basically immediately, and 12 months later I appear to have become the cmake guru for my company.
"The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf."
At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because...
"This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those."
The version of autotools someone was using when they wrote the scripts is very closely tied to the scripts. It's not at all a good idea to use a different version of the autotools.
At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because...
"This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those."
The version of autotools someone was using when they wrote the scripts is very closely tied to the scripts. It's not at all a good idea to use a different version of the autotools.
> At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because...
And indeed, the exact issue the OP is complaining about is how the zipfile automatically created by GitHub has NOT had autotools run on it yet, and the maintainer cannot even manually overwrite that file!
And indeed, the exact issue the OP is complaining about is how the zipfile automatically created by GitHub has NOT had autotools run on it yet, and the maintainer cannot even manually overwrite that file!
I have to respectfully disagree. Cmake isn't super amazing and has some flaws and a less than ideal design and language, but it gets the job done. Autotools is more like something that was needed once in the 1980's when you had to support 300 different proprietary UNIX's and compilers / stdlib's weren't very standardized and had lots of bugs and warts, and now only exist because of inertia.
I too have to disagree. Cmake is crap compared to Autotools. It's makefiles don't work if the end user who does the compilation doesn't have cmake installed. Autotools doesn't have any runtime dependencies - that's a design goal that yes, still matters 2016.
[deleted]
Source distribution packages aren't necessarily a simple snapshot of the repository.
For example: for autotools based build systems you want to run autoconf and automake to generate the Makefile.in and configure scripts.
For example: for autotools based build systems you want to run autoconf and automake to generate the Makefile.in and configure scripts.
A ZIP file is less helpful than the GitHub interface pointed at that specific commit ID.
It's not immediately obvious, but the tag and commit links to the left of the release (under the green "latest release" label) actually do that.
The tag link points to the tree (in Github's file browser UI) for the release, and the commit ID link points to the specific commit for that tag (in Github's diff UI).
Trouble is, this isn't very discoverable, given that those two links aren't styled as links-- they're the same font and color as is used for the subheading with date and commits since, which aren't clickable elements.
The tag link points to the tree (in Github's file browser UI) for the release, and the commit ID link points to the specific commit for that tag (in Github's diff UI).
Trouble is, this isn't very discoverable, given that those two links aren't styled as links-- they're the same font and color as is used for the subheading with date and commits since, which aren't clickable elements.
Sure. The issue is less with the functionality and more with how it's presented to the user.
I also have a problem with the "download zip" button on repositories. It doesn't include submodules. I've asked Github several times to give me a button to remove it from my repo, or to add submodules, to no avail.
I'll bet they have zero positive feedback over the Source Code zip, and you confirm yet more negative feedback over it.
I like having it as a simple way to quickly download a git-free tree of simple projects. So there's one small piece of positive feedback.
You can already get such an archive by clicking on the right bit of the release page. And I believe at any page reflecting a revision. It is easy to get a copy of the repository.
It isn't the case for all projects, but for some there are some pre-build steps that the majority of people who want to install and use the project don't have or even know about. The project can put up the source after those steps are done, and the downloader does the final source building and installation with ease.
As an end user looking at the release page, you can't tell the difference between the easy way (the pre-processed source that will work well for you) and the hard way (you'll need to install and invoke several tools for no real benefit).
The underlying problem is that Github make it really easy for people to end up with the hard way, and not the intended easy way. This benefits no-one. I have no problem with them making the repository files available - I just want them to stop confusing people who go to a release page.
It isn't the case for all projects, but for some there are some pre-build steps that the majority of people who want to install and use the project don't have or even know about. The project can put up the source after those steps are done, and the downloader does the final source building and installation with ease.
As an end user looking at the release page, you can't tell the difference between the easy way (the pre-processed source that will work well for you) and the hard way (you'll need to install and invoke several tools for no real benefit).
The underlying problem is that Github make it really easy for people to end up with the hard way, and not the intended easy way. This benefits no-one. I have no problem with them making the repository files available - I just want them to stop confusing people who go to a release page.
I'm not talking about the releases page, and I don't think @Sir_Cmpwn was either.
Many small projects don't have a releases page. The download zip is just a way of quickly getting the source code for such projects.
To be honest, I wasn't trying to start an argument. I was just pointing out that I like having a "download zip" button.
Many small projects don't have a releases page. The download zip is just a way of quickly getting the source code for such projects.
To be honest, I wasn't trying to start an argument. I was just pointing out that I like having a "download zip" button.
Understood. I wasn't clear that I have no problem with being able to download a copy of the repository from as many pages/places as is reasonable, and there is no need to change that.
The specific top level complaint is about the releases page when visited by a human who would have the goal of building and installing the software release. There the "Source Code" link is misleading if the maintainer has a release file that is the expected one for building and installing the software.
The specific top level complaint is about the releases page when visited by a human who would have the goal of building and installing the software release. There the "Source Code" link is misleading if the maintainer has a release file that is the expected one for building and installing the software.
It's also immensely useful for installers like pip that can pull an archive directly from Github using just a URL and no local git install.
This issue is not about tools, but about humans being confused by the releases page. I have no problem with an archive of the repository being available - the issue is that github ui on the release page implies that is the best download to build and install the software, when it can be the least convenient hardest way.
Personally, I'm a big fan of the "Source Code" zip file download. I use it regularly, and have never had a problem.
There is no problem with a way of grabbing the repository contents. Good to have, and shouldn't go away. It is the github ui on the release page strongly suggesting to use that download, even when the project has provided a better archive for users to build and install the software. That better archive can already have several pre-build steps run so the end user doesn't need additional tools of no benefit to them.
To be honest, I didn't even know there was a release page in github repos. I don't recall seeing those. I normally don't expect to be able to download installers from github, so I never really thought to look for such a thing.
I use it semi-frequently and have never had a problem.
>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.
I fall for this everytime I go to use that link.
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.
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.
Totally agree.
A few examples for me:
- From a "pull request / files" view like this (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), 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) 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/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.
A few examples for me:
- From a "pull request / files" view like this (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), 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) 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/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.
I'm wondering what's a good way for a dogfooding company to look at things from a fresh perspective. Perhaps the traditional focus group and user interaction studies?
Listen closely to anything new team members have to say. From the inside, it all makes sense, but from the outside, it's often obvious insanity ;-)
Glad someone else acknowledges this.. the number of times I've had to answer questions about how to get automake to work, etc., from people who should be just downloading the tar and running `./configure`. People are starting to get this tendency to check out the whole repository just to use the software. (I've been guilty of this too! There is something about it..) But people: If you're not going to work on the software, use the release distributions!
In one project I went as far as making a "releases" branch, and actually putting the "make dist" output there, in full, and tagging that instead of the master branch. This was a pretty good compromise, since the github download link now points at the actual release tarball, and you can easily see from `gitk` which commit from the development branch each releases branches from.
However, it's annoying not to be able to use tags as a way of navigating the development branch, and since I wasn't the one officially putting together final releases, eventually it was found that this was just too complicated to keep doing for each release. And it's just a dumb trick to satisfy github's weird releases interface anyway, so I couldn't justify the complexity.
In one project I went as far as making a "releases" branch, and actually putting the "make dist" output there, in full, and tagging that instead of the master branch. This was a pretty good compromise, since the github download link now points at the actual release tarball, and you can easily see from `gitk` which commit from the development branch each releases branches from.
However, it's annoying not to be able to use tags as a way of navigating the development branch, and since I wasn't the one officially putting together final releases, eventually it was found that this was just too complicated to keep doing for each release. And it's just a dumb trick to satisfy github's weird releases interface anyway, so I couldn't justify the complexity.
We have the same 'Source Code' link in GitLab on our tag/release page. Should we rename it into 'download source' to be more clear?
Or I am always a fan of putting a checkbox in the project's Settings page "show 'download source code' link" and a text box underneath it with "source code download label", enabling the project to use language they are happy with
That said, I am also cognizant that "checkbox overload" is a real thing, so merely "for your consideration"
That said, I am also cognizant that "checkbox overload" is a real thing, so merely "for your consideration"
We're indeed pretty hesitant to add options for these things, it makes it harder to refactor the UI if you have to account for all settings.
Google Code used to have labels, in particular one named "featured". You can label files in the release with it, and the ui put those at the top. Consequently it was clear to users which release files would be best.
"Source Code" has two meanings. One is the preferred form of contributing to the project. The other is the preferred form for building and installing it on a system. Sometimes they are the same. However I argue someone going to a release page is more interested in the latter, and the former is confusion.
I'd suggest making your UI reflect the page visitor's goals. "Repository Archive" is better wording, but still not that good.
"Source Code" has two meanings. One is the preferred form of contributing to the project. The other is the preferred form for building and installing it on a system. Sometimes they are the same. However I argue someone going to a release page is more interested in the latter, and the former is confusion.
I'd suggest making your UI reflect the page visitor's goals. "Repository Archive" is better wording, but still not that good.
The GitHub API allows you to provide much more useful content for a release. See this project as an example: https://github.com/aws/aws-sdk-ruby/releases - Notice that it has links for build artifacts, generated docs, and even contains links to issues closed by the release. Also, its pretty easy to automate a "release" from travis.
The problem isn't that you can't add more content to a release, it's that you can't remove the misleading zipball/tarball links which are labelled source code but break traditional tarball conventions (e.g. not running autotools first).
I'm not sure if that's what you're looking for, but you can edit release assets using Github's API: https://developer.github.com/v3/repos/releases/#list-assets-...
Absolutely. This feature is such an integral part of a repo that distributes releases that I'm surprised it hasn't gotten more attention from Github. I, for one, would love to see them provide the checksum for the archives that are published via Releases -- it's not currently available when you create a release and relies on the operator to implement a workaround that creates a digest and publishes it on an external endpoint.
Adding a script that builds the project from “maintainer state” and referencing it in the README may save you some aggravation.
Not really. Not many people have the whole autotools/automake tool chain installed, let alone document building tools, and whatever other processing the project does (eg SQLite uses some TCL scripts). So they'd have to go and get all those, obeying any version constraints. And after all that they'd end up at the same point as getting an archive intended by the maintainer for them to build and install.
That is the intended outcome.
[deleted]
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?
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?
I've been working on a bot to copy Github Pull Requests into Gerrit reviews, using the Google-hosted Gerrit servers.
My bot isn't running publicly yet, but you can see the start of it working at:
https://github.com/grpc/grpc-go/pull/546 or https://github.com/grpc/grpc-go/pull/545
(Code is at https://github.com/LetsUseGerrit/gerritbot for now, but I don't imagine anybody would use the code themselves... they'd only interact with it via the Github bot)
My bot isn't running publicly yet, but you can see the start of it working at:
https://github.com/grpc/grpc-go/pull/546 or https://github.com/grpc/grpc-go/pull/545
(Code is at https://github.com/LetsUseGerrit/gerritbot for now, but I don't imagine anybody would use the code themselves... they'd only interact with it via the Github bot)
Gerrit has an excellent REST API, and because I like working with code in a terminal, I wrote Gertty -- a terminal based interface to Gerrit. It should work with the Google hosted servers.
https://pypi.python.org/pypi/gertty
https://pypi.python.org/pypi/gertty
Gertty is the greatest greatness ever. Doing code reviews on a plane and syncing up when back online is so cool. Thank you for your work on this.
Is there any public "how to" about Gerrit? I've interacted with it a few times for Go codereviews, but not frequently enough to get comfortable. Really simple things like finding the "submit comments" button I have to spend five minutes finding every time.
> 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)
> 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)
I was actually shocked two weeks ago when I was talking to someone about Gerrit and they complained that their comments were never addressed. Turns out they hadn't been hitting the "Publish Comments" button, and had been assuming that every draft comment they left was being sent as an individual email.
This taught me (or reminded me of) two things:
* GitHub is so dominant that even its poor decisions are being enshrined as "the way things work"
* Gerrit really needs some UI love as well.
This taught me (or reminded me of) two things:
* GitHub is so dominant that even its poor decisions are being enshrined as "the way things work"
* Gerrit really needs some UI love as well.
Hopefully the recently begun work on a Polymer based interface (PolyGerrit) will help in that department.
Not github, but you may be interested in http://phabricator.org/. We hired a guy a while back who swore by it. We had too much momentum in github, so it did not catch on at our org. One of his favorite features, if I recall as it was a few years ago, is what you are talking about.
Review Board works with GitHub and allows you to publish your review when you're ready.
I recently switched our large-ish GitHub project to use reviewable.io for code reviews. The UI can be hard to understand sometimes, but so far everyone agrees it's a tremendous improvement over GitHub's joke of a code review UI.
Reviewable founder here. I'd love to get somebody to sit down with me and rant about the UI so I can figure out how to improve it. Let me know if you're game. :)
Besides the UI, "reviewable.io" is a memory hog. It's simply unusable if you try to browse the site from a device without a lot of free memory (e.g. older tablets, ARM SoCs, etc).
Reviewable founder here. Yep, Reviewable is a heavy client-side app, and I make no apologies for it. Mobile devices are getting powerful very quickly (you can already use Reviewable pretty much fine on modern phones/tablets) and the target audience of developers generally needs reasonably powerful devices anyway. I'd rather miss out on some users in the short term than lock myself into an obsolete server-centric architecture in the long term...
That said, performance is always an issue, it's just a question of where to set the target.
That said, performance is always an issue, it's just a question of where to set the target.
Excellent idea... some notion of a review session would be nice.
Gerrit does this as well.
Just continue to use Reitveld :)
Wow, It took them 29 days to say "we hear you stay tuned"
Or, more cynically, it took them 6 days to find a way to respond to some of the problems raised by the Business Insider article on GitHub without addressing the article directly.
"Dear GitHub" paints a picture of feature requests going unanswered. To a software developer userbase that isn't damning on it's own. We all understand the realities of software project priorities, and users can be accommodating to their timeline (and changing development platforms isn't a trivial task). But that accommodating attitude is severely damaged by learning the business doesn't care about serving that userbase anymore.
"Dear GitHub" paints a picture of feature requests going unanswered. To a software developer userbase that isn't damning on it's own. We all understand the realities of software project priorities, and users can be accommodating to their timeline (and changing development platforms isn't a trivial task). But that accommodating attitude is severely damaged by learning the business doesn't care about serving that userbase anymore.
Exactly what I was thinking: The BI article lit a fire under their arse and this is a quick scramble rather than a long-considered response.
Oh, do you have a link to that article?
"GitHub is undergoing a full-blown overhaul as execs and employees depart — and we have the full inside story" http://www.businessinsider.com/github-the-full-inside-story-..., HN discussion was here: https://news.ycombinator.com/item?id=11049067
It's almost as if planning changes to ui and backend design used by millions of people on a daily basis just can't happen instantly...
I don't think anyone was expecting a list of specific measures, but more something like what they published today. "We heard you, we'll report back in a month once we figured out what we can do" is (IMHO) better than silence.
It's almost as if it takes 29 days to say that you have read an open letter and respond that you will get back to them...
It's almost as if they did that, then we would be reading a post on why it is taking so long, and why didn't github supply realtime daily blog posts on exactly what every single engineer is doing every day.
They are damned either way since everyone now days believes they deserve every question they post answered immediately and if they don't they are ignoring their customers. If they do, and then don't turn around and immediately release a product they are also shunned. But the sentiment here these days is pretty needy and entitled so I understand...
They are damned either way since everyone now days believes they deserve every question they post answered immediately and if they don't they are ignoring their customers. If they do, and then don't turn around and immediately release a product they are also shunned. But the sentiment here these days is pretty needy and entitled so I understand...
What's being asked for here isn't exactly onerous, you know.
It's not unreasonable to expect a response to an open letter, signed by some very nontrivial names, in less than a month.
It's not unreasonable to expect something other than bullshit hand-wavy corpspeak.
It's not unreasonable to address the letter, point by point, and lay out why they're doing or not doing something.
If the organization has grown so bureaucratic that they can't manage these simple few things in a timely manner, that's another huge point against them.
It's not unreasonable to expect a response to an open letter, signed by some very nontrivial names, in less than a month.
It's not unreasonable to expect something other than bullshit hand-wavy corpspeak.
It's not unreasonable to address the letter, point by point, and lay out why they're doing or not doing something.
If the organization has grown so bureaucratic that they can't manage these simple few things in a timely manner, that's another huge point against them.
It's always more complex than most on HN think. I've seen it firsthand after AWS outages and the laughably simplistic solutions or complaints offered up here.
So they respond immediately that they are looking into it. Then this post would be raging that it has been 30 days without any updates.
So they should reprioritize everyone who needs to be involved and sideline their current work, move to this project and start tossing updates over the wall to satisfy the mob? There are a lot more people involved with big websites/infrastructure when you have millions of customers and everyone here seems to happily ignore that fact when it is something they believe they are entitled to have because "its easy". They shouldn't be responding w/ hand-wavy answers just to get the enraged masses something to chew on, what happens if they don't come through?
Everyone should just calm down and stop whining. They've responded that they are working on a solution, it will take a while to implement.
So they respond immediately that they are looking into it. Then this post would be raging that it has been 30 days without any updates.
So they should reprioritize everyone who needs to be involved and sideline their current work, move to this project and start tossing updates over the wall to satisfy the mob? There are a lot more people involved with big websites/infrastructure when you have millions of customers and everyone here seems to happily ignore that fact when it is something they believe they are entitled to have because "its easy". They shouldn't be responding w/ hand-wavy answers just to get the enraged masses something to chew on, what happens if they don't come through?
Everyone should just calm down and stop whining. They've responded that they are working on a solution, it will take a while to implement.
> Everyone should just calm down and stop whining. They've responded that they are working on a solution, it will take a while to implement.
As someone who's actually involved in the Dear Github movement and not just some commenter on HN, not a single one of us wanted them to respond immediately with "We're doing this, and this for you RIGHT NOW" and stop everything their doing.
While today's response is a good sign, it does nothing more than satisfy what you should have done from the start. Respond that they are aware of the situation and will have a better response in time. That time could be 3 days, 3 weeks, or 3 months. Just acknowledging that they seen it and are addressing it is good enough.
Their support has been notorious (we've outlined it on the letter) for not being responsive... So the best response is quietness for almost a month, just to say "We see your letter, we will prepare something soon."?
As someone who's actually involved in the Dear Github movement and not just some commenter on HN, not a single one of us wanted them to respond immediately with "We're doing this, and this for you RIGHT NOW" and stop everything their doing.
While today's response is a good sign, it does nothing more than satisfy what you should have done from the start. Respond that they are aware of the situation and will have a better response in time. That time could be 3 days, 3 weeks, or 3 months. Just acknowledging that they seen it and are addressing it is good enough.
Their support has been notorious (we've outlined it on the letter) for not being responsive... So the best response is quietness for almost a month, just to say "We see your letter, we will prepare something soon."?
You really, really need to reach out to Jono Bacon via email.
This article was covered by top tech news sources, why the heck does everyone need to reach out privately?
I thought you said you were directly involved with that letter? Don't you want to talk to one of the people who could make that happen?
> But the sentiment here these days is pretty needy and entitled so I understand
Don't be so silly. Plenty of people pay for the service, to ensure it serves the purpose it advertises. They're utterly entitled to complain if it doesn't.
Don't be so silly. Plenty of people pay for the service, to ensure it serves the purpose it advertises. They're utterly entitled to complain if it doesn't.
Maybe they were busy fighting such heinous evils as meritocracy and inappropriate language.
Some other companies usually don't reply at all. E.g. Apple, Microsoft, etc.
Gitlab responded to dear github within a week:
https://about.gitlab.com/2016/01/15/making-gitlab-better-for...
Someone wants your business :p
https://about.gitlab.com/2016/01/15/making-gitlab-better-for...
Someone wants your business :p
For sure!
Aspiring to communicate with developers as well as Apple does is a perverse goal. Microsoft for example has a status page for their browser work [1] just like Google does for Chrome [2]. (The Microsoft page lets people vote for their favorite features, the Chrome one does it via stars on their tickets.) Something like either of those from Github would be great.
[1] https://dev.windows.com/en-us/microsoft-edge/platform/status... [2] https://www.chromestatus.com/features
[1] https://dev.windows.com/en-us/microsoft-edge/platform/status... [2] https://www.chromestatus.com/features
Submitting bug reports to Apple is about as fruitful as playing tennis with the pacific ocean.
Dunno, the ocean can send back your tennis balls. They'll be went, they may take a long time and they may come back on a different beach altogether, but there's a chance.
Radar issues? They just fall off the radar.
Radar issues? They just fall off the radar.
ROTFL. I report only when they have really annoying bugs and still don't condone their way of hiding issues from other (paying) users inside a private system. They answer after weeks, if they do, and then they expect me to retest next day. Sorry, but that's not gonna work.
At least better than on Android.
Even goddamn String::split is directly, and reproducably, broken. WONTFIX.
Even goddamn String::split is directly, and reproducably, broken. WONTFIX.
GitLab implements Emoji Award (think of vote system with some emojis: https://about.gitlab.com/2015/11/22/gitlab-8-2-released/)
Apple responded to antennagate and other hardware issues pretty quickly actually. 2 weeks for Antennagate:
http://www.pcworld.com/article/201297/apples_iphone_4_antenn...
http://www.pcworld.com/article/201297/apples_iphone_4_antenn...
Yep, i guess that was an exception
https://en.m.wikipedia.org/wiki/Criticism_of_Apple_Inc.#Qual...
https://en.m.wikipedia.org/wiki/Criticism_of_Apple_Inc.#Qual...
That was only after Consumer Reports tested it and confirmed that it did actually have a problem.
[deleted]
Parts of Microsoft actually do respond and provide nice roadmaps. I am hoping Github will do something similiar.
https://blogs.msdn.microsoft.com/bharry/2016/01/11/team-foun...
https://blogs.msdn.microsoft.com/bharry/2016/01/11/team-foun...
It's really sad though when you consider gitlab answered a while back.
Microsoft usually responds pretty fast with "wont fix"
I will grant you that. At the same time, it is a horrible benchmark and it is even more deadly when you compare github, a company, among many, that offers hosting to a monopoly that you can't easily move away from.
And have suffered for it in the past (though Apple, less so, it is true).
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.
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.
Yup, agree with everything you say. You just said it better than I could have :-)
You can add Google to that list but just because some other big companies do it does not make it right. Nor should we accept it.
Yeah, how dare you take your time to respond to non-paying customers.
This seems like an unrealistic attitude. The free users running open source projects on GitHub are part of what made them so big and successful.
Non-paying customers? I pay for a private repos on my account, and for repos on 3 orgs. That's $82/mo. Many others also pay for private repos. Hardly non-paying customers.
Or, they got the original letter and only then decided to implement some changes. It could take 29 days to get management level approval for switching developement to issues, and to get an idea if all those issue changes are possible, before they are willing to publically announce it
That's certainly possible, but if so then it's a pretty sad indictment.
If it takes 29 days just to get approval to say you're going to work on the problem, imagine how long it will take to actually get something done.
If it takes 29 days just to get approval to say you're going to work on the problem, imagine how long it will take to actually get something done.
They could have acknowledged the problem quickly, but without an actual plan to implement something useful in a close time frame someone would have called the bluff.
Insulting customers with empty, insincere declarations is worse than working in silence.
Insulting customers with empty, insincere declarations is worse than working in silence.
They were probably resisting the urge to say "We give you an awesome and extremely valuable product for free and all you fuckers do is complain."
My credit card statement every month with 3 charges from GitHub totaling $82 is hardly free.
I distinctly remember them responding to Dear Github previously, and pretty quickly.
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.
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.
That being said, I bet that enterprises are screaming about Issues too. Enterprise loves their custom fields.
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.
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]
their most important constituent
Well, if they responded within a day, the answer would be something like "we'll look that up".
Because they waited for almost a month, they can confidently say something like "we thought about your issues thoroughly and we are ready to take some actions to resolve them".
Because they waited for almost a month, they can confidently say something like "we thought about your issues thoroughly and we are ready to take some actions to resolve them".
Once you strip out the fluff, those sentences are effectively identical. It's not like they said what they'll be doing. Just a bunch of hand-wavey "we're working on it".
Sure, they had a more meaningful response, but a public response immediately saying "We hear you, and we'll have a more detailed response after we look things over. Thank you." Would have sufficed and been way better for their case.
Ignoring your users just to spend a month writing a response to those users is not in the best interests.
Ignoring your users just to spend a month writing a response to those users is not in the best interests.
I'm glad that you are not.
I wonder if this has more to do with ESLint[1] than the letter.
[1]:https://github.com/eslint/eslint/issues/5205
[1]:https://github.com/eslint/eslint/issues/5205
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.
Just a tip from a person who's interacted with cranky people for a long time....
When I get feedback, especially negative, I like to think about it before I respond. And I may take a month to respond.
But I always immediately respond with something like
"Thank you for providing feedback, and thanks for your patience while I think about your feedback, discuss it, and respond appropriately."
At least you then know I'm not ignoring it.
When I get feedback, especially negative, I like to think about it before I respond. And I may take a month to respond.
But I always immediately respond with something like
"Thank you for providing feedback, and thanks for your patience while I think about your feedback, discuss it, and respond appropriately."
At least you then know I'm not ignoring it.
As a classroom teacher, I agree wholeheartedly. A timeline for when you will respond in more depth (24h, a week, a month) is also quite helpful.
They responded in the original HN thread saying basically that.
Most Github users don't read HN.
Most GitHub users probably also didn't know about the open letter in the first place.
I think it looks worse that it took so long to respond without any demonstrable improvements.
I disagree: I'd rather see a well reasoned response than a knee jerk relation. If they had decided _not_ to do anything, I'd prefer to have them think about it first.
That said, they set the bar pretty high, and now they need to execute.
That said, they set the bar pretty high, and now they need to execute.
What world do we live in that 29 days is an unacceptably long amount of time to deliver a feature that affects 0.1% of millions of users?
They didn't deliver a feature, they put out the lame equivalent of a press release. It's like somebody called you on the phone, said "hello? Can you hear me?" and you waited 29 hours to reply "hello".
That's no way to run a modern web-based business for alpha geeks.
That's no way to run a modern web-based business for alpha geeks.
This world. Seriously their response was some words, that doesn't take that long to come up with. 29 days to go to production on that is not good. Adding a simple feature on a project which I am pretty sure they say they deploy daily on shouldn't take 29 days when you have the amount of talent they have. I am sure people aren't expecting the world, but 29 days should equal some text saying ok we're listening here is something we've done.
They’re already working on a lot of different things; they’re not just there waiting for someone to write a letter and then jump on coding everything that’s written in.
Oh, the classic "HR" response. "We're very busy here".
Well, if they truly have "more imporant things to do than address community ire", then this also means that they agree to take the community's ire.
Well, if they truly have "more imporant things to do than address community ire", then this also means that they agree to take the community's ire.
I didn’t say they have more important things to do but that they can’t just stop what they’re doing and code a solution in 3 weeks as the parent comment was suggesting. It’s perfectly ok to have to wait more than 29 days to (hopefully) see new features released that address the letter.
They don't have to just stop what they're doing, they stop what a couple of people are doing and ship something. 29 days would be fine if they replied straight away. But they didn't they took ages, 29 days is a long time for a response. So if you take a long time to reply you have to have something to show why. As it stands, this just looks like they couldn't really be bothered and had it as a "do at some point" task.
[deleted]
You really should consider telling those who filed the letter that you were at least working on it. Did you expect them to know?!?
Someone, not the GP, did: https://news.ycombinator.com/item?id=10905338
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.
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.
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.
It's a statement. There's no question there.
It's a statement that said that they asked them to address some critical issues via their regular support channel. The statement said they have already reached out, and they had nowhere else to go so hence the open letter.
Or in other words, to answer the question I was asked (which was "Did they who filed the letter ask?"), yes, they did ask. Apparently repeatedly.
Or in other words, to answer the question I was asked (which was "Did they who filed the letter ask?"), yes, they did ask. Apparently repeatedly.
They were in the HN thread at least, not sure about elsewhere.
If they have a culture of "only catering to the big corporate players" like a lot people have been saying, it'd be hard to change momentum. They probably also had to do a lot of internal discussions about how they would address this, and what changes they wanted to make. They also had to be careful about how they responded, for fear of making things perceptibly worse.
I have no insight into their internals, but, IME, getting that many people, especially upper-management to adjust focus is a long, slow process. I'd guess it just took a lot of time to get coordinated.
I have no insight into their internals, but, IME, getting that many people, especially upper-management to adjust focus is a long, slow process. I'd guess it just took a lot of time to get coordinated.
I don't think it is because they want to cater to the big players, but more that this got a lot of attention.
I think I may have mis-stated my point. I'll caveat my response this with: This is what I've heard, I don't know if it's true.
They have an internal culture of "lets develop features for the companies that pay us, rather than the free-users". This got a lot of attention, because they started to realize that they can't keep heading in that direction and expect things to keep working.
They have an internal culture of "lets develop features for the companies that pay us, rather than the free-users". This got a lot of attention, because they started to realize that they can't keep heading in that direction and expect things to keep working.
That would be odd; ESLint is a pretty small project compared to, say, the top 100 or so. I can't imagine their investigation would be much of an issue.
Honestly git is distributed so I don't know why people wouldn't just setup another repo somewhere, say, GitLab and you could experiment with different workflows, etc and essentially have a remote back-up.
Honestly git is distributed so I don't know why people wouldn't just setup another repo somewhere, say, GitLab and you could experiment with different workflows, etc and essentially have a remote back-up.
[deleted]
Now, if only we could get a movement behind a "merge" button that does fast-forward only commits.
I know that gitlab has it as a project option!
Agreed, and here's a git alias I made for the occasion:
Note: This merges only to master, no way to specify another merge target. Feel free to suggest improvements.
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"
Note: This merges only to master, no way to specify another merge target. Feel free to suggest improvements.
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"I remember trying and failing to get exactly that working. I'll give yours a shot, thanks!
Here are mine, helpful colors and error message included.
sync = "!f() { echo \"$(tput setaf 4)Syncing this branch with origin master$(tput sgr 0)\" && git fetch origin master && git rebase origin/master && echo \"$(tput setaf 2)Branch sync successful$(tput sgr 0)\"; }; f"
ship = "!f() { echo \"$(tput setaf 4)Shipping this branch to master$(tput sgr 0)\" && git checkout master && (git merge --ff-only - || (echo \"$(tput setaf 1)Could not merge branch into local master\\nRun git sync before running this command\\nIf this error persists, you have local, un-pushed commits in your master branch\\nPush them to origin master or move them into a branch before running this command$(tput sgr 0)\"; git checkout -; return 1)) && (git push origin master || (echo \"$(tput setaf 1)Could not push branch\\nRun git sync before running this command$(tput sgr 0)\"; git reset --hard HEAD@{1}; git checkout -; return 1)) && echo \"$(tput setaf 2)Branch ship successful$(tput sgr 0)\"; }; f"
git push --force-with-lease origin HEAD:<remote-branch-name>
They’re already working on it (source: inside info).
It should really support both. I prefer the current behaviour though.
or squash
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.
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.
Perhaps HNers would have appreciated some more substantive action by now, rather than just a response.
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!
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.
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.
Maybe they are still trying to figure out what to do? There isn't an easy solution to some of these problems, and it is not like they have NOTHING else to do than solve this issue.
They could be as transparent as possible and tell us what they have. This seems like just a stopgap to prevent leakage of the more popular OS repos.
Damage control is not a replacement for answers.
Damage control is not a replacement for answers.
After nearly a month, yes. If significant starfighter users complained about how it worked, how long would it take for there to be a response? 2 hours? That is because you care.
A month is how long you spend when you really don't care, when you rather not deal with it at all, but somebody force you to. Of course people get annoyed when those they think cared about them actually hate them.
A month is how long you spend when you really don't care, when you rather not deal with it at all, but somebody force you to. Of course people get annoyed when those they think cared about them actually hate them.
once the troll is fed the appetizers, it demands the main course.
Right? Damned if they do, damned if they don't...
That's an odd impression for you to have gotten!
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.
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.
"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??
A lot of thinking but no action. Github, what have you been up to these years??
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.
You can see a list by scrolling through:
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.
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.
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.
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.
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").
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").
Well they used to be open about their future plans on their blog[1].
It hasn't been even a month after that letter and we _finally_ have a response from them. It really doesn't seem to be that big of a deal IMO.
[1] https://github.com/blog
[1] https://github.com/blog
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.
Any of those would have been better than perfect silence followed with, we'll see what we can do.
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.
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.
Then they might have grown too quickly then. At this point, is really not that hard to move to GitLab.
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.
[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.
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.
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.
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
They haven't for some time: https://www.google.com/search?q=github+meritocracy+rug
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.
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.
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.
Well, that makes it even more ridiculous.
But even if women get worse education, the answer can’t be to reduce hiring standards.
But even if women get worse education, the answer can’t be to reduce hiring standards.
He isn't very fond of HN / Y Combinator as well. His article "Y Combinator and the Negative Externalities of Hackernews" (2014) http://danilocampos.com/2014/09/y-combinator-and-the-negativ... and the HN discussion https://news.ycombinator.com/item?id=8389163
Have you read this HN comments on racism?
They're disturbing.
I don't think he understands the difference between /being racist/ and /neither working towards nor against, just taking profit of a racist situation created by someone else/
(a) is racism, and needs to be fought directly.
(b) is capitalism, and a whole different story (although one could argue that it should be fought, too, and companies should work for the advancement of society, not just profit)
When he mislabels (b) as (a), he distorts the meaning of racism — same with sexism.
They're disturbing.
I don't think he understands the difference between /being racist/ and /neither working towards nor against, just taking profit of a racist situation created by someone else/
(a) is racism, and needs to be fought directly.
(b) is capitalism, and a whole different story (although one could argue that it should be fought, too, and companies should work for the advancement of society, not just profit)
When he mislabels (b) as (a), he distorts the meaning of racism — same with sexism.
Thank you GitHub, to know that you need 29 days to reply, let my OpenSource GitHub Project look not soooo bad. :-)
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/
[1] https://blog.r3bl.me/en/worst-support-experience-ever/
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
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
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.
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.
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.
Maybe the overhauling meant they had no resources to respond? i.e. everyone was busy hiring?
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.
There's simply no winning.
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.
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
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.
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.
> 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.
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.
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 :-)
> I wonder if GitHub itself can use its own issues system for prioritizing feature requests and bugs :-)
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!
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!
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?
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.
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...
Sometimes a project that hasn't seen commits in a long time isn't orphaned, but just doesn't need changes...
[deleted](1)
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.
That is a really bad way to solve the issue, since smaller pieces of software may not need further development.
What's wrong with putting that in the project description ,or prepending it with a "DEPRECATED"? I mean the easily editable field in the header of every repository.
Great, but please resist the urge and goading to build another JIRA in github. The second best thing about github is its simplicity.
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
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.
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.
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.
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.
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)
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.
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.
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.
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]
>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.
Yes, please ignore all reasonable expectations for communication and go back inside the hugbox.
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.
A smart organization will focus on that, rather than weak tone arguments.
Yeah.. Poor github. I'm playing a tiny violin made of hundreds of millions of dollars.
thanks coach.
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.
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.
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)
Just please, whatever you do, do it fast, and stop people from doing what babel did and migrating to phabricator. :P
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)
Just please, whatever you do, do it fast, and stop people from doing what babel did and migrating to phabricator. :P
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.
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.
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.
Ironic that most of the replies were '+1's
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.
If we all demand software freedom, then we won't be so helpless in the future with whatever issues come up.
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.
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.
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.
Kind of sad honestly. Not very good community leadership by ignoring your own community to promote a community leadership conference.
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.
And of course I'm kicking myself that I missed the conference entirely. Sigh. Next year I guess.
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.
They do address the slowness on the commit too and they provided a timeline.
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!
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]
[deleted]
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.
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.
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?
[deleted]
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.
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...
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).
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.
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.
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.
What's the point of "we're going to reply next week" post on a Friday? Just make a statement next week.
GitHub should consider "open sourcing" GitHub itself so the community can submit PRs and RFPs.
But if they did that it might hurt their enterprise, non-SaaS, offering considering people could then install it on their own.
True, but that's GitLab's business strategy anyway.
this would be a better link :
https://github.com/bkeepers/dear-github
What I want, more than anything, is to search on commit hashes.
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.
So tempted to add a +1 comment...
(This is a joke, please do not do it)
(This is a joke, please do not do it)
TLDR; We've been busy making piles of money in Enterprise land and forgot that we acquire customers via FOSS. Oops.
And the first response to their letter was a:
:+1:
:+1:
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.
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.
[deleted]
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.