OpenJDK bug database: DRAFT Developer Workflow

[Igor Nekrestyanov]

Rich,

thank you for your comments.

I agree we might be getting lost in the details and not advocating for 
custom extensions of JIRA.
I also believe that nailing down process first is important and for me 
JIRA is just a tool we use to automate the process
(things like state names are minor details).

IMHO, it make sense to define an ideal process, then evaluate how this 
can be implemented using JIRA
- what can be done with out of the box, what need custom extensions and 
in later case may be simplify process a little to match JIRA capabilities.

However, i think it is crucial to start from what process we want to use 
instead of what JIRA can do.
It does not mean we should start from bugster or should not look into 
default JIRA workflow.

But it make sense to look into this from not just release team perspective.
Other parties (dev teams, sqe, re) will also be using same tool.
And having simple UE for release team at the expense of "custom" 
solutions for others does not seem right to me.

Whatever process we decide to stick with we need to play by it rules.
And for this it make sense to have mechanisms to "enforce" these rules 
and not just at the end of bug lifecycle.
During bug lifetime bug is transferred between different owners (dev, 
sqe, re, etc.) and it make sense it to ensure its state is consistent
when control is moved to other team.

Few comments below:
>> 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.
Right, it is not JIRA issue. It is process issue.
>   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).
I understand the motivation and fears.
I am just saying it does not seem to work well in the areas i can 
observe it.
>
> 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.
Sorry. I did not mean to use this argument to advocate for "Cause Known" 
state.
I was trying to illustrate why current setup is not perfect using this 
as example (one of).

Totally agree that priority need to be adjusted first.
In bugster this used to be responsibility of initial evaluator who was 
triaging incoming bug to adjust priority and assign responsible engineer.
Responsible engineer could tweak it further.

In current JavaFX JIRA setup all bugs are assigned to some engineer but 
they do not look any different from what he has on his plate otherwise.
Makes it harder for for him as well as others to see if we behind on 
dispatching bugs.
And it gets annoying when someone need to cover for initial evaluator 
who might be on vacation.

Again these are just examples of pain points. I am not sure what would 
be best way to simplify and yet enforce the process.
>
> . 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.
Yes, i agree they are not much useful for person who reported the bug.
But they are useful for dev teams in case when work on the fix need to 
be postponed till later.

E.g. fix is ready but is to risky for this release. Fix need to wait for 
something else to happen first, etc.
This helps to separate issues where work is needed comparing to where we 
are blocked on something else.

Another example from real life i am dealing with right now.
We have batch of 20+ bugs to be resolved for next release and we need to 
come up with plan.
For this we need to evaluate bugs first to understand the root cause of 
the problem and estimate time to fix.
Some bugs are easy and can be fixed at the time of evaluation but for 
most it make sense to separate this.

To easily track progress in the dashboard we need a way to quickly find 
out whether evaluation is done for the given CR.
In bugster we use cause known or fix understood state to separate them 
and it helps to get grand view of the state easily.

We are using custom labels in JIRA but this is somewhat inconvenient for 
the team efforts (harder to ensure proper labels are used).
>
>> 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.
I understand release team goals but i think JavaFX view is simple 
because for JavaFX 2.0 bug backlogs were reset.
For JDK there are bugs open for 10 years, assigned to some engineers and 
might have numerous comments/votes to fix them.
Yet they stay in low priority and nobody look at them recently.

Priority is often decreased to get bug from release team radar as it 
deemed to be not important at this stage of release.
But priority does not necessary will be reconsidered for next release.

Moreover, by default all bugs are filed as P4. Meaning that if engineer 
did not really bother to adjust priority first time
(and this is often the case because in JIRA to adjust priority you 
actually need to click EDIT and to change state you can simply chose 
command in the menu)
then it is not on release team radar regardless of how critical is it.

Perhaps it will help if bugs will be filed without priority assigned and 
priority need to be set by initial evaluator.
Not sure if JIRA can enforce it.

Anyway, my main plea here is make process not just release team focused.

-igor

>   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