JIRA: Help us help you. Follow
I was referred to the forums by one of our rabid JIRA users saying that some rabid IDEA users weren't such big fans. I'm here to change that :)
I suppose I should explain myself - I'm one of the two founders of Atlassian - http://www.atlassian.com - the developers of JIRA.
I've also been an IDEA user since it was a JBuilder plugin, JIRA was completely developed using IDEA and every single one of our developers uses IDEA. So I'm not some big stuffy corporate CEO, I'm most certainly a developer at heart.
We pride ourselves on being an open, reactive company - here's your chance to test us.
I can't promise to fix everything in a week, but we will do what we can to make the transition as painless as possible, whilst hopefully showing you why JIRA has so many advantages over the old tracker system :)
I've read through all the threads, and here is what I think the main "pain points" are in the transition to the new system. Once we've worked out a comprehensive list of these problems, we can work to improve things.
Please correct me if I'm wrong or have missed any major items here:
- JIRA has no text formatting in comments
- "I can't understand how to create an issue in JIRA"
- I can't see what issues were fixed in version X?
- I can't search a custom field
- I can't search for issues where build # is between 500 and 508
- JIRA doesn't assign individual modules/components to individual engineers
- Do we need a "two step" system to handle issues in JIRA and the trackers, keeping development issues separate from spurious reports?
- should we duplicate issues between JIRA and the tracker?
- I can't see RSS feeds without assing my username and password
- Can issues be hidden from the public, while sharing others?
- Should a "select group of the community" have access to JIRA?
- How do I get "new / updated issues" in my RSS aggregator?
Did I miss any current problems?
Please feel free to sing out here. I'll respond to these points individually below.
Please sign in to leave a comment.
I'd add to find anything or get to learn to find anything in Jira has
been a major pain the butt. I spend more time trying to figure out how
the heck the interface works than to actually look at what I need and
get good info flowing from it. I used to have a couple of great saved
searches in tracker, and setting them back up in jira has been a hassle.
I also don't want to see custom fields like time to fix, fixed in build,
they're not mine to modify, don't bother me with them.
I don't like that I have to scroll all the way down the page to submit
I don't like that I have to submit my ticket first before attaching
something to it. Why this 2 step?
>have missed any major items here:
a few :)
The most important to me:
>- How do I get "new / updated issues" in my RSS aggregator?
- I don't want RSS, I want newsgroups threads, easy to read, easy to
access, easy to use. My time is valuable to me.
RSS is not the proper tool to handle conversations. Newsgroups are.
- Why is 90% of the info in the web interface to absolutely no use to
me (as an eap member)
- I can't preview, before posting
- I can't spellcheck
- I want search results titles to appear in 1 page, 1 table, like in
the tracker, with sortable columns, etc... LIKE IN THE TRACKER.
(because I want to search with my browser Ctrl-F, and not by
And (not really a critic, rather a question to JB, about why they forced
us, the EAP users, to use a tool that suits their work, but not ours :
Why is everything 2-20x slower than it was a week ago, with
- reading : newsgroups +Thunderbird, and
- posting : tracker + Firefox?
Alain Ravet wrote:
NNTP Support should be easy to write, similar to how the "email
everything to a user" would, you would "post everything to a group",
replies to the group may be a bit tricker, but not impossible I'd say.
My major issue is the missing newsgroups support. Following an issue and
commenting on it was so incredibly easy with the tracker. Everything
could be done from within the news reader.
Now with JIRA it's a real PITA. Although I managed to set up the three
IDEA RSS feeds, it's almost useless compared to what we had before. I
can't display the relevant page directly because of the missing
authentication information, so I only get the issue's description over
and over again. To see the actual comments I have to separately load the
page in the browser.
Before I had a threaded view of the whole issue, commenting was as easy
as replying to a previous comment. Everything was a lot easier and less
time-consuming than now.
Mike Cannon-Brookes wrote:
Fuhrer Engineering AG
I want to add another: I don't have the ability to preview my changes before
creating an issue (especially, when I do not have the right to change it)
and when commenting. This issue becomes more important, when JIRA can
understand bold, italic or fixed width[/fixed] fonts.
Martin Fuhrer wrote:
JIRA may be a great tool, but not for us.
In restaurants, they use 2 sets of knives: 1 for the clients, and 1 for
It's useless and stupid, to force one population to use the others'
tools, just to simplify your cutlery housekeeping.
Same here. The tracker is the right tool for us.
JIRA is the right tool for JB.
Solution: synchronize them.
Well, I wouldn't go that far. JIRA can be the right tool for us, too,
when Jetbrains make more use of versions (in the meaning of "released
builds"), the wiki-like styling is solved and when the JIRA -> newsgroup
Even if it CAN become, one day, after mucho juggling on 1 foot, the old
(tracker+newsgroups) already IS: it's light, efficient, agile, .... the
right tool for OUR mission.
Whenever I start a JIRA activity, I feel like my time is stolen from me:
everything takes 2..20 as many time, and I can't notice events anymore,
I have to actively seek. And don't tell me about those f$* RSS feeds.
It's newsgroups or nothing.
>> - How do I get "new / updated issues" in my RSS aggregator?
This is the most important for me too.
Without newsgroup access as before, the missing of this feature is the biggest
Yes that's true. The WebIterface is nice, but the most of the information
I suppose JIRA is using SiteMesh, so it shouldn't be a problem for them to
write a decorator for the "EAP user view " :).
I guess the Jetbrains IDEA team has to get used to JIRA too. These are
hopefully all just startup problems. I'm hoping everything will get
sorted out eventually.
Also the tracker wasn't perfect either. Two examples of things that
1. Newsgroup synchronization was broken often, especially on the
exceptions newsgroup. That is broken since 20 oktober and I gave up
reporting on it.
2. It impossible to find exception reports using the quick find box in
the upper right corner of the tracker page.
Hmmm, now that I think about it, this still is a problem, since the
exception reports were not transfered to JIRA
In article <firstname.lastname@example.org>,
Alain Ravet <email@example.com> wrote:
I have to agree, I've been filing more duplicates because even if I
search, I often don't see the results of what I think might be a
duplicate, clicking on 20-30 links is a little too much to read.
Setting up the rss feed was retarded at best, and even then though my
info is flowing in nicely, I have to rely on the search capabilities of
the rss feed app, which means paying for it because the free version
doesn't have search. So I'm paying to be able to do what I used to do
in a synch.
Further, if someone files a bug, I can see it in the rss, I have to
click on the link to go to jira, find the comment window, enter my
information and submit. wth? The 'old' way, I was in newswatcher, I
read something, I just hit reply and I'm done. I don't have to start a
browser and keep my rss feed client running on top of having my
newswatcher app... we simply don't always have multiple screens to work
RSS is not for Tracking. you're applying a technology to the wrong
use... use a hammer to open the door, instead of using a key... it's
more efficient, does less damage, doesn't bother your neighbors and it's
what it was made for.
I do want to add one thing... Why is it that I have to go to every
single ticket to watch it. Let me watch the whole stupid project, or
let me watch all open issues or resolved issues. I don't have time to
pick and choose what I want to watch.
In article <420C8B2F.9050501@SPAMBLOCK.carp-technologies.nl>,
Bas Leijdekkers <leijdekkers@SPAMBLOCK.carp-technologies.nl> wrote:
I'm not as worried about exception reports. These reports are often
picked apart before IDEA submits the exception to the tracker, so if
there is one, I just add it, I don't bother with looking for a duplicate.
Something like the "JIRA Browser plug-in" for IDEA would be the best
solution IMHO. The plug-in should be extended to support "sending" of
This could be used by default, even when exceptions appear. Having it
integrated as a plug-in, the user wouldn't need to fill a lot of fields
by default, cause the plug-in could "prefill" them.
Even more, as a plug-in, the browsing and search of similar tickets
would be very fast, since the 90% of the useless webinterface would not
be rendered, thus reducing greatly the number of duplicates - AFAIK this
was on of the biggest problems of the old tracker.
This can't be said enough. Using a newsgroup application like
Thunderbird makes keeping up-to-date on all of the EAP's progress so
easy. AFAIK, using Jira makes this impossible. I never know what
changed. I can't have an easy conversation while hashing out an idea.
Sun Certified Java Programmer
Alain Ravet wrote:
AM> Something like the "JIRA Browser plug-in" for IDEA would be the best
AM> solution IMHO. The plug-in should be extended to support "sending"
AM> of tickets.
Will people use that if it will be a plugin for Omea and not IDEA?
Omea Project Leader
"Develop with pleasure!"
In article <firstname.lastname@example.org>,
Dmitry Jemerov (JetBrains) <email@example.com> wrote:
No, Omea is only on windows. What do you do with Mac and Linux people?
AM>> Something like the "JIRA Browser plug-in" for IDEA would be the
AM>> best solution IMHO. The plug-in should be extended to support
AM>> "sending" of tickets.
Sorry if I wasn't to precise:
With "JIRA Browser plug-in", I ment the already existing plug-in for IDEA,
develped by Mark Derrictt AFAIK.
That would be a very good starting point IMHO.
No, I don't think so.
AFAIK you target with Omea the normal user, not the programmer(you said that).
In this area, of course, the most of them use Windows, so it's OK for you
that you've choosen .NET.
The problem is that a much higher percentege of programmers do not use Windows,
and a lot of them are very active right now. They won't change to windows,
that's for sure, so you will loose their valuable contribution, i.e. exactly
what EAP was made for.
Dmitry Jemerov (JetBrains) wrote:
If Omea will run linux, why not ?
In article <firstname.lastname@example.org>,
Karol <email@example.com> wrote:
and OS X, and it would be in Omea lite or what ever the free version is,
because I won't pay more money just to participate in EAP. That defeats
the purpose of the eap.
Because it means installing another tool.
I already have email, web browser and idea open.
Sure that should be enough to read/comment/submit issues?
Not really a JIRA issue, more of an ITN issue -
add a link to JIRA in the top RH corner of the ITN pages.
One more thing:
Single Sign On - I log in to ITN to access the EAP builds / forums etc. Make the ITN/Tracker/JIRA integration seemless.
The JIRA plugin can already create new issues...
>> Will people use that if it will be a plugin for Omea and not IDEA?
AM> No, I don't think so.
AM> AFAIK you target with Omea the normal user, not the programmer(you said
AM> In this area, of course, the most of them use Windows, so it's OK for you
AM> that you've choosen .NET.
AM> The problem is that a much higher percentege of programmers do not use
AM> and a lot of them are very active right now. They won't change to windows,
AM> that's for sure, so you will loose their valuable contribution, i.e.
AM> what EAP was made for.
It is very interesting - why do you think that providing an additional service
(the Omea plugin) will cause us to lose any contributions? It's not like
we're going to make it the only way to browse or submit bugs. People who
can't use Omea will still be able to use the JIRA Web interface.
Omea Project Leader
"Develop with pleasure!"
AM>> The problem is that a much higher percentege of programmers do not
AM>> and a lot of them are very active right now. They won't change to
AM>> windows, that's for sure, so you will loose their valuable
AM>> contribution, i.e.
AM>> what EAP was made for.
Please read the existing IDEA forums.
You will see that the EAP users with the most of the contribution, do not
Now consider that most of them do not like the actual WebInterface (that's
why we search a solution -right?).
They will provide less feedback, because of that webinterface.
By making the plug-in in Omea (with no relation to IDEA - so not automatic
excetion item generation), you will loose them, cause you try to solve the
problem in the wrong way (you don't target those who have the problem).
Even a lot of those who use IDEA on windows, won't use OMEA cause:
- IDEA already consumes all the resources.
- a lot of the programers allready have other similar tools, already running.
- there's a pretty high number of programmers that do not want to have any
NET on their computer.
Consider that there's already an IDEA plug-in JIRA. Why not just to improve
it, instead of writting from ground a new one (for Omea) that doesn't target
the most active EAP users(those who would really benefit from a plug-in)?
P.S. Besides, AFAIK, Omea's target are the normal windows+outlook users,
who don't have anything to do with JIRA, programming :). That's what wou've
said. If your target were the programmers, than you would have implemented
Omea in JAVA.
>> It is very interesting - why do you think that providing an
>> additional service (the Omea plugin) will cause us to lose any
>> contributions? It's not like we're going to make it the only way to
>> browse or submit bugs. People who can't use Omea will still be able
>> to use the JIRA Web interface.
AM> Please read the existing IDEA forums.
AM> You will see that the EAP users with the most of the contribution,
AM> do not use windows.
AM> Now consider that most of them do not like the actual WebInterface
AM> (that's why we search a solution -right?).
AM> They will provide less feedback, because of that webinterface.
AM> By making the plug-in in Omea (with no relation to IDEA - so not automatic
AM> excetion item generation), you will loose them, cause you try to solve
AM> problem in the wrong way (you don't target those who have the problem).
Just to make it clearer: I do not suggest that the Omea plugin should be
the only solution, and that after creating it we should stop all other attempts
to improve the tracker experience.
AM> Consider that there's already an IDEA plug-in JIRA. Why not just to
AM> improve it, instead of writting from ground a new one (for Omea)
AM> that doesn't target the most active EAP users(those who would really
AM> benefit from a plug-in)?
The IDEA JIRA plugin was not developed by JetBrains, and as far as I know
it is not open-source. So I can't really do much to improve it.
On the other hand, we have the possibility to create the Omea JIRA plugin
with relatively little effort, and I thought that it may be useful for some
people. But if you insist on us not creating it, OK, we will not. :)
AM> P.S. Besides, AFAIK, Omea's target are the normal windows+outlook users,
AM> who don't have anything to do with JIRA, programming :). That's what
AM> said. If your target were the programmers, than you would have
AM> implemented Omea in JAVA.
That is a big over-simplification of the issues involved.
Omea Project Leader
"Develop with pleasure!"
Don't give up Dmitry! Even if this plugin will be used for report only Omea requests to Jira it enough to begin development :)
I am not really sure how we can solve the comment<->newsgroup issue
effectively unless the Atlassian guys come up with some elegant solution.
The flexibility of JIRA is in that it allows to get RSS feeds for ANY filter
you create which comes very handy for a lot of purposes. However, I do
agree that it does not solve the task of watching the whole project in a
usable way, which I myself, as you can understand, am missing a lot as well
We have thought of a great way to improve the usability of JIRA, for
developers and EAP'ers, by developing a plugin for IDEA which would greatly
improve a lot of issues. I am seeking ways to do that.
Yes, you are correct, we are a bit selfish in that we went the JIRA path
mostly for our internal benefits, not for EAP's. However, I am not sure if
this is a bad thing today. We want to improve a lot of things, if the old
way to work with requests is usable for EAP but hard for us, what is good
about it anyway, since you can submit and track requests easily but not get
it fixed, or get it marked "To be discussed", or even the famous "Open, No
version assigned, Low priority"?
"Develop with pleasure"
On 11.02.2005 12:42, in article firstname.lastname@example.org, "Alain Ravet"
>> Well, I wouldn't go that far. JIRA can be the right tool for us, too,
In article <BE346C69.A4A4email@example.com>,
Eugene Belyaev <firstname.lastname@example.org> wrote:
Indeed. YOUR needs have to come first. But JetBrains created a monster
in the EAP. This process is so unique compared to other companies,
you've inadvertently (or maybe this was the intent) made your users so
close to your process and how you work that in order to improve your
internal processes, the users have to get their butts kicked for a
while, while things get figured out and cleaned up. This doesn't mean
Jira is ever going to be good, or enjoyable for the users though, and no
matter what, it sounds like it's going to cost JetBrains some man power
to cover for this switch and make things work again. I hope it's as
worth it for you as it will be for us. In the mean time the user just
have to try to take the pain and deal with it... or not, and simply stop
submitting bugs until things are right again I guess.
Thanks for the great improved communication by the way, it's been a
loooong looooog time since you've been in the forums Eugene... I believe
since the birth of your daughter :)
Ahmed Mohombe wrote:
After being poked and proded by Mike on the weekend I went through and
fixed up a heap of bugs and will hopefully drop a new build out shortly
to the plugin server.
I've also just set it up under cruisecontrol with automated builds from
subversion being made available at:
But thats assuming you want bleeding edge.