JIRA book news

Last month I posted an article about why I wasn't writing a book about JIRA. Now Packt publishing is working on one and have asked me to be a technical reviewer for it.  Nothing is certain until a book is printed (probably next year) but this is good progress.

~Matt

Jiraaaargh!

Summary: how to get Atlassian's attention effectively.

If you were an Atlassian Product Manager, what would get your attention? Obviously show-stopping issues such as the security problems earlier this year are going to stop you cold. But after that, what to do first with your limited time and small, only-human team? You've got literally thousands of issues to choose from.

There's no need to keep guessing because Atlassian publish an official "how we choose what to work on" guide. Here's my take on what it says:

• We use JIRA and Confluence to track issues and we expect you to also
• No roadmaps (they change too often)
• Votes do matter
• Feature Requests are not Bugs, and are not treated the same way

and finally "We schedule features based on a variety of factors", which I take to include "the importance of your request depends on more than just how irritated you were when you submitted it".

Failed Approaches

• Angry rants: "this issue has dozens of votes, so you obviously don't care about your customers, I hate you all!"
• Unfounded estimates: "this is so simple, it should only take you an hour or two"
• Snarky "Happy Birthday" comments in an issue

I think I've tried all of these in the past five years. None of them worked very well.

Better Approaches

• Good bugs - define action (what did you do), expectation (what should have happened) and observation (what actually happened)
• Crisp and concise communication, because vagueness or wordiness makes it look like you don't care
• Pointing out how your request fits in so nicely with the rest of the Atlassian products
• Talking to Atlassians about the request at AtlasCamp, AtlasSummit and Atlassian User Groups

Open Questions

• Does an existing implementation help or hinder your request? It can live on as a workaround, or it could provide a working specification for Atlassian. There's probably no definite answer to this.

Documentation

http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+Policy

Disclaimer: The author, Matt Doar, is an Atlassian Partner with no secret access to Atlassian product managers.

JIRA Levels of Change

Summary: the different levels of changes to JIRA for plugins are listed

A few months ago Vincent Thoulé of Minyaa and I were discussing the different kinds of changes we've done to JIRA. We came up with the following list different levels of changes.

Levels

0. Client side install, no JIRA restart required, e.g. a JIRA CLI
1. One plugin jar file, no JIRA restart required - mostly not possible yet but can happen for groovy scripts
2. One plugin jar files and JIRA restart required - the common case
3. One plugin jar file, some custom jsp files, JIRA restart required
4. One plugin jar file, modified system jsp, vm or XML files, JIRA restart required
5. One plugin jar file, modified system files with possible recompilation, JIRA restart required
6. More than one plugin jar file, new language installation required, first-born child required.

No classification is perfect, but some are more useful than others. It would great to have each of the public plugins for JIRA fall into one of these categories, to help give a sense of what you're in for if you try to get it running.

What do you think?

JIRA Versions

All

Documentation

None