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.
I completely agree with some of these suggestions, but it doesn't need all of them. If you really need a heavily-customizable issue tracking system, you can do anything you want in Bugzilla or Jira.
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.
I guess it depends who is logging issues. If I'm experiencing some bug that I need fixed and motivated enough to log an issue at all, I'm probably motivated enough to fill out a few more fields.
Being a maintainer on a project with some minor community on GitHub is such a garbage experience.
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.
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?
Because Github succeeded in being the Git repo host. I think you're on track with saying their complacency is an opportunity and I wouldn't doubt to see a Github killer born this year.
Bitbucket requires payment for larger numbers of collaborators. Github requires payment for private repositories. Open source requires unlimited collaborators, and no one wants to pay.
I'm maintaining a GitLab instance for my team at work and it's been really great for us. I am pretty disappointed that the CE version doesn't include GitLab Pages, though, as that was the one feature I missed most from GitHub and GitLab Enterprise is outside of our budget at this time.
As people can use GitLab Pages on GitLab.com for free, we felt the ability to host your own static pages was more interesting for larger teams, hence our decision to bring it to GitLab Enterprise Edition.
I understand, but that's just not an option for us. I don't resent them at all, they've every right to decide which features are restricted to EE licenses, but I can lament it all the same.
At a previous company, we did this in GitLab with a simple post receive hook that just checked out the gh_pages (or gl_pages) branch on a webserver configured w/ rewrite to serve at a proper path. We even were able to do one better and allow PHP since it was self hosted and we trusted the committers.
The same reason YouTube is so popular. Neither GitHub or YouTube are big because of their technology, it's their community that keeps people there.
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.
Playing devil's advocate - in their respective heydays, SourceForge and Google Code both seeemed unassailable. They had large, active communities that hosted the most popular OSS projects.
But it requires feature expansion on the scale of github, and a perpetual decline and ignorance of the community on the parts of the current host for years for that kind of transition to happen naturally.
That, and github has centralized development to a degree that sourceforge or gcode in 2008 could only dream of. It not only obsoleted other hosting solutions but also brought millions of developers into these kinds of development ecosystems whom used to just use forums or their own personal websites to host their projects.
By their very nature, git repos are one of the easiest things to migrate. Simply point at a new remote and push, and that's really it. It means that, unlike many other services, I could see GitHub being completely abandoned almost over night. If something better came along.
True, but thanks to the API and their relatively simple structure it's reasonably easy to at least copy their contents as well. Linking them correctly to user accounts on a new platform is probably the biggest issue.
> 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?
Network effects strong enough to slow the growth of any competitor long enough for GitHub to adapt.
For a very large percentage of young developers I work with, "Git" and "GitHub" are synonyms. GitHub has made themselves literally synonymous with version control to a large number of people. That's a lot of social momentum that a competitor has to overcome. In light of that, it's not that surprising at all that GitHub has become complacent.
That will be extremely challenging. GitHub has a huge community with a lot of heavy weight projects behind it. Sure you can add a few features on top of whatever you build, but GitHub has the ability to copy whatever seems popular very quickly.
Most people on GitHub do not suffer these issues, simply put. It's only really the popular open source projects, which represents a small minority but are loud and vocal.
The issues were deleted in fairly short order, but their notifications were still sent out to all repository watchers and persisted beyond the issue deletion. Also, most issues were generated mere seconds apart from accounts less than a day old.
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.
Being a maintainer on a project with some minor community on GitHub is such a garbage experience.
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.
I wonder if the whole "managerless culture" is to blame and is unfixable? (In other words, why hasn't SOMEONE had this thought about issues in N years? One is they deem it not a problem, another could be that they think to optimize for the filer, and the maintainer doesn't matter, or... there's no organization at all?)
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.
I like the theory of the flat-office culture or philosophy affecting this.
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.
True, I guess with Atlassian it's different as their actual flagship product is Jira (and I assume the people who buy the paid-for BB packages are loyal to BB due to things like the free repos so it evens itself out).
Not just bitbucket, but most of Atlassian's products, IMO. We switched from Slack to Hipchat at work recently, and the rough edges constantly irritate me.
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.
It's also annoying that Github sometimes is missing some basic features like attachments to bug reports and comments for instsance. All mature bug trackers have such feature.
Do the undersigned send any money to github? It might be better to phrase your demand in the form of a question, "how much can we pay you to do this work for us?"
GitHub got to where it is today thanks to the network effect that the undersigned helped create. If open source were to do a mass migration to another provider, many of the contributors whom are paying for private repositories and other features would most likely follow.
GitHub's success is based on its community. Simple fairness says the community should be respected and listened to, simple business says if the community doesn't get something back, it will get pissed and go somewhere else.
The post with ~110 points was killed in favor of the ~50 point post at the time. In that case using time as the tie breaker might not be the best since people will have to upvote again.
In general you're right, but this story was guaranteed not to lack for upvotes. Indeed it went to #1 as soon as we buried the other one as a dupe.
I realize it's not a big deal, and it's actually a great sign about the HN community that almost no one cares much about karma. But we do want to try harder to give the original submitter credit, because then the incentive is aligned with what's best for the community: finding good stories that haven't been posted yet.
waffle.io does this, but having to run on top of GitHub means it can't really fix problems like voting. But it can offer better search and things like that
We would love your thoughts on ZenHub.io [1] - fully integrated issue tracking, +1, estimates, burndown charts, kanban boards, even a personal todo list - a lot of the features asked for here, right within the GitHub interface and presented a lot more cleanly than competing products.
Looks nice. How do I add additional organizations after the first one? Can I send an invite to other organization managers to make themselves available for ZenHub?
Each organization is treated separately, all you need to do is install the extension and visit a repo of the other org. From there you'll start a 2 week trial and you'll be able to invite your team members and managers :)
This tracker app [0] is designed to be pretty modular, and there's a service implementation that uses the GitHub API client [1]. In theory, you could modify it and expand it to cover your custom needs for issue tracking.
While I don't maintain Ansible anymore, +9 billion on this. GitHub is hard at scale.
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.
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?
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).
My experience with Github support is terrible, if not one of the worst, I once had an issue and contacted their support and it took them 1 month to respond to me (literally) I was really surprised by that.
I had the opposite experience. I am on the free student plan for private repos. It has to be renewed annually. It wasn't clear to my how to do so. I asked, and Scott from Github support contacted me in under a minute and sorted it out. I was very impressed.
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.
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'd like to think that someone who writes this kind of letter would take such a thing into account. It's really possible that there is a strong correlation between a language and people being more involved with Github. I wouldn't be surprised that many developers from other language ecosystems just don't care.
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.
There's an old story about this man who stood quietly next to a closed door in Moscow, said nothing to no one, and did nothing else of interest. Eventually others joined him, and before long a queue has formed. No one knew what they were standing in line for.
I remember one day I was walking through london with multiple hours to kill; and there was a massive line. Without anything else to do, I just stood in it. Approx 45 minutes later, I got to the front: turns out it was a sale for a clothing store. I didn't really need any clothing, but the discounts were good; so I purchased a jacket. This was 6 years ago and it's still my favourite jacket....
I agree that that's probably how it started, but it seems that once the cultural expectation has been set, it's hard for a single project maintainer to set a different custom just for their own project. People are going to use the conventions and communication methods that they learn elsewhere, even if you say not to in the contributing guidelines document. You might be able to get individuals to stop doing it in your project by asking them directly, but then each person has done it at least once, and you've had to ask each person to change their normal habits.
Besides, as they note in the letter, there is a valid and valuable purpose to these communications, it would just be better if they were in a different place than clogging up the comment thread.
Yeah, and now look at SO, it's got so many "rules" that you can't look cross eyed at it without breaking one of them. "You don't have enough rep!" "A minimum of 15 characters per comment." "At least 5 characters per edit." "That's been asked before." Eventually, everyone just stands in line with blinders on, forced to stare straight ahead, mouth shut, one step at a time. There's never an end once you start "tackling" these so called problems.
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.
Yep. The problem is that some users are not aware of the conventions, and often you see on the Android Google Code repo "+1" or something along the lines of "Google plz fix this".
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 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.
From skimming, they found "+/-1, because REASON" to be valuable, not "+/-1". Indeed, in the open letter, they mention these are valuable, but the current implementation is a pain.
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.
True, but it's still user problems that aren't problems with the software itself. Far too often you get people who want help with _everything_ on a project, from installing the right language, their editor and so on when it's not something that really concerns you.
Maybe "complain" is too strong, but he created a GitHub issue –notifying several hundred people– without running ag --version. Heck, he didn't even look at the output of his command. It was immediately obvious to me, from the limited information he provided, that it was a bash alias.
To the person raising the issue it's a simple mistake, sorry.
To the person that has to deal with it, it's yet another issue being raised where the reporter didn't follow the necessary steps to diagnose the problem themselves and (implicitly) expected a bunch of other people to apply their own time to solving it.
If the "New Issue" form had a place where the reporter was asked to paste the output from ag --version then it might have caught the accident before it wasted the developers' time.
I think it's an over reaction to describe the issue as a complaint, but it is an example of how the GitHub UI forces project admins to deal with incomplete and poorly investigated issues from users.
A mistake, I can understand. But each issue I linked to was not a mistake. Each one was the end result of a series of mistakes stemming from a combination of ignorance, negligence, and (occasionally) incompetence.
Have I done dumb things without realizing? Of course.[1] But in almost 20 years of software development, I have never created issues resembling the ones I linked to. Bug reports are seen by hundreds of people and take up valuable developer time, so I make sure mine are useful.
To use an analogy: Say I'm giving a talk to an audience of a hundred people. I wouldn't do it extemporaneously, without slides, then walk away in the middle of Q&A. And if I did, I wouldn't call it a mistake. I'd call it being a terrible presenter. Yet that's what bad bug reports are like:
User (notifying hundreds of people): "It doesn't work."
Dev: "What version are you using? What error messages do you see? How are you running it?"
User: * crickets *
It's gotten bad enough that I wrote a short post on how to report bugs.[2]
Why would you even respond to a bug report that was "it doesn't work."
Such a vague report tells you all you need to know about whether it's going to be worth your time trying to work with the person who submitted it. Close it immediately as non-actionable.
> Do you really want people to be afraid to report an issue in case it's something silly/not an actual problem? Would that be better?
I seriously doubt the pendulum will swing too far in the opposite direction. Right now, the majority of created issues are close to useless. If those people took five minutes of their own time to troubleshoot, it would save others hours.
I actually hesitate to really "watch" repos because the sheer volume of email generated is staggering. I take my hat off to those who run successful OSS projects. Thank you!
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.
I don't see anything wrong with going after the massive amount of smaller project with simple needs, instead of the few large projects & popular projects with very specific needs.
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.
I have mixed feelings about these requests. Yes it would be nice to have these extra features in GitHub. Its issue handling has always been a bit light on the workflow side—but IMHO has made up for it with a pleasant way to organize conversation around issues. The simple and smooth UX is part of what makes GitHub so great.
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.
I have mixed feelings about custom fields, I'd like Github UI to become as burden as Jira, but in the other hand 'reactions' as Slack or Facebook are implementing would make much easier to follow a discussion without so much scroll down.
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.
I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems.
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.
Not so. For my project, I noticed on several occasions that different people were asking the same questions and that prompted me to rethink the design of the project a bit and it greatly improved the community engagement as a result.
Why should maintainers not get annoyed if people ignore the proper support channels (which often have a great community of users to help) and further burden the developers instead?
Have you ever tried to maintain a popular OS project on Github? Github issues feel great until you start using them at scale, and then they start to fall apart without some structure. This is especially pronounced in open source where many issues come from people who aren't familiar with what information you need in an issue to quickly resolve it.
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.
My project's main repo has 150 issues (only 7 still open) and it works out pretty well. Usually contributors will answer each other's questions and help close issues.
I suppose that could be a problem if you have 7000+ issues (as is the case for Docker) - But those projects represent an extremely small percentage of all OSS projects on GitHub.
Also, these projects usually have a lot of contributors, so maybe those contributors could help filter through and tag/close issues as necessary?
>I wouldn't like to force people to adhere to a particular format when reporting problems.
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.
While I applaud the initiative, it's also a pretty strong indictment of the JavaScript / node.js community that there is not even a single non-male OSS maintainer on this list of important JS projects.
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?
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.
There is plenty being done in JS/node communities (plural! because there is more than one) at all levels. It just turns out that change doesn't happen over night.
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.
Addendum: if all the non-males majoring in literary/communications/gender studies who complain about the lack of diversity in STEM would major in STEM, maybe they would no longer have anything to complain about. Whining isn't a science.
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.
Phabricator is pretty great overall, love that it's under such active development.
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.
Phabricator is great! I host it for a couple of my projects. I love it, and it was easy to setup.
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.
Another shoutout here to phabricator. I started hosting it internally at the company a year ago and have near 100% adoption from developers for code reviews, additionally using the task/issue tracking for some projects.
489 comments
[ 1.6 ms ] story [ 733 ms ] threadGoogle 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.
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.
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.
There is GitLab, which is good and is FOSS in addition.
As people can use GitLab Pages on GitLab.com for free, we felt the ability to host your own static pages was more interesting for larger teams, hence our decision to bring it to GitLab Enterprise Edition.
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.
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.
Could the same thing happen to GitHub?
That, and github has centralized development to a degree that sourceforge or gcode in 2008 could only dream of. It not only obsoleted other hosting solutions but also brought millions of developers into these kinds of development ecosystems whom used to just use forums or their own personal websites to host their projects.
When a new user signs up, ask them for their existing Github username and to upload an SSH key that matches.
Network effects strong enough to slow the growth of any competitor long enough for GitHub to adapt.
Management, money, growth.
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.
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.
- 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.
Seems like the Tony Soprano way of doing things.
I realize it's not a big deal, and it's actually a great sign about the HN community that almost no one cares much about karma. But we do want to try harder to give the original submitter credit, because then the incentive is aligned with what's best for the community: finding good stories that haven't been posted yet.
Disclosure: I work on ZenHub :)
[1] https://www.zenhub.io
Thanks!
[0] https://src.sourcegraph.com/apps/tracker
[1] https://godoc.org/src.sourcegraph.com/apps/tracker/issues/gi...
Anyway, I found that http://feathub.com/ addressed my frustration about the absence of a voting system.
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.
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?
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).
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!
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.
https://youtu.be/P0e6zG8IbE8
Is it really possible that people just continue standing there while not getting why they are doing it? Don't they even care to ask?
Feels like it would take just a single guy to ask: "What are we looking at?" For everyone to realize that they are acting like fools.
Try the classic: enter an elevator and turn around to face the back - see how many copy you.
Is it really possible that people just continue standing there while not getting why they are doing it? Don't they even care to ask?
Feels like it would take just a single guy to ask: "What are we looking at?" For everyone to realize that they are acting like fools.
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.
But still, yeah, it would be fairly trivial to require posts to be more than +1, or to display a warning when anyone starts a post with :+1:
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.
[1]https://meta.stackoverflow.com/questions/277314
[2]http://meta.stackoverflow.com/a/277319
[3]http://meta.stackoverflow.com/a/283935
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
To the person raising the issue it's a simple mistake, sorry.
To the person that has to deal with it, it's yet another issue being raised where the reporter didn't follow the necessary steps to diagnose the problem themselves and (implicitly) expected a bunch of other people to apply their own time to solving it.
If the "New Issue" form had a place where the reporter was asked to paste the output from ag --version then it might have caught the accident before it wasted the developers' time.
I think it's an over reaction to describe the issue as a complaint, but it is an example of how the GitHub UI forces project admins to deal with incomplete and poorly investigated issues from users.
Have I done dumb things without realizing? Of course.[1] But in almost 20 years of software development, I have never created issues resembling the ones I linked to. Bug reports are seen by hundreds of people and take up valuable developer time, so I make sure mine are useful.
To use an analogy: Say I'm giving a talk to an audience of a hundred people. I wouldn't do it extemporaneously, without slides, then walk away in the middle of Q&A. And if I did, I wouldn't call it a mistake. I'd call it being a terrible presenter. Yet that's what bad bug reports are like:
User (notifying hundreds of people): "It doesn't work."
Dev: "What version are you using? What error messages do you see? How are you running it?"
User: * crickets *
It's gotten bad enough that I wrote a short post on how to report bugs.[2]
1. https://news.ycombinator.com/item?id=7145451
2. http://geoff.greer.fm/2015/08/15/how-to-write-good-bug-repor...
Such a vague report tells you all you need to know about whether it's going to be worth your time trying to work with the person who submitted it. Close it immediately as non-actionable.
I guess it depends on the project and its contribution guidelines.
I seriously doubt the pendulum will swing too far in the opposite direction. Right now, the majority of created issues are close to useless. If those people took five minutes of their own time to troubleshoot, it would save others hours.
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.
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.
> 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.
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.
> Maybe if your software was better designed, people wouldn't be asking the question to begin with.
This is just silly.
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.
I suppose that could be a problem if you have 7000+ issues (as is the case for Docker) - But those projects represent an extremely small percentage of all OSS projects on GitHub. Also, these projects usually have a lot of contributors, so maybe those contributors could help filter through and tag/close issues as necessary?
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.
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?
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.
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.
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.