711–720 of 765 posts
Earlier quoted context omitted.
>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.
They're much better now than 7 years ago, try them again.
Earlier quoted context omitted.
>"I think you're totally out of luck if you expect anybody to make a clone that's cheaper." Better tell the Wekan team they're wasting their time then. ;-) https://wekan.io/
It's not a hosted service, its downloadable and open source. Big difference.
Very happy for the folks at Trello. Great outcome for a great tool. Seems lots of JIRA-haters in the comments but lets get back and look at this event. The folks at Fog Creek brought us FogBugz, Stackoverflow, Trello. We should celebrate their success because its events like this that create the motivation for some of us to go create something that "stands on their shoulders" or competes with them or creates some new…
Earlier quoted context omitted.
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 passe…
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. - Roger, Bitbucket Server PM
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.
Earlier quoted context omitted.
What workflow or reporting would we need to add first to GitLab in your opinion?
I remember being in a pitch meeting with an engineer who sells to various other enterprises and he said that what's changed for traditional enterprises over the last few years is that, no matter what their industry, they've all kind of woken up and realized that they're software companies too. A large enterprise that's fully exploiting Jira will set it up for non-developers, indeed they'll set up Jira primarily for t…
Earlier quoted context omitted.
> Seems lots of JIRA-haters in the comments Not just JIRA; I think a lot of people were burnt by Atlassian's management of Hipchat or Bitbucket too. Historically there's something of a track record where Atlassian is the place where interesting, innovative products go to stagnate. Bug fixes happen glacially (a 1 year turnaround seems to be standard), and new feature development doesn't happen at all. Running Hipchat…
That was my first thought too. Jira has Kanban so there's little point for them to improve Trello if they can convert people to Jira.
Earlier quoted context omitted.
I hope you don't think our (Jenkins) UI is ugly now ;) We've recently launched the Jenkins Blue Ocean project that aims to modernize the developer experience and UI https://jenkins.io/projects/blueocean/
psst :-) @i386 used to work on Bamboo for Atlassian. Good luck James, I really want to try out BlueOcean but might depend on stuff[1] at work. 1. GoCD (blah) CircleCI (not used yet but frankly looked better)
Earlier quoted context omitted.
What workflow or reporting would we need to add first to GitLab in your opinion?
I remember being in a pitch meeting with an engineer who sells to various other enterprises and he said that what's changed for traditional enterprises over the last few years is that, no matter what their industry, they've all kind of woken up and realized that they're software companies too. A large enterprise that's fully exploiting Jira will set it up for non-developers, indeed they'll set up Jira primarily for t…
Thanks for bringing up this very relevant discussion. We definitely recognize the shortcomings and we are working hard to improve in these areas. GitLab started out as a software management tool, similar to what you describe. But we are definitely looking to expand in multiple directions. One of them is definitely to make it a tool that is useful beyond just engineers. One of our major thrusts in this area is issue boards. We are considering who the individuals are in a large enterprise that would be interested in issue boards. And we can't solve every use case right away. So we are starting with personas like engineering managers, product managers, and designers. These are folks that may not be very technical, but still are important in the product development flow in a large organization. See this as an example: https://gitlab.com/gitlab-org/gitlab-ce/issues/24686
We definitely have our eye to expand beyond these use cases. So we anticipate getting into areas like road mapping, Gantt charts / swim lanes, etc. But again, we work iteratively at GitLab, so our very first stab in this area is burn down charts to get feedback on how a software iteration is performing. And then we build on that to bigger scopes like roadmaps for business managers, etc. See https://gitlab.com/gitlab-org/gitlab-ee/issues/91 for burn down charts.
In addition, we recognize the rich nature of teams and the multi-faceted of different roles in an organization. For lack of better term, we've called it "team-centered collaboration" in this issue, we start the discussion that we want to go beyond just software-first projects: https://gitlab.com/gitlab-org/gitlab-ee/issues/1295
Earlier quoted context omitted.
I remember being in a pitch meeting with an engineer who sells to various other enterprises and he said that what's changed for traditional enterprises over the last few years is that, no matter what their industry, they've all kind of woken up and realized that they're software companies too. A large enterprise that's fully exploiting Jira will set it up for non-developers, indeed they'll set up Jira primarily for t…
Hey! I am a product manager over at GitLab. Thanks for bringing up this very relevant discussion. We definitely recognize the shortcomings and we are working hard to improve in these areas. GitLab started out as a software management tool, similar to what you describe. But we are definitely looking to expand in multiple directions. One of them is definitely to make it a tool that is useful beyond just engineers. One…
Earlier quoted context omitted.
What workflow or reporting would we need to add first to GitLab in your opinion?
I remember being in a pitch meeting with an engineer who sells to various other enterprises and he said that what's changed for traditional enterprises over the last few years is that, no matter what their industry, they've all kind of woken up and realized that they're software companies too. A large enterprise that's fully exploiting Jira will set it up for non-developers, indeed they'll set up Jira primarily for t…
With GitLab, one of our goals is to put all the pieces together. We are building out the integrations, step by step, from idea to production. We believe in a world where everyone can contribute to projects. In a large organization, this means diversity in workflows and individuals. Again, I mention that we are focused on really understanding who those users are as part of this exercise. Our UX design team has begun that work and we have already started research on personas. This will further drive our development of GitLab and make sure to nail those other use cases beyond the narrow scope of software development, into allowing companies to leverage GitLab to create software and processes to run their businesses.
In particular, here at GitLab we use GitLab itself for some HR operations too. So we recognize the potential there. And we even want to ship a simple feature for operational support tickets (https://gitlab.com/gitlab-org/gitlab-ee/issues/149). So we definitely recognize the breadth of opportunity and the gaps we still have.