GitHub responds to Dear GitHub letter
github.com
github.com
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.
That I know of, anyway.
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?
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.
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...
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.
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...
(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.
Also, do you guys do Mercurial? Or just Git?
See https://about.gitlab.com/2015/03/09/moving-all-your-data/
Perhaps their scaling strategy has improved since then.
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.
[1]: https://confluence.atlassian.com/bitbucket/projects-79249795...
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.
You can navigate or search to your groups so I think it does what you want.
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.
Mind if I contact you to ask some questions? It'd be real quick.
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.
Projects fully on GitLab.com include F-droid and Mailman.
It's possible for the same thing to happen with GitHub, though Facebook's continued entrenchment is also a signal that it may not.
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...).
- GitLab
- Phabricator
- GitHub + Phabricator Maniphest (or alternative)
I do have one issue, but I already reported it here: https://gitlab.com/gitlab-com/support-forum/issues/536
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 ...
I fall for this everytime I go to use that link.
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.
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.
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.
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.
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.
Huh, if all the files of the repository at that tag aren't the "source code" of that release what is?
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.
For example: for autotools based build systems you want to run autoconf and automake to generate the Makefile.in and configure scripts.
Do your projects not have a README telling people how to build? Are you targeting a nontechnical or beginner audience?
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.
It's more likely than you think.
[1] http://source.winehq.org/git/wine.git/blob/0f8a0fd4002f9d5d1...
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.
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.
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.
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!
That said, I am also cognizant that "checkbox overload" is a real thing, so merely "for your consideration"
"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.
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.
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?
> 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)
That said, performance is always an issue, it's just a question of where to set the target.
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)
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.
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.
http://www.pcworld.com/article/201297/apples_iphone_4_antenn...
https://en.m.wikipedia.org/wiki/Criticism_of_Apple_Inc.#Qual...
[1] https://dev.windows.com/en-us/microsoft-edge/platform/status... [2] https://www.chromestatus.com/features
Radar issues? They just fall off the radar.
Even goddamn String::split is directly, and reproducably, broken. WONTFIX.
https://about.gitlab.com/2016/01/15/making-gitlab-better-for...
Someone wants your business :p
https://blogs.msdn.microsoft.com/bharry/2016/01/11/team-foun...
"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.
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...
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.
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.
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."?
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.
Insulting customers with empty, insincere declarations is worse than working in silence.
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.
That being said, I bet that enterprises are screaming about Issues too. Enterprise loves their custom fields.
I have absolutely no idea how GitHub could have lost sight of this simple fact.
That'd explain it.
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".
Ignoring your users just to spend a month writing a response to those users is not in the best interests.
their most important constituent
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.
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.
That said, they set the bar pretty high, and now they need to execute.
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.
That's no way to run a modern web-based business for alpha geeks.
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.
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.
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.
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.
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.
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" 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>
Perhaps HNers would have appreciated some more substantive action by now, rather than just a response.
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.
Damage control is not a replacement for answers.
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.
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.
A lot of thinking but no action. Github, what have you been up to these years??
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.
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.
Any of those would have been better than perfect silence followed with, we'll see what we can do.
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.
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").
[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.
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.
They haven't for some time: https://www.google.com/search?q=github+meritocracy+rug
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.
But even if women get worse education, the answer can’t be to reduce hiring standards.
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.
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.
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.
There's simply no winning.
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.
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.
> I wonder if GitHub itself can use its own issues system for prioritizing feature requests and bugs :-)
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!
Sometimes a project that hasn't seen commits in a long time isn't orphaned, but just doesn't need changes...
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.
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, please ignore all reasonable expectations for communication and go back inside the hugbox.
A smart organization will focus on that, rather than weak tone arguments.
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 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.
If we all demand software freedom, then we won't be so helpless in the future with whatever issues come up.
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.
They do address the slowness on the commit too and they provided a timeline.
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!
Kind of sad honestly. Not very good community leadership by ignoring your own community to promote a community leadership conference.
And of course I'm kicking myself that I missed the conference entirely. Sigh. Next year I guess.
Hope to see you at linux.conf.au next year, chris_wot! :-)
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.
(This is a joke, please do not do it)
:+1:
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.