Absence of a component could be avoided if we could remove this option from the user that enters the report (so there is somebody assigned to it, even if it is the wrong person) but it doesn't seem possible in JIRA. I don't think it is bad to have unscheduled reports, as long as there is periodic review to schedule tasks. It is equally bad to use the next release as a dumping ground and move around deferred tasks from release to release. I totally agree proper/periodic review is needed to categorize the importance of tasks. There was a proposal by Andrig to do this monthly but we didn't follow up properly. > -----Original Message----- > From: jboss-development-bounces(a)lists.jboss.org > [mailto:jboss-development-bounces@lists.jboss.org] On Behalf > Of Adrian Brock > Sent: Friday, September 22, 2006 5:56 PM > To: jboss-development > Subject: [JBoss-dev] House keeping in JIRA - bug reports > > Until JBoss-4.0.4 I made a regular check of JIRA using two > queries. After that release as an experiment I stopped doing > it to see what kind of state we would be in by the 4.0.5 release. > > Bugs without fix versions: > http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hid > e&requestId=12310183 > > All bugs should either be > * assigned to the currently being worked on release > * deferred to a later release > * closed as not bugs or incomplete description > > Bugs should never be left unscheduled. > > Bugs without components: > http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hid > e&requestId=12310202 > > Which probably means that nobody has even looked at them. > > It is very important that for each release we have analysed > all bugs and decided their importance. > > 61 bugs that are not scheduled (i.e. importance undetermined) > 11 bugs without components (not even validated at the most > basic level) > > is not good! > > Just choosing one at random (the oldest one with "affects > 4.0.4") falls into both categories. There is no evidence it > was ever looked at: > http://jira.jboss.com/jira/browse/JBAS-3406 > It was raised on the 20th of July (over two months ago). > > Obviously, the user doesn't consider a MalformedObjectName > exception as telling him the format is invalid nor has he > read the javadoc for that class which links him to valid > query formats. :-) > > So this is obviously a trival "user friendly" bug where an > invalid name should forward to a page explaining the > ObjectName format. > -- > xxxxxxxxxxxxxxxxxxxxxxxxxxx > Adrian Brock > Chief Scientist > JBoss a division of Red Hat > xxxxxxxxxxxxxxxxxxxxxxxxxxx > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

On Fri, 2006-09-22 at 12:31 -0500, Dimitris Andreadis wrote: > I don't think it is bad to have unscheduled reports, as long as there is > periodic review to schedule tasks. It is equally bad to use the next > release as a dumping ground and move around deferred tasks from release > to release. > > I totally agree proper/periodic review is needed to categorize the > importance of tasks. There was a proposal by Andrig to do this monthly > but we didn't follow up properly. The correct time to check all bugs have been diagnosed is on releases. They are either dealt with or deferred. There should be no unscheduled bugs. There should be a plan to fix it.

On Mon, 2006-09-25 at 10:40 -0600, Andrig T Miller wrote: > The idea behind this is to keep releases from filling with > everything, and them not getting reviewed. When things are directly > assigned to releases, everyone just assumes it should be done, and > there is no review. By having them initially unscheduled, and > instituting a mandatory review, we can intelligently assign them to > the proper release with the proper priority. They shouldn't remain in > unscheduled for any length of time. > Before we did this, releases just grow in scope unchecked, and we > cannot continue to do that. You can't fix the problem of bugs not getting reviewed by hiding them under the rug. :-)

Assigning to a release, forces somebody to remove them from that release. So they are least looked at.

Where this failed before, is that they had no assignees. So Dimitris just bumped to the next release without pinging the assignee to tell them to "to pull his finger out ..." :-) If don't want to assign a bug to release, e.g. it is too complicated to fix in the near future there is a "No Release" dummy version. But doing this, will probably lead to them getting forgotten about!

On Thu, 2006-09-28 at 13:08 -0600, Andrig T Miller wrote: > Having them unscheduled doesn't hid them under any rug. They are > just as visible in JIRA. And just as unprocessed as when we used sourceforge and nobody was trying to monitor the problem. > > > > Assigning to a release, forces somebody to remove > > them from that release. So they are least looked at. > > All it really does is force someone to go into JIRA and change > the fix version, not to actually evaluate the issue. > That just comes down to how good a project lead you are. If you are continually bumping problems to the next release then we have to ask what are you doing? > To really solve this, is we need a formal review process. It doesn't > matter whether something is assigned to a release or not. We have to > have formal, mandatory review as a team. I'm a great believer that you cannot replace human intervention with automation when it comes to effective management.

But the person that manages things needs to have reasonable metrics. Forcing people to go through a process of review (even if it is just bumping it to the next release) gives an indicator of how much on top of the problems we are.

Rather than the current situation, where we don't have a clue what is getting reviewed, because according to JIRA it is nothing!