We use Jira at our company and it's probably one of the best issue tracking systems I've tried. Confluence is alright but I think that there are a few open source wiki packages that are at least as good, if not better.
Which free ones do you like? My biggest Confluence draws are rich text editor (nice for one-off pages), attachment indexing, and attachment versioning. But I'm always open to trying something else.
For what it's worth - we have a huge new release of Confluence coming out in 4 days time. We've also released an infographic about the history of collaboration (and I'm still not able to find the easter egg):
http://www.atlassian.com/en/communication-through-the-ages-i...
Confluence 4 has a completely rebuilt rich-text editor with autocomplete - the ease of use of a WYSIWYG editor with the speed of an IDE. Love your thoughts on it when it ships.
Do you have any plans, in Jira, to allow sub-tasks to have their own sub-tasks. Only having one level of nesting is extremely restrictive and an annoyance we come up against a lot. On the whole though I quite like Jira, particularly its integration with FishEye.
FishEye is also pretty decent although it chokes a lot with the size of our repository - we have a lot of code and a lot of branches which have really pushed the size up. A few JS optimisations would be nice as well - it can really chew up the CPU sometimes.
Thanks for the feedback. Letting arbitrary levels of nesting is one of the things that keeps me, and the JIRA product manager up at night.
This feature request is our second highest voted issue (JRA-4446), and one that I personally want to see fixed. For the moment, there is a 3rd party plugin that solves most use cases (Structure Plugin from ALM works).
The key for us as a vendor is making it work without degrading the overall experience. We have seen plenty of other issue trackers implement this, but it really detracts from the overall experience when you don't know what is a task, or a project, or a feature etc.
But we're definitely trying to find a solution.
On FishEye - we have it working on code bases that have hundreds of millions of lines of code, but it often requires some tuning. For example (and one of many such examples), in older versions of Subversion, there was no real way to tell what was a branch, and we rely on 'conventions' such as /branches/ to tell this.
Unfortunately, every code base contains 'mistakes' where someone copied the entire tree into /branches/ or created a branch somewhere else.
There are some easily configured settings that usually make FishEye run a lot faster but explicitly telling it about some of these cases.
But - even saying that, performance was around 50% of the last few releases of FishEye, so the latest versions do run significantly faster in all instances.
It's interesting to hear that it's actually a user experience, rather than a technical problem. I was assuming there was some dodgy database code to blame! I will install the 3rd party plugin and see how it works for us though.
Our branches probably put us in the hundreds of millions of LoC category. It's unfortunate that for a long time we were prepared to allow each of our customers a separate branch for each release - each of which potentially has active development on it (not a real branch I know as we don't intend to ever re-merge them). As such we have a lot of code that potentially needs supporting. I'm not actually sure how often they are searched on as I'm lucky enough to work on newer parts of our software but the idea of dropping them from FishEye didn't go down too well.
I believe the guy who did the setup spent some time messing around with performance - I have no idea if he did everything right but he's a pretty smart guy.
I'll definitely take a look at the most recent release though, thanks for the tip.
Oh and thanks for taking the time to reply to my unsolicited feedback!
What would be nice is if you could have some sort of warning in place for hosting Confluence instances letting the day-to-day users know that a major change is coming. It's pretty disruptive.
