FogBugz Technical SupportA forum for technical support discussion related to Fogbugz. |
||
Our company uses Fogbugz and loves it. It doesn't do everything we want and some its limitations are quite frustrating but its simplicty does make people use it. So much so we are up to 17 000 cases (99% of them resolved).
So that should make us a happy customer. However the slow progress on a new version of Fogbugz, V.5, and all its Ajax additions was a nice to have but didn't offer major improvements to the product. I'm probably being unfair after all we love Fogbugz and enangelize the product, but that is my opinion. In tandem products like Atlassian's Jira, though requiring a lot more work and complication to get configured and users running smoothly offer so much more and seem to introduce so many more improvements at least 4 times a year. In our company there is now a strong push to move to Jira, because of its workflows and that the reporting is not limited to a single submit field (which with the greatest of respect is a poor showing in a world being driven by inteligent search). Don't get me wrong. I lovge Fogbugz and it is has helped out business greatly but it seems Fogcreek's policy of "we say nothing until it is released" means that in our company's case we will end up moving to Jira because there is no guidance from Fogcreek of what new features are coming up, whether Fogcreek has absorbed any feedback from their usesrs and when they will actually deliver them. I know it is Fogcreek dogma not to promise a delivery date but at least an indication that: * Hey, we're focusing on workflows, frisbee trajectory tracking, reporting by project, more explicit use of capital letters and linking of cases * Hey, we're taking feedback on this at areyouoncrack@fogcreek.com * Hey, we are hoping to release some or all of this as Fogbugz 6 in Spring Wow, it would make a Fogcreek's stated ambition to be responsive to users and *not* be the Juno of Joel's postings. I'm sure it would make for a better product and since we are not talking about a rocket science application (no offence, but we're talking bug or business flow here) it is hardly going to cause the competition to start pulling the long work hours. Fogcreek has som unqiue strengths that can't be just replicated by other businesses. So how about stepping up to the plate and actually engaging a little more with your users? Like I said I love the product. I'll do my best to keep it alive in our company. But at the end of the day if the bext fighting punch I can come out with is "I'm sure they'll deliver on new features that will be really useful and will get used, but they won't say what those are or when" then I've already lost the battle and $4 800 will be dispatched to Atlassian for Jira.
Where to Fogbugz? Tuesday, January 16, 2007
Very good point. I think Joel's theory about don't talk about anything in advance is plain wrong. It's fine for a product that hasn't been released, but once you have customers using a product, you need to treat them with a bit of respect and give them some idea of the future plans. Particularly with a product like bug tracking where companies are designing processes around it that will hopefully be used long into the future.
Some companies issue a "Statement of Direction" for a product, which gives customers an idea of what they can expect without going into too many specifics. I'm sure it is also an opportunity to get feedback along the lines of "we don't care about any of that, what we really want is..."
Crap... I thought that's exactly what we're doing here in the forum! I realize you might not read every thread in here, but WE do, and you can be certain that when we say "We've added this to our wishlist" it's going in there to be looked at.
We're still not going to promise on dates because we don't want to be in a bad position later, but if you look at our release cycle, we've had a major release every year or even more often. In addition as evidenced by our API release, and the FogBugz for Visual Studio Add-in, you can certainly see we're expanding in really useful ways. To give you a high level view of what we've been focusing on, it has been making it much easier to plan the whole software dev cycle and figure out when you're going to ship (or why you aren't shipping when you thought you would). There are a bunch of features we've put in there to help with that which I'm going to leave up to Joel to talk about, but it includes the kind of reporting you're looking for and the kind of plugs if you need to do something more specific.
I'm glad to see that CityDesk has finally made it as a verb! Although not the one I wanted it to be.
Half the company is working on FogBugz 6, but it's not ready to talk about yet. Even before that comes out, we have two more modest releases. We're actually big enough to work on all three in parallel right now. The one (and only) time I announced when a product would come out, I had to eat my words. I'm not falling for that again!
The tone of the thread may be a bit harsh, but I think the point is reasonable.
Putting things on the wishlist in this forum isn't particularly helpful from a customer point of view. We can't see the wishlist or the priorities, all we know is that there are probably a lot more things on the list than we can expect to see in the product in the short term. An example of something that would be helpful to know about is what is the likelihood of better separation of internal and external functions in Fogbugz - as discussed in various security threads that have appeared here. With the current information, I suspect anyone for whom that is important would be looking to switch to another product. A statement that it is is planned for an upcoming version might convince them to wait for new functionality. The Citydesk reference is a fair point I think - I don't think there was any announcement that development was being stopped or anything - the company just seemed to lose interest in it. FogBugz users have a much greater investment of their own information in their FogBugz systems - you can see why they might look at what happened to Citydesk and feel nervous that the same thing might happen to Fogbugz
The catch there is that if you want to upgrade to a new version later, you have to pay for the support contract back to the time that it lapsed. You end up paying the support contract for the period, without receiving any of the benefits for it.
Hi all,
our company is not yet a client of fogbugz and we already have same problem....with less or should I say no feeadback about what will happen next with this application. It looks like Joel has a lot of "sutisfied-pissed off clients"....hmmm, hard to convince my managemnet to buy the application with such a description. I do understand the "do not promisse" policy, and i'm for it, i never promise a dead line or a certain feature, i always say will try our best to fit it in the XorZ release, whcih it maybe around that date....but we are not asking Joel to promise anything....we just want to see the wish list they have and alow us to vote for a feature or other...at least the curent clients should be alowed to. This will alow the fogcreek team to see what clients need most and act in this direction. What maybe more valuable than understand what clients need directly from the clients? You may say that this forum does this already....you are halph right...you get what your clients wish for...but you don't get what your clients wish for most.
I also agree with the content and tone of many of the people on this list. We also waited anxiously for Fogbugz 5, and felt extremely let down (we also did not upgrade to 5 - no value added). We are now waiting anxiously for Fogbugz 6, and if it doesn't meet our objectives, are planning to move to a new system, most likely Jira. I run a company the size of Fogcreek, and I just don't understand this policy of not preparing your customers with where you are going. If you feel burned by dates, then give promises like "in 2007", or throw lots of caveats in the discussion. Michael, "adding to the wishlist" is not information. I do read all posts, in the hope of figuring out where Fogcreek is going, and it is really annoying to not know.
I'm going to add a me-too.
I suspect FCS has lost its way - the 5.0 ajax stuff looks like the result of internal playing rather than request, and the UNIX port feels to me link an indulgence which has diluted developer effort to the extent that they're now writing cross-compilers rather than working on saleable products. Had FogBugz been ported to ASP.NET, I guess that the improvements in performance due to the much better state-management at the server would have made the AJAX stuff much less attractive. Instead, they're now totally tied to an aging technology, stuck with the LCD of TradASP and PHP. I am not soothed during two-second page waits by the instant appearance of a drop-shaddow 'please wait' box. And that's before we start on the sorry saga of 'guess the status of Citydesk.' Personally, I am starting to wonder about the Emperor's Clothes.
Will Dean Saturday, January 20, 2007
I agree with most of what you say, Will, but not about the unix stuff. I wouldn't be running it if it wasn't on unix. I also think that it has more potential for sales to larger sites on unix. (Maybe I'm old fashioned, but I think that unix works better for servers. Much easier to backup and restore for one thing. Any backup/restore procedure that includes instructions to install/reinstall is not a proper backup IMHO).
There obviously are people who want to run on Unix - and of these there is clearly a subset who wouldn't run on Windows instead - I don't dispute this, though I'm skeptical of their value vs. their cost.
However, from a selfish point of view, I just look as the enormous effort to port and support Unix (and its umpteen homebrew databases) as being effort which wasn't spent on improving the product in any other way. And as I said, not only has it diluted the developer effort, but it constrains the way the product can be evolved. I'm sure Joel will be along to say 'if you don't like the product, don't buy it' shortly...
Will Dean Sunday, January 21, 2007
We are very satisfied customers with the product. We do really wish it had some more reporting, but I've messed with Jira and it has Bugzilla-like usability.
That all being said, it would really be nice to know where its going. We use it extensively for support as well as bugs, and frankly we're overloading the mail import service to the point that it grinds IIS to a halt. We're currently toying with writing our own direct MAPI->MySQL import service. I'd love to know if this is a problem FogCreek has any intention of addressing some time in the next year. Personally, I'd like to see scheduled quarterly or semi-yearly releases, with a quarterly update of the feature list for the next release. If things slip from one release to another, at least we know what's going on. Some will bitch, but for most I think it would help plan. At this rate Solaris gets more major refreshes in the course of a year (2), which is kind of depressing.
Is it me or wouldn't it be nice if - assuming Fogcreek dogfood their own software - there was a public view on the bugs \ features that had been assigned to Fogbugz 6. Then Joel doesn't need to let us know - we can go look.
That's a pretty cool idea. Though judging from the lack of FogCreek comments on this thread after they first noticed it...I'm not sure anyone's paying attention anymore.
I can understand why they don't publicly make available their list of defects (Security would be one of my concerns).
But, at least we could have a roadmap. Joel posted to his blog almost 18 months ago about the ability to fork a bug and implementing something to support 'painless software scheduling'. He didn't directly say that these were going to be included in Fogbugz 5, just that these were features that the dev team were voting on. That was some time ago. In the meantime Fogbugz 5 came and, well....meh. Don't get me wrong; the AJAX stuff is pretty cool and done a lot better than other sites I've seen. But it didn't add any value (to me at least). So how do I know if Fogbugz 6 isn't going to be another fizzer.
Andrew Davey Tuesday, January 23, 2007
We're still reading this thread. Given the number of cool new things we are working on for FogBugz 6, we certainly hope that it won't be considered a "fizzer", but I can understand that our customers would like more assurances than that. But as Joel notes at http://www.joelonsoftware.com/articles/MouthWideShut.html, there are a variety of good reasons for us to not advertise features until we are ready to release. I'm not sure what the right answer is.
Frankly, you've got to keep your customers informed. We owe to our customers, and expect it from our vendors. People will stick with you as long as they know what's going on. As far as having to slip a feature, that's life. It happens, but its not a reason to go silent on your customers. Just makes them think they're not valuable, and go elsewhere where they're kept in the loop.
Just because Joel writes it doesn't make it right. I have no objection to the policy for a new, not yet released product, but when people have already parted with their money (and are still paying money in "maintenence") it just show a lack of respect for your customers.
It's not unlike the justification for not telling young children what's for desert before they've finished their first course.
Watch out for them growing-up and leaving home...
Will Dean Thursday, January 25, 2007
Mouth wide shut is fine for new features but wouldn't it be reasonable to maintain a list of bugs which are \ have been fixed in Fgbz 6 based on submissions either directly or in this forum?
Or perhaps work it like Jamie Cansdale does with Fgbz for TestDriven.NET and allow people to see the progress of their bugs so they at least are satisfied progress is being made?
In terms of searching, we installed a Google-Mini that scans the bug database for information and it's working great. You have to create a custom result screen but it's not that hard. The benefit here is we're not limited to static string searches but more useful full-text searches.
Humbug Friday, February 09, 2007 |
||
Powered by FogBugz Bug Tracking and Evidence-Based Sheduling.


