I love their response to open issues like: we'd like to be able to delete pull requests.
Response: what a silly notion, no
Or another one I found recently: we'd like to comment on code that isn't within 10 lines of a changed file. You know, because one line change in file a can impact stuff elsewhere. Or even in another project but the chances of that happening are more slim than a tachyon hitting an atom as it passes through earth.
Response: Good idea, here's stuff we did this year, and here's other stuff we do. (aka the non committal middle finger)
It sucks because atlassian products are 80% of the way there, but the final 20% polish never seems to arrive. And its been years.
We appreciate the frank feedback, but I have to disagree with the interpretation.
I really hate that we can't say yes to every feature suggestion, and what we _are_ able to talk about seems to come across as non-committal to some. The fact that a suggestion is open means we think it has merit too (we close "silly notions"), it then becomes a matter of priorities.
That may be the case. However when such tickets are open for 6-7 years with no update the general viewpoint everyone I know that uses Bitbucket has is that it will never be a priority to Atlassian.
Adding things like large file storage support is cool, I guess, but when you never use it its rather a case of appearing to prioritize certain market segments over others.
I know I've read the article that states how you prioritize, with a major one being usage patterns. But I wonder just how accurate a metric that is given in my specific group, we've started to avoid using the review tooling in bitbucket because its almost impossible to use to accomplish the goal.
Unless the idea is for Bitbucket to have a completely minimal set of features and for anything useful to pay license fees for plugins I can't quite make sense of how the priorities are decided.
I think you've hit on a really important point. In isolation, a particular suggestion might be something of a papercut with a workaround. An unwanted pull request, for example, isn't going to stop others from getting their work done. But, if there are enough of these things that happen to affect a team together, it all adds up. It sounds your team is in that boat, and people not wanting to use the review functionality is a serious concern. Whether or not that's uniquely the case, I'd love to discuss further to make sure I properly understand your experience. If you're willing, please email me (rbarnes atlassian com) and we can set up a call.
>atlassian products are 80% of the way there, but the final 20% polish never seems to arrive
This was kind of my synopsis when I looked at implementing them back in 2009. My take was that they built out 80% of the platform and then expected the customers/users to build out the extra 20% for each other.
Response: what a silly notion, no
Or another one I found recently: we'd like to comment on code that isn't within 10 lines of a changed file. You know, because one line change in file a can impact stuff elsewhere. Or even in another project but the chances of that happening are more slim than a tachyon hitting an atom as it passes through earth.
Response: Good idea, here's stuff we did this year, and here's other stuff we do. (aka the non committal middle finger)
It sucks because atlassian products are 80% of the way there, but the final 20% polish never seems to arrive. And its been years.