geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [DISCUSS] JIRA description text template for bug fixes
Date Sun, 16 Jul 2006 06:18:07 GMT
Adding the fields so that they only show up for Geronimo Bugs is simple 
enough.  I can help.  BTW, what about our RTC state discussion?  Can I 
go ahead and move on that idea?


Regards,
Alan

John Sisson wrote:
> I'm fine with using fields instead, as it would be more work for 
> developers to use the wiki syntax (especially if they aren't familiar 
> with it).  The main thing I'm trying to push is to have the 
> information there.  I'm not so concerned how it looks.  The only 
> downside I can see with separate fields is that if someone wants to 
> search for a string AFAIK they now would have to search in multiple 
> fields.
>
> Any idea how much work would it be to add new fields?  Note that these 
> new fields only make sense for bugs, not enhancements. Can we do this 
> without infra's help?
>
> Here are the "proposed" fields for discussion.  I have removed the 
> Problem field, as it probably doesn't make sense to have both the 
> existing Description field and a Problem field in the issue.
>
> Description
>     A short description of the problem that is being fixed. (not sure 
> if we can have the usage text shown under the field differ based on 
> the issue type?).
>
> Symptom
>    A description of the erroneous behavior. How does the user know 
> that they've hit this problem?
>
> Cause
>    A description of the underlying defect which causes the symptom.
>
> Solution
>    Overview of how the problem has been fixed.
>
> Workaround
>    Techniques that can be used to avoid the problem, to minimize its 
> symptoms, or to repair damage which has occurred.
>
> I am planning to document JIRA usage on the Wiki as part of 
> GERONIMO-2080, so the use of these fields would be covered in more 
> detail (e.g. example text).
>
> Comments?
>
> John
>
> Jason Dillon wrote:
>> I think if we want to get folks to give us these sections of data 
>> that we should probably add fields for them to fill in, not ask them 
>> to use a wiki-based template.
>>
>> --jason
>>
>>
>> On Jul 15, 2006, at 6:51 PM, John Sisson wrote:
>>
>>> Are your concerns about it being *way* to much related to the use 
>>> wiki markup which you feel may be unproductive (not easy to use) and 
>>> your solution to that is the suggestion of adding  new fields, or do 
>>> you think it is *way* to much because  one would have to take more 
>>> time thinking about and documenting a fix?
>>>
>>> Thanks,
>>> John
>>>
>>> Aaron Mulder wrote:
>>>> The issue in question looks great, but I think asking everyone to use
>>>> a specific format within their description is *way* too much to ask.
>>>> If you want to propose some fields be added (such as symptom and so
>>>> on) that would be better, but they'd have to have some descriptive
>>>> text so people could tell what to put where.
>>>>
>>>> Thanks,
>>>>    Aaron
>>>>
>>>> On 7/15/06, John Sisson <jrsisson@gmail.com> wrote:
>>>>> What does everyone think of adopting a format similar to what I have
>>>>> used in http://issues.apache.org/jira/browse/GERONIMO-2194 for JIRA
>>>>> issues for "bug fixes".  I expect we would use a different format for
>>>>> enhancements.  I got the idea from Derby's wiki  page
>>>>> http://wiki.apache.org/db-derby/ReleaseNoteFormat .
>>>>>
>>>>> When a JIRA for a bug is closed, we should ensure it's description
>>>>> generally follows that format.  When a new JIRA is created, it 
>>>>> should be
>>>>> just a matter of copying some template wiki markup into the issue.
>>>>>
>>>>> Following the format would have the following benefits:
>>>>>
>>>>> * Makes developers think about the information that other
>>>>> users/developers would want to know about the problem
>>>>> * Helps users who searching for problems reported with the release 
>>>>> they
>>>>> are running to get a better understanding of the issues with that
>>>>> release and whether there are any workarounds to get them by until 
>>>>> the
>>>>> next release.
>>>>>
>>>>> If people are happy I'll add a wiki entry about the format.
>>>>>
>>>>> Regards,
>>>>>
>>>>> John
>>>>>
>>>>
>>>
>>
>>
>


Mime
View raw message