farkas

I'm the CEO of Atlassian (who run Bitbucket & Stash). Would love to get your feedback on what we can do to improve. We really pride ourselves on making products that have the right level of control in our products.

Or email me - scott <at> atlassian.

Can you point me to another company with a public bug tracker that you would reference as the gold standard?

Whilst I know we can always improve (and we always try to), we always end up with some bug that has been open for 5+ years that has the most votes. By definition.

At least with Atlassian you can see the bugs, vote on them, provide comments. If there is another company with this level of transparency that does it better - I'll get in contact to find out how.

Scott, CEO Atlassian

I really appreciate the feedback. Whilst I can't comment on future releases, I want to assure you that we are aware of the items you mention. Stay tuned :)

Thanks. As I'm sure you've guessed, this was a permissions problem with some of the pages we'd been keeping quiet until the launch. Let us know if you find any more.

It's fine. However, we would recommend pushing and pulling over SSH for speed.

And let me clarify: by fair-use we mean we offer unlimited _code_ hosting, not general storage. We monitor for abuse, such as large repos containing only music, videos, and public viruses or malware. Though don't worry - if we notice any problems we'd of course contact you first.

We'd love to have you as a customer!

Just as a FYI - we don't have any disk limits (apart from fair use).

We don't want our pricing to be based on repos, or disk space, or any other limitation that is hard to predict, or encourages sub-optimal decision making to optimise cost. We think that users is the best way to price a product, and is easy to predict.

In terms of UI - there are things that bug me today, but our team is cranking along improving it.

But we have found that most of our users spend their time interacting via the command-line, and therefore we have prioritised features around stability and performance, as well as enabling Git support. Now that this is done, we'll be focusing more time on UI again.

(disclaimer - I'm the CEO of Atlassian)

Developers are religious. Whether it is vi vs emacs, or IDEA vs Eclipse or Mac vs Linux. In September we had a huge debate internally (hundreds of comments long) on functional vs non-functional programming.

We know that no-one wins in these religious debates.

We've found that developers are equally religious regarding their DVCS. Most frequently it is whatever DVCS you started with is the one that you're passionate about.

We've found that most companies of any size have both Git and Mercurial lurking somewhere in their development ranks. Previously if they wanted to host their code in the cloud (and who wouldn't), they would have had to choose two different hosting providers. As a developer, this was a pain as you never knew where your code was.

Now that Bitbucket supports both, you no longer have to choose. We think this is a huge win! Companies can store all their code in one place. And with the per-user pricing, it is a very fair pricing model (don't have to think about whether a fork is going to cost you or not!).

> By far, my biggest complaint to Atlassian is upgrades, which are a huge PITA. There has to be an amazing new feature for me to go through that.

Just as a FYI - the latest version of JIRA (4.4) and the soon to be released (next week) version of Confluence (4.0) have had the install and upgrade process rewritten from the ground up.

If you've been bitten in the past, I'd strongly recommend taking another look.

A summary of the features here: http://blogs.atlassian.com/jira/2011/06/jira-44-sneak-peek--...

Interestingly - I just had this exact same feedback at a pub in Amsterdam with one of our customers.

I agree there is improvement here. But in my years of experience with JIRA, I do find that most software development teams approach things differently, and so there is no 'one size fits all' for most dev teams.

One team wants saved filters to be front and centre, another RSS feeds. One user creates a hundred issues a day (usually QA), whilst others rarely create issues at all.

If you can spare the time, I'd love a more complete report of your issues with our products and support. If you can email me on scott@atlassian.com, I'd love to hear your story and see if there is anything we can do to improve things.

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.

Hey - I'm not sure what you mean? You mean do I realise that the guy I fired wouldn't find a job again?

I think that it is useful to understand the philosophy behind the process, but adapt the process to your own style.

There are two points that I have taken from the TopGrading process: - hire people who are 'A' players who have succeeded at whatever they have done AND who have a passion for the role you are hiring for - past performance IS the best determinant of future success, and the best way to answer the first question

The interview process generally starts at college where you dig into why they chose their course, the highlights, where they excelled, where they failed, who influenced them and why. Did they take on any leadership positions? Win any awards?

Then for each job they have had since, find out - why they chose it, what they found, what they fixed, what they learnt & what they would do differently. Would their boss give them a reference, and why did they leave.

At each turn, you are looking for: 'were they an A player / had outstanding results' and 'does their career path lead you to believe that they will be passionate about this job'.

There's a lot of nuances to it, but I wouldn't hire senior people any other way. I recently compared our hiring notes to a comprehensive personality test of a new employee, and they matched exactly.

Sorry that 'remember me' didn't work for you. It could have been a bug with how it was set up, or equally likely - a bug in some edge case that you were hitting.

I can assure you that it works now :)

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.

Yep - I don't think that I said that particularly eloquently. And it was related to a point (that I can't remember) that had been brought up earlier in the conference.

But my overarching belief about product design: - build stuff you are passionate about because you use it - listen to customers, but don't do what they say

The reason that products all start to look the same is that customer's only experience of 'better' is a competitors product. That's why you have Audi's advertising about their safety record, and Volkswagon's advertising about their performance features.

A great read on this topic is Youngme Moon's book different: http://www.amazon.com/Different-Escaping-Competitive-Youngme...

Hey! I was the founder / developer that wrote the stats system for JIRA, and I'm quite proud of that code! :)

But I'm worried as I've read a few people on this thread say that JIRA is made for managers and not for developers. As the guy who was here from the beginning - I can say that it is definitely true that we made JIRA target managers - we found that too many people using Bugzilla spent all their time reporting status upwards, and if we could automate this, then developers could spend more time coding, and less time reporting.

But that doesn't mean it shouldn't be a great experience for developers. As someone who longs for the day that I can spend 10 hours coding (I'm now co-CEO, so I don't get to code as much anymore), I want JIRA to rock for this use-case.

But I'd love your feedback on where we need to improve. What is the 'inner loop' of JIRA usage for yourself? What functions do you do 20 times a day that we should make lightening fast?

I'd also love to know which version you are using. We've made some serious speed improvements in the last 12 months, as well as introducing keyboard shortcuts for the most common actions, so you can get around much faster than you used to. In JIRA versions >4.1 press '?' to get a list of shortcuts. My favourite is '.' when you are viewing an issue.

But seriously - would love your feedback. Or email me: scott@atlassian.com