OpenJDK bug database: DRAFT Developer Workflow

[Richard Bair]

>>> However, i think it is crucial to start from what process we want to use
>>> instead of what JIRA can do.
>> 
>> I think what you're getting at here is trying to avoid having the tail wag the dog.  So far, I agree.  But I think trying to do either without thinking about the other would be foolish.  Yes, of course we should consider what process we want -- after all, the tool is there to serve us, not the other way around.  But to do so without considering *at the same time* what the tool can easily support, that will almost certainly lead to a suboptimal result.  (Starting from what the tool does without any regard for what processes would work for us would be equally silly.)
>> 
>> Processes don't fall from the sky; they are compromises between many forces (such as what we've done historically, the temperament of the people involved, industry trends and fashions, what we were most recently burned by, etc.)  To pretend that the ability to represent the process easily in the tools available is not a consideration is unrealistic.  Instead, we have to seek a balance between "what would the process look like in an ideal world" and "what is easily expressible in the tools available to us."
>> 
> Absolutely, we need to consider to what tool can support.
> It just seem we are too focused on "how do we customize" JIRA and this does not seem to help us to ensure we will have good process in place?

Totally agree. I think what we need is a solid set of requirements and an understanding of how the entire system is designed to fit together before we can really have a productive discussion as to the relative trade-offs of customization. If we really have to, we should, but we should be willing to adjust process to match the tool as well.

Cheers
Richard