OpenJDK bug database: DRAFT Developer Workflow

Wed Jan 4 21:28:42 UTC 2012

I kind of agree with Phil here.
I am following existing Jira rules for JavaFX because it is existing 
process and there did not seem to be easy way to change them
(from my experience even simple Jira config changes were taking long 
time and often never happen).

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.

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.

 >  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.

What is the problem to have some optional states (with well defined 
semantics)?
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?
How to distinguish between issue nobody ever tried to fix and one that 
can not be fixed until something else happens?
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.
We use keywords in bugster but it is fragile and almost impossible to 
enforce.

-igor

On 1/4/12 11:34 AM, Richard Bair wrote:
> It sounds like you could make use of the tags as well. But I don't agree at all that it "sucks big time", and I have certainly not heard this complaint from anybody else. So yes I agree it is a personal opinion, 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?
>
> Richard
>
> On Jan 4, 2012, at 11:23 AM, Phil Race wrote:
>
>> I've not read the entire thread on developer workflow (I've got thousands of emails to
>> read after being out a month, but  I beg to differ on this point at least :
>>
>>> To give even more context to this, we haven't missed these sub states at all in JavaFX.
>> Don't make it sound as if that's a univeral view because its not. Its a personal opinion
>> and here's mine :
>>
>> The Jira config we have on FX sucks big time. When I've complained I'm told its
>> because we use it more or less out of the box. I hope we don't repeat this mistake.
>>
>> I find states other than "open" to be invaluable in bug management, particularly as an engineer.
>> Maybe some people see no problem with a big morass of "open" bugs but I feel proper bug management
>> needs more than that. And I do not have time to re-read the commentary of every bug in my queue to know
>> which ones I evaluated  etc. ( evaluated in the sense of "cause known" and "fix understood), not
>> just "triaged". Instead I can sort by state.
>>
>> -phil.
>>
>> On 01/04/12 10:36 AM, Richard Bair wrote:
>>>> [snip, snip]
>>>>
>>>>> I don't see how asking a question relates/compares in any way to having clearly defined states like "cause known" or "fix understood". And of course you never know ALL of the implications - "fix understood" doesn't imply absolute knowledge of every nuance, just as actually fixing the bug doesn't imply you know ALL the implications of the fix you've committed.
>>>>>
>>>>>
>>>>>> Management would be much better served by updated estimates and risk
>>>>>> evaluation. I've yet to meet a manager who, deadline looming or not,
>>>>>> would make a decision to commit-to-fix or reject a bug based on these
>>>>>> states.
>>>>>>
>>>>> The states convey initial information used to discuss estimates and risks pertaining to the bug. If every bug is just "accepted" then the discussion has to start with "where are with this bug? do we know what's causing it? do we have a fix?" instead of "I see the fix is understood, what do we need to do before pushing it? Is it a high or low-risk fix?"
>>>>>
>>>>> Just my opinions - YMMV
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>> After countless hours (maybe years!) of conducting bug review meetings, my experience is that *every* bug has a story.  Nobody is content to describe their work as "fix understood" or "cause known".  And without the story, reviewers can't make useful decisions about risks, rewards, estimates etc.  The story is (or should be) captured in the commentary and it must be read.  I can't think of any useful decisions that an RTeam or Eng. Mgr. could make simply by looking at a "cause known" or "fix understood" status.
>>>>
>>>> Perhaps these statuses are useful for individual engineers to sort their bugs, but I don't see them helping any of the management functions.
>>>>
>>> To give even more context to this, we haven't missed these sub states at all in JavaFX. Most of us are ex-JDK developers, but in JavaFX we have been using JIRA for 3 maybe 4 years now. The states we have are:
>>>
>>> 	New
>>> 	Open (Not my favorite term)
>>> 	In Progress
>>> 	Reopened
>>> 	Resolved (Engineers resolve)
>>> 	Closed (SQE closes after verification)
>>>
>>> There are a couple others in our JIRA system, but we don't use them. To be honest, I've not found a great deal of utility out of Reopened either, but it hasn't complicated my life much so I'm OK with it.
>>>
>>> Then there are a number of different "Resolutions" which indicate how we resolved it.
>>>
>>> 	Fixed
>>> 	Won't Fix
>>> 	Duplicate
>>> 	etc etc
>>>
>>> The only piece of information that we've felt pain over not having, is "Fix Available" or some other method for tagging the issue with what repo the fix is available in. I'd prefer not having a state for this, but just tag the issue (so it is still searchable), and have the tagging done automatically when an issue is pushed into a repo.
>>>
>>> As Brian said, I don't see any value from a bug court or release team perspective in having more states or sub states, and as an engineer I wouldn't ever use them. However as an engineer, if you find them useful, you can make use of the custom tag feature in JIRA and keep this additional information in a way that is easy for you to query and understand. Likewise if a team decides they want additional categorization (for example, in the JavaFX UI Controls team we would add a tag ScrollPane for any issues involving the ScrollPane control, etc, and a single Issue might affect multiple controls and so forth), then that is perfectly reasonable as well. But from a higher level release team perspective and from a don't-overcomplicate-my-life perspective and from a universal-process-decision perspective, I much prefer just having a short list of states.
>>>
>>> Thanks
>>> Richard