4 ms·

I love JIRA and would absolutely advocate for using it over any other tracker. With just a little tweaking (30 minutes or so on a fresh install), I can have it

I love JIRA and would absolutely advocate for using it over any other tracker. With just a little tweaking (30 minutes or so on a fresh install), I can have it perfectly configured to match my ideal workflow.

gaius 11y ago
Have you considered the possibility that your cow-orkers hate it, and by extension, you?
- morgante 11y ago
  Yes, I regularly contemplate the possibility that they all secretly hate me for using software which you don't like. All their appreciation and thanks for moving us over to Jira is surely a facade for their secret plot of hate.
- dang 11y ago
  > your cow-orkers hate it, and by extension, you I'm guessing you meant this as a joke, but such jokes come across as personal attacks, which are not ok here.
jackhack 11y ago
Can you please elaborate on this configuration? What is the general nature of the configuration changes you're making? Or, how is your workflow affecting the product. I ask as I am in an organization right on the cusp of implementing JIRA, and I would love to steer the implementation team toward a more useful configuration than the clunky defaults, with which I've had prior experience.
- morgante 11y ago
  The biggest things for me are: * Setting up several statuses (more than in the default) to reflect backlog, selected, in progress, testing, deployed * Creating an appropriate board which splits everything into columns by status and rows by user * Setting up a few quick filters to find things like anything which has been in the backlog for more than 6 weeks or bugs which haven't seen activity in the last 48 hours * Integrating GitHub. Being able to kick a ticket over to QA from your commit message is awesome. Beyond that, I mostly focus on stripping out default things to make the workflow simpler. I don't need my software to enforce that I can't move a ticket to deployed straight from in progress, and stripping out those extra rules makes it easier to deal with.
  - jackhack 11y ago
    Much appreciated. That's a great opener for a discussion with our impl. team.

gaius 11y ago

Have you considered the possibility that your cow-orkers hate it, and by extension, you?

morgante 11y ago
Yes, I regularly contemplate the possibility that they all secretly hate me for using software which you don't like. All their appreciation and thanks for moving us over to Jira is surely a facade for their secret plot of hate.
dang 11y ago
> your cow-orkers hate it, and by extension, you I'm guessing you meant this as a joke, but such jokes come across as personal attacks, which are not ok here.

jackhack 11y ago

Can you please elaborate on this configuration? What is the general nature of the configuration changes you're making? Or, how is your workflow affecting the product. I ask as I am in an organization right on the cusp of implementing JIRA, and I would love to steer the implementation team toward a more useful configuration than the clunky defaults, with which I've had prior experience.

morgante 11y ago
The biggest things for me are: * Setting up several statuses (more than in the default) to reflect backlog, selected, in progress, testing, deployed * Creating an appropriate board which splits everything into columns by status and rows by user * Setting up a few quick filters to find things like anything which has been in the backlog for more than 6 weeks or bugs which haven't seen activity in the last 48 hours * Integrating GitHub. Being able to kick a ticket over to QA from your commit message is awesome. Beyond that, I mostly focus on stripping out default things to make the workflow simpler. I don't need my software to enforce that I can't move a ticket to deployed straight from in progress, and stripping out those extra rules makes it easier to deal with.
- jackhack 11y ago
  Much appreciated. That's a great opener for a discussion with our impl. team.