3 ms·

> The data model is non-sensical (everything is shared between projects - if you create a status, a field, an issue type, it becomes the one true object shared

> The data model is non-sensical (everything is shared between projects - if you create a status, a field, an issue type, it becomes the one true object shared by everyone) No, that's not the case. If you create any of those new objects, you have to explicitly add it to what you want it to be associated with. New fields have to be added to screens and schemes, new issue types associated with issue type schemes and then to projects, and so forth. None of this happens automatically from the admin side. If you want to share stuff across projects, you can, but it is in no way a requirement. > As a developer, this is a giant leap backwards. The only Jiras I've ever seen suck that hard is when the end users are treated as hostile rather than stakeholders in the deployment. It can be as easy to use or as complicated to use as the people writing your workflows and screens. That applies to the UI as well. The basic UI, OOTB, is fairly easy to understand. Once you have management dictating 30 different required fields along 50 different projects, each with their own issue types and workflows... yeah, it can get hairy. > To see your PRs attached to a card, you have to click into the card, then click into the PR list. This is going to be a bit "you're holding it wrong", but why would you expect to see PRs at the card level rather than the detail view? The agile board is meant to show who and what, not how. PRs would be meaningless noise to the average user of an agile board, not to mention taking up the limited space available on a single card. Those issues aside, you'll never hear me accuse Jira of being easy to administer. It's a tool that tries to be all things to all people, meaning it will take a non-trivial amount of time to get your head around and have some rough edges.

dbingham 8y ago
Have you ever used waffle or something like it? Waffle attaches PRs as little rows underneath the primary card. On the PR row you have a one click link to pop open the PR in a new tab, an indicator of each review on the PR (and its status - whether there are new comments etc), an indicator of the build status and the ability to assign someone to the individual PR as opposed to the card as a whole. As a developer lead, these features are extraordinarily useful. I can see the exact state of the card, and all its attached PRs across multiple repos, at a glance. I can jump into any of the PRs to contribute comments, update a review, make a review. I can make use of the PR assignment to assign different people to different parts of the overarching card (assign a different dev to the infrastructure PR, than for the front end PR, for instance) or to assign people to do the review while leaving the executing dev on the primary card. It's a well designed UX that's trying to be exactly one thing: a highly functioning kanban board tightly integrated with Github. And it shows what good UX design can accomplish. It's not perfect, but it's miles better than Jira and I'm feeling its lack having to move from Waffle to Jira. To respond to the first point, I'm reacting to the fact that everything exists in common and must be associated rather than simply created. If someone's created a "Story Points" field already on another project, that's the one true "Story Points" field. If I want a different one for my project, I have to name it something else. And if other people have created a bunch of fields, you can quickly find yourself swimming in a mess.
- seanjregan 8y ago
  With this new release of Jira everything is no longer "common", This means we've moved from a more global permissions policy to a more local on. "Project Based" if you will. This means that within a "project" you have more flexibility to design the way you want to work at a project level (boards, issues etc. than you ever did in the past.

dbingham 8y ago

Have you ever used waffle or something like it? Waffle attaches PRs as little rows underneath the primary card. On the PR row you have a one click link to pop open the PR in a new tab, an indicator of each review on the PR (and its status - whether there are new comments etc), an indicator of the build status and the ability to assign someone to the individual PR as opposed to the card as a whole. As a developer lead, these features are extraordinarily useful. I can see the exact state of the card, and all its attached PRs across multiple repos, at a glance. I can jump into any of the PRs to contribute comments, update a review, make a review. I can make use of the PR assignment to assign different people to different parts of the overarching card (assign a different dev to the infrastructure PR, than for the front end PR, for instance) or to assign people to do the review while leaving the executing dev on the primary card. It's a well designed UX that's trying to be exactly one thing: a highly functioning kanban board tightly integrated with Github. And it shows what good UX design can accomplish. It's not perfect, but it's miles better than Jira and I'm feeling its lack having to move from Waffle to Jira. To respond to the first point, I'm reacting to the fact that everything exists in common and must be associated rather than simply created. If someone's created a "Story Points" field already on another project, that's the one true "Story Points" field. If I want a different one for my project, I have to name it something else. And if other people have created a bunch of fields, you can quickly find yourself swimming in a mess.

seanjregan 8y ago
With this new release of Jira everything is no longer "common", This means we've moved from a more global permissions policy to a more local on. "Project Based" if you will. This means that within a "project" you have more flexibility to design the way you want to work at a project level (boards, issues etc. than you ever did in the past.