commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <>
Subject Re: [PROPOSAL] Jakarta Commons moving to JIRA
Date Tue, 20 Jan 2004 21:03:40 GMT
I sometimes think that there is an aspect of the ASF bug tracking 
systems that gets forgotten... How easy it is to learn to use them. As a 
contributer to Ant, and an operator of my own bugzilla, I have been very 
satisfied with bugzilla in this repsect. The first time I ever used 
bugzilla I had no trouble figuring out how to do a query, or fill in a 
bug form. The query form seemed a bit disorganized, but there were lots 
of explanatory links and with a little looking I found the submit button 
without too much trouble. I have not once had to explain details of how 
to use bugzilla to users of my bugzilla, nor have I recieved complaints 
about it. Some of the users are introductory programming students who 
have never used any bug tracker before.

In contrast, I don't like scarab. I have several times found issues in 
OJB (relating to JDO implementations), but they use Scarab. Scarab I 
regret to say is quite difficult to use (at least if you don't already 
know how to use it, or maybe only if you are used to using bugzilla, I 
don't know which). It entirely fails to document itself clearly. 
Bugzilla has explanitory links all over it's bug creation and query 
forms, which is something I beleive to be critical to a bug tracking 
system that will be accessed by users who are not already familiar with 
it. I have several times tried to use Scarab, and each time it has 
failed, or it has eaten all my plain text formatting by coalescing all 
the whtiespace (that makes stack traces really fun to read), or whatnot. 
I am sure it is user error on my part, but so far I really haven't had 
time to find out where to read up on how to properly use Scarab. Another 
annoyance is that after you sign up for an account with scarab it tells 
you you must "request" membership in a project, which seems to imply 
that you might be rejected. Really not a very welcoming start.

The systems used at apache should (IMHO) be transparent, user friendly 
and self explanitory. If they want users to report bugs in their 
software, it should be easy to learn the system. The current result with 
Scarab and me, is if I see that a project uses scarab, I only report 
bugs on their mailing list. I suppose if I decide I want to become a 
direct contriubuter to a project that uses Scarab, or I have some free 
time and think of it, I will take the time do the research to figure out 
how to enter bugs properly in Scarab.

So I wrote the above mostly based on the gut reaction, oh no not another 
bug system to fight with...

After looking at Jelly's JIRA as linked from their project pages 
(, it 
is clear that there are some nice features, it looks nicer than both 
bugzilla and scarab and is and friendlier than scarab, but I do see one 
major usability glitch, and possibly a bug in searching. Nowhere did I 
see a link for Entering a bug. This is the main reason people come to a 
bug database. How can there not be a link on the front page for it!?!? I 
have a strong suspeicion that such a link would have appeared had I 
created an account and logged in, but there was no link for that 
either... just a log in link. (now I think it is vairly likely if I 
followed the log in link it would eventually get me to an account 
creation link, but....) Only my existing knowledge of how web apps and 
bug trackers tend to work tells me that. Nothing on the page helps you 
enter a bug. (unless I am blind or stupid, both of which happen 
occasionally). It could use more explanitory links too, but at least 
there was a help link (once I saw the really tiny bubble thing in the 
upper right) that led to a detailed manual (though that manual didn't 
have a "Enter a bug" section). I didn't have time to browse the manual 
deeply, but this is still inferior to links on the issue entry page, 
because the user must leave the page, and search the manual for the item 
they don't understand, rather than being taken directly to the item. 
It's hypertext man, take advantage of that!

The entry page is is a stark contrast to bugzilla where you are 
immediately provided with links to do each of the main tasks (quick 
search, detailed query, enter bug, get summaries, log in, create 
account). Whatever reason someone came to a bugzilla front page, (other 
than by accident) the link is there where they can't miss it. The 
possible bug in searching is that I did a search on "escape", a word 
chosen randomly from one of the Popular Bugs (JELLY-55, in which it 
appeard as "escapeText"), and it failed to find the bug I chose the word 
from. chosing the word "body" however did bring up that bug. It seems 
that perhaps JIRA was only finding .*escape and not .*escape.*...

So my order of preference for bug tracking from a "support the novice 
user" perspective is:


Just my $0.02 worth (I don't get much per word do I?),


Henri Yandell wrote:

>+1 to any Commons component to JIRA. I far prefer it to Bugzilla.
>On Mon, 12 Jan 2004, Noel J. Bergman wrote:
>>There are separate requests on the table to move BETWIXT, CLI, CODEC, JEXL
>>and CONFIGURATION from Bugzilla to JIRA.  JELLY is already there.
>>Are there any other Jakarta Commons projects that want to migrate?  Are
>>there any that do NOT want to leave bugzilla?
>>Right now, each "project" is a component of Commons.  If we move to JIRA, I
>>would propose that we create a Project Category for Jakarta Commons, and
>>make each component a project, so that each one can be released separately
>>with its own versioning, etc.  We could use a common scheme for permissions,
>>notifications, etc..  Jelly has a dedicate scheme, but I think we could use
>>a single scheme for all of Jakarta Commons.
>>A bugzilla import will create a single Commons project, but we can then move
>>the issues from the imported project into a new project for each of our real
>>For each TLP, we should probably have a single permission scheme, but I'm
>>not going to get into that argument today.  We can create
>>jakarta-administrator and jakarta-commons-developer groups.
>>	--- Noel
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message