OpenJDK bug database: DRAFT Developer Workflow

[Richard Bair]

Hi Igor,

I think actually we're getting lost in the details and losing sight of the bigger picture. However, I wanted to provide answers to some of the questions you raised. But in the end I think this topic itself could go on forever, so there probably isn't much use in too much back and forth on it.

> Current setup works but IMHO it is far from being perfect.
> E.g. people on my team often bugged to make sure their bugs are "properly" moved out of the "New" state and this often seem to mean nothing.
> To comply to the "bugs need to be properly marked soon" engineers have to move them to the "Open" state without spending any time on evaluating them.

> The only difference between New and Open state for me is that engineer who gets all the bugs assigned by default can triage what's new and what he need to
> distribute between team members. But then it make sense to tag bug differently once real responsible engineer is assigned
> and it does not seem to be inline with definition of "New" state discussed here.

This is not and issue you have with JIRA, but with the desire of the release team to have an accurate view of the priority of a bug within a short amount of time from when the bug is filed. Again, to be clear, this has nothing to do with the number of states or what their names are. Even if you had a "Cause Known" state, it wouldn't do anything to resolve this.

For those not familiar, one of the great fears in the release team (especially as we get close to a release) is that there will be some critical bug that we don't know about because the bug has not been triaged. So there is an SLA to make sure all bugs are triaged shortly after they arrive, especially as we get close to a release. Triage simply means, looking at the bug to determine: is it a duplicate; who should it be assigned to; is the priority correct; is the bug targeted at the correct release; is the issue type correct (bug vs. feature).

This should all be possible to do up front with little work. The actual bug priority may change after further evaluation, but the first approximation can be made rather quickly.

An additional "Cause Known" state doesn't help this. We would still expect that the above state on each issue is accurate after it has been "Triaged". In any case, since the primary reason for requiring triage is to determine the priority, if determination of the priority didn't happen until after "Cause Known" you would be required to get it to "Cause Known" within the SLA. So this point you mention really is orthogonal.

> In my experience we end up with all bugs to be fixed in the same "Open" state (and very rarely "in progress") and it hard to see if anything really happened to them
> from looking to the list and not reading comments.
> And in our area we often have external dependencies and situations when bug is "cause known" but can not be fixed until dependency is resolved, etc.

You can view the date on the bug to see if progress has been made in any recent time. "Is somebody working on my bug" is actually not something I really care about, as much as "is my bug going to be fixed for the next release? If not, which one?". Somebody who files a bug will get notified when comments are added or progress is started or stopped so they'll know. Somebody who is just lurking can look at timestamps. And anyway, Cause Known and Fix Understood are both pretty useless to the person who filed a bug. All they really care is, will my bug be fixed? And neither of those states help.

> >  but with tags you have the liberty to categorize your bugs in any way you see fit. Why should we complicate the entire system when for most people the current states are sufficient?
> 
> We are using tags but they are too weak as it is much harder to enforce them and harder to use in queries.
> Having explicit states seem to be helpful. E.g. i can guess what is the state of bugs in the other team queue without reading
> through comments or learning their private keyword-based solution.

You can guess, but that is all. Unless you are going to have the organization force the accuracy of these bugs, then you will never have anything more than a guess, and probably not a very reasonable one at that. In fact, the notion that these values will be reliable is the very thing I'm arguing against. I think it is bound to be inaccurate on a macro level. The only way it means anything is to the individual engineer or team according to whatever rules they have established internally. And at that level, a label (tag) works great.

I do agree that tags are difficult to enforce and not something that you really want on the macro level, but they work great at the micro level. My argument is that Cause Known and Fix Understood are not important at the macro level and for many engineers they aren't useful at the Micro level either. For many others they are useful at the micro level. So that implies they should be tags and not states.

Every time we add a state or customize JIRA we pay a penalty.

> What is the problem to have some optional states (with well defined semantics)?

The problem is that optional states lie. They tell somebody that there is some meaningful information there, but if they are optional, then they really don't contain anything meaningful. Put another way, if used, they convey meaningful information, but when not used, they don't tell you anything.

But it is actually much broader than that. I will send another email with the real issue (hint: we're just talking about bike shed paint color, the real question is why are we painting at all?).

> You still can go from Open to Resolved if your fix is ready immediately.
> But what if you know what needs to be done but you need to wait month for dependency to be in place? Keep bug in the Open state?

Yes, and establish a depends on relationship between your bug and the one you depend on.

> How to distinguish between issue nobody ever tried to fix and one that can not be fixed until something else happens?

There is a dependency there. In any case, the release team doesn't care. From the release team perspective (on JavaFX anyway), all we care is how many P2 and P3 bugs are we deferring to the next release, and should we slip the date instead. That is the main function. Fix Understood and Cause Known are not useful in determining that information. We have to go through each bug and understand the implications before deferral. So we have to read the comments anyway. So the only implied person in your question must be the engineer or engineering manager, and you're so close to the bug that using labels or some other technique works just fine.

> IMHO, it is important to be able to quickly identify former to prevent "lost from the radar" situations.
> 
> Another thought is - any way we can have explicit way to specify regression test(s) associated with given issue?
> And if test is not provided reason for it. IMHO, bug should not be allowed to be in the Resolved state without this info.

The enforcement in JavaFX JIRA comes at time of closing. A JIRA issue cannot be closed until there are tests provided or SQE verifies. As such, the resolved but not closed issues are an indicator that something isn't done with the bug (regression tests are just one problem, documentation might be another).

Cheers
Richard