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 [email protected].
This, I feel, is the most important bug, even though it precedes the list:
> 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.
[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.
The author mentions that if GitHub was open source, they would implement these features themselves.
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.
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.
We need world class, modern, distributed bug tracking now. If you google around for this technology, a lot of nice ideas, many using git itself as transport, were poking around, and around 2009 they started falling silent. Why? Because GitHub started up and everyone just buzzed over to it like so many moths to a flame, having learned nothing from places like Sourceforge about what happens when 90% of the open source world trusts their issue trackers, which is really a huge part of a project's documentation, to a for-profit, closed source platform that does not provide very good interoperability.
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.
> If GitHub is kicking back and sitting on their huge valuations,
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.
This. I'm a big fan of Github, but it bothers me that this single service is the centerpiece of most OSS projects. We see it every time Github goes down and virtually nobody can be productive anymore.
I hope to see a version control system on top of IPFS some day.
>We need world class, modern, distributed bug tracking now
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?
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.
I do not operate a popular OSS project, but I have experienced the +1 spam and it sucks. The suggestions, in my opinion seem rational.
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.
I think it's just monkey see->monkey do. As soon as one person said +1, everyone that saw it thought that that's just how you voted for stuff. It's the same reason you see comments on HN or reddit that just say "This." or that if you leave your shoes by the door, everyone else will do the same. I doubt these people keep doing it if you ask them not to.
I maintain a C repo[1] and user idiocy is much lower than what I've seen in JS projects of similar popularity. Still, I agree with these criticisms of GitHub. I hate +1 spam enough to delete such comments. Sometimes I even ban those who do it. I'm frustrated by people who open idiotic issues[2][3][4][5]. I procrastinate on bad pull requests because my options are:
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.
The same question about JS repos struck me. I suspect that if you write a shared letter then you just ask your network to sign it instead of <random other person from different ecosystem>, but I would be curious to know if these grievances are disproportionate in different communities.
I agree that the suggestions are great; I'm also generally happy to see a letter like this take a clear tone without being aggressive or overtly confrontational. Re: the prevalence JS/HTML projects, I think that may just be a matter of simple base popularity; the web is the most popular development platform, and JS is the most used language on github (githut.info has great stats on this). If the letter gains steam, I'm sure we could expect project maintainers from other ecosystems to get on board.
I noticed that most of the signers are maintaning JS/HTML projects too.
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.
+1 isn't spam. It's valuable. However the implementation of how people can +1 an issue that's very important to them is the point. There should be a voting system.
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.
This first request is the anti-thesis of GitHub's simple approach:
>Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.
Every checkbox, text-field and dropdown you add to a page adds cognitive overhead to the process and GitHub has historically taken a pretty solid stance against this.
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.
The bullet points of complaints feel like a continuation of Linus Torvald's refusal of github pull requests in May 2012.[1]
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.
Distributed revision control users whining about centralized repository lacking features.
Ummm ... anybody getting the irony here?
And, from a GitHub business perspective, why do I hear Lily Tomlin: "We don't care. We don't have to."
Everybody anointed GitHub as "the chosen one" over strenuous objections from some of us that creating another monopoly for open source projects is a bad idea.
Pardon me for enjoying some Schadenfreude now that GitHub leveraged the open-source adoption into corporate contracts and now doesn't have to give two shits about open source folks.
There's been no mention of phabricator yet so I thought I'd give it a shout out. It's used by LLVM, FreeBSD, Blender, Wikimedia and others and I love it. It's under very active development and even if it doesn't solve every issue in this letter, by using an open source tool for development you of course have the option to customize it to the needs of your community.
Is this a case of the squeakiest wheels getting the grease? What if these problems aren't representative of the overall user base? What if far more people prefer a more simple, minimalistic interface than an ultra-customizeable interface with myriad custom actions and events. I've always appreciated software that deliberately keeps things simple (Basecamp and Workflowly come to mind). It sounds like these people want a full blown Jira/Stash installation.
I don't like the general feel of these suggestions. It sounds like more bureaucratic features, the lack of which is a big part of why GitHub is so pleasant.
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.
I guess for maintainers of popular projects, everybody's "casual chat" (by people who did not read CONTRIBUTING.txt, do not supply the version of relevant software they are using etc.) is not as fun as it is for you.
Wow, what a bunch of whiners. If you hate github so much why don't you just fork it and fix-- Oh, right. It's not open source.
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?
I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developing in the open can't be done on platforms where restrictions apply, and they do apply. I'm saying this with no intention of sounding like a jerk, but 18 project maintainers and/or developer need to write an open letter to get Github to give'em a "me too" button? I understand the issue, but i still find it rather silly.
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.
> I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain
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.
>but what I'd genuinely like to know is why don't big projects just move to their own thing?
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.
It's a momentum thing I think. A big part of the Github platform mirrors a social media platform. When you meet a developer, you check out what they're up to on Github just like you might check on a friend's status on Facebook. Like Twitter, it's a way to get your name out there.
Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to 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.
I feel like there is a great opportunity right now for anyone to make a Github replacement. Sounds like a lot of these features are sorely needed at the moment. Why has Github been complacent?
My company pays me to work on a fairly old-school free software project and we run our own git service. Our workflow is email based so we won't ever consider switching to GitHub.
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.
I work on a very relevant project called Product Pains.
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.
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.
I've used Bitbucket for years and I've never seen "multiple assignees for an issue" as something which is available. I've just looked at a couple of our (private) repositories and I still can't see how you would do it. Either that feature doesn't exist or it's used in an extremely obscure manner.
Yup, I love GH, use it every day, but issue management is the pits.
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.
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).
A shame that GitHub aren't more responsive to the community that enables their success when they make such a big deal of their openness. It is also our own fault that we have allowed ourselves to become dependent on a single provider of a relatively simple service.
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?
[+] [-] jonobacon|10 years ago|reply
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 [email protected].
[+] [-] deathanatos|10 years ago|reply
> 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.
[+] [-] Osiris|10 years ago|reply
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.
[1] https://gitlab.com/gitlab-org/gitlab-ce/tree/master
[+] [-] jballanc|10 years ago|reply
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.
[+] [-] zzzeek|10 years ago|reply
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.
[+] [-] urda|10 years ago|reply
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.
[+] [-] pierrebeaucamp|10 years ago|reply
[+] [-] patrickaljord|10 years ago|reply
There you go: https://github.com/google/git-appraise
[+] [-] hendry|10 years ago|reply
http://lists.suckless.org/dev/1201/index.html#msg10574
Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html
[+] [-] aws_ls|10 years ago|reply
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?
[+] [-] hk__2|10 years ago|reply
Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.
[+] [-] andreastt|10 years ago|reply
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.
[+] [-] ywecur|10 years ago|reply
[+] [-] monkmartinez|10 years ago|reply
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.
[+] [-] ketralnis|10 years ago|reply
[+] [-] ggreer|10 years ago|reply
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
6. https://github.com/ggreer/the_silver_searcher/pull/614
[+] [-] dikaiosune|10 years ago|reply
[+] [-] decisiveness|10 years ago|reply
[1]https://meta.stackoverflow.com/questions/277314
[2]http://meta.stackoverflow.com/a/277319
[3]http://meta.stackoverflow.com/a/283935
[+] [-] bsimpson|10 years ago|reply
You can sort something by stars, but it's bad etiquette there for a user to comment +1 rather than just star.
[+] [-] magicmu|10 years ago|reply
[+] [-] jrochkind1|10 years ago|reply
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.
[+] [-] briandear|10 years ago|reply
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.
[+] [-] slantedview|10 years ago|reply
[+] [-] Permit|10 years ago|reply
>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...
[+] [-] jasode|10 years ago|reply
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...
[+] [-] bsder|10 years ago|reply
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
[+] [-] asb|10 years ago|reply
[+] [-] marknutter|10 years ago|reply
[+] [-] AndyKelley|10 years ago|reply
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.
[+] [-] lorenzfx|10 years ago|reply
[+] [-] carapace|10 years ago|reply
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.
[+] [-] santix|10 years ago|reply
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?
[+] [-] beshrkayali|10 years ago|reply
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.
[+] [-] tyre|10 years ago|reply
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.
[+] [-] Sir_Substance|10 years ago|reply
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.
[+] [-] curryst|10 years ago|reply
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.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] anarchy8|10 years ago|reply
[+] [-] notabot|10 years ago|reply
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.
[+] [-] justincormack|10 years ago|reply
[+] [-] arasmussen|10 years ago|reply
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...
[+] [-] mplewis|10 years ago|reply
- Multiple assignees for an issue - An "Approve" button so that maintainers can stamp a PR with the seal of approval
[+] [-] diezge|10 years ago|reply
[+] [-] earlz|10 years ago|reply
[+] [-] fidget|10 years ago|reply
[+] [-] danielsamuels|10 years ago|reply
[+] [-] neilgrey|10 years ago|reply
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.
[+] [-] ma138|10 years ago|reply
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!
[+] [-] mjevans|10 years ago|reply
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).
[+] [-] rmchugh|10 years ago|reply
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?