OpenJDK bug database: DRAFT Developer Workflow

[Richard Bair]

> If we "complicate the entire system" (I'm not sure it does), at least we could have a uniform view for all bugs for all engineers.

That is exactly what I am arguing against. It own't be uniform. Some engineers will use the states, others (like me) won't. Others will use additional criteria (have I written tests? have I updated the javadoc? Is this bug against a specific control?).

I think there is a much larger issue though that we're not discussing. We're talking about the color of paint for the bike shed, but what we should be asking is, why are we painting the shed? I think we first need to have agreement that it is critically important that we limit the number of changes we make to the standard JIRA. Every change introduces costs.

JIRA has an ecosystem, including additional Atlassian tools such as FishEye, Confluence, and Crucible. There are IDE plugins for NetBeans, Intellij, and Eclipse which talk to JIRA. There are plugins to Hudson which talk to JIRA. There are many, many developers who are accustomed to using JIRA either at work or in other open source projects. When we customize JIRA, we have to balance those customizations against the damage we do to interoperability with these other tools.

Even more important is upgrading. We don't want to spend months and many hundreds of thousands of dollars to upgrade from one version of JIRA to another. When the next version of JIRA comes out and has some great new feature we want to take advantage of, we'll be out of luck if we've done too much customization. The most stock-and-standard the easier it is to maintain and the easier it is to leverage the work being done by Atlassian and others.

The closer you can stick to a standard install, the easier and cheaper it will be to interoperate with everything else. We lose all the benefits of "off the shelf" and gain all the headaches of custom-rolled the more customization we do.

I think we're making a very big mistake by looking at JIRA from a bugster point of view. Instead we should be asking ourselves "how would I solve this problem in JIRA" rather than "how can I customize JIRA to fit my existing process".

In addition, I don't understand how we can have a productive debate over bug states without having some larger document available which describes the entire process and workflow. At the very least we need a wiki with all of the requirements that have been gathered so far. Igor raised a very good point about "how do we enforce that tests have been written?". Do we? Do we further customize JIRA? Do we just use tags or comments? Sub tasks? The answer to those questions depends on the design center -- is it "how do we solve this problem using JIRA" or is it "how do we customize JIRA to solve this problem".

I would suggest that the first question is the only one we should be asking. Only in the last extremity should we resort to customization, and then only where it is very easy to do so (and granted, states is a relatively easy thing to customize which *hopefully* works well throughout the rest of the JIRA ecosystem, but I wouldn't be terribly confident of that).

What we should do however is to lobby Atlassian for whatever bugs or features we want built into JIRA and then streamline our upgrade process so that we can always stay current with the latest and greatest. If it takes a herculean effort to upgrade, then we're soaked. Instead, make it easy to upgrade and get solutions at the source rather than do a lot of our own modifications down stream.

There are things about JIRA that I would do differently if I were building my own bug database. But as I see it, we shouldn't be in that business.

Now, to get back to Iris' initial proposal. The first thing that other people have mentioned as well is that the names of the states are odd. In particular, "Dispatched" is an odd name, as is "Accepted" for reasons pointed out previously. The JIRA names are better but not perfect: "New" and "Open". (I guess they use "open" because it is the opposite of "closed" and there is a closed state. But personally I liked "Dispatched" better that Georges suggested. However, since this does not pass the bar I've set above about only customizing JIRA in the most extreme cases, so I would say, leave it as "Open").

"Understood" is a bone of contention, obviously, so I'll skip it.

"In Progress" already exists in JIRA, so that is OK. I've not seen anybody use it the way it is described here -- it is actually rarely used. Most people just start working on an Open bug and then change to Resolved when they finish. I tend to use "In Progress" just to make it easier for me to see the list of bugs I am currently working on in my Dashboard. Some folks also find it useful as a way to let others on the team know they are actively working on an issue and so nobody should try to take it from them.

Then we have "Resolved" and "Closed". Resolved is a state you get into when you, the developer, decide you will not fix it, or you have fixed it, or it is a duplicate, and so forth. The "Resolution" is a sub state if you will which indicates the list of reasons. I honestly haven't had any qualms with the set of choices JIRA provides us on JavaFX (I assume these are the out of the box choices, but I'm not certain).

I don't really see "Not accepted" or "Not our bug" or "Future Project" as being useful (in fact, Future Project is weird. Why not just adjust the fix version?)

SQE then moves bugs from Resolved to Closed when they have verified the bug. This is the true terminal state, and no changes can be made to the bug without reopening it. Sometimes this is lame (like when you want to make a previously internal bug public or remove some tags) but 99% of the time this is not a problem at all.

I guess what I'd rather see is an argument as to why we have deviated at all from the stock and standard JIRA. There are probably good reasons, maybe even great ones, but I'd like to see those. Instead it seems too much like we're arguing why we have deviated from bugster, which I think is exactly the wrong question to ask.

Richard