OpenJDK bug database: DRAFT Developer Workflow

[Iris Clark]

Hi!

> > I personally don't think that two parallel JIRA instances will be 
> > particularly useful. They will be just a constant cause of confusion.
> > Because eventually you'd have to transfer bugs from the "end-user" bug 
> > system to the "real" bug system. And even if you'd somehow manage to 
> > keep the bug ids unique between the two systems, you would still have 
> > two systems with all the drawbacks:
> > - which system to search (before entering a new bug)
> > - in which system to track the bug
> > - you'll have to keep the bug content in sync between the two systems 
> > (otherwise, if you just move the bug from one system to the other, 
> > links to the original bug won't be valid any more)
> > 
> > So please stick to one system if possible. You could for example just 
> > introduce a new state "UserBug" in the workflow which comes just 
> > before "Dispatched".
> 
> Currently there is a system (web-bugs) for handling bug reports from end
> users.  Most of these are not developers.  Most have no idea what information
> is needed to track down an issue.  There are millions of these reports that
> come in each year.  Many need more info. Many are duplicates.  Many are not
> even bugs.
> 
> Every once in a while something really really important comes through this
> channel, however.
> 
> IMHO - we want end users to be able to file reports, but keep them separate
> from the database used by development.  We want the OpenJDK community to be
> able to help triage and respond so that it is possible to scale the way we
> deal with these and not miss real and important reports -- but get these
> swiftly and smoothly transitioned to the development JIRA project.

While I understand the desire to have a single JIRA Project for all bugs
regardless of their source, I'm not confident that that is very feasible given
the nature of typical end-user-submitted bugs.  Even with the hints we
provide during submission (i.e. explicit request for "Steps to reproduce",
"Expected Result", "Actual Result", etc.), we still get problematic reports 
as Georges indicates above.

I don't think that one or two statuses tacked on to the beginning of the
Developer workflow will be sufficient.  I'm also concerned that by having all
of these end-user bugs within the same JIRA Project, we'll introduce a
degradation in our ability to manage the main developer workload.

Thanks,
iris