Dear GitHub
github.com
github.com
My name is Jono and I started as Director of Community back in November at GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in.
Firstly, thanks for your feedback. I think it is essential that GitHub always has a good sense of not just what works well for our users, but also where the pain points are. Constructive criticism is an important of doing great work. I appreciate how specific and detailed you were in your feedback. Getting a good sense of specific problems provides a more fruitful beginning to a conversation than "it suxx0rs", so I appreciate that.
I am still figuring out how GitHub fits together as an organization but I am happy to take a look into these issues and ensure they are considered in how future work is planned. We have a growing product team at GitHub that I know is passionate about solving the major pain points that rub up against our users. Obviously I can't make any firm commitments as I am not on the product team, but I can ensure the right eyeballs are on this. I also want to explore with my colleagues how we can be a little clearer about future feature and development plans to see if we can reduce some ambiguity.
As I say, I am pretty new, so I am still getting the lay of the land, but feel free to reach out to me personally if you have any further questions or concerns about this or any other issue. I am at jono@github.com.
My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other people with the same frustration [2], but we have no idea how to get that on GitHub's roadmap.
[1] http://help.trello.com/article/724-submitting-feature-reques... [2] https://github.com/isaacs/github/issues/144
Perhaps if Github used their own issues system to gather feedback on Github itself, they'd more rapidly improve it. I'm sure they'd feel a lot of these pain points in a far sharper, more visceral way if they were subjected to them daily.
What I came up to work around this is:
- Create an org named <YOUR-USERNAME>-deprecated - Move the projects to the organization - Set the avatar of the organization to your avatar, with desaturated colors (purely cosmetic, optional)
Another good example is harthur's "[UNMAINTAINED]" [1]
Anyway, a good example of a successful feature request – shared since it might help others in their quest for success – included me attempting to reduce the problem, scoping it and suggesting a solution. If you can find examples of this problem over multiple open source repositories (in my case nodejs) it seems to contribute to it getting fixed.
- Note the feedback.
- Bring in the right folks to consult with on your end.
- Write a public response with concrete information (should be first interaction).
- Finally, reach out to the authors of this post. Perhaps, getting them more clarity on your roadmap and your thought process will go a long way in resolving matters like this with high profile maintainers.
The next step, as you mention, is to bring the right people in. This is why I want to ensure this is raised with our teams inside GitHub to explore ways to rectify some of these concerns.
At present, I’m not sure how this response is different from the "empty response" that motivated the publication of this document in the first place, except that this response is also public. Comments like "happy to take a look into these issues", "considered in how future work is planned" and "ensure the right eyeballs are on this" uses a lot of words to say nothing. If the community department is not the right place, maybe it’s time to walk over to where the the product group sits and ask. They probably read Hacker New too.
I’ll also highlight a possible theory: the right people at Github have already looked at these requests and decided that is not what Github Issues is for. Perhaps Issues is prioritized for the masses, not the small minority of very popular projects (but not resourceful enough that they have staff). Each of these feature requests do add friction (if only in complexity) and the majority of projects that do not need and should not utilize them. Hopefully someone at Github will quash this theory but it is consistent with events so far.
Why not have the option to enable issue voting? It could be as easy as stars for issues.
Custom issue instructions would be trivial to tuck away in the settings page or associate with a specially named markdown file. They turn a wiki on by default, but you can't instruct users about the info you expect in their issue on the page where they create the issue. Documentation is very effective when it is inline with the system it is describing.
Custom issue fields with validation is a little more complex. Punt.
When people submit your issue tracker to hackernews/reddit/twitter all hell breaks lose and time gets wasted for nothing.
1) apologizing for being new
2) extending borderline patronizing praise (the OP likely wanted a response to the issues put forth, not your approval)
& 3) a promise, which you can't necessarily keep, to put eyes on the issue instead of speaking to the issues raised directly.
It's not what I would expect from someone in that role at that sort of company. It's, unfortunately, what I would expect from a company that had the sort of issues raised by the OP.
Edit: Essentially the same as reported here: https://github.com/isaacs/github/issues/268
Here are some of my fave :+1:-a-thons that help demonstrate when the issue system starts to be less useful, and the Github acknowledgement seems sparse:
* https://github.com/isaacs/github/issues/18
* https://github.com/isaacs/github/issues/215
Also, you might consider empowering your social media team. I see Github as a pretty cool company. And when I sent this tweet, I was expecting to have a bit of a shared chortle with this tweet as I know I would of had with @SlackHq:
https://twitter.com/Ash_Coolman/status/670595632659206146
But instead I got nothing, except a vague sense of having offended someone (sorry BTW, it was only a joke! :'()
Similar to the way twitter provides verified accounts maybe GitHub should consider a tagging these popular repositories to allow for more advanced control over the collaboration project.
When I first read the letter I was a little bit disappointed, one thing I've enjoyed (to an limited extent) is the low barrier of entry to pull requests. The spring boot team especially are extremely patient and understanding when it comes to pull requests.
Hopefully there's enough community will in this to encourage GitHub to make the change, if it does really come down it not being worth the money it would be a disappointing sign.
Given many open source project adopting it for their code repository its important question to be answered.
Otherwise sourceforge.net story will repeat again, this time with github. Many projects adapted it when it was closed source and then when they open source it slowly and later due to falling revenues just started crumbling.
> 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.
I'd like to call out that the GitHub user @isaacs maintains an unofficial repository[1] where the issues are "Issues for GitHub". It's not much more than a token of goodwill from a user to open a place like that to organize bugs (GitHub: you are lucky you have such a userbase!), but it's the best thing I know of for "has someone else thought of this?"[2]. Many of the issues that have been filed there are excellent ideas.
[1]: https://github.com/isaacs/github
[2]: though I'd say if you also think about it, you should also go through the official channel, even if just to spam them so they know people want that feature.
Gitlab[1] is an open source repository manager that supports local installs as well as public hosting at gitlab.com. If author appreciates open source, perhaps they should put their efforts into improving an existing open source option rather than relying on a proprietary solution.
I cannot fathom why people are still actively supporting GitHub.
Even if you ignore the ethical reasons, which if you are an open source developer really should suffice, GitLab is better and more customizable in every way.
Supporting it benefits yourself and all of the FOSS community.
GitHub used to bill itself as "Social Coding", but the "Network" graph has not seen ANY updates since its original introduction in April of 2008. Issues has seen very few updates. Even the OSS projects that GitHub uses internally have grown stagnant as GitHub runs on private, internal forks and maintainership passes to non-GitHub-employed individuals (e.g. https://github.com/resque/resque/issues/1372).
The word "Social" no longer appears on GitHub's landing page. They're chasing some other goal...whatever it is.
I've been puzzled for a while with what github is doing hiring so many social impact employees.
https://twitter.com/rachelmyers
https://twitter.com/BiancaCreating
https://twitter.com/davystevenson
Maybe something more noble than a social coding site?
Maybe something more noble than a social coding site?
I don't want to assume any motive to your comment, but I think it would be a cause for concern if the world at large assumes that women/minorities are hired strictly for their "social impact".
I wonder if threads like this keep popping up if people will say "Fuck it" and build an OSS Github clone that focus on being the Reddit of Code/Git rather than another Version Control Enterprise product.
I'd do it but I'm an asshole, not a community builder.
EDIT:
Since I'm in the edit window and its complaining I submit too fast:
Tbh, the problem with Kallithea SCM and Trac is they aren't really built to generate network effects. They both suffer from the same problem as literally every other unsuccessful Github competitor has:
1) You need something built to generate a network effect first, other considerations second, to successfully compete.
2) You need to then leverage that network to chase Corporate money.
GitHub seems to be neglecting #1 in favor of #2 and that imbalance is an opportunity if someone can exploit it. However, that requires someone who is good at being a community builder rather than a software dev.
I hope they change the decision to support one of the project like Kallithea or trac by migrating their system and build network effects.
git issues "This needs attention"
>> Issue #1 created
git issues
>> List of issues
git issues -u #11
>> Issue #11 up voted
>> #11 Important stuff, needs attention
git issues -d #6
>> Issue #6 down voted
git issues -f #4
>> Issue #4 flagged
Maybe putting most of their efforts into Atom and Electron?
If GitHub is kicking back and sitting on their huge valuations, then it's time to pick up this work again. If issue tracking and code reviews were based on a common, distributed system like git itself, then all these companies could compete evenly for features and UX on top of such a system, without ever having the advantage of "locking in" its users with extremely high migration costs.
There is no longer an "if". It's absolutely true that GitHub is cruising at this time. For example: They are more interested in hiring community managers / community "heroes" instead of actual engineers in SF.
There you go: https://github.com/google/git-appraise
http://lists.suckless.org/dev/1201/index.html#msg10574
Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html
Distributed is the key word. Blockchain/Bitcoin (not withstanding the hurtful politics ongoing at present) has shown the way, and ideally most shared/social things should work in a distributed, trust-less environment in future. Including Social networks and Search Engines.
So it is quite natural, that OSS developers can pave the way for shared/distributed source control (a protocol on top of GIT. Just like HTTP is over TCP).
Just to clarify, I don't hate github. But it sort of obscures the beauty/advancement that is GIT, over previous version control softwares. Wonder what does the creator Linus think of this?
https://github.com/torvalds/linux/pull/17#issuecomment-56546...
Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.
Thinking about it, something like this would be sweet. I would immediately have a snap shot of things that might go boom when I run said software. eta: Instead, I have to go dig through github itself, which is slow compared to greping through a git log.
There’s not necessarily an antagonism between distributed and centralised in this case. You can still have a centralised frontend such as Github Issues, backed by a versioned and distributed backend using i.e. git.
Interesting side note: With the exception of Selenium, most of signees are maintainers of JS/HTML OSS projects. I wonder if we could objectively compare JS to <lang> projects in terms of the problems mentioned in the document. For example, there is a strong correlation between +1'ers and JS repos vs. Python or vice versa. Perhaps, we could walk away with JS devs are more chatty than CPP developers when discussing issues... I don't know, just a thought.
Monkey see - monkey do.
1. Close the PR with little or no comment. People then think I'm an asshole.
2. Spend hours explaining why the code is terrible and why it can't be improved. In addition to being a big time sink, PR submitters often don't understand the criticisms. Half the time, they still think I'm wrong.
People even defend stuff as obviously wrong as adding a thousand lines of GPL'd code to an Apache-licensed project.[6] Then they say I should remove .gitignore support from ag because it doesn't implement 100% of .gitignore syntax. As if users would be happier with tons of extraneous results instead of some extraneous results.
A lot of this is cultural, but GitHub could help steer things in a better direction with the features proposed in this letter. I hope they take this letter seriously.
1. https://github.com/ggreer/the_silver_searcher
2. User accuses ag of hard-locking his computer: https://github.com/ggreer/the_silver_searcher/issues/791
3. User wants ag to always print filenames, unlike every other tool out there: https://github.com/ggreer/the_silver_searcher/issues/749
4. User wants ag to replace PCRE with a totally different, incompatible regex library: https://github.com/ggreer/the_silver_searcher/issues/698
5. User aliases 'ag' to 'grep', then complains ag doesn't work: https://github.com/ggreer/the_silver_searcher/issues/578
[1]https://meta.stackoverflow.com/questions/277314
You can sort something by stars, but it's bad etiquette there for a user to comment +1 rather than just star.
This becomes heavily apparent when someone posts an Android issue directly onto the Android subreddit. I suspect the same could happen with GitHub issues. When you see others posting "+1", then others follow the same practice.
I wonder if those types of projects are more likely to have these problems (larger userbase? Less experienced userbase? just different userbase?)? It could also just be a coincidence that they knew each other because they work on similar things, and a group of people who knew each other are the ones who wrote the letter.
Spam would indicate that +1 adds no value.. But it does! If I have an issue with no comments, no indication of its importance to the users, then I would deprioritize that issue over another one that has lots of activity.
>Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.
Every checkbox, text-field and dropdown you add to a page adds cognitive overhead to the process and GitHub has historically taken a pretty solid stance against this.
From "How GitHub uses GitHub to Build GitHub"[1]: http://i.imgur.com/1yJx8CG.png
There are tools like Jira and Bugzilla for people who prefer this style of issue management. I hope GitHub resists the temptation to add whatever people ask of them.
[1] http://zachholman.com/talk/how-github-uses-github-to-build-g...
Yes! The maintainers deliberately want to add cognitive overhead so the quality bar for creating issues is higher.
By having simple zero-friction forms, you haven't removed cognitive overhead. You've simply shifted the cognitive load into the followup messages asking for clarification of "reproduction steps", "version tested". The issues' threads therefore begin with "meta" type questions which duplicate the checkboxes and dropdowns you were trying to avoid.
The default can remain zero-friction but it seems very reasonable to offer options for maintainers to gain some control over their inbox.
A simple optional field to include the version number that the issue was being reported against would do wonders for my interaction with users.
And you don't need to include that on your software project, but really if our users can't be bothered to tell us what version they're running, I have many, many other issues to fix which I know are broken in master.
Which I guess is the difference. If you're a small project with few users, then the handful of bug reports you get are useful and you want a zero barrier.
I have literally thousands of bug reports, hundreds of those will be left without ever being fixed (even though they may be perfectly legitimate). I have to triage. If a user is blocked by not being able to tell me what version they are running then that pre-triage of making them not even bother to cut a ticket with bad information is useful because then they don't waste any of my time...
As someone who has opened issues myself on projects in gitHub its easy to be unaware or even forget all the information a maintainer would need to reproduce the issue. As someone who uses an open source stack every day anything to make the whole issue flow better for maintainers and users I'm for 110%
- GitHub doesn't use GitHub issues to take feature requests or bug reports.
- GitHub doesn't use Pull Requests to allow users to submit bug fixes
When all your issues and pull-request are being raised by a defined set of people who are (or ought to be) committed to the same collective goal (because they're employees of the same company) you can develop a culture and norms around how those things work.
If "Some Guy" at GitHub raises issues where the only description is "This feature doesn't work on Mac" or raises PRs where the only description is "this fixes a bug I found" the cultural pressure would teach him/her that's not how things are done, and if the lesson wasn't learned, then they wouldn't last at GitHub.
When the people you're interacting with are infrequent contributors, it's a different scenario. They need guidance. They need to be pushed to go down the helpful path on their first attempt, because there are too many new contributors and they often don't stick around for long enough to change behaviours by osmosis and cultural pressure.
I do concur, but there should be at least some of them. One shouldn't have to hope that people will be kind enough to submit proper issues, the platform should force them somehow to do so. I think, if a study of github issues was made, we'd see that about first five messages on a given issue would be those of maintainers craving for more input. What is the output of dmesg, how is your configuration, what is the output of the process, can you run it with the verbose flag on... A bit of cognitive overload is good, so that who submit bugs are those who take the burden of doing so.
And I agree, simple is good... but simple is also bad for large projects, as while it makes it easier to create a ticket, it makes it harder to track for the maintainers. They are (rightfully) looking to ease their work, and I do believe it is a net win for both sides if filing a bug is made a little harder, but it becomes a lot easier to manage.
Taken all together, it seems like github is on a path of alienating their most valuable members. Github was unresponsive to Linus' feature requests and it turns out that theme continues almost 3 years later.
If github plans to evolve into a full-featured ALM[2] like MS Team Foundation or JIRA instead of being relegated to being just a "dumb" disk backup node for repositories, they have to get these UI workflow issues fixed.
[1]https://github.com/torvalds/linux/pull/17#issuecomment-56546...
[2]https://en.wikipedia.org/wiki/Application_lifecycle_manageme...
If github evolves to the projects you're mentioning, you'll surely alienate the many more casual users. I personally hate working with the bloated applications you mention.
Ummm ... anybody getting the irony here?
And, from a GitHub business perspective, why do I hear Lily Tomlin: "We don't care. We don't have to."
Everybody anointed GitHub as "the chosen one" over strenuous objections from some of us that creating another monopoly for open source projects is a bad idea.
Pardon me for enjoying some Schadenfreude now that GitHub leveraged the open-source adoption into corporate contracts and now doesn't have to give two shits about open source folks.
Lily Tomlin's Phone Company Sketch: https://www.youtube.com/watch?v=CHgUN_95UAw
It's likely that GitHub will alleviate these pain points in time, but the lesson is the same: let a company control your destiny and you can no longer have what you want or need when their interests diverge from yours, even if their system is the best there is and was radically better than everything else at the time you switched to it.
Only gripe is that some parts of it are still highly coupled, so doing something like adding a custom button to the text editor view or writing your own internal application very quickly becomes a huge mess, an effect that is multiplied by the active development and no promise of stable public APIs.
Your experience will be great as long as you don't try and do anything custom, at least for the next year or two.
Seriously: if you have a web server (or php hosting) anywhere, try out phabricator; it's easy to setup, and you can even point it at a github (or any public git/svn/hg) repository to fiddle around with its features, as hosting the repository inside phabricator is not mandatory.
Making an issue or a pull request feels like having a casual chat with the project maintainers. Adding fields and other hoops to jump through puts distance between people.
Well, there's your problem right there.
(I have sooooo much more in this vein but I'll spare you. ;-)
EDIT: No I won't. Fuck it. This is too ridiculous.
These guys (and they are all guys) chained themselves to github's metaphorical car and now they're complaining that the ride is too bumpy and the wind is a little much.
Don't whine about not getting to sit inside the car! Unchain yourself and go catch one of the cars where the doors are unlocked and open and the driver and other passengers are beckoning you to join them. (Apologies for the mangled metaphor.)
These folks come off to me like masochistic babies.
Shouldn't we (the OSS community) have an open source, roll-your-own version of something like GitHub? Like, the repo-management equivalent to a phpBB or a Wiki or a Wordpress.
We do have the separate components, though maybe the hard part is to glue them together. But still, it is something what would be worth the time and effort, wouldn't it?
The only aspect I could think of where Github has the pro is the community of developers it has, but does it really matter that much? Especially for established/big projects that probably don't care about the fork/stars numbers, or the random look around-ers that pass by.
You outlined exactly why people don't build their own or use another system. Github is the best there is. That doesn't mean it doesn't have problems, but if your company/project/expertise isn't focused in collaborative development and/or version control, you're just distracting yourself by building your own.
The authors are not saying "we can build a better Github." They have complaints and would like them resolved, but don't see a good way of having that happen.
Doesn't matter really as it's still a locked platform. The argument they're making is that they're developing in the open and they'd like some sort of expedited treatment because of the size of the project or because they're doing OSS. I don't think those two can go hand in hand all the way.
Open Source projects move to GitHub because their users are all already familiar with GitHub from all the other open source projects that use it. That means those people already have a user account, know how to check out your code, are able to file issues, and can probably make contributions even if they're not very familiar with git, for example using one of the GitHub integrated GUIs that will handhold you through making a PR. If you are an odd-duck project using some other infrastructure you don't have any of these advantages, and the barrier to entry for potential contributors is correspondingly larger.
For users having a near-monoculture of source code hosting has all the same advantages but reversed; it means they only need a single account, and that every process they learn — all of which are well documented across the web — is fully transferable between projects. It also gives them a recognised place to show off their own code, and increasingly people are asking for a link to a GitHub profile as part of a hiring process. This even happens at Mozilla, an organisation that doesn't actually use GitHub for its most prominent projects (but increasingly does for new things; the advantages I mention here are valuable even when you already have everything set up for using something else).
Another benefit enjoyed by projects that use GitHub is the plethora of tools designed to integrate with it; again little to do with the intrinsic merits of the tool and everything to do with network effects (although I will allow that the API is generally very good). So if you chose an alternative to GitHub you might miss out on IDE integration, Travis, landscape.io, reviewable.io, or any number of other third party tools that either exclusively work with GitHub or have smoother integration in the case of such a well-worn path.
Tools like reviewable.io are interesting because they are clearly making up for deficiencies in the GitHub platform itself. In that case it's the totally, utterly, useless code review functionality in stock GitHub. And there are many other things in the site that could stand to be improved. For example the notification system that either spams you with every comment from a repo or ensures that you miss anything you don't check via the web UI. The permissions system that makes it impossible to add commits to a PR against your own repository without losing all the metadata associated with the PR. The issue tracker that doesn't allow assigning issues to anyone other than a project admin. But, from a business point of view, none of these things matter because GitHub isn't popular for being the best. It's popular for having been good enough for long enough to become ubiquitous, and now not being so bad as to negate the enormous network effects.
So the core of the problem here is not whether or not the authors, or anyone else, can build a better GitHub. The problem is that even if they could it would have to be wildly, dramatically, better to even provide competition. And so people, without meaningful leverage, resort to writing open letters and hoping that they can drum up enough noise that someone at GitHub chooses to care.
Github is a great advertising and marketing platform for large OSS projects. Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge (sorry FOSShub, it was a bold try), with all that implies.
The thing I really don't get is why people use it for small projects. Like Facebook, Twitter and basically every other social media site out there, it's a drama factory. It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
That's the last thing small OSS projects need, and I'd have thought most 5-15 man projects would be vastly better off throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business. I acknowledge that this reduces discoverability by some amount and thus risks taking a hit to your developer acquisition, but I'd love to see some hard numbers on how much. I'd wager that much like the Apple app store, if you're not in the top 50 on github, you're no one.
But hey, I'm apparently an old fogey born young, and I prefer to self-host when I can, so maybe I'm just pointlessly resisting the tide of the inevitable or something.
> Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge.
Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform. If it's the issue of getting people excited about the project to want to use it or join in and help, it'd be interesting to see if there are any numbers to back this up.
I'm not sure about sourceforge but i never thought of it as a serious thing for big project hosting before github came around.
> It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.
Totally. This is a good point I think. I never understood the fascination with obsessive forking (edit: lol, after the letter moved to github it got 2 forks! WHY! https://github.com/dear-github/dear-github) just to apply a patch or change a line of code (there's a lot of those). It's a nice feature and all, but not really that useful imo. I'd like to see some data on forks that haven't been touched as well, amounting to garbage, outdated code basically.
> ... throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business...
The thing that bugs me the most about Github and the likes is this. It's slowly taking away the will or need to do this. Same as how the use of Slack/Gitter has somewhat eclipsed IRC in OSS world. From my experience, I learn a lot when I'm doing things I don't really want to do or I find tedious because I either discover that there's a detail that I don't understand well or it motivated me to write an automator to sort things out.
> so maybe I'm just pointlessly resisting the tide of the inevitable or something.
Wait until the fixation on cloud crap washes off and everything will be back to normal lol.
Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project.
The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
There are multiple ways to go around this, OpenID, Mozilla Persona, or any third-party authenticator.
> The final thing is just name recognition. People trust code from Github. They shouldnt, but a Github URL legitimizes your project more than git.abrakadoodle.io.
I see this more of an additional reason for big projects to move away from Github. It gives unwarranted legitimacy to everything on the platform.
There is GitLab, which is good and is FOSS in addition.
It's a huge tax on attention and contributions if a project decides not to use GitHub. There are many GitHub replacements but none of them have the community of GitHub.
Most of these features are ones that only affect public projects. You're not customers of Github, you're the product. Or rather, the advertising.
Network effects strong enough to slow the growth of any competitor long enough for GitHub to adapt.
Management, money, growth.
That said, we do sometimes consider setting up an official mirror on GitHub. Ideology aside (some team members might think we shouldn't promote a propriety solution for free software project), the main thing that puts us off is that there is no way to disable pull requests. Closing all pull requests by hand is not appealing; leaving all pull requests open is not desirable. We can probably write a bot to close pull requests, but that is just yet another administrative burden.
Not sure if GitHub will ever consider allowing users to disable pull requests though. That seems to go against GitHub's core interest.
[0] https://github.com/freebsd/freebsd/pulls [1] https://github.com/torvalds/linux/pulls
React Native, the open source project, is using Product Pains instead of GitHub issues for bug reports and feature requests. This is because there were thousands of open issues and, just as this document mentions, it's impossible to organize them. The comments are all "+1" and it's really hard to tell what's important and what's just noise.
If you take a look at https://productpains.com/product/react-native?tab=top you'll see the power of being able to vote on these issues.
So why's Product Pains relevant?
1. It's a temporary alternative to GitHub issues. I'm guessing GitHub will get to adding votes eventually. If you want to use Product Pains for organizing issues for your open source project, go for it. I'll even give it away to you for free.
2. It's a community dedicated to improving products. This document is chock-full of great, constructive, actionable feedback. Product Pains is a community built for posting exactly this. You can post feedback publicly, about any product, people can vote on it, and posts with a lot of votes create a social responsibility for the company to respond.
3. It's a way for your voice to be heard. Posting on Hacker News lasts a day and will get your voice heard. If you post actionable, constructive feedback on Product Pains, and 150 people vote on it, it lingers waiting for GitHub to do something about it. Around 600 users on Product Pains are also React Native developers. They'd probably be ecstatic to vote on constructive feedback for GitHub.
For example, go make an account and vote here: https://productpains.com/post/github/implement-voting-for-is...
- Multiple assignees for an issue - An "Approve" button so that maintainers can stamp a PR with the seal of approval
None of the complaints are about the GitHub business model, which is IMO pretty fair.
It'd be really nice if I could custom sort the queue of issues so that I know what's next up in my queue of things to do; right now I've got 5 tags called NextUp:1 -> NextUp:5 on each repo; this takes way more manual updating than a simple drag/drop widget.
Like they mentioned, having a voting system would be super useful for knowing what matters -- I cringe every time I leave a +1, so I've gotten into the habit of at least adding a comment after it --- but the premise and the pain are the same.
The addition of a task board in the GitHub interface allows you to communicate both the priority and progress of GitHub issues.
While adding a +1 button to comments allows feedback without clutter.
Best of all, it is free for Open Source :)
You can read more on why we created ZenHub here - https://medium.com/axiom-zen/introducing-zenhub-2-0-c352a12c... and get in touch with us via our public support repo here - https://github.com/zenhubio/support
I hope we can help improve your GitHub experience!
I also think that voting systems should only have /positive/ inputs. (I agree with the content of a given statement/post). Negatives belong as a concretely expressed /contrasting opinion/ which can, it's self, be 'agreed with' (voted for).
That said, I'm extremely grateful to the platform for enabling collaboration on open source and to the company for its work on Git, Resque etc.
GitHub's strategy is to open source everything except the business critical stuff, but it seems to me that their business is in enterprise support rather than in actual software. Perhaps they should just open source the whole platform and count on their service business being enough to carry the company?
I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.
I do think there should be a +1/like button though.
I don't think the authors are requesting that this be made mandatory for all repos, but instead they just want the option to set up rules for repos they maintain. As someone giving up their free time to offer software for the rest of us, it seems only fair to let them set the rules about what they need before they can resolve an issue.
The biggest issue I see OSS maintainers running into is that they likely aren't the voice that Github listens to most anymore. If they can get some companies that pay for Github Enterprise to sign their letter as well that would likely help prioritize these features.
> Maybe if your software was better designed, people wouldn't be asking the question to begin with.
This is just silly.
The thing is, if they implemented issue formatting in the way the posted document describes, the default would be exactly what it is now. Giving maintainers more control can't possibly be a bad thing.
For the opposite side of the spectrum, there's the Bitbucket+Jira combo. It is customizable to a PM's heart's content, and in the process can become a mess of a tool.
Their 'control' of code and lack of respect to the people running projects is very disappointing and they seem to not want to move forward on the issues.
I'm surprised the open community is allowing this de-facto ownership of the worlds code and how it's written to take place, I'm not so sure they are a benevolent dictator.
https://www.techdirt.com/articles/20150802/20330431831/githu...
I also noticed that most of the repositories seem to be based on Javascript.
> JavaScript developers _(at least the ones using GitHub)_ are more prone to complain than other type of developers.
My guess:
Based on numerous sources [1][2], Javascript is the most popular language on GitHub. So there are more developers, more repositories, more activity involved. It just happens that one (or a few of them) talked this through and gather up other folks in their community.
[1] http://githut.info [2] https://github.com/blog/2047-language-trends-on-github
Regarding the three demands in the doc:
1. GitLab has issue templates in EE and on GitLab.com https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/28
2. GitLab has the award emoji function that doesn't spam and acts as a voting system https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
3. We're open to displaying CONTRIBUTING.md more prominently, please open an issue on our public issue tracker that contains all our planned features https://gitlab.com/gitlab-org/gitlab-ce/issues
I'll go sleep now but please ask any questions so I can respond tomorrow.
Unfortunately, there's no Travis CI integration yet, which I've been using on GitHub a lot.
I'm evaluating GitLab CI right now. Am I right, that I have to host a runner myself if I don't want to use a shared runner for my project?
> You can setup as many runners as you need. Runners can be placed on separate users, servers, and even on your local machine.
Does "local machine" really mean a non-public machine like my notebook?
Appreciating help from GitLab's CEO :)
Every checkbox, dropdown and mandatory field they add makes GitHub Issues less attractive to those who don't need it. Simplicity is a feature, and it's one that you sacrifice as you make your software more flexible.
Google Code had stars in order to encourage people to +1 something without creating noise and then instead of +1 comments you got +1 comments AND people yelling at them for using it wrong.
We’re really pumped about improving dev team collaboration in the GitHub ecosystem by (soon) letting anyone use Sourcegraph.com’s code intelligence (semantic search/browsing), improved pull requests, flexible issue tracking with Emoji reactions instead of +1s (example: https://src.sourcegraph.com/sourcegraph/.tracker/151), etc.—all on their existing GitHub.com repositories.
All of Sourcegraph’s source code is public and hackable at https://src.sourcegraph.com/sourcegraph, so it can grow over time to solve the changing needs of these projects. (It’s licensed as Fair Source (https://fair.io), not closed source like GitHub or open source.)
Email me (sqs@sourcegraph.com) if you’re interested in beta-testing this on your GitHub.com repositories.
My workaround has been to use email notifications exclusively. I have a Gmail filter that applies a label to all notifications and skips the inbox. Then in my mail client I have a smart mailbox that only shows me unread notifications with that label (or that folder, from an IMAP perspective). The smart mailbox then shows me a counter of unread notifications. This way I don't oversee comments when multiple ones are made in a PR.
Problem 1: No context in these notifications. It would be nice if these emails could show the code in question for diff comments or the entire comments thread.
Problem 2: Now what is really bad with these notification emails is that the link "view it on GitHub" sometimes no longer links to the comment I'm being notified of. This happens when the comment was made on a PR on a line of the diff that no longer exists, as sometimes is the case when new commits are pushed. I then have to go to the main PR page, expand all collapsed "foo commented on an outdated diff" comments and manually search for the comment in order to get the context and be able to reply.
By fixing problem 1, problem 2 would be automatically fixed with it and make my workflow much more productive. Is there anyone else annoyed by this?
I think the bundling aspect is an awesome feature! I can read multiple new comments all at once, with context in mind and less total context switches.
About being able to miss new comments - doesn't the link in the notifications UI take you directly to the first unread comment?
But I read some complaints about the users and the issues they tend to open and I fully agree. They are a minority but I can't only imagine what people with bigger projects have to deal with. This is what I've found:
- People with little to zero experience in the language/framework that simply state that my project doesn't work without providing more information and sometimes they didn't reply to my "give me more info" inquiries.
- Guys who just want to get their homework done and They are basically trying to get it done using me as non-paid freelance.
- And my favourite one, junior dev in a company, he needs to get their work done with more pressure than the previous one so became anxious about their problems and I feel it even via email. Eventually He gets the thing done but He notices I changed the build system to Jitpack for better dependency handling and and start to complain about Man in the middle attacks to his company and black-hat hackers replacing my lib with a malicious one (I guess it could happen but come on).
But it is a very rewarding experience besides these anecdotical cases
You can also run JitPack on-premises and have full control over build artifacts.
They all seem to stem from the fact that github is too successful. And too many people are on github and too many people are using it, often in wrong ways.
Of course github should solve them all. But still, it's still better to have problems with too many people and too much interest, than have the opposite problem - dying platform that people are leaving (see: sourceforge and Google Code).
Ability to block users from an organization.
Why blocking a whole organization from an open source project? What would prevent such users to use a personal account instead to do what they organization counterpart is blocked from anyways?
GitHub is fantastic because everyone is on it, but the issue system has not improved since inception - and I felt the UI changes have actually stepped back.
We had to implement our own bot to comment on tickets that did not appear to follow a template, and I would have given a kingdom for a template that let people filter their own tickets into whether they were bugs or feature requests or doc items.
We also had a repo of common replies we copy and pasted manually (this because there was so much traffic and me replying quickly would likely tick someone off - but this too could have been eliminated mostly with a good template system). Having this built-in (maybe I could have picked a web extension) would have also been helpful.
So many hours lost that could have been features or bugfixes - and by many, I mean totally weeks, if not cumulative months.
GitHub does the world a great service, and I love it, but this would help tons.
I always got a response when I filed a ticket - ALWAYS - but a lot of them were in the "we'll take that under consideration" type vein.
I feel opening GitHub RFEs up to votes is probably not the answer to serve the maintainer side of the equation, since users outnumber maintainers, but these needs to be done and would greatly improve OSS just based on expediting velocity.
If you don't use the GitHub tracker you lose out on a lot of useful tickets. However, if you use it, you are pretty much using the most unsophisticated tracker out there.
It's good because there's a low barrier to entry, but just having a template system - a very very very basic one, would do wonders.
A final idea is that GitHub really should have a mailing list or discussion system. Google Groups sucks for moderation, and I THINK you could probably make something awesome. Think about how Trac and the Wiki were integrated, for instance, and how you could automatically hyperlink between threads and tickets. The reason I say this is often GitHub creates a "throw code at project" methodology, which is bound to upset both contributor and maintainer - when often a "how should I do this" discussion first saves work. Yet joining a Google Group is a lot of commitment for people, and they probably don't want the email. Something to think about, perhaps.
Also think about StackOverflow. It's kind of a wasteland of questions, but if there was a users-helping-users type area, it would reduce tickets that were not really bugs, but really requests for help. These take time to triage, and "please instead ask over here and join this list" causes people pain.
I love all the work to keep up site reliability, maybe I'd appreciate more/better analytics, but I totally say this wearing a GitHub octocat shirt at the moment.
+1 from the Kubernetes project
The main bread and butter of GitHub is from private or organizational projects and do not have these issues
The majority of accounts on GitHub are folks like the majority of HN readers - developers, coders, hackers and do not have these issues.
So all these complaints are in a sense not applicable to the vast majority of both GitHubs revenue generating customers and the vast majority of GitHub users.
What I like about GitHub's issue tracking is that (compared with alternatives, such as Redmine or Jira) it is free form. It doesn't force users to fill information such as steps to reproduce and I don't think it should. And that's because the needs of every project is slightly different. Consider how different the "steps to reproduce" are for a web user interface, versus the usage of some library. Yes, it can be painful for an issue to not provide all the information required, but on the other hand GitHub does a better job than alternatives at fostering conversations and keeping people in the loop. I've even seen projects use the GitHub issues as some sort of mailing list.
On the second point, I do agree that GitHub needs a voting system for issues. Given that GitHub has long turned into some sort of social network, adding a voting system for issues is a no-brainer. But then a voting system doesn't address the problem of people getting frustrated about issues taking too long to get fixed. +1's are annoying, but sometimes that's a feature and I've been on both sides of the barricade.
Seems like the Tony Soprano way of doing things.
[0] https://src.sourcegraph.com/apps/tracker
[1] https://godoc.org/src.sourcegraph.com/apps/tracker/issues/gi...
Disclosure: I work on ZenHub :)
Thanks!
So every time someone who knows a "Sam" uses @sam incorrectly in an issue I get notified, have to unsubscribe, ignore, and leave a polite message to let them know they're doing it wrong.
It's really lame that they've never fixed this.
* Issue templating.
It's one thing to prefill the entry box, it's quite another to add fields that everyone must fill out. I quite like that filling out something on Github is totally the opposite of filling out something on Jira.
* Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines
This is a people problem that has plagued open source from day one. You cannot engineer your way around it in a manner that doesn't annoy your contributors.
There was a blurb in here about getting rid of the big green "new pull request" button, but that was when this link went to a google doc. Good - if someone doesn't want to take PR's, then they have almost no reason to be on Github in the first place. Put another way, it's the mark of someone that wants a repo as a signpost of sorts without actually interacting with its community.
GitHub needs to step it up. They got to the top first, but can they stay there?
Next, we'll see public complaints to Microsoft because MS Word doesn't properly support the way they want to maintain their project's documentation?
I mean, sure, feel free to complain all you like, but how is this not exactly what was to be expected from the beginning, and why do you expect them to care in the future, given that you just seem to have realized that they didn't care in the past, for obvious reasons, and given that their incentives haven't changed, and there is no reason for them to change in the future?
As an example of how this would be used, we have a Github team within our organisation which is used for non-technical people to post bugs. These people have no reason to be able to see or push code to the repository, they only need to be able to create issues. This applies to every repository in the organisation. As far as I can see, and without manually adding every single repository to the team, there's no way of setting global permissions permissions for a team. This seems like a major oversight to me.
Anyway, I found that http://feathub.com/ addressed my frustration about the absence of a voting system.
They make a facility available as a nicety, but if your project has legitimate Global impact, you should be looking at (or bootstrapping) a counterpart.
Don't have the revenue for JIRA? Apply for the Free license.
Don't have the stomach for Bugzilla? Turn out a Node/Go alternative.
Don't have the business alignment with Clearquest or Rally? Lower your expectations to suit your Free (as in beer) SCM tool.
Yet, I 100% agree with them. I do not understand why Github issues are so basic. The only feature I feel was added in all of 2015 was making the logging of every metadata change extremely verbose (read: maybe too noisy now?!).
"Person assigned to the issue"
"Person added label"
"Person removed label"
Don’t make it so easy to submit bad PRs
> uh oh, someone is still sulking [...] We really don't care about the drama
Oh, okay buddy.
> Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!
LOL. I can't tell if this is "go-fuck-yourself"-level passive aggression, or mindless hopefulness that there might actually be a universe in which Github (or a company like it, with hundreds of millions of dollars of venture funding) could be open source. If I worked at Github, my first thought after reading this would be "mmmmm yeeeeaaaaaaa y'can g'fuck yr'self", while the second thought would be "yea, you're not wrong". Generally, passive aggression gets you nowhere when you're asking for something from someone/something who owes you nothing (I know, I know, they "owe" their customers everything).
The Node/React/JS community is hilariously entitled, petulant and childish. The tone of this whole letter is so god damned millennial, it's mind-boggling, because they're not wrong about anything they're asking for. But it's how they ask for it that leaves a dry, acid-y taste in your mouth.
We’d like issues to gain a first-class voting system,
and for content-less comments like “+1” or “:+1:” or
“me too” to trigger a warning and instructions on how
to use the voting mechanism.
That, and something for code review. Pull Requests are terrible for code review, and it wouldn't take that much to make them so much better.
I also tried the demo, and was shocked to see that Reviewable had edited our PR descriptions to include a big "Review on Reviewable" badge. We currently make heavy use of PR descriptions in quite specific formats, and it felt like Reviewable was forcing itself upon us.
To be clear, I'm really glad someone is looking at this problem, and Reviewable looks like a step in the right direction. I'm just quite opinionated on code review and developer tools, and I feel like it could be much better.
It’s pretty neat as a general user, but at least you get the impression with BitBucket that they prioritize productivity and project management. And the task system hasn't received any significant updates since their inception - which is a shame, because tasks are an awesome invention, they just have to be implemented awfully with issues.
I also remember that we recently had to move the entire decision-making process to Slack instead where I suggested we just use the emoji voting system to make our decisions with.
What really gets to me is how adamantly GitHub has ignored all the people who've gone on about this forever. Last time they seemed to care marginally was when jacobian finally managed to twist their arm and get them to implement the Close Issue feature, because one repo issue was a radioactive pit of abuse and invective.
There could be (theoretically) no one to make anyone do anything, and perhaps the issue tracker is either a quagmire of a codebase or something no one wants to touch because something else is more exciting?
That's one theory.
My other theory is they spend a lot of time on scaling problems and/or GitHub enterprise (which I haven't seen) -- and don't really do features anymore.
But it does feel there is no vision for changes to GitHub (maybe they think it's "solved") and it's ceasing to evolve in noticeable ways in any direction.
Can't really be sure. But I find it interesting. Again, the core is good. It's just curious to watch it so closely and not see the needle moving in any perceptible way.
Then again, it could be the kind of anarchic Libertarian or laissez-faire bent that we see with reddit that makes it exceedingly different to grant special permissions and privileges, especially across subreddits/issues/users/orgs. Or maybe user experience just doesn't matter for today's start-ups; maybe we've passed the Overton window for start-ups deciding it's not worth caring about their users.
A lot of the time, I feel like more of a user+ than a(n) (super)admin on my own repos. I might as well have the permissions and tools to ruin my own project - in the name of pure unadulterated freedom if for no other reason.
The dashboard and notification system have always been POS, too, so it might just be that everything that basically isn't tethered to a GUI is on the bottom of the totem pole.
Anyway, implementing just voting won't be a such a good idea in the time of Emoji Reactions!
So the issue isn't that GitHub didn't let them clean up the issues after the fact, but that there were no a) rate limiting options, b) user reputation options, or c) issue submission filtering options.
Any one of those three would have reduced the impact significantly.
PS, it was moved to https://github.com/dear-github/dear-github
There are tradeoffs, so pick services you like.
What is being done in the JS community by those who lead it to make progress on this and who is leading that charge? If the answer is "Nobody", why is that true?
Conferences already reverse discriminate by aiming for a gender balance in speakers (despite the submissions they chose from being very imbalanced). User groups have adopted CoCs to protect female and minority members. There are even female-only special interest groups. There's also this: https://github.com/nodejs/inclusivity
Besides, the list you're referring to is not an exhaustive list of important JS projects. It's a list of maintainers who have signed this open letter. What does their gender add to the conversation?
Inclusivity in programming comunities and JS/node in particular has drastically improved throughout the past decade. But structural changes take a long time to show results. The distribution you're seeing today represents what was being done in the past, not what is happening today.
This is like blaming the schools for poverty. Yes it would be wonderful if Node module maintainers were a perfectly representative blend of all the races, genders, religions, and orientations on Earth. The gap between that vision of Node and the one we have pales in comparison to the gap between that vision of Earth and the one we inhabit.