Comment by gustavo_duarte | Hacker News Reader

Comment by gustavo_duarte | Hacker News Reader

Parent Full thread

I respectfully disagree regarding Fogbugz vs. GitHub issues.

I used FogBugz for about 6 years in a major client project (a successful SaaS product). We used FogCreek's hosted solution and were pretty heavy users: different projects, milestones, feature requests, user communication, etc. However, we were unhappy with FogBugz. The UI always felt clunky and slow to navigate, it felt like we were battling FB rather than getting help from it. In particular, milestone / release management and issue grouping were painful.

Then late last year we moved our repos to GH, and decided to look for another issue management system. We evaluated several: JIRA sucked hard imho, JetBrains YouTrack was my favorite full-featured product.

But then we decided to give GH issue management a try. It is minimalist and surely lacked some features, but hey, if it could handle our needs, the simplicity would be a huge plus.

A few months later, _everyone_ in the team is thrilled: devs, testers, support personnel. Using milestones and labels we have been able to manage more people and more work on GH (we're growing) with less hassle. It feels much friendlier than FogBugz. Now whenever I create / solve / assign / organize issues, I feel happy, whereas before it was a dreaded chore.

YMMV of course, but I wanted to give my 2c since I do have a lot of experience with both issue managers.

When using github, do you keep all of your code in a single repo? If not, have you found any solutions to the "fragmentation" problem where it's hard to get a big picture view due to issues being scattered across different repos? We're looking for solutions for that at my workplace.

I haven't used bitbucket for larger projects yet, any insights there also appreciated.

You can use the organization issues dashboard. Its almost impossible to find though (you just reminded me of it and I had to hunt down how to access it: https://github.com/organizations/[Username]/dashboard/issues.

Sadly doesn't provide any filtering on tags, which is the only way to assign priority. In fact, all I really get is a list of all open issues.

This is a huge problem for us also, and I've considered moving things over to Jira several times over the past couple weeks because of it. The only quasi-solution I've found is to feed multiple repos into a single chat room in Hipchat so people can get some idea of progress. More broadly though, I'm quite dissatisfied with GH issues (UI, poor search, clunky milestones, no burn charts, etc.).

I understand the frustration with GH limitations (no burn charts and hardly any reporting). For us, the minimalism ended up working in harmony with our process, but I can see situations where it wouldn't.

The UI and milestones, though, I think are good. JIRA is to me the king of clunky. I've used it in 3 projects over the years and evaluated it last year, and I've been pretty disappointed with it.

To borrow from another comment here, it has a bit of a Bugzilla feel, like it just grew and grew, and you have tons of fields and features, but they're poorly designed and put together. A bit of a mess, to put it bluntly. FogBugz has a similar feel to me.

I encourage you to check out JetBrains' YouTrack. I never used it in a project, but a couple days evaluating gave me a good impression. Good luck with your search.

Thanks for the suggestion. I've also used Jira in the past and wasn't super impressed with it at the time for just the reasons you mentioned -- lots of features but not integrated seamlessly and often overloading the user with options and not presenting a very good user experience (both in terms of speed / design / etc.). That said, I have the sense that GH is slowing down, I constantly have issues that seem to be similar to the old Twitter fail whale problem, either with what appears to be incorrect old cached data or Octocat "hello these droids that you are looking for can't be found since our ORM sucks." I assume this is some Rails stack issue (i.e. some aspect of the old Rails can't scale argument that was never really refuted but people forgot about as they stopped trying to optimize Rails apps for speed).

btw, I don't think that there is necessarily anything wrong Milestones, but there are always too many clicks involved in the GH interface and the buttons are often not where I expect them to be -- even when you have something that works well (i.e. dynamic adding of tags that automatically updates the DB), there is frequently no indication of actual success, which ends up puzzling the user.

Thanks a lot for the suggestion for YouTrack, will definitely check it out.

I agree completely on the GH slow down / fail whale type of problems.

I use GH for about 12 hours a day almost every day, between open source and client projects. I face slow downs in the issue tracker, the git repos themselves (I only use command line), and the web interface to browse a project (code, history, pull requests). I notice a slow down about once a day. Some features, like the contributors graph, are always dead slow. About 10-20% of PR merge attempts fail, and I have to click the button again, sometimes multiple times. I see the Unicorn fail page or some Octocat fail page often enough.

It makes me think exactly of what you describe, a combination of Rails perf / scalability and perhaps a lack of strong backend engineering, I'm not sure.

Right now the problems are in the level of a mild annoyance / surprise that a company like GH has these issues. If it gets worse, I would consider moving away. But because I truly love the UI and overall functionality, it's a positive tradeoff for us at the moment.

You're very welcome regarding the YouTrack suggestion.

Yep, we are seeing exactly the same things and have more or less the same response. I've long been a huge Github fan so to think of moving away makes me quite sad, but the frequent chunkiness (even exhibited in things as simple as switching between page 1 and 2 of open issues) causes me a lot of frustration every day. I'm not ready to give up just yet however.

This is a great point. We have ~10 repos as part of our product, so we faced the same issue.

After toying with different solutions, we settled on using two dedicated issues-only repositories. One of them handles software development (all bugs, feature requests, the engineering stuff) and the other handles operational stuff like client installs and so on.

This has worked well for us. Here are some advantages:

0. We get the big picture you mentioned, which is the crucial point. Planning, grouping issues for releases, etc., becomes much easier.

1. When it comes to access security, we can give people access to the issues repositories (via GH teams) without giving them access to the full source code.

2. Splitting operations and engineering increases focus. Engineers don't need to look at client installs, etc.

3. We can still reference repo issues in commits to other repositories. See [0] and [1]

So all in all, I agree the fragmentation is a real problem, and I think centralized issues-only repos are the way to go. Hope this helps.

0: https://github.com/blog/1439-closing-issues-across-repositor...

1: https://github.com/blog/967-github-secrets

Just a nit on GH issues: email vs web don't mix. Email formatting isn't rendered properly online (line breaks, "> " quoting) - and you can't edit an issue/comment online if you originally mailed it in (it's type is email, and that's it). Editing online is incredibly slow on small machines (zenmode is much faster, but you can't preview).

Agreed, email is clunky.

Have you used the GitHub mobile apps though? I find it's a decent way to keep tabs on issues, add comments, etc., when one is away from a bigger computer. I see that as a big plus for GH.

I may be totally off... But sound like you were trying to use several features in fogbugz just because they were there... And then liked best the one that did not give you so much hope for you to hang yourself

The part that really irks me about BitBucket issues is that you can't reassign the issue to someone else without editing the header record. This applies to some of the other issue fields as well, and just seems bizarre. We wanted to move from GitHub to BitBucket, but after a day of trying their issue tracker, we gave up.

Reply on news.ycombinator.com